Business Takeaways

• Service-enabling strategies for application integration depend on whether the applications to be integrated are purchased, previously developed in house, or being built from scratch.
• A service oriented architecture (SOA) is as relevant for application integration as it is for application construction.

• Sometimes an Enterprise Service Bus (ESB) is the right approach to provide SOA features.
• Sometimes invasive application modification is the right approach to provide SOA features.

Ah yes, S-O-A, the elusive Service Oriented Architecture. You've read the analyst reports. You've watched some online webinars. You even have a fancy poster in your office. It all sounds good, but you're not quite sure how it applies to your environment.

The bottom line is:

1.  SOA is relevant even if you're not focused strictly on building applications.
2.  You need the right infrastructure.
3.  You must consider the provenance of your applications to take the best approach to enable them for SOA.

The remainder of this article will illustrate how the application of these basic concepts can help you evolve your current IT landscape to one that takes advantage of the opportunities offered by an SOA. But before we get too deep into the details, let's clarify what we're referring to as an SOA and look at how this can be interpreted to maximize its benefits.

SOA OK
An SOA is typically described as an approach to building applications based on well-defined, loosely coupled processes or "services." This design approach has been appreciated as a theoretical model for years, but the advent of standards for Web Services has recently allowed SOA to gain a significant foothold in the industry. A full discussion of SOA and Web Services standards is beyond the scope of this article. Interested readers are encouraged to review back issues of this publication for a variety of pieces on these subjects. For now, we will merely point out that Web Service standards enable SOA in a manner which is language-neutral, platform-independent, and based on well-established Internet standards.

To Serve IT
SOA and Web Services have historically been discussed in the context of software development, when an application is built from the ground up. Application development is also where SOA and Web Services have gained real traction, for example, with software vendors and IT shops where business requirements are met with custom applications.

Today, however, many IT shops no longer develop software as a core competency. New capability is primarily provided via the acquisition of commercial off-the-shelf (COTS) software or by modifying previously developed applications. These previously developed legacy applications either pre-date the adoption of a COTS strategy or were deployed to achieve some competitive advantage.

The value these shops deliver in the provisioning of new functionality therefore centers on the integration of independently designed COTS, legacy, and occasionally newly developed applications. Differentiation is driven by this mix and by how well these systems work together. In such shops it may not be obvious how this newfangled SOA applies.

However, as some integration architects have recognized, SOA leverages the same principles and offers the same advantages as those associated with Enterprise Application Integration (EAI) approaches. The basic difference between EAI and SOA is that SOA is usually discussed in terms of a particular application whereas EAI applies at the application portfolio level. For example, the loosely coupled SOA approach to application assembly is analogous to the loosely coupled EAI approach to application integration.

What's All This Then?
It all sounds very interesting but what does any of this mean in practice for "buy and integrate" IT shops? What implication does the SOA model have for these organizations? Do Web Services play a role in meeting day-to-day requirements? One way to answer these questions is to consider the roles systems can play in an SOA and the application model they follow.

The basic roles in an SOA are the service provider and the service consumer. The first role is taken by the application that presents services. The second role is taken by the application that exercises services to accomplish some business objective. In reality, services are often combined or composed into more complex processes, but conclusions drawn from the simpler interactions can be extrapolated to these more sophisticated scenarios.

The application models - new custom applications, legacy, and COTS - should be familiar to most readers. For the uninitiated, the sidebar provides a brief primer.

For service-based integration to be viable service producers must possess a service presentation capability and they must present services relevant to integration requirements. Service consumers must have a service consumption capability and must be able to invoke services at points relevant to integration requirements in a manner supported by the available services.

One other consideration is an integration infrastructure, specifically what is commonly referred to as an ESB, described in the sidebar.

For each application model, we recommend SOA enablement strategies in the context of service provider and service consumer roles. Aside from using native service capabilities, two basic approaches are discussed: applying ESB technology and invasive application modification.

Table 1 summarizes the recommendations for COTS, legacy, and custom development scenarios using a familiar stoplight metaphor. These are the three faces of SOA.

COTS - It Is What It Is
Ultimately, whether a COTS application is service-enabled is at the discretion of the vendor. Note that most vendors are taking an SOA approach to the construction of these applications because of the advantages of this approach from an application build standpoint. Of course, for many implementation teams, the internal COTS architecture is obscured inside a black box. So this application of SOA in and of itself has little impact.

However, when SOA is the internal build approach, it's also likely to be an external integration approach. That is, service-based interfaces, usually following Web Services standards, are likely to be available, at least as an option.

The only real point of influence customers have therefore is the extent to which these capabilities are considered in purchase decisions. Ironically, even this influence is limited because COTS application selection is usually based largely on business priorities.