Quote from BEA:
The idea that you can buy SOA in a box is both amusing and dangerous. Thinking that you could buy a piece of software, install it, and then say you have SOA is the amusing part. The dangerous part is what might happen to your job once you install the software and people start to realize you are nowhere near having a service-oriented architecture.And BEA continues:
The reality is that before you can implement an SOA, you’ve got to lay the groundwork: a service bus where your services will managed, a service registry for identifying services, a security framework to manage access to your services, a solid understanding of your business processes, an enterprise architecture showing your eventual goals, and most importantly, executive sponsorship for your project. Putting these pieces in place will “service enable” your enterprise and get you ready to start implementing your SOA.BEA is not the only one who says so. And BEA, among all others, forgets the most important part along the service registry: a business events registry - which is one of the most important keys to the success of SOA. Why did they forget to mention this part? Probably because they don't offer it in their product portfolio (but I may be wrong on this one).
All true I would say. But... what about ERP-vendors like SAP? SAP offers a service bus, service registry, events registry, canonical data management, business processes, services deployments (!), business monitoring, business process management, security... out-of-the-box. Yes, of course the implementation must be tuned and configured. But it's all there, out-of-the-box. The difference between infrastucture-vendors and ERP-vendors like SAP is that the infrastructure-vendors are trying to sell infrastructure to the business whilst ERP-vendors are selling business solutions to the business. Who do you think will win?
I think mid-size companies that fully rely on ERP-solutions will be the first companies with a full-fledged SOA in place. The big enterprises relying on custom development will need much more years to reach the same level of SOA maturity. They might benefit from a kick start by building their SOA around one or more open SOA based ERP-systems that are positioned as dominant business solutions at enterprise level. If they don't, the big enterprises will all get behind on their smaller competitors with regard to vital IT-maturity within the years to come.
So the idea that you can buy SOA in a box might turn out not to be as amusing as the infrastructure-vendors want us to believe. It might even turn out to be dangerous to ignore the idea. Building an unpopulated SOA infrastructure from scratch, as the infrastructure-vendors are promoting, might in the end turn into a big mistake.
Posts
4 comments:
It's a difference between knowing the game and playing the game. SAP knows the game, but ...
Playing the game means being part of an enterprise SOA (be part of the team), not running around on all positions on the field. An ERP SOA will not, can not, and doesn't know how to replace parts and resources within a SOA. ERP systems are not team players ...
Hi Jonas,
Reading your comment I get the impression that there lives a misconception of current maturity of "some" ERP-vendors. These vendors also know what is going on! I would advise you to study the big players more in-depth.
By the way, this was not the subject I wanted to stress. What I wanted te say is that current innovative ERP-vendors will help you more and quicker in realizing SOA then the native infrastructure vendors will. Some ERP-vendors sell complete SOA business solutions: tools, templates, infrastructure, services (including deployments!), business processes and guidelines. I think it will help you in a great way to get of the ground with SOA.
And believe me, I know how to play the game. And I think SAP knows to play the game better then most infrastructure vendors. Let's talk again in an odd three years. ;-)
Jack
TFEM
Good luck ... jack |
I think you stand on the boundary between two different realms, allowing you to see both... and that gives you a rare but valuable perspective that others may not understand well.
The ERP vendors were faced with integration challenges just like everyone else. The difference is that they had to answer the question with the same measurables that we now apply to SOA. They had to develop an integration layer that would allow for a wide variety of integration possibilities, because they were selling their wares into companies with wildly diverse environments, and those ERP systems had to cope with huge variability.
So the ERP vendors created PROPRIETARY integration platforms that were very versitile, but which required specialized people to use them. A community grew up around those specialized skills, and it broke off from the rest of "business service IT". These folks needed different skills and they spoke a different language.
Now, in the SOA realm, we see infrastructure vendors who learned about the integration layers developed for ERP and other systems, and those vendors are trying to sell the integration bits to companies. That is great, but you and I know that the things that made the integration layers work, in ERP tools, were not the technologies.
This is proven by Netweaver. SAP has, over the course of years, replaced their older integration layer with Netweaver, in a move towards open SOA.
Netweaver is, by itself, just another integration engine.
But the thing that makes it work is the consistency of the information model, the uniformity of the business events model, the 'defined by the product' partitioning model between different modules, and the consistently applied data process flow model that informs and constrains the flow of information on the basis of business processes.
These things cannot be purchased out of a box. These things must be developed with full awareness of the "things you are integrating." ERP vendors have the luxury of this awareness.
I am trying to create that awareness through standardization to cross the entire "supporting systems" base of business software.
At the end of the day, we need a consolodation. We ERP systems to use the same integration ESB products as the rest of the enterprise does. (Don't care how that happens). That will force the ERP integration hub to have all the features needed for communication between two parties, neither of which come from the ERP vendor. And it will force the ERP vendor to define the functional partitions between their modules in a clear and standardized manner.
They have little financial incentive, today, to do that, so this will be a long road.
The convergence will come. If we do our part, it will come a bit sooner ;-).
--- Nick
Post a Comment