I just saw Joe McKendrick's entry on the value of an ESB. Although I appreciate his comments, and even agree with some of his points, I don't come to the same conclusions.
There are two things that drive common understanding: shared experiences, and common problems. The wide acceptance of ESBs is driven by common experiences trying to implement SOA on a large scale with disparate organizations involved.
Without an ESB, the product of such situations is often a fragile, tightly coupled, tangled web of services that is nearly impossible to change, or even reason about -- this causes a lot of pain that motivates people to consider alternative approaches. (This is often the architectural equivalent of burning your hand on the stove -- something you don't do twice =)Now, this is not to say that ESBs for the sake of ESBs is a good idea. Often, organizational boundaries can be used as a good litmus test when deciding whether or not to use an ESB, but consider "organizational boundaries" in the more broad sense of the term. This is more than just the end-consumers/producers involved (e.g. trading partners). It takes into account the vendors supplying and integrating the functional components (infrastructure) of the system. For example, if you're authentication & authorization components are coming from a different vendor than your service stack; you have an organizational boundary you probably want to consider.
Thus, if your scope is small enough, and you are getting all of your infrastructure from the same vendor (and plan to continue to do so), ESBs may not be worth it.
Joe was actually just reacting to an article by Bobby Woolf, which has some good insights in it...
"The problem is this: An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do."
I completely agree with Bobby's statement and just (IMHO) believe Joe made an incorrect inference.
Faucets and toilets deliver the value, but the pipes are not to be overlooked. Lets all face it, if it wasn't for plumbing we'd all still be sh*tting in outhouses. There *is* value in being able to connect a Moen faucet to any well pump, and being able to inject a UV-filter and water softener into the line without disturbing either the faucet or the pump; plumbing enables that. If we take another step back, there is value in being able to then hook into a public sewer system eliminating the need for everyone to install their own septic system.
A real world example of this can be found in Chad's SIP to XMPP tutorial. He was able to build that capability without coding because he used a JBI-based ESB approach. In this example, the two networks (SIP & XMPP) had "plumbing interfaces", and BPEL could be used as the manifold to connect them. Consider that Chad could have quickly and easily also added security "in-line" as well that ask the question "Is Alice authorized to talk to Bob?". These kinds of things are difficult to do without a standards-based, orchestratable messaging and transformation infrastructure (i.e. an ESB).
So, although plumbing might not be worth it for everyone, I for one don't like having to walk outside to relieve myself -- especially in the dead of winter. =)
