Planning SOA is a complicated process and there is a strong temptation to let a vendor offer up easy answers. Lawrence Wilkes of CBDI really drives home why it is problematic to select an ESB (Enterprise Service Bus) vendor instead of simply viewing it as an architectural pattern useful in achieving SOA goals...
"Don’t make the mistake of thinking it is safe to 'standardize' on an ESB product on an internal basis. The whole point of SOA is to provide the agility so that business and IT capability can be bestsourced. What is internal today may be external tomorrow, and vice versa.
"For these reasons," he concludes, "it is better to think of ESB as a service architecture of infrastructure capabilities, and then to consider what products best provide an implementation of each of the infrastructure services required. This may result in the selection of a product (or products) bearing the ESB label, or it may not."
Additional key thoughts from the article... (which make it a must read IMO)
- The goal of SOA is solutions based on loosely coupled, agile, federated, reusable Services. This should not just apply to the delivery of business solutions, which is rightly the organization’s prime focus, but also the implementation of the IT infrastructure. Organizations need to take care that in delivering business solutions they don’t lock themselves in infrastructure products that inhibit IT agility, and ultimately business agility.
- The capabilities required are unlikely to be delivered by a single product, nor may not be best delivery in a single product. Part of this lies in the fact that there is no common agreement on what an ESB is. ESB products often contain a mixture of service mediation, transport, management, and security capabilities. This is a useful set of capabilities to support SOA, but clearly overlaps with many other product categories. As different products in each category become better service enabled, they may be better (because of their specialization) at delivering that capability than a single “jack of all trades”.
- Federation requires the loose coupling, not just of business services and solutions, but of infrastructure. Service Providers cannot place ESB product demands on Service Consumers. Don’t make the mistake of thinking it is safe to “standardize” on an ESB product on an internal basis. The whole point of SOA is to provide the agility so that business and IT capability can be bestsourced. What is internal today may be external tomorrow, and vice versa.
Expect that line of thinking to gain momentum. At ThoughtWorks we've been advising our clients on how to resist vendor lock-in .
