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.

Comments (3)

  1. Sander Hoogendoorn - Reply

    January 18, 2007 at 9:47 am

    Good thinking indeed! As always I am tempted to agree with you. However, there is a nice aspect about introducing an ESB - in whatever implementation; as most companies start off by building one themselves. It seems to help people think "in services". For instance, I recently visited a customer who told me that they had just implemented an ESB (using .NET by the way, sorry for that). Now, at this time, no services were implemented yet, but the IT department stood firmly on the demand that every new project should consider releasing there software as services on their ESB. Thus, within reasonable time the customer hoped to get a bunch of services running. On the other hand, projects are required to find out if any existing services match there requirements.
    I agree, this is not a very top-down approach to introducing services, but it is pragmatic and will help organisations thinking in services. So, the ESB is indeed not technically required in a SOA, but might assist SOA awakenings

  2. rswart - Reply

    January 31, 2007 at 11:13 am

    Somehow I get the feeling you are putting all the blame on the ESB. Please let me defend the poor guy (or is it a girl?).

    ESB\'s do not reinforce application silos, it is the way most companies use them: as an integration broker. They just create a hub-and-spoke architecture using an ESB. IMO, an ESB should be a lightweight ‘bus’ by nature. So not an all-knowing centralised nexus surrounded by dumb nodes. A true ESB should consist of intelligent nodes that can act in a distributed (federated) fashion. This also enables a more gradual, evolutionary approach to SOA with tiny, agile steps. I definitely see merit in using an ESB from the start.
    The problem is that some companies rebrand their heavy weight integration broker as an advanced 😉 ESB.

    Another issue I see is that people tend to think that when they use SOAP and WSDL that they are creating a SOA. Many service descriptions (WSDLs) I encounter are so specific that describe an one-to-one interface not allowing re-use (one-to-many), while this one of the promises of SOA (and before that Component Based Development). Here I fully agree with you: SOA is about analysis and design. Where this should be a big up-front design or a more agile approach is another question.

  3. Vincent Partington - Reply

    February 8, 2007 at 11:58 am

    It\'s funny how the Enterprise Services Bus products are not actual buses. Instead they are hubs to which everybody connects. This seems to combat the feared \"point-to-point problem\" but in fact the point-to-point could still exist while being routed though the \"Enterprise Service Hub\" which by then is just a bottleneck.

    See this nice article on InfoQ for some more thoughts on this subject:
    http://www.infoq.com/articles/ESB-alternative

Add a Comment