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:
- An insufficient integration requirement
- 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.