Let’s talk about when to use an ESB and in what cases a ESB might be an overkill. Review my blog posting from a few days ago about ESB Myths as a pre-cursor to this.
As you probably already know, all SOA vendors and consulting firms will try to sell you an ESB or some equivalent product. Here is a simple rule of thumb that I apply whenever I guide someone on ESB’s. – If this is your first SOA project or some sort of SOA pilot – do not even think about an ESB. Focus on other key SOA issues first – primarily Service Design. This to me is the key to success – getting your Service Design wrong can be the end of SOA or your organization. Help you Architects and Business Analysts drive the culture of Services and how to get their business users think in terms of data, services and re-use.
Often and ESB is an overkill, if -
1. All Services are simple, Request-Response type messages – or rather all messges in your SOA use a single communication paradigm.
2. You have fewer then X services (you can define X for yourself – I use 25 or 50).
3. End points are pretty static; or really there is only 1 type of service for each business function. For example if you have a Product Master system and there is only 1 Service to get information from that system. This would be unlike a typical weather or stock service where if 1 is down, you can select from 10 others. In a scenario where an end-point is static, routing and navigation can be achieved without a directory, or a ESB as easily as if you had one.
4. Most of your Serivces are internal facing – which means the producers and consumers of the Service are pretty static.
5. The actual development teams know each other and can talk as easily across a room or bldg or whatever. Basically this applies to inter-organization services where communication about the interfaces, business fucntions etc are happening between the functional and technical teams. Services are just used as a means to make integration easier.
So, when do you really need an ESB -?
1. Your Services are truly dynamic – the consumers are unknown or they are evolving fast.
2. Elements of your Services are constantly or frequently changing as new customers of the Services come aboard
3. You have a lot of Services
4. Services are integrating legacy business applications with new applications or packaged solutions. More over you need a mix of technologies and communication channels – request/response, pub/sub, reliable delivery, queuing and so on.
5. Basic transformation of messages is required – either to support new customers and/or service versioning
6. Back-end systems are evolving or being replaced – example a business process today has a touchpoint to a legacy mainframe app that is scheduled for retirement as the new system is built
7. Business processes are evolving and changing due to market pressures, M&A activity etc.
Again, the important thing to remember is that you will probably answer yes to 4 or 5 of the above – and that is fine. An ESB does have a role in an SOA, but just not in the initial SOA. Think always about your overall SOA maturity in terms of technology, infrastructure, governance, business maturity, culture and budget. Once you are at some relatively mature state (using any SOA maturity model you choose) – an ESB can add a lot of value.
My key recommendation is to avoid the 100-500K investment (typical of any medium size ESB implementation) till you have already proven the value of your SOA to the dudes with the purse strings.
