Missing the Bus?
July 27, 2004
Missing the Bus?
If May 2004 was about vendors jockeying for position in an apparent—and often transparent—Service-Oriented Architecture (SOA) land grab, July appears to be the month that industry analysts are taking their turn. Witness new publications from Forrester, META Group, Burton Group, and a soon-to-be-published middleware report from another major analyst firm, that all take a stand on enterprise service buses (ESBs), or ESB-like infrastructure. This new round of analysis covers the range you might expect, from simply summarizing findings, to attempts to give shape to this emerging technology category. Equally predictable is that at least one firm (Burton Group, in this case) goes out of their way to not use the three-letter acronym used by others but defines, in their own terms, a "network-centric platform" that offers "seamless, dynamic integration" through an SOA model.
In these defining days of SOA infrastructure, it's more useful to get the model right and be a contrarian on acronyms (as Burton has) than it is to reference a popular term like ESB but misunderstand the model and its implications. It would appear that Forrester, in an effort to take a controversial stand on the popular topic of SOA, exemplifies the latter behavior. In addition to producing an ESB report, Forrester has published their thoughts on CNET News.com: "Commentary: Hop on the bus?". The commentary suggests that while ESBs are more flexible and cost-effective than traditional integration brokers, they have significant shortcomings. Interestingly, the main expressed "shortcoming" of the ESB model is one of its greatest strengths, and the remaining "gaps" that Forrester identifies are addressed in some (but not all) ESB vendors' product lines—and not just those of first-wave EAI vendors.
The main thrust of the Forrester commentary is what they refer to as "missing ingredients", such as process engines, application adapters, etc., as well as some oddly negative statements regarding ESB customization. Both assertions miss the mark, and by no small degree. ESBs, by design, offer a generalized, standards-based platform that can be extended and customized to fit specific needs. For integration to become pervasive—within an organization and across the industry—the base platform must be standardized and generalized. Extensions come in the form of additional products (optimally, integrated with the ESB's service-oriented architecture) and customization by third parties or an organization's own development team.
Vendors like Sonic already provide ESB-based integration suites that offer additional integration capabilities in the form of optional products, allowing customers to select the specific capabilities they need. For example, many integration projects don't require full business process management (BPM), and can instead use the orchestration capabilities inherent in the ESB (interestingly, most customers that have bought monolithic integration brokers don't use the BPM features they paid for). For projects with BPM requirements, the customer can purchase the specific number of process engines that they need, safe in the knowledge that process modeling and management they possess can leverage any services across the bus no matter how large or distributed it is. Similarly, ESB vendors offer best-of-breed adapters that have been modified to work in a distributed SOA environment. The result is both more cost-effective and more flexible than the all-in-one integration broker approach, yet fully unified.
Even more surprising is Forrester's implication that extensibility and customization is somehow a detractor from adopting standards-based technology. The reality is that most integration projects require the ability to extend and customize the integration platform. Connecting to custom in-house applications, providing business-specific auditing or compliance capabilities, taking advantage of existing logic for data manipulation or validation, or implementing so-called "micro-flows" between existing applications all require custom work, regardless of what form of integration solution is employed. Saying that ESBs are limited as a result, is like saying that application servers are incomplete because they don't include the customer's application in the box. With an ESB, customers—or their systems integrators—can extend the standards-based ESB framework to support these capabilities. The result is often faster implementation than with traditional EAI products, with the re-use and flexibility that stem from an SOA.
META Group uses most of the real estate in their short commentary on ESB not to discuss emerging SOA and middleware strategies, but to dissect whether or not ESB is the best name for this emerging category of SOA middleware. They take issue with the words "enterprise" (pointing out that ESBs are often deployed between enterprises in a B2B capacity) as well as the word "bus". Fair points, I suppose (I jokingly suggested the alternate moniker of "intergalactic service cloud" to Janelle Hill and Nick Gall of META), but is this really the point? The technology trends, motivators and architectures that are driving strong enterprise interest in—and adoption of—SOA middleware have come to the fore. I would think that during this defining stage for the industry, analysts could provide the most value to their customers by illuminating the truly vital issues and assisting with industry-wide convergence around best models and practices. Instead, we seem to be experiencing the next wave of the SOA land grab, where acronyms are debated and each analyst firm attempts to position that they—and they alone—can create a new model for enterprise SOA.
It is my strong hope that we as an industry can converge rather than diverge around SOA, lest we lose this remarkable opportunity to help simplify IT. I invite analysts to comment, and will publish any such replies I receive in the interest of useful public debate. In the meantime, the next installments of this column will get back to the original charter of discussing SOA technology and how it can be employed to address real-world issues.
Gordon Van Huizen
Chief Technology Officer
Sonic Software
