Your ESB ate my SOA

Over the past weeks I have been pulled into quite a few debates about SOA and, more specifically, about the “right” way to do it. And the definition of “right” gyrates alarmingly often towards the application of an ESB.
Every new computing trend elicits debate and any sizeable debate provokes vendors to aggressively position their –often already existing– products to take advantage of the customer’s interest in the hot, new trend. Of course, the energy pumped into ever inflating expectations inevitably finds a way out in the guise of confusion and disillusionment. The vendor hype surrounding ESBs has been especially effective to the extent that organizations that want a quick-fix solution (and don’t they all?) are sold on the idea that an ESB is the yellow brick road to “instant SOA”.
Here’s the gentle introduction: an ESB is not an essential part of SOA. Actually, leave any product in their glitzy shrink-wraps for now: SOA is about analysis and design, and not about technology.
Of course, there are a few basic components you’ll probably want to use get kick-started. But an ESB is not one of these “basic components”; in fact – and here comes the shocker to some – you should absolutely not use an ESB when starting with SOA because an ESB does not encourage good SOA. ESBs are integration solutions and integration solutions reinforce application silos while SOA is about tearing down those silos.
An ESB is a useful component in a services infrastructure as it is especially good for bridging to legacy applications. Many ESBs also support reliable messaging, asynchronous messaging, and several message exchange patterns, which are all useful capabilities — just not in the initial stages of a SOA project. To put this in perspective, you might also want an orchestration engine at some stage in a SOA project — but that too isn’t where an organization should start a SOA initiative. All of this you just don’t need when first getting started; an ESB should be a later-stage purchase.
Some parting words for all of the kind folk that tried to convince me of the essential nature of an ESB by drawing hub-and-spoke diagrams: a bus, by definition, is not a hub but a physically distributed set of federated hubs. It may start out centralized, but as the implementation evolves the infrastructure should allow for more physical distribution. You might want (and appreciate) to keep the bus’ configuration and control centralized however.