World Wide Webber - ESBs are Irrelevant, Transitory, and Expensive!

ESBs are Irrelevant, Transitory, and Expensive!

Posted: 29 November 2006 @ 23:31 UT from Melbourne, Australia

Over on his blog "Roads to SOA" Ronan Bradley writes:

"The largest components of the software spend was on ESBs and security (both at 24% of that 40% of total). This suggests that the ESB has been recognized as a keystone product in a SOA strategy. This may come as a surprise to the remaining hold-outs who continue to argue strongly that ESBs are irrelevant or transitory."

Think about that for a minute. If you're spending 24% of your software spend on ESBs - plumbing if you will - then you are spending 24% of your budget on infrastructure that provides zero business value. The value in an SOA comes from the processes that flow over systems. The integration part of SOA is a side-affect of process automation, not an end in itself. Yet ESB advocates still maintain that it's a necessary up-front purchase before you can have a successful SOA.

This is clearly nonsense. The remaining "hold-outs" are in fact that community that refuses to see that we are moving towards endpointware and rich metadata, and away from big up-front middleware. I am yet to see a scenario where an ESB does something that smart endpoints cannot - and I challenge the ESB community to demonstrate otherwise.

comments: 4

Comments:

Jim,

I didn't say that big upfront purchase is necessary - and in fact most ESB vendors preach a start small and pay a small amount of money, then grow the investment as the scale increases.

I would also agree that the reason for integration is process automation (if that is agreeing with your point!). However even if it is a side-effect you still need to deal with it and hence invest in some technology (like an ESB).

And finally, I don't think we will ever agree on smart endpoint versus intermediary issue (but I would point out that both should use rich metadata). However, I don't actually have a problem with that disagreement. The people who I was targeting with my comments hold on to the automagic view of SOA: If I define a service any good client will automagically be able to connect. I think your view is a little different in that (if I may put words in your mouth) you are saying that you need to have a significant levels of smarts in the end-points to achieve the same goal and you clearly believe that this is a better approach.

Ronan

Posted by Ronan Bradley, email, url @ 30 November 2006 05:30 UT

Hi Ronan,

Down under at least ESBs are sold as the foundation of your SOA. This implies an up-front purchase before you can even start thinking in SOA terms, or so

the message-broker vendors would like enterprises to believe. My appologies if I misrepresented you here.

I do believe you need smarts in the endpoints. Really really sophisticated smarts. The kind of smarts that it takes tens of developers several years to

produce. Fortunately such smarts are a commodity nowadays. WCF and WSIT are, for example, inherently able to interoperate in a straightforward manner even

in the presence of sophisticated non-functional requirements. The only intermediary needed there is a network which adds nothing to the complexity (and

therefore long term gonvernance) of the solution.

My main worry (and it's not my only worry by any means) with the intermediary model is governance - services are no longer transparent, but are instead

subject to the whims (routing, transformation, rules) of a third-party system (the ESB) which makes re-use and governance hard which in turn makes it nigh

on impossible to get processes validated by their business stakeholders. It's a classic N-body problem.

As you know I prefer such "whims" to be encapsulated within the service they apply to, not scattered around the network.

Jim

Posted by Jim Webber, url @ 30 November 2006 10:25 UT

This all depends on your definition of an ESB. Believe it or not, the term is so overused as to make comparisons between products difficult. However, if an ESB claims to be a SOA infrastructure and yet requires you to throw away your existing infrastructural investments in order to use it, or locks you in in some other way, then I'd be wary of it.

Posted by Mark Little @ 02 December 2006 10:55 UT

All this talk about SOA and ESB seems to be losing sight of the fact that what we really want to do is build, using new and existing pieces, software that is so tailored to the user thereof that she does not need to think much about how to use it, just as is the case with, say, a phone or a radio.

I also believe that we are confusing "use with functionality" and still trying to build the "ideal" application; why else do people think an ESB is necessary in "most" cases in order to build SOA applications?

I'm also beginning to wonder why it's called service-oriented rather than simply service? Does an architect (of buildings) build them with service-oriented architecture in mind?

Why, also, is it called an Enterprise service bus? What has it to do with an enterprise? As Mark writes, the term ESB is much overused; as is also the term SOA...

Getting late in the day and the above is probably a bit esoteric...

Posted by John Apps, email, url @ 03 December 2006 07:30 UT