Are ESBs Evil?

Untitled Document Editor's Note: Interested in optimizing your SOA, then you cannot miss ebizQ's upcoming virtual conference on SOA Governance, which you can sign up for right here.

There has been a bit of a blogging war going on over the last few weeks, starting with a post I made that, in essence, pushes back on the use of multiple ESBs (Enterprise Service Buses) in a particular enterprise. It was not the use of ESBs that bothered me. It was that perhaps there was not a lot of architectural thinking going on, and people are dragging ESBs into their enterprises for the wrong reasons.

While I've hit this topic about 50 times in the last four years, for some reason that post hit a nerve. Half of those responding said I was "spot on." The other half thought I was muckraking. The truth is, I've called ESBs into question since they hit the marketplace, and will continue to do so. My cautionary tales do not focus on the value of ESBs, but the fact that, in many instances, they are overhyped and overused, and, generally speaking, not a lot of architectural forethought has preceded the selection of an ESB, or worse, ESBs.

Backing up for a bit, ESBs really became a way to label JMS-based middleware, which was service enabled as "ESBs." Although Progress Software and the Gartner Group had a bit of back and forth on who invented the term "ESB," at this point it really does not matter. What does matter is that with the explosion of interest in SOA, almost all of those who had anything that resembled an integration server, message-oriented middleware, or a message broker, re-labeled their product as an "ESB." Thus, you had dozens of ESBs out there, all different, thus all supporting the notion of SOA differently.

Moreover, the use of ESBs were promoted as "SOA in a box"-type technology. While architects should have been going through typical business requirements analysis, they instead ran out and purchased ESBs in hopes that the answer would somehow come out of the box. Unfortunately, in many cases, they actually made things more complex, and thus worse. That was the essence of my argument.

Indeed this was proven out by a recent poll that's own Joe McKendrick implemented, asking the question: "Are ESBs an effective platform for SOA?"

The results were as follows, with 92 responding:

It doesn't really matter - SOA should be oblivious to underlying technology (41%)

No, they create costly messes (28%)

Yes, they provide a ready solution (26%)

Other - add your comments to TalkBack (4%)

Total Votes: 92

What's most disturbing about this is the number who responded "…they create costly messes." Perhaps this proves my point that they were dragged into the enterprise for the wrong reasons, and without the proper amount of planning. Typically, there is no holistic architecture defined and the enterprise is a huge collection of one-off tactical solutions that don't work well together. Thus, the architecture is fragile and static, the opposite goal of SOA. At least the way I define SOA.

ESBs are not evil. I think they make sense in certain circumstances. What I am saying is that they have a tendency to be found within components of the architecture where they don't belong. They do have applications within the context of architecture, but, again, they are all different thus you need to understand the features and functions of a particular ESB.

Although all ESBs are not the same, generally speaking they have a tendency to be too information-oriented, and they are typically repurposed messaging systems with services interfaces built on top of them. Thus, some ESBs have issues with how they deal with true service behavior, and are really just service-oriented message brokers when you get right down to it, as I stated. However, in some instances, your architecture may need a service-oriented message broker, or an ESB. The ESB still needs to be within the context of a much larger architectural plan.

So, what does one need to do before selecting an ESB? It's really a matter of things you would typically think of doing around architecture, including:

1. Start
2. Understand core metadata
3. Understand core business processes
4. Understand governance requirements
5. Understand performance expectations
6. Understand business objectives
7. Create an ROI model
8. Create a technical solution
9. Test the solution
10. Go back to Start

No rocket science here, it's just a lot of work that many organizations have a tendency to ignore in favor of playing with technology. They put up technical solutions quickly because within tactical problem domains, that may have been an effective approach. However, in the world of SOA or enterprise architecture, the strategic architecture takes years to develop and is an ongoing operation as the business needs change. In other words, if you don't have a master plan around architecture which includes a core understanding of the business, you're actually going to take the business backwards.

The core issue here is leadership, within enterprise architecture and beyond. The entire executive team should be involved in making sure that a core plan is both created and followed, and that you don't end up with a situation where you have to keep hacking and patching, which is what most enterprises are doing today. Stop the wasted motion and get a plan in place that works for the business, and execute the plan. It will not be perfect, but we have to get better at leveraging our IT assets in support of the business. For now, it seems that many are dealing with messes, and consider that behavior "just fine." I don't accept that.

About the Author

David S. Linthicum (Dave) knows cloud computing and Service Oriented Architecture (SOA). He is an internationally recognized industry expert and thought leader, and the author and coauthor of 13 books on computing, including the best selling Enterprise Application Integration (Addison Wesley). Dave keynotes at many leading technology conferences on cloud computing, SOA, Web 2.0, and enterprise architecture, and has appeared on a number of TV and radio shows as a computing expert. He is a blogger for InfoWorld, Intelligent Enterprise, and, covering SOA and enterprise computing topics. Dave also has columns in Government Computer News, Cloud Computing Journal, SOA Journal, Align Journal, and is the editor of Virtualization Journal.

In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including Enterprise Application Integration, B2B Application Integration, and SOA, approaches and technologies in wide use today. For the last 10 years, Dave has focused on the technology and strategies around cloud computing, and how to make cloud computing work for the modern enterprise. This includes work with several cloud computing startups.

Dave’s industry experience includes tenure as CTO and CEO of several successful software companies, and upper-level management positions in Fortune 100 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities including the University of Virginia, Arizona State University, and the University of Wisconsin.

More by David S. Linthicum