ESB Buyers Beware

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 your problem.

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.

Part II

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 inevitably occur.

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 basis.

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.