Don’t use an ESB unless you absolutely, positively need one, Mule CTO warns

Don’t use an ESB unless you absolutely, positively need one, Mule CTO warns

Summary: Misuse of ESBs leads to overly complex architectures that can be more difficult to remedy than a straightforward Web services-based architecture that omits the ESB in early versions of an enterprise application.


“To ESB or not to ESB,” that is the question Ross Mason, MuleSource CTO, raises in a his blog this week.

It would be heresy among marketers at many vendors, but the MuleSoruce CTO is actively discouraging architects and developers from using an enterprise service bus (ESB), including his company’s open-source version, unless they are sure they really need one.

Misuse of ESBs leads to overly complex architectures that can be more difficult to remedy than a straightforward Web services-based architecture that omits the ESB in early versions of an enterprise application, Mason argued in a phone conversation about his blog.

“There are two main mistakes I see most of the time,” he told BriefingsDirect. “There’s not enough of an integration requirement or there’s not enough use of the ESB features to warrant it.”

You don’t need an ESB if your project involves two applications, or if you are only using one type of protocol, he explains.

“If I’m only using HTTP or Web services, I’m not going to get a lot of value from an ESB as opposed to using a simpler Web services framework,” Mason said. “Web services frameworks are very good at handling HTTP and SOAP. By putting in an ESB, you’re adding an extra layer of complexity that’s not required for that job.”

Architects and developers using an ESB in these cases are probably engaging in "resume-driven development (RDD)." If anybody asks you if you’ve deployed an ESB in an application you’ve worked on you can say, yes. And then you can hope the hiring manager doesn’t ask if the application really required the technology.

Another mistake, Mason cites, is using an ESB and thinking that you are future-proofing an application that doesn’t need it now, but might someday.

“You’ll Never Need It (YNNI), that acronym has been around awhile for a reason,” Mason says. “That’s another killer problem. 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.”

Adding his two-cents to the “Is service-oriented architecture (SOA) dead” debate, the MuleSource CTO says such over-architecting is one of the things that contributes to the problems being encountered by IT in SOA that has given the acronym a bad name. “Architecture is hard enough without adding unnecessary complexity,” he said. “You need to keep it as simple as possible.”

Ironically, adding an ESB because you might need it someday can lead to future problems that might be avoided if you left it out to begin with and then added it in later, Mason said.

“The price of architecting today and re-architecting later is going to be a lot less than architecting badly the first time,” he explained. “If you have a stable architecture, you can augment it later with an ESB, which is going to be easier than trying to plug in an ESB where it’s not going to be needed at that time.”

While the conversation focused on the pitfalls of using an ESB where you don’t need one, the MuleSource CTO naturally believes there are architectures where the ESB makes sense. To begin with, you need to be working on a project where you have three or more applications that need to talk to each other, he explained.

“If you’ve got three applications that have to talk to each other, you’ve actually got six integration points, one for each service, and then it goes up exponentially,” Mason said.

The ESB technology is also needed where the protocols go beyond HTTP. “You should consider an ESB when you start using Java Message Service (JMS), representational state transfer (REST), or any of the other protocols out there,” Mason said. “When communications start getting more complicated is when an ESB shows its true value.”

BriefingsDirect contributor Rich Seeley provided research and editorial assistance on this post. He can be reached at

Topics: Software, Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Architecture should take care of future needs

    Architecture should take care of future needs. That is one of the design principles of a good architecture. Architecture can be complex if it has to meet complex needs. Keep them as simple as possible. However, it is the smart design that can take care of future needs. For example, if you design a database field with 2 digit field that failed to understand the future needs of a 3 digit field look into how much of rework that you need to do convert that into a 3-digit field later. Hence, accomodating future needs is a good principle. So, ESB is good in concepts. SOA has not become the kind of run-away success that it should have been. That needs to be studied.
  • Need to assess each situation on it's own merits...

    Not sure I fully agree with such a hard and fast rule. So much can depend on the detail of each scenario. Sure, if you literally have a business with no other requirement than connecting a couple of applications over HTTP then an ESB would be overkill, but it's rarely the case in large organisations.

    We (Acumen Solutions) often spend a substantial amount of time educating our customers as to why they should start with a foundational architecture that can grow with their requirements rather than having to be ripped out and re-designed after the first phase of the project, wasting all the hours spent by their development and QA teams coding a point-to-point solutions by hand.

    If we knew for certain their requirements were never going to change, we could opt for a more rigid point-to-point solution, but in our experience the requirements do change and there are ESB/ETL technologies out there that are flexible enough to handle most of the potential integration requirements they'll be faced with.

    Furthermore, instead of a patchy set of poorly maintained (and even more poorly understood) web-services that are managed by different project teams around the business, each of them regularly re-inventing the wheel when it comes to how these services should be architected, deployed and monitored... a solid middleware solution can bring substantially greater stability by ensuring all integration services are managed and monitored in one place and built using configuration over code, which can greatly reduce the amount of time it takes to make adjustments, test and deploy.

    I'm a big fan of KISS and YAGNI principles and a huge follower of lean methodologies, but each of these principles requires careful application when it comes to architecture. The primary goal when architecting in an agile environment is to find the right balance between an architecture that has some inherent scalability/flexibility, while at the same time not attempting to pre-empt future requirements that are not yet defined or clearly understood.
  • Integration Framework vs. Enterprise Service Bus vs. Integration Suite

    Take a look at my presentation "Spoilt for Choice - How to choose the right ESB":

    I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.
    Kai Wähner