ESB

There is lots of stuff about ESB around at the moment. Much of it is focused on product evaluation, and not the architectural questions.

However, I have found some useful comments from Steve Vinoski (Iona) on ESB vs decentralization, and a discussion between David Chappell (Sonic) and Jim Fawcett posted under the title Is the A in SOA spelled ESB? Meanwhile, Barry Briggs rightly draws attention to the Service Bus and the Process.

---

User perspective: why do I need a new architectural layer? I understand why I might want platform independence, but if I'm simply switching from dependence on a platform to dependence on an ESB, I don't see that I've gained anything.

Stratification only makes sense if it delivers something of value to the user - for example in terms of managing complexity and/or change. Furthermore, since each layer costs something, the value provided by the layer must be greater than its cost.

So what might I be doing, that this extra layer buys me anything?

---

As I see it, ESB is occupying some space between what people want to achieve with SOA, and what is provided as part of the core web service/messaging capabilities of the major platforms. This space is surely going to be changing shape constantly, as both the demand side and the supply side develop and mature.

There are two possible future scenarios for the small ESB vendors. One is that ESB simply fractures into separate services, which are cherry-picked by the big platform vendors, leaving behind only tiny fragments with little commercial coherence. The other is that ESB becomes an agile on-demand process-driven metaservice, whereby the small and nimble ESB vendors retain an advantage over the big platform vendors by being closer to (and more dynamically responsive to) the corporate demand for complex service orchestration and management.

This means that the competitive advantage of the ESB vendors lies not in a static standardized formulation of the stratification and granularity of infrastructure services - since this is the kind of position that is easily captured and controlled by the big platform vendors. Instead, the competitive advantage of the ESB vendors lies in providing dynamic customized architectures, where the stratification and granularity is driven by the business process requirements.

There is no point talking "on-demand" if you don't have a credible way of dealing with demand. This is the opportunity for ESB - to be genuinely demand-driven.

The challenge for the small ESB vendors is therefore to develop new ways of engaging with their customers, to provide truly on-demand service architectures, and to develop sustainable products and services that cannot be easily colonized by the big platform vendors.