To ESB or Not To ESB

At a recent Butler SOA strategy seminar (where I banged on again about how to sell SOA to the business, see here), there was the normal range of vendors (IBM, Sun, Progress) and anti-vendors - analysts and consultancies having a go at the vendors (no names, but you know who you are).  Amongst the noise there was the familiar debate/slanging match about the whether an Enterprise Service Bus (ESB) was a product or a concept.

To many bearded ones, this was an important philosophical question. To most of us, it was yet another infuriating part of the whole SOA hype cycle.  Customers praying for a simple answer were disappointed - the analysts and vendors lived to fight another day.  So, for those still unclear on this semantic difference, here is my attempt.

The reason why the answer to this is fuzzy is mainly down to the vendors.  Many of them have called products ESBs, but they don't all do the same thing.  IBM has both an ESB and an Advanced ESB that do things quite differently.  Other companies try to sell you on a complete SOA framework that might include ESB functionality, but not necessarily a standalone ESB.  For example, Microsoft doesn't have an ESB per se - you add together parts of Windows Server, .NET Framework and Biztalk.

But the analysts haven't helped either.  Because most of them have been talking about ESBs for years (and before that Hubs and EAI), they are struggling to find anything interesting to say that will keep them ahead of the vendors.  So most are either talking more and more abstract (Separation of Concerns, anyone?) or producing increasingly long lists of 'must-have features' hoops for the vendors to jump through.  Some of these lists are getting absurd - how many people understand or need Complex Event Processing or Federated ESBs yet?

Which view is right?  It depends on where you currently are and where you need to go.  Most companies already have some of the key ESB functionality in their infrastructure already: Routing and transformation have been around since the world moved from SNA to TCP/IP.  Start with what you have and do a gap analysis based upon potential Service Bus requirements in the foreseeable future.  From here you can plan your journey to ESB maturity - or not, if there is no obvious benefit.

So it is not about whether to ESB or not, or which product is best, but what Service Bus Architecture (if any) will suit your journey.  That is the question.

[Exit Stage Right]

John 'The Ham' Moe