SAO and ESB
All CIO and IT architects always imply that to implement SOA (Service Oriented Architecture) in the entreprise, all what they need is an ESB (Entreprise Service Bus) and make IT developers build a set of reusable services and transformations to allow the data flow form a service to the other. I always found that approach simplistic and could lead to a disaster. This is an article that exactly explains very well my thoughts.
Easy and simplified answers are de rigueur at the moment – and "ESB" is exactly the kind of answer you might get when asking about an SOA. Don’t get me wrong – an ESB is a very valuable and useful component in an SOA set-up. If, however, you think that you are perfectly prepared for setting up an SOA simply because you now have at last got the selection process for your ESB over and done with – then you had better think again.
There is another view – although an ESB does not equal a SOA, it is however at its very heart. While this answer may be incrementally better, it doesn’t quite capture the essence of what an SOA really is: an SOA’s main task is to chop up the IT world into small tidbits. These tidbits are designed in line with the individual wishes of the specialist departments, correspond to industry standards and can be combined to form new processes and applications. They have to communicate with each other, exchange information, transform it and then forward it securely. There is also the need to link these tidbits with larger ones, bringing us to the topics of orchestration and composition. And this is where an ESB can actually be of help.
The question is, however, how do you decide on which tidbits? Who tells IT what the business requires and who tells the business what is feasible for IT? And who tells you whether the various tidbits are yet to be deployed, as originally planned? It’s now no longer a case of using middleware: it’s a question of how we deal with the actual development process of services, which leads us then to SOA management and governance. It is impossible to develop services that are worth being wired via an ESB, unless accompanied by processes that go beyond the borders of individual departments. The heart of an SOA is, therefore, more to be found on an organisational level – reinforced by the principles and best practices involved in SOA governance. Once these processes have been understood, then an ESB really does make sense for an SOA, just as HTTP (Hypertext Transfer Protocol) does for the Internet.
Source
2 comments:
Tried once in a monolithic organisation this approach and failed...Researchers usually avoid the human factor and cost of migrating from anterior application driven architecture to data driven ones. It's true that the benefits are huge but it has to be a company scaled projected and therefore much more complicated to put in practice than a usual service project. That's why simply having an ESB doesn't lead to a successful SOA. From my point of vue, SOA goes only through imposing first of all "best practices" like using xml and open data formats...
I can't agree with you more! Enforcing best practices and changing gradually your IT organization by implementing proof of concept projects, adopting XML data exchange and think component/service/assembly instead of applications and demonstrating their benefits is the right approach, educating your IT teams too. The big the organization is the more challenging is this task. SOA solutions should also take in consideration legacy systems and offer tools that make migration easy. Tooling is what will make or break SOA introduction in IT orgs.
Post a Comment