Untitled DocumentEditor'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
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 ebizQ.net'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
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
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:
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
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 eBizq.net, 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.