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
