Commentary: Hop on the bus?

by Ken Vollmer, Mike Gilpin and Jost Hoppermann, Forrester Research

An enterprise service bus can be a flexible, low-cost alternative for meeting basic integration requirements, but at this time there are limits to what can be accomplished with a commercial ESB product without custom-developed extensions.

Still, customized ESB technology is being deployed in many companies as part of a broader strategy to enable a service-oriented architecture (SOA), and its applicability to a broader range of integration problems will increase as ESB functionality expands in parallel with the growing maturity of new Web services standards. This will lead more and more to commodity status for many features of today's proprietary enterprise application integration (EAI) arrangements, as these become commonly embedded features of service-oriented application platforms.

The term "enterprise service bus" has become widely used to refer to a layer of middleware through which a set of core (reusable) business services are made widely available. The bus is expected to provide certain infrastructure services, such as service registration and location, reliable messaging and other quality-of-service options, message routing and transformation, security, endpoint identity, and rights management. As such, ESBs are one alternative for implementing an SOA or service fabric, but an SOA can be implemented in other ways, such as message-oriented middleware, CORBA, integration platforms and custom development.

Flexibility and cost
Depending on its particular needs, a business may find that an ESB is a more flexible and lower-cost alternative to proprietary

		Related story IBM plans bus technology ride ESB technology is part of Big Blue's streamlining plan to move customers to cheaper, easier integration options.

Consequently, one increasingly popular strategy is to implement a part-commercial, part-custom-development approach in which the vendor-supplied ESB technology provides core services, while additional required functionality like process automation, custom security features, and business gateway functions are provided via custom development. Such hybrid ESB efforts often build in support for additional service delivery mechanisms, such as message-oriented middleware, in addition to standard support for Web services (Simple Object Access Protocol, or SOAP) connectivity.

For example, Federated Department Stores has implemented a part-commercial, part-custom-developed ESB to support communications between its Macys.com Web site, call centers, Wedding.com Web site and point-of-sale terminals using SOAP-based connectivity plus message-oriented middleware-based interfaces with multiple back-office mainframe applications providing service implementations. This sort of ESB is not just an EAI replacement, for it enables a services-oriented architecture and customized integration functionality for which EAI arrangements may not be well suited, because they provide a number of additional features not needed in some SOA contexts. Extra features can also mean extra costs, and when those features are not needed (or only needed in lightweight forms available from an ESB), EAI can be overkill.

Missing ingredients
Packaged ESB solutions are standards-based products that provide core infrastructure services but do not yet provide complete EAI functionality because the relevant Web services standards are not yet available or commercialized. In particular, process automation, support for packaged application adapters, complex data transformation, and process modeling are functions that are commonly found in EAI tools but are generally missing from packaged ESB products. However, as integration standards like Business Process Execution Language, ASAP (a Web services protocol for supporting long-running activity), and many others mature during the next two to three years, Forrester does expect ESB products to become feasible alternatives for the current level of integration functionality provided by proprietary EAI solution providers.

Some of these integration vendors, such as WebMethods and SeeBeyond, already have ESB functionality embedded in their product suites, and Forrester expects most other integration providers to follow suit. At the same time, Forrester also expects that integration vendors of all types will continue to add new functionality to their product suites in an attempt to avoid commoditization that is being driven by increasing levels of ESB adoption. This will lead to a vendor landscape in which many options will be available for implementing an ESB--some lighter, some heavier--with a range of features to suit problems from the simple to the complex.

Recommendations
As integration standards mature, ESBs will become increasingly relevant to large and midsize organizations.

•  Organizations that have not worked with an ESB should look for an opportunity to experiment with this technology, especially if an SOA implementation is already in the works.

•  Do not plan on replacing your EAI setup with an ESB at this time unless you are using only a subset of EAI features that can be provided by today's more limited ESB products and services, with only limited custom extensions. Only the largest companies should consider more than very limited custom development of ESB infrastructure services, where the cost of such custom development can be amortized over a large number of projects and in the context of a broader SOA initiative.

•  Adjust your strategy as ESB functionality matures, as the capabilities of products--and the maturity of the relevant standards--will evolve rapidly for the next few years.

© 2004, Forrester Research, Inc. All rights reserved. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.