Delta 2964

16 June 2004

Making SOA Real

Enterprise Planning & Architecture Strategies, Integration & Development Strategies
Daniel Sholler

Service-oriented architecture (SOA) is a concept that nearly every organization is striving for.
However, the path toward an SOA is often unclear, and the promises of that architecture can seem
very far off. However, it is possible to progress toward an SOA incrementally and benefit from this
progress commensurately with the additional skills, costs, and efforts required for new technologies
and architectures.
SOA is a significant shift in the way organizations will design business systems and the applications that support
them. This shift will affect not only the applications, but also the roles and the responsibilities of the firm and the
various tools and techniques that are used to build them. The changes associated with service orientation can
seem daunting, and the vision of the future (highly adaptable services connected via an easily changed model that
parallels the business process and that can be related to it in a manner that is meaningful to a business user)
seems well beyond what existing systems and organizations are capable of. Many vendors and publications will
talk about the end vision in a manner that makes it difficult for a typical firm to plan a road map.

However, many firms have planned the road map and are indeed progressing toward an SOA. Although not all
organizations did exactly the same things to begin this progression, such firms have numerous common activities
on that road map. Such activities are all well within reach of the typical corporate IT organization and will deliver
significant benefits almost immediately. Although none of these steps is truly a service-oriented scenario, most of
the following will deliver some of the benefits of service orientation:
• Organizations must begin creating services and using models-based development techniques:
One of the significant attractive features of an SOA is that it holds out the promise of creating applications
and systems using models. Because services can be completely described by their metadata (in theory at
the moment, but becoming more practical all the time), one should be able to construct a system by
linking together the invocation of services in a defined sequence. Of course, the sequence itself (and any
attendant logic that goes along with it) can be described in metadata as well. (Pi calculus has given us a
good foundation for how to construct the basic series of
reference actions that are needed to describe sequencing.) META Trend: By 2005, a new set of
The act of creating metadata to sequence the invocation of meta-architectural principles, currently
services is known as “composition.” (The terms referred to as “service-oriented
“orchestration” and “choreography” are also sometimes architecture” (SOA), will be broadly
used.) This composite is often thought of in terms of a model diffused throughout the IT environment
(e.g., the model is the visualization of the sequence in the form of service-oriented business
metadata). Therefore, composition (building composite architecture, service-oriented security
applications) is often associated with the business process architecture, service-oriented
modeling capability of a tool or a system (see Delta 2838). management architecture, etc. By 2006,
The models that are used to create this metadata are SOA will be widely understood and
business process models, in the sense that they represent treated as a metadata (or model)
sequences and decisions about what to implement, when, interoperability architecture, given its
and for whom. Business process execution language is the emphasis on interoperable identifiers
standard by which such models can be made interoperable (namespace metadata), formats
with each other. (information models), and protocols
(process models). By 2007, composite
Using business process modeling and the tools that can applications will be based on the SOA
make such models into executables is a good start for an principles of dynamic, extensible,
SOA. The parts of the system that are represented by such federated interoperability and enabled
models will be relatively easy to construct and simple to by XML-based technologies such as
modify compared to (usually code-based) alternatives. Web services.
However, it is unreasonable to expect that most existing

208 Harbor Drive • Stamford, CT 06902 • (203) 973-6700 • Fax (203) 359-8066 • metagroup.com
Copyright © 2004 META Group, Inc. All rights reserved.
META Delta

systems and applications have exposed services at the correct level of granularity to be composed in this
fashion. In early implementations, this limits the use of the business process-based system to newly
constructed applications, integrations between various applications, and human-based processes that
currently have only limited automation. Business process modeling of this type has not reached a level of
sophistication where it can substitute for code to describe many of the interactions between components
and services.
• Firms must build standards for common business reference objects, patterns for service, and system
designs: The most common project to build a business-level service is the creation of services around
common business reference objects for the organization. What such objects are will depend on the
organizational alignment and the industry. However, in almost every case, there is agreement about the
aspects of such objects for customers and products. Basic objects are part of nearly every process within the
organization, and thus have some representation in nearly every system that the organization uses. Creating a
set of common definitions of basic objects (nouns) and a set of well-defined services (verbs) that identify their
use enables the organization to tolerate the distributed implementations of the actual objects and to
compensate for their inconsistent implementation. The model that should be used is one that draws on
federated data principles. This should be a generic data model that can be enhanced by individual groups for
their particular purposes, but in a way that maintains minimal consistency across the elements. This is not a
simple process, but one that takes place naturally as the result of many integration projects and that can be
done incrementally. The technology to create such services, though non-trivial, is often not overly complex.
The bigger issue of generally creating the process by which the organization reaches some agreement about
what such objects are and what they mean is by far the bigger task (see ADS Delta 1245).
• Organizations must focus on integration that uses standards-based mechanisms: In addition to building
basic reference objects, there must be an infrastructure present that enables the use of such services in any
application environment. This infrastructure should be based on current Web services standards so that future
upgrades of the technology can be streamlined. It should be noted that standards-based does not mean the
same thing as “open source” or “free.” Most organizations will purchase implementations of standards-based
integration from a vendor of integration products.
• Firms must use appropriate standards to reduce technology dependencies: Along with standards-based
integration mechanisms, users should exploit all other standards as they find them. For integration
mechanisms, users can isolate from the specific transport by utilizing SOAP messaging and binding it to the
transport of choice. This will ensure that coding considerations are minimally impacted by any change in
transport infrastructure. Similarly, users can simplify the coding of the various components that must know the
contents of the header or message by using XML messages. Messages should be composed from existing
public standards or from internal standards for the representation of information.
• Organizations must work toward an interoperable middleware platform: The goal of all this is to end up
with a consistent set of services that is exposed using a set of technologies and accessed using a diverse set
of tools and frameworks. In most organizations, this will take some time to achieve. However, as organizations
plan their application deployments, they should be working toward reducing the number of middleware
components involved in the architecture. Combinations of capabilities that have been proven to work for similar
applications, or pre-integrated sets of capabilities from vendors, should be sought out. In many cases, there
will be corporate standards for such capabilities (e.g., application servers, integration servers, portal
frameworks). Sets of technologies should be defined and used as a corporate platform for future system
development. There is likely to be some degree of variation around this platform, because different types of
applications may need different capabilities (i.e., some applications may not use a content management
capability or an Internet commerce capability). However, having a strategic direction and governance over this
platform will enable the organization to create more highly leveraged skills and more reusable patterns,
components, and services.

Bottom Line
To begin the journey toward SOA and to gain some of the benefits of that architecture, organizations
must begin creating services and using model-based development techniques. They must build
standards for common business reference objects and patterns for service and system design.
Organizations must focus on integration that uses standards-based mechanisms, exploit
appropriate standards to reduce technology dependencies, and work toward an interoperable
middleware platform.
Business Impact: Small steps on the road to an SOA can create direct benefits for the organization.

208 Harbor Drive • Stamford, CT 06902 • (203) 973-6700 • Fax (203) 359-8066 • metagroup.com
Copyright © 2004 META Group, Inc. All rights reserved. 2
Delta 2964 • 16 June 2004