ESB and other SOA middleware can provide many important capabilities but at the end of the day what really counts is whether these products make developers and other stakeholders more productive.
There is nothing “magic” about ESB products. They are all based on well-known application servers and/or messaging products and so they really don’t change the underlying basic characteristics of these platforms. Some ESBs may provide a leg up if advanced Web services specifications, such as WS-Security and WS-ReliableMessaging, must be used; however, their use is still relatively rare even for internal integration, let alone for integrating with external system outside of an enterprise. As far as basic Web services go, ESBs don’t really have any advantage, since any application server and many open-source products can provide equally good Web service run-time platforms.
So the true value-add of ESBs is transformation and mediation capabilities that I described in one of my previous posts. However, there is nothing “magic” about these capabilities either. Any mediation flow or a BPEL flow can be implemented in a regular language, such as Java. There are many open-source and relatively light-weight workflow implementations (some of them even support BPEL) that can be used in place of a full-blown commercial ESB. There are also many adapters and converters for a variety of different applications and formats that can be purchased separately (and many ESB vendors do not package adapters with their products).
So it all boils down to whether an ESB product’s tools help create and modify mediation flows and BPEL flows quicker and easier than competitors. This is why all ESB vendors put great emphasis on visual modeling and development tools. And this is where an evaluation of ESB products must focus on. Ideally, users should be able to measure a productivity gain when creating a mediation flow/process and when making changes, such as adding an activity or re-wiring a flow. This gain could even be measured in absolute time it takes from the start of implementation to when changes are fully deployed in a target environment. Of course, any evaluation should include multiple products, potentially using different approaches (e.g., visual tool versus API-based workflow library).
My suspicion is that ESBs demonstrate productivity gains primarily in a case of simple to medium complexity flows. As I blogged before, BPEL and many proprietary mediation flow languages could be inadequate when dealing with complex flows with a very high number of activities and complex business logic. So an ideal product should also provide an easy-to-use APIs to allow developers to switch from “visual” mode to “textual” development environment where all features of Java or, perhaps, a scripting language, can be used (so that the appropriate reusable components can be created).