| |
Friday 2nd September 2005
COMMENTARY: TO ESB OR NOT TO ESB?
| I don’t disagree that some form of ESB is needed, and would recommend organizations do put the capability in place. However, ESB should be seen first as an architecture, and only then as a product. Some reasons for this are
• 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.
For these reasons 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. Either way, at least the decision should be made on the basis of architectural principles that will deliver infrastructure agility.
It is interesting to see that Microsoft has recently entered the ESB debate with the publication of a paper “Microsoft on the Enterprise Service Bus”, in which they adopt the view that ESB is a set of capabilities not a product label. As we pointed out in our own report on the ESB market “Don't make the mistake of leaving Microsoft out of an ESB evaluation list just because they don't use the label”.
Even so, the same principles apply to Microsoft as any other vendor. Organizations should not just be comparing ESB functionality, but questioning vendors as to how they are exposing their capability as infrastructure services to enable infrastructure agility. If SOA is good enough for their customers, then vendors should be demonstrating how their own products exhibit sound SOA principles too.
Lawrence Wilkes
LINKS
Microsoft on the Enterprise Service Bus
CBDI Market Trends Report: Time to Board the Enterprise Service Bus?
CBDI Product Report: Polarlake Integration Suite | SOA is by definition driven by the adoption of architectural principles. Various products may assist the delivery process, but cannot on their own guarantee business and IT agility and other goals of SOA. The rule must be architecture first, products second.
Enterprise Service Bus (ESB) is a case in point. Many organizations are rushing to make ESB product selections, yet don’t always have a sound understanding of the architectural principles of SOA in place. The false assumption as ever is that such products will be the “silver bullet” that bring SOA success. |
| | Read Full Article / Link to referenced materials |
|
Home