Planning and Conducting Enterprise Service Bus Rides (Part I)

*Editor’s Note: This is an excerpt prepared for ebizQ from a report originally issued by the Patricia Seybold Group on December 15, 2005. The full report details are available at http://www.psgroup.com/detail.aspx?ID=668



Research Recap: Enterprise Service Bus for Integration and Event-Driven/Process-Driven SOA

Over the course of a year, we have been actively researching two interconnected IT architecture areas—integration and service-oriented architecture (SOA)—that are foundational to building a customer-adaptive architecture.

Not only are integration and SOA connected in the end game—delivering customer-adaptive IT solutions—but also in their IT instantiations. These connections are (minimally) three fold. First, SOA is commonly used to achieve business, application, and/or information integration. Business-oriented services are often employed to provide access to disparate resources, execute a business process, and/or disseminate information. Second, service orientation is starting to be applied to integration infrastructure, in the form of networked integration environments. These networked integration environments host collections of integration-oriented services (translation, transformation, orchestration, business process execution) that can be composed to resolve an integration scenario.*1

Third, integration and SOA share underlying technologies and application infrastructure. Examples of common technologies are XML, Web Services, messaging, and Business Process Execution Language (BPEL). Examples of common application infrastructure are application servers, Web Services platforms, messaging infrastructure and enterprise service buses (ESB).*2

Within the common application infrastructure, this year we have been closely following the enterprise service bus space. Initially, our interest in the ESB was as a backbone candidate for the networked integration environment. However, as our research progressed, we widened our ESB lens to include infrastructure services for advanced styles of SOA: event-driven and business-process driven SOA.*3

Our Enterprise Service Bus Evaluation Status

With this dual (integration and SOA) focus, we published a collection of papers and blog posts over the summer to provide education and evaluation assistance on ESBs, and related technologies, such as BPEL and Java Business Integration (JBI).

At the close of our wildly popular ESB Evaluation Framework,4 we shared our intent to evaluate some leading (commercial and open source) “pure-play” ESBs.5 Now, that time is (finally) upon us. A natural question is, why now? Or rather, why not over the summer, right after the publication of our ESB evaluation framework? The short answer is we have been collecting, synthesizing, and sharing information to make the ESB evaluations most valuable for our readers. The longer answer is, two reasons:

INDUSTRY MOVEMENT. First, over the last few months, there has been significant activity in the ESB marketplace. The commercial market saw the entry of the application infrastructure giants, BEA, IBM, and Tibco. The entry of the giants didn’t contract the ESB space; rather, their entry legitimized it. The existing ESB vendors we’ve spoken with, such as CapeClear, Iona, PolarLake, and Sonic Software, welcomed the giants. During the same time, many of these existing vendors have released product upgrades.

The activity wasn’t limited to the commercial market. On the open source side, (seemingly) everyone had an ESB-related announcement. There were open source ESB (and ESB-like) announcements from existing projects ServiceMix and Mule, and new projects from Sun, Iona, Apache, and, most recently, JBoss.*6

READER INTERACTION. Second, we took the opportunity to converse (email, phone, and pub) with the enterprise professionals downloading our ESB, integration, and SOA papers. These interactions were invaluable. We learned how readers are using our research, what vendors and products piqued their interest, and the burning questions they wanted answered from our ESB evaluation series.

In-House Evaluation Best Practices. A bonus from our reader interaction was the surfacing of best practices for in-house evaluations of ESBs. As we’ve mentioned throughout our SOA and integration research, every enterprise is different, and in your technology and product evaluations, you need to focus on the best fit for your situation. In some cases, the best fit might be continued investment in an installed product line, rather than an industry-ordained best product. To find the best fit, you need to supplement research activities with hands-on evaluations. In other words, take your own Enterprise Service Bus Rides, using your own integration scenarios, and focusing on the portions of the evaluation framework that are most important to you.

In this report excerpt, we share best practices for your own enterprise service bus evaluation process.

IN-HOUSE ESB EVALUATION BEST PRACTICES

Our readers described their ESB evaluation work in three large categories: understand the situation, technology and product education, and product run-offs. While all three are equally important, the most interesting insights shared, and therefore to share, pertain to the product run-offs.

In the first part of this section, we describe the major ESB evaluation activities. In the second part of this section, we share insights on the product run-offs, or in-house Enterprise Service Bus Rides. Please note, while this report is specific to the enterprise service bus, the frame of the evaluation process described can be used for any application infrastructure evaluation.

Major ESB Evaluation Activities

The categories described above break down into four major activities. The amount of time you spend in each activity depends on your familiarity with the subject matter. As with most architectural activities, your progression will be iterative, rather than linear. Just be certain you have a solid problem definition before creating your product short list and conducting your bus rides.

1. DEFINE THE PROBLEM. Take the time to understand your situation. What business and technology problems are you trying to solve? What are your business and technology plans? What is the state of your application, information, and infrastructure portfolios? What is the skill level of your organization? Do you have a budget? Are you working at a project or enterprise level? What is your organization’s appetite for change? What is your organization’s tolerance for risk? Is your interest integration or service orientation? If SOA, which style—composite applications or flow? What resources—people, information, applications, or services—are you trying to connect? For what types of interactions or scenarios?

2. LEARN ABOUT THE TECHNOLOGY. Technology education starts with key integration and service-oriented technologies (XML, XSLT, messaging, Web Services and BPEL) and practices (loose coupling, mediation, integration patterns, and semantic models). Your goal is familiarity, rather than expertise. You’ll need this background to effectively evaluate the ESB solutions, both in the research and hands-on activities.

Next, learn about ESBs. Not the specific products (yet), but the technology category. Leverage resources like our ESB Q&A paper and ESB Evaluation Framework. Think about your own integration scenarios. Does an ESB make sense for you? What are your most important requirements? Use our ESB Evaluation Framework as the basis for an RFI/RFP and/or a product scoring system. Assign weights to the evaluation dimensions that are most important for you.

For both educational pursuits, find resources that match your learning style: reading, instruction (Webinar, seminar) and/or hands-on (tutorials, reference implementations). For hands-on learning, leverage open source projects to get full product access without time constraints and sales calls.

3. LEARN ABOUT THE PRODUCTS. With a solid problem definition and a good understanding of the technology, it is time to engage in the normal product evaluation tasks in order to generate a short list. Scan the market for solutions. Read vendor-supplied documentation and whitepapers. Gather industry insights from independent research (our bus rides), blogs, and message boards. Attend product-related Webinars and seminars. Invite vendors to respond to your RFI/RFP, and give an on-site demo. Talk to references and industry peers. Finally, be sure to download evaluation software and perform the tutorials. If the product isn’t available for your evaluation, it is typically a bad sign.

From the above, score the products against the criteria you deemed important in our ESB Evaluation Framework. As a result of the scoring, identify two or three products you’d like to exercise in your bus rides.

4. PLAN AND CONDUCT YOUR BUS RIDES. At this stage, you want to exercise two or three products in your environment, resolving a sampling of your key integration scenarios. There are two legs to the bus rides. The first leg is a vendor-executed run-off. In the vendor run-off you are asking a vendor to come to your site, install their products, and resolve the integration scenarios you supplied ahead of time. This is a very effective way to see the product in action. But keep in mind, for the vendor, this is a race. They want to resolve your integration scenarios quickest. So, while you will have the opportunity to observe and absorb, you won’t have an opportunity to interact with the product.

The second leg is an internally-executed proof-of-concept, which is your opportunity to interact with the product. Work from the software installation and deliverables from the vendor run-off. Execute additional scenarios. Add integration tasks to the vendor-built scenarios. Get a feel for the product in design time, development, and runtime. Include runtime tests for problem detection and correction.

This dual approach allows you to see the product put to the test by experts, as well as have hands-on evaluation time, all within your environment.

Tips for Planning and Conducting Your Bus Rides

In this section, we share insights from our readers and our own experience on planning and conducting the vendor run-off portion of the enterprise bus rides—activity four above.

*1 For more on our vision of the networked integration environment and creating an integration strategy for customer experience, please see “Integration Scenarios and the Networked Integration Environment: Pillars of Your IT Integration Strategy for Customer Experience,” April 14, 2005, http://dx.doi.org/10.1571/bda4-14-05cc.

*2 An enterprise service bus (ESB) is an open standards, message-based, distributed, integration solution that provides routing, invocation, and mediation services to facilitate the interactions of disparate distributed information technology resources (applications, services, information, platforms) in a reliable manner.

*3 The two primary styles of SOA used in business solution development are composite application development and flow. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.

In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise. For more information, see our “‘Service-Oriented World’ Cheat Sheet,” June 2, 2005, http://dx.doi.org/10.1571/bda6-2-05cc.

*4 Popularity statement reflects download volume. To judge for yourself, please see “Enterprise Service Bus Evaluation Framework: Criteria for Selecting an Enterprise Service Bus as an Integration Backbone,” July 28, 2005, http://dx.doi.org/10.1571/fw7-28-05cc.

*5 Pure-play refers to the origin and architecture of the ESB. In general, a pure-play ESB is built from the ground up as an ESB, has a distributed bus architecture, has a messaging backbone, and is NOT a re-branded hub-and-spoke EAI solution.

*6 The ESB-like announcement was the Apache Synapse project, which provides ESB-like functionality (services mediation) but is not called an ESB. For more information, see Brenda Michelson’s blog post on Open Source ESB Announcements: http://elementallinks.typepad.com/bmichelson/2005/09/open_source_esb.html, and JBoss’ Matrix: http://jboss.org/jbossBlog/blog/pfricke/2005/10/27/The_Open_Source_Platform_for_SOA_%E2%80%93_JBoss_Enterprise_Middleware_Suite.txt

About the Author

Brenda Michelson is an IT strategist, hands-on practitioner, and the voice of business-driven architecture. Brenda’s day job is principal consultant for Elemental Links. Brenda also contributes architecturally to the Patricia Seybold Group. Brenda spent 19 years in corporate IT, most recently as Chief Enterprise Architect for L.L. Bean. At L.L. Bean, Brenda was responsible for the articulation and execution of the enterprise architecture strategy (J2EE transformation, enterprise integration, SOA and EDA), strategic planning, portfolio management and talent development. Previous to L.L. Bean, over the span of 10 years, Brenda provided development services for Insurance, Banking, a Chip Manufacturer and a world leader in Aircraft Engine Design & Manufacturing. Email Brenda.

More by Brenda M. Michelson

About Elemental Links

Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.