Do You Really Need that ESB?

Loraine Lawson

Erik Drnenburg is a software developer who loves to find cool ways to visually demonstrate code and architecture.


Recently, he consulted on a project with a very simple plan-use an ESB to connect two applications. But there were problems. After talking to the project's developers, Drnenburg learned the ESB had created "nothing but pain." Apparently, the ESB had been added based on the "possibility" that it would be needed later.


Drnenburg didn't need a diagram to suspect the architecture might have been driven more by enhancing a resume than an actual business case.


As Drnenburg demonstrates in a recent blog post, the ESB actually introduced way more complexity than the problem needed.


It's an unusual point, and it inspired - oddly enough - MuleSource CTO Ross Mason to write a checklist to help you decide whether you really need an ESB.


MuleSource is an open source ESB, so you wouldn't think the CTO of the company would want to deter people from buying one. But, Mason realizes technology often takes the rap for project failures:


"This is a fairly common problem for ESBs and other enterprise technology like BPM/BPEL where the technology is not chosen for the right reasons and then the technology gets blamed when the project struggles. Given that much of the enterprise software disillusionment today stems from the incorrect usage of the technology I thought I'd offer some rough guidelines for selecting an ESB."


Dana Gardner of BriefingsDirect picked up on the post, and interviewed Mason about his checklist. Mason explained the two most common mistakes he sees with ESBs:


  1. An insufficient integration requirement
  2. Not enough use of the ESB features to warrant its deployment


As Mason notes in his post, if you're only connecting two applications, it'll be easier to just use point-to-point integration-even if you think you might need to add applications later. He adds in the Gardner interview:


"If you select an ESB because you think you might need it, you definitely don't have an architecture that lays out how you're going to use an ESB because you haven't given it that much thought. That's a red flag. You could be bringing in technology just for the sake of it."


A few other obvious times to skip the ESB:


  • If you're using only HTTP or Web services
  • If you're using only one type of protocol


He elaborates further in the full checklist, providing a list of things to consider before you buy into an ESB.


Not surprisingly, he does NOT include "If someone wants to build a resume" as one of the deciding factors.

Add Comment      Leave a comment on this blog post
Jul 14, 2009 3:00 AM Robert Eve Robert Eve  says:

Chapter 4 in An Implementor's Guide to Service Oriented Architecture (free downloads at ) provides a great answer to the question...'Do you really need an ESB?" 

In fact, the entire book addresses similar pragmatic questions.

I recommend it

- Bob Eve, Composite Software

Oct 25, 2012 7:59 AM Robert Robert  says:
I think ESB has a very strong business case as an EAI solution. As for the backplane to SOA and BPM etc, well, that's harder to sell, since full-blown SOA needs organisational change. Robert Reply
Nov 28, 2012 2:04 AM Stephen Stephen  says:
I agree with Robert. Thing is ESBs in thier early days had a steep learning curve and were pretty heavy going. Some of the current offerings are much more lightweight.Of course you would have to have a substantial number of integrations to merit the investment. In any case I think it has to be considered in any new architecture with current trends. See: Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.