Enterprise Service Bus
ESB Buyers Beware
By Ronan Bradley, Principal, Lustratus Research
2006 continued to be the year of the ESB in terms of new entrants and new products.
However, the core problem with the category has not been resolved and in fact
have got worse: Although every vendor seems to have one, nobody can agree on precisely
what one is.
Throughout my tenure at PolarLake, I believed that (a) there was a need for
complex integration middleware to implement an SOA – a view which now has
become generally accepted (it certainly wasn’t the case back in 2001 when
we started!), and (b) the Enterprise Service Bus would be the title used for the complete stack of middleware required. It appears the industry is speaking or
at least mumbling with different voices on this one.
Ron Schmelzer of Zapthink sums up the situation well when he says:
“The ESB craze has entered the final phase with JBoss entering the
fray. The real problem is that despite all these vendors entering the market,
there is even more confusion about what specific features an ESB must have.”
This makes the job harder for prospective buyers of ESB products in 2007. Right
now the ESB tag can mean anything from reliable messaging with bells-and-whistles
added, all the way across to what was formerly known as EAI! As there is so
much diversity, you need to dig deeper into more products prior to short-listing
to see if the potential products are in fact comparable and could in fact address
The second issue is whether the glut of ESB badged products and vendors can
continue and prosper. Both Steve Craggs and Computer Business Review in their
2007 predictions see trouble ahead for ESB vendors. CBR points out that there
are already too many ESB vendors and with 4 significant Open Source plays (once
JBoss appears), it will get harder for all the vendors and open source projects
to stay the course:
“There are more vendors than the market will be able to support in
the long term, and this will result in price pressure.”
Steve takes the next logical step and predicts:
“pure-play ESB vendors at least will struggle to be able to sustain
a viable business model. On top of this, most of the large IT companies are
either producing or have indicated the intention to produce an ESB. As such,
pure-play vendors are likely to be squeezed out or acquired, and it is highly
likely that at least some of this activity will happen in the next twelve months."
(I would also include the Open Source projects in the danger zone as these
are mostly single-vendor backed rather than relying on a broad developer community.)
Again buyer must beware – checking further into the long term viability
of the vendor.
So am I saying stay clear of ESB in ’07? Definitely, not: If you are implementing
SOA you will need the functionality provided by this motley crew of products
– it is just going to take more time to work out which is the one for you.
My post (above) sparked an excellent thread on the SOA Yahoo! Group around
whether an Enterprise Service Bus was really a “keystone product in a SOA
strategy” as I claimed . What the discussion highlighted for me was the
importance of balance between the need to strive to design reusable services
and the need to be pragmatic and fix service definition mismatches when they
Anne Thomas Mane contributed to this discussion with points that I would at
least partially agree with (A statement that she may find surprising as she
identified herself as one of the "remaining hold-outs who continue to argue
strongly that ESBs are irrelevant or transitory" who I referred to in the
original posting.) Her points were:
1. “[An ESB] provides a means to expose legacy application functionality
as services, and it supports mediation (although not efficiently) and sometimes
orchestration.” Most ESBs provide good support for accessing existing applications,
manipulating message formats and doing the work required to covert one or more
existing systems into a black box service implementation which consumers can
access without worrying about what is going on inside the box. I certainly agree
with these statements.
2. “not all messages must flow through an ESB. Only those messages that
require the services of the ESB should flow through the ESB.” To a degree,
I agree with this one as there will be cases where the ESB provides little value
beyond the acting as a common infrastructure through which all messages can
flow – the value of which commonality must be judged on a case-by-case
3. Anne’s third point is that by relying so strongly on an ESB –
with its integration capabilities – it can undermine the focus on getting
the service definitions right. In effect because an ESB can fix deficiencies
with your service definitions on the fly, organizations can get away with poor
service design – initially at least. Again I have sympathy with this but
I feel it is like shooting the messenger. The SOA message is that the service
definitions are crucial to getting the reuse/sharing which drives the economic
argument. It is absolutely the case that adopting an ESB or any other product
should not be used as a way of avoiding that architectural investment. Using
an ESB without investing in service design is simply using an updated EAI product
to do old style EAI!
Which brings me back to a favorite question: is it possible to create services
which are capable of being used by all potential consumers now or in the future
without some mediation (such as transformation orchestration) between the service
implementation and consumer? I simply do not believe it is. Even if you can
design the service to suit all possible needs today without mediation, there
will be unforeseeable changes in the future.
The answer could be to refactor the service but the experience of many years
of attempting to build large scale data models (which is effectively what you
are trying to do – build a shared model between service definition and
all the consumers) tells us that this gets more and more difficult to achieve
as the scale (the number and diversity of clients in this case) increases. Therefore,
the only alternative is to accept that to some degree there will be a need for
mediation as the service definition will not be perfect for every consumer.
The only remaining issue is whether individual ESB products provide sufficient
mediation capabilities. And again I tend to agree with Anne when she criticizes
the three ESB vendors that she name checks (IBM, Sonic and BEA) as these do
not provide great mediation capabilities within their ESB products. However,
current product deficiencies should not (yet) lead to the ESB baby being thrown
out with the bath water.
About the Author
Financial services expert Ronan Bradley is ebizQ's Community Manager for Banking and Capital Markets.
As Community Manager, Bradley will blog and podcast on the latest news and breakthroughs relevant to the financial services industry. He will also publish press releases, cover briefings, write feature articles and source content from other analysts, industry associations and vendors for publication on ebizQ. Each week, Bradley will compile the most important news and views in an e-mail newsletter for ebizQ's ever-growing financial services community. Bradley has spent over 17 years in the software industry and has held senior management positions in a number of international software
vendors with strong emphasis on the financial services sector. As Vice
President for Product Management at IONA Technologies, he was
responsible for products generating over $100 million of revenue.
Bradley also founded PolarLake, which has grown into a leading
Enterprise Service Bus (ESB) vendor.
Currently, Bradley is a co-founder and analyst with Lustratus
Research, a market analyst and consultancy firm focused on software
infrastructure. He is also principal of The IT Perspective, a
specialist IT advisory firm working to help clients align their IT and
business agendas. As a recognized expert on business integration software and its uses in financial services, Bradley has spoken at many events worldwide and has been quoted in publications such as The Financial Times, Banking Technology, and Computer Business Review. He also lectures at The Dublin Institute of Technology.More by Ronan Bradley
About Lustratus Research
Delivering independent and unbiased analysis of global software technology trends for senior IT and business unit management, shedding light on the latest developments and best practices and interpreting them into business value and impact. Illuminatus analysts include some of the top thought leaders in market segments such as service-oriented architecture (SOA) and business integration.