Chapter

4. Understanding SOA

Introduction to SOA
4.1 The Four Characteristics of SOA
4.2 The Four Common Types of SOA
4.3 The End Result of Service-Orientation and SOA
4.4 SOA Project and Lifecycle Stages
The focus of this chapter is to establish the link between service-orientation and
technology architecture, establish distinct SOA characteristics and types, and
raise key project delivery considerations.

Note
Several of the upcoming sections make reference to clouds and
cloud computing in general. If you are new to cloud computing, you
can find introductory content at www.whatiscloud.com and cloud
computing patterns at www.cloudpatterns.org. More comprehensive
coverage is provided in the Cloud Computing: Concepts,
Technology & Architecture and Cloud Computing Design Patterns
titles that are part of the Prentice Hall Service Technology Series
from Thomas Erl.

Introduction to SOA
Let’s briefly recap some of the topics covered in Chapter 3 to clearly establish
how they relate to each other and how they specifically lead to a definition of
SOA:
• There is a set of strategic goals associated with service-oriented
computing.
• These goals represent a specific target state.
• Service-orientation is the paradigm that provides a proven method for
achieving this target state.
• When we apply service-orientation to the design of software, we build
units of logic called “services.”
• Service-oriented solutions are comprised of one or more services.
We have established that a solution is considered service-oriented after service-
orientation has been applied to a meaningful extent. A mere understanding of the
design paradigm, however, is insufficient. To apply service-orientation
consistently and successfully requires a technology architecture customized to
accommodate its design preferences, initially when services are first delivered
and especially when collections of services are accumulated and assembled into
complex compositions.
In other words:
• To build successful service-oriented solutions, we need a distributed
technology architecture with specific characteristics.
 • These characteristics distinguish the technology architecture as being
service-oriented. This is SOA.
Service-orientation is fundamentally about attaining the specific target state we
established toward the end of Chapter 3. It asks that we take extra design
considerations into account with everything we build so that all the moving parts
of a given service-oriented solution support the realization of this state and foster
its growth and evolution. These design considerations carry over into the
supporting technology architecture, which must have a distinct set of
characteristics that enable the target state and inherently accommodate ongoing
change within that target environment.

4.1 The Four Characteristics of SOA

Service-oriented technology architecture must have certain properties that fulfill
the fundamental requirements for an automation solution comprised of services
to which service-orientation design principles have been applied. These four
characteristics further help distinguish SOA from other architectural models.

Note
As we explore each of these characteristics individually, keep in
mind that in real-world implementations the extent to which these
characteristics can be attained will likely vary.

Business-Driven
Technology architectures are commonly designed in support of solutions
delivered to fulfill tactical (short-term) business requirements. Because the
overarching, strategic (long-term) business goals of the organization aren’t taken
into consideration when the architecture is defined, this approach can result in a
technical environment that, over time, becomes out of alignment with the
organization’s business direction and requirements.
This gradual separation of business and technology results in a technology
architecture with diminishing potential to fulfill business requirements and one
that is increasingly difficult to adapt to changing business needs (Figure 4.1).
 Figure 4.1 A technology architecture (A) is often delivered in alignment with
the current state of a business but can be incapable of changing in alignment
with how the business evolves. As business and technology architectures
become increasingly out of sync, business requirement fulfillment decreases,
often to the point that a whole new technology architecture (B) is needed,
which effectively resets this cycle.
When a technology architecture is business-driven, the overarching business
vision, goals, and requirements are positioned as the basis for and the primary
influence of the architectural model. This maximizes the potential alignment of
technology and business and allows for a technology architecture that can evolve
in tandem with the organization as a whole (Figure 4.2). The result is a continual
increase in the value and lifespan of the architecture.
 Figure 4.2 By defining a strategic, business-centric scope to the technology
architecture, it can be kept in constant sync with how the business evolves
over time.

Vendor-Neutral
Designing a service-oriented technology architecture around one particular
vendor platform can lead to an implementation that inadvertently inherits
proprietary characteristics. This can end up inhibiting the future evolution of an
inventory architecture in response to technology innovations that become
available from other vendors.
An inhibitive technology architecture is unable to evolve and expand in response
to changing automation requirements, which can result in the architecture having
a limited lifespan after which it needs to be replaced to remain effective (Figure
4.3).
 Figure 4.3 Vendor-centric technology architectures are often bound to
corresponding vendor platform roadmaps. This can reduce opportunities to
leverage technology innovations provided by other vendor platforms and can
result in the need to eventually replace the architecture entirely with a new
vendor implementation (which starts the cycle over again).
It is in the best interest of an organization to base the design of a service-oriented
architecture on a model that is in alignment with the primary SOA vendor
platforms, yet neutral to all of them. A vendor-neutral architectural model can be
derived from a vendor-neutral design paradigm used to build the solution logic
the architecture will be responsible for supporting (Figure 4.4). The service-
orientation paradigm provides such an approach, in that it is derived from and
applicable to real-world technology platforms while remaining neutral to them.
Figure 4.4 If the architectural model is designed to be and remain neutral to
vendor platforms, it maintains the freedom to diversify its implementation by
leveraging multiple vendor technology innovations. This increases the
longevity of the architecture as it is allowed to augment and evolve in
response to changing requirements.
 Note
Just because an architecture is classified as vendor-neutral doesn’t
mean it is also aligned with current vendor technology. Some
models produced by independent efforts are out of synch with the
manner in which mainstream SOA technology exists today and is
expected to evolve in the future and can therefore be just as
inhibitive as vendor-specific models.

Enterprise-Centric
The fact that service-oriented solutions are based on a distributed architecture
doesn’t mean that there still isn’t the constant danger of creating new silos within
an enterprise when building poorly designed services, as illustrated in Figure 4.5.

Figure 4.5 Single-purpose services delivered to automate specific business

processes can end up establishing silos within the enterprise.
When you apply service-orientation, services are positioned as enterprise
resources, which implies that service logic is designed with the following
primary characteristics:
• The logic is available beyond a specific implementation boundary.
• The logic is designed according to established design principles and
enterprise standards.
Essentially, the body of logic is classified as a resource of the enterprise. This
does not necessarily make it an enterprise-wide resource or one that must be
used throughout an entire technical environment. An enterprise resource is
simply logic positioned as an IT asset; an extension of the enterprise that does
not belong solely to any one application or solution.

SOA Patterns
As established in the Service Encapsulation [359] pattern, an
enterprise resource essentially embodies the fundamental
characteristics of service logic.

To leverage services as enterprise resources, the underlying technology

architecture must establish a model that is natively based on the assumption that
software programs delivered as services will be shared by other parts of the
enterprise or will be part of larger solutions that include shared services. This
baseline requirement places an emphasis on standardizing parts of the
architecture so that service reuse and interoperability can be continually fostered
(Figure 4.6).

Figure 4.6 When services are positioned as enterprise resources, they no

longer create or reside in silos. Instead they are made available to a broader
scope of utilization by being part of a service inventory.

Composition-Centric
More so than in previous distributed computing paradigms, service-orientation
places an emphasis on designing software programs as not just reusable
resources, but as flexible resources that can be plugged into different aggregate
structures for a variety of service-oriented solutions.
To accomplish this, services must be composable. As advocated by the Service
Composability (302) principle, this means that services must be capable of being
pulled into a variety of composition designs, regardless of whether or not they
are initially required to participate in a composition when they are first delivered
(Figure 4.7).

Figure 4.7 Services within the same service inventory are composed into
different configurations. The highlighted service is reused by multiple
compositions to automate different business processes.
To support native composability, the underlying technology architecture must be
prepared to enable a range of simple and complex composition designs.
Architectural extensions (and related infrastructure extensions) pertaining to
scalability, reliability, and runtime data exchange processing and integrity are
essential to support this key characteristic.

Design Priorities
A valuable perspective of how service-orientation relates to SOA and of how the
formalization of this relationship results in a set of design priorities was provided
by the publication of the “SOA Manifesto.” Have a look at the following
excerpt:
Service orientation is a paradigm that frames what you do. Service-
oriented architecture (SOA) is a type of architecture that results from
applying service orientation.
We have been applying service orientation to help organizations
consistently deliver sustainable business value, with increased agility
and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on
the left more.
It is evident how these design priorities are directly supported by the service-
orientation design paradigm and the service-oriented architectural model. This is
further explored in the “Annotated SOA Manifesto” that was published at
www.soa-manifesto.com and is also provided in Appendix D of this book.

4.2 The Four Common Types of SOA

As we’ve already established, every software program ends up being comprised
of and residing in some form of architectural combination of resources,
technologies, and platforms (infrastructure-related or otherwise). If we take the
time to customize these architectural elements, we can establish a refined and
standardized environment for the implementation of (also customized) software
programs.
The intentional design of technology architecture is very important to service-
oriented computing. It is essential to establishing an environment within which
services can be repeatedly recomposed to maximize business requirements
fulfillment. The strategic benefit to customizing the scope, context, and
boundary of an architecture can be significant.
To better understand the basic mechanics of SOA, we now need to study the
common types of technology architectures that exist within a typical service-
oriented environment:
• Service Architecture – The architecture of a single service.
• Service Composition Architecture – The architecture of a set of services
assembled into a service composition.
• Service Inventory Architecture – The architecture that supports a collection
of related services that are independently standardized and governed.
• Service-Oriented Enterprise Architecture – The architecture of the
enterprise itself, to whatever extent it is service-oriented.

SOA Patterns
Architecture types are closely related to SOA patterns. Note how
each pattern profile table in Appendix C contains a field dedicated
to showing related architectures.

The service-oriented enterprise architecture represents a parent architecture that

encompasses all others. The environment and conventions established by this
parent platform are carried over into the service inventory architecture
implementations that may reside within a single enterprise environment. These
inventories further introduce new and more specific architectural elements (such
as runtime platforms and middleware) that then form the foundation of service
and composition architectures implemented within an inventory’s boundary.
As a result, a natural form of architectural inheritance is formed whereby more
granular architecture implementations inherit elements from less granular ones
(Figure 4.8). This relationship between architecture types is good to keep in
mind as it can identify potential (positive and negative) dependencies that may
exist.
 Figure 4.8 The layered SOA model establishes the four common SOA types:
service architecture, service composition architecture, service inventory
architecture, and service-oriented enterprise architecture.
The following section explores the architecture types individually and concludes
by highlighting links between these characteristics and common SOA design
priorities.

Service Architecture
A technology architecture limited to the physical design of a software program
designed as a service is referred to as the service architecture. This form of
technology architecture is comparable in scope to a component architecture,
except that it will typically rely on a greater amount of infrastructure extensions
to support its need for increased reliability, performance, scalability, behavioral
predictability, and especially its need for increased autonomy. The scope of a
service architecture will also tend to be larger because a service can, among
other things, encompass multiple components (Figure 4.9).
 Figure 4.9 An example of a high-level service architecture view for the
Accounts service, depicting the parts of the surrounding infrastructure utilized
to fulfill the functional requirements of all capabilities. Additional views can
be created to show only those architectural elements related to the processing
of specific capabilities. Further detail, such as data flow and security
requirements, would normally also be included.
Whereas it was not always that common to document a separate architecture for
a component in traditional distributed applications, the importance of producing
services that need to exist as independent and highly self-sufficient and self-
contained software programs requires that each be individually designed.
Service architecture specifications are typically owned by service custodians
and, in support of the Service Abstraction (294) design principle, their contents
are often protected and hidden from other project team members (Figure 4.10).

Figure 4.10 The custodian of the Accounts service intentionally limits access
to architecture documentation. As a result, service consumer designers are
only privy to published service contract documents.
The application of design standards and other service-orientation design
principles further affects the depth and detail to which a service’s technology
architecture may need to be defined (Figure 4.11). For example, implementation
considerations raised by the Service Autonomy (297) and Service Statelessness
(298) principles can require a service architecture to extend deeply into its
surrounding infrastructure by defining exactly what physical environment it is
deployed within, what resources it needs to access, what other parts of the
enterprise may be accessing those same resources, and what extensions from the
infrastructure it can use to defer or store data it is responsible for processing.

Figure 4.11 Custom design standards and service-orientation design

principles are applied to establish a specific set of design characteristics
within the Accounts service architecture.
A central part of a service architecture is typically its API. Following standard
service-oriented design processes, the service contract is generally the first part
of a service to be physically delivered. The capabilities expressed by the contract
further dictate the scope and nature of its underlying logic and the processing
requirements that will need to be supported by its implementation (Figure 4.12).
 Figure 4.12 The service contract is a fundamental part of the Accounts
service architecture. Its definition gives the service a public identity and helps
express its functional scope. Specifically, the WSDL document (A) expresses
operations that correspond to segments of functionality (B) within the
underlying Accounts service logic. The logic, in turn, accesses other resources
in the enterprise to carry out those functions (C). To accomplish this, the
WSDL document provides data exchange definitions via input and output
 message types established in separate XML schema documents (D).
This is why some consideration is given to implementation during the service
modeling phase. The details documented during this analysis stage are carried
forth into design, and much of this information can make its way into the official
architecture definition.

Note
Many organizations use standard service profile documents to
collect and maintain information about a service throughout its
lifespan. Chapter 15 of SOA: Principles of Service Design explains
the service profile document and provides a sample template.

Another infrastructure-related aspect of service design that may be part of a

service architecture is any dependencies the service may have on service agents
—event-driven intermediary programs capable of transparently intercepting and
processing messages sent to or from a service.

SOA Patterns
Service agents can be custom-developed or may be provided by the
underlying runtime environment, as per the Service Agent [357]
pattern.

Within a service architecture the specific agent programs may be identified along
with runtime information as to how message contents are processed or even
altered by agent involvement. Service agents may themselves also have
architecture specifications that can be referenced by the service architecture
(Figure 4.13).
 Figure 4.13 A variety of service agents are part of the Accounts service
architecture. Some perform general processing of all data whereas others are
specific to input or output data flow.
A key aspect of any service architecture is the fact that the functionality offered
by a service resides within one or more individual capabilities. This often
requires the architecture definition itself to be taken to the capability level.
Each service capability encapsulates its own piece of logic. Some of this logic
may be custom-developed for the service, whereas other capabilities may need to
access one or more legacy resources. Therefore, individual capabilities end up
with their own, individual designs that may need to be so detailed that they are
documented as separate “capability architectures.” However, all relate back to
the parent service architecture.

Service Composition Architecture

The fundamental purpose of delivering a series of independent services is so
they can be combined into service compositions, fully functional solutions
capable of automating larger, more complex business tasks (Figure 4.14).

Figure 4.14 The Accounts service composition from a modeling perspective.

 The numbered arrows indicate the sequence of data flow and service
interaction required for the Add capability to compose capabilities within the
Client and Invoice services.
Each service composition has a corresponding service composition architecture.
In much the same way an application architecture for a distributed system
includes the individual architecture definitions of its components, this form of
architecture encompasses the service architectures of all participating services
(Figure 4.15).
 Figure 4.15 The same Accounts service composition from Figure 4.14 viewed
from a physical architecture perspective illustrating how each composition
member’s underlying resources provide the functionality required to automate
the process logic represented by the Accounts service’s Add capability.

Note
Standard composition terminology defines two basic roles that
services can assume within a composition. The service responsible
for composing others takes on the role of composition controller,
whereas composed services are referred to as composition members.

A composition architecture (especially one that composes service capabilities

that encapsulate disparate legacy systems) may be compared to a traditional
integration architecture. This comparison is usually only valid in scope, as the
design considerations emphasized by service-orientation ensure that the design
of a service composition is much different than that of integrated applications.
For example, one difference in how composition architectures are documented is
in the extent of detail they include about agnostic services involved in the
composition. Because these types of service architecture specifications are often
guarded—as per the requirements raised by the Service Abstraction (294)
principle—a composition architecture may only be able to make reference to the
technical interface documents and service-level agreement (SLA)-related
information published as part of the service’s public contract (Figure 4.16).
 Figure 4.16 The physical service architecture view from Figure 4.15 is not
available to the designer of the Accounts service. Instead, only the
information published in the contracts for the Invoice and Client services can
be accessed.
Another rather unique aspect of service composition architecture is that a
composition may find itself a nested part of a larger parent composition, and
therefore one composition architecture may encompass or reference another
(Figure 4.17).
 Figure 4.17 The Accounts service finds itself nested within the larger Annual
Reports composition that composes the Accounts Get History capability
which, in turn, composes capabilities within the Client and Invoice services.
Service composition architectures are much more than just an accumulation of
individual service architectures (or contracts). A newly created composition is
usually accompanied by a non-agnostic task service that is positioned as the
composition controller. The details of this service are less private, and its design
is an integral part of the architecture because it provides the composition logic to
invoke and interact with all identified composition members.
Furthermore, the business process the service is required to automate may
involve the need for composition logic capable of dealing with multiple runtime
scenarios (exception-related or otherwise), each of which may result in a
different composition configuration. These scenarios and their related service
activities and message paths are a common part of composition designs. They
need to be understood and mapped out in advance so that the composition logic
is fully prepared to deal with the range of runtime situations it may need to face
(Figure 4.18).

Figure 4.18 A given business process may need to be automated by a range of

service compositions in order to accommodate different runtime scenarios. In
this case, alternative composition logic within the Annual Report’s Revenue
capability kicks in to deal with an exception condition. As a result, the
Notifications service is invoked prior to the Accounts service even being
included in the composition.
Finally, the composition will rely on the activity management abilities of the
underlying runtime environment responsible for hosting the composition
members. Security, transaction management, reliable messaging, and other
infrastructure extensions, such as support for sophisticated message routing, may
all find their way into a composition architecture specification.

SOA Patterns
Even though compositions are comprised of services, it is actually
the service capabilities that are individually invoked and that
execute a specific subset of service functionality to carry out the
composition logic. This is why design patterns, such as Capability
Composition [328] and Capability Recomposition [329] make
specific reference to the composed capability (as opposed to the
composed service).

Service Inventory Architecture

Services delivered independently or as part of compositions by different IT
projects risk establishing redundancy and non-standardized functional
expression and data representation. This can lead to a non-federated enterprise in
which clusters of services mimic an environment comprised of traditional siloed
applications.
The result is that though often classified as a service-oriented architecture, many
of the traditional challenges associated with design disparity, transformation, and
integration continue to emerge and undermine strategic service-oriented
computing goals.
As explained in Chapter 3, a service inventory is a collection of independently
standardized and governed services delivered within a pre-defined architectural
boundary. This collection represents a meaningful scope that exceeds the
processing boundary of a single business process and ideally spans numerous
business processes.

SOA Patterns
The scope and boundary of a service inventory architecture can
vary, as per the Enterprise Inventory [340] and Domain Inventory
[338] patterns.

Ideally, the service inventory is first conceptually modeled, leading to the

creation of a service inventory blueprint. It is often this blueprint that ends up
defining the required scope of the architecture type referred to as a service
inventory architecture (Figure 4.19).
Figure 4.19 Ultimately, the services within an inventory can be composed and
 recomposed, as represented by different composition architectures. To that
end, many of the design patterns in this book need to be consistently applied
within the boundary of the service inventory.
From an architectural perspective, the service inventory can represent a concrete
boundary for a standardized architecture implementation. That means that
because the services within an inventory are standardized, so are the
technologies and extensions provided by the underlying architecture.
As previously mentioned, the scope of a service inventory can be enterprise-
wide, or it can represent a domain within the enterprise. For that reason, this type
of architecture is not called a “domain architecture.” It relates to the scope of the
inventory boundary, which may encompass multiple domains.

SOA Patterns
When the term “SOA” or “SOA implementation” is used, it is most
commonly associated with the scope of a service inventory. In fact,
with the exception of some design patterns that address cross-
inventory exchanges, most SOA patterns are expected to be applied
within the boundary of an inventory.

It is difficult to compare a service inventory architecture with traditional types of

architecture because the concept of an inventory has not been common. The
closest candidate would be an integration architecture that represents some
significant segment of an enterprise. However, this comparison would be only
relevant in scope, as service-orientation design characteristics and related
standardization efforts strive to turn a service inventory into a homogenous
environment where integration, as a separate process, is not required to achieve
connectivity.

Service-Oriented Enterprise Architecture

This form of technology architecture essentially represents all service, service
composition, and service inventory architectures that reside within a specific
enterprise.
A service-oriented enterprise architecture is comparable to a traditional
enterprise technical architecture only when most or all of an enterprise’s
technical environments are service-oriented. Otherwise it may simply be a
documentation of the parts of the enterprise that have adopted SOA, in which
case it exists as a subset of the parent enterprise technology architecture.
In multi-inventory environments or in environments where standardization
efforts were not fully successful, a service-oriented enterprise architecture
specification will further document any transformation points and design
disparity that may also exist.

SOA Patterns
The Inventory Endpoint [346] pattern can play a key role when
designing service inventory environments with external
communication requirements.

Additionally, the service-oriented enterprise architecture can further establish

enterprise-wide design standards and conventions to which all service,
composition, and inventory architecture implementations need to comply, and
which may also need to be referenced in the corresponding architecture
specifications.

Note
This section is focused on technology architecture. However, it is
worth pointing out that a “complete” service-oriented enterprise
architecture would encompass both the technology and business
architecture of an enterprise (much like traditional enterprise
architecture).
Furthermore, additional types of service-oriented architecture can
exist, especially when spanning beyond a private enterprise
environment. Examples can include interbusiness service
architecture, service-oriented community architecture and various
hybrid architectures that encompass IT resources from external
cloud computing environments.

4.3 The End Result of Service-Orientation and SOA

Business communities and the IT industry have an endless bi-directional
relationship where each influences the other (Figure 4.20). Business demands
and trends create automation requirements that the IT community strives to
fulfill. New method and technology innovations produced by the IT community
help inspire organizations to improve their existing business and even try out
new lines of business. (The advent of cloud computing is a good example of the
latter.)
 Figure 4.20 The endless progress cycle establishes the dynamics between the
business and IT communities.
The IT industry has been through the cycle depicted in Figure 4.20 many times.
Each iteration has brought about change and generally an increase in the
sophistication and complexity of technology platforms.
Sometimes a series of iterations through this progress cycle leads to a
foundational shift in the overall approach to automation and computing itself.
The emergence of major platforms and frameworks, such as object-orientation
and enterprise application integration, are examples of this. Significant changes
like these represent an accumulation of technologies and methods and can
therefore be considered landmarks in the evolution of IT itself. Each also results
in the formation of distinct technology architecture requirements.
Service-oriented computing is no exception. The platform it establishes provides
the potential to achieve significant strategic benefits that are a reflection of what
business communities are currently demanding, as represented by the strategic
goals and benefits previously described in Chapter 3.
It is the target state resulting from the attainment of these strategic goals that an
adoption of service-orientation attempts to achieve. In other words, they
represent the desired end result of applying the method of service-orientation.
How then does this relate to service-oriented technology architecture? Figure
4.21 hints at how the pursuit of these specific goals results in a series of impacts
onto all architecture types brought upon by the application of service-orientation.
 Figure 4.21 The common strategic goals and benefits of service-oriented
computing are realized through the application of service-orientation. This, in
turn, impacts the demands and requirements placed upon the four types of
service-oriented technology architectures. (Note that the three goals on the
right represent the ultimate target benefits sought in a typical SOA initiative.)

Note
 For those of you interested in how each of the strategic goals
specifically influences the four types of service-oriented
architecture, Chapter 23 in SOA Design Patterns documents the
individual impacts.

Ultimately, the successful implementation of service-oriented architectures will

support and maintain the benefits associated with the strategic goals of service-
oriented computing. As illustrated in Figure 4.22, the progress cycle that
continually transpires between business and IT communities results in constant
change. Standardized, optimized, and overall robust service-oriented
architectures fully support and even enable the accommodation of this change as
a natural characteristic of a service-oriented enterprise.

Figure 4.22 Service-oriented technology architecture supports the two-way

dynamic between business and IT communities, allowing each to introduce or
accommodate change throughout an endless cycle.
Finally, to best understand how to achieve a technology architecture capable of
enabling the two-way dynamic illustrated in Figure 4.22, we need to reveal how,
behind the scenes, the supporting, formalized bodies of knowledge and
intelligence comprise SOA as a mature field of practice (Figure 4.23).
 Figure 4.23 The strategic goals of service-oriented computing represent a
target state that can be achieved through a method provided by service-
orientation. The successful application of service-orientation principles and
supporting SOA design patterns helps to shape and define requirements for
different types of service-oriented architectures, resulting in an IT automation
model that is designed to fully support the two-way cycle of change through
which business and IT communities continually transition.

4.4 SOA Project and Lifecycle Stages

Understanding how to realize service-oriented architecture also requires an
understanding of how SOA projects are carried out. For the remainder of this
chapter, we take a step away from technology to briefly summarize common
SOA methodology and project delivery topics.

Note
This section provides a good transition to Chapter 5, which explores
service definition as a foundational part of the service-oriented
analysis project stage, and Chapters 6 to 9, which further delve into
the service-oriented analysis stage and then cover considerations
pertaining to the service-oriented design project stage.

Methodology and Project Delivery Strategies

Several project delivery approaches can be employed to build services. The
bottom-up strategy, for example, is tactically focused in that it makes the
fulfillment of immediate business requirements a priority and the prime
objective of the project. On the other side of the spectrum is the top-down
strategy, which advocates the completion of an inventory analysis prior to the
actual design, development, and delivery of services.
As shown in Figure 4.24, each approach has its own benefits and consequences.
Whereas the bottom-up strategy avoids the extra cost, effort, and time required
to deliver services via a top-down approach, it ends up imposing increased
governance burden because bottom-up delivered services tend to have shorter
lifespans and require more frequent maintenance and refactoring.
 Figure 4.24 Generally, the less time and effort spent on the upfront service
analysis, the greater the ongoing, post-deployment governance burden. The
approach on the left is comparable with bottom-up service delivery and the
approach on the right is more akin to top-down delivery. SOA methodologies
that attempt to combine elements of both approaches also exist.
The top-down strategy demands more of an initial investment because it
introduces an upfront analysis stage focused on the creation of the service
inventory blueprint. A collection of service candidates are individually defined
as part of this blueprint to ensure that subsequent service designs will be highly
normalized, standardized, and aligned.

Note
A top-down strategy needs to be applied to an extent to
meaningfully carry out the service-oriented analysis and service-
oriented design stages covered in Chapters 6 to 9. The scope of this
effort is determined by the scope of the planned service inventory,
as per the Balanced Scope pillar covered in Chapter 3.

SOA Project Stages

Figure 4.25 displays the common and primary stages related to SOA project
delivery and the overall service delivery lifecycle. Although the stages are
shown sequentially, how and when each stage is carried out depends on the
methodology being used. Different methodologies can be considered, depending
on the nature and scope of the overall SOA project, the size and extent of
standardization of the service inventory for which services are being delivered,
and the manner in which tactical (short-term) requirements are being prioritized
in relation to strategic (long-term) requirements.
 Figure 4.25 Common stages associated with SOA projects. Note the
distinction between SOA project stages, service delivery project stages, and
service lifecycle stages. These terms are used in subsequent chapters when
referring to the overall adoption project, the delivery of individual services,
and service-specific lifecycle stages, respectively.
Top-down SOA projects tend to emphasize the need for some meaningful extent
of the strategic target state that the delivery of each service is intended to
support. In order to realize this, some level of increased upfront analysis effort is
generally necessary. Therefore, a primary way in which SOA project delivery
methodologies differ is in how they position and prioritize analysis-related
phases.
There are two primary analysis phases in a typical SOA project: the analysis of
individual services in relation to business process automation, and the collective
analysis of a service inventory. The service-oriented analysis phase is dedicated
to producing conceptual service definitions (service candidates) as part of the
functional decomposition of business process logic. The service inventory
analysis establishes a cycle whereby the service-oriented analysis process is
carried out iteratively (together with other business processes) to whatever extent
a top-down (strategic) approach is followed.
The upcoming sections briefly describe these and other stages.

SOA Adoption Planning

During this initial stage is when foundational planning decisions are made.
These decisions will shape the entire project, which is why this is considered a
critical stage that may require separately allocated funding and time to carry out
significant studies required to assess and determine a range of factors, including:
• Scope of planned service inventory and the ultimate target state
• Milestones representing intermediate target states
• Timeline for the completion of milestones and the overall adoption effort
• Available funding and suitable funding model
• Governance system
• Management system
• Methodology
• Risk assessment
Additionally, prerequisite requirements need to be defined in order to establish
criteria used to determine the overall viability of the SOA adoption. The basis of
these requirements typically originates with the four pillars of service-orientation
described earlier in Chapter 3.

Service Inventory Analysis

The scope of a service inventory is expected to be meaningfully “cross-silo,”
which generally implies that it encompasses multiple business processes or
operational areas within an organization.
This service inventory analysis stage is dedicated to conceptually defining an
inventory of services. It is comprised of a cycle (Figure 4.26) during which the
service-oriented analysis stage (explained shortly) is carried out once during
each iteration. Each completion of a service-oriented analysis results in the
definition of new service candidates or the refinement of existing ones. The
cycle is repeated until all business processes that fall within the domain of the
service inventory are analyzed and decomposed into individual actions suitable
for service encapsulation.

Figure 4.26 The service inventory analysis cycle. The highlighted step refers
to the service inventory blueprint that represents the primary deliverable of
 this stage.
As individual service candidates are identified, they are assigned appropriate
functional contexts in relation to each other. This ensures that services (within
the service inventory boundary) are normalized so that they don’t functionally
overlap. As a result, service reuse is maximized and the separation of concerns is
cleanly carried out. A primary deliverable produced during this stage is the
service inventory blueprint.
The scope of the initiative and the size of the target service inventory tend to
determine the amount of upfront effort required to create a complete service
inventory blueprint. More upfront analysis results in a better defined conceptual
blueprint, which is intended to lead to the creation of a better quality inventory
of services. Less upfront analysis leads to partial or less well-defined service
inventory blueprints.
Here are brief descriptions of the primary analysis cycle steps:
• Define Enterprise Business Models – Business models and specifications
(such as business process definitions, business entity models, logical data
models, etc.) are identified, defined, and, if necessary, brought up-to-date
and further refined. These models are used as the primary business analysis
input.
• Define Technology Architecture – Based on what we learn of business
automation and service encapsulation requirements, we are able to define
preliminary technology architecture characteristics and constraints. This
provides a preview of the service inventory environment, which can raise
practical considerations that may impact how we define service candidates.
• Define Service Inventory Blueprint – After an initial definition that
establishes the scope and structure of the planned service inventory, this
blueprint acts as the master specification wherein modeled service
candidates are documented.
• Perform Service-Oriented Analysis – Each iteration of the service
inventory lifecycle executes a service-oriented analysis process.
The service inventory blueprint is incrementally defined as a result of repeated
iterations of steps that include the service-oriented analysis.

Note
The scope of the service inventory analysis stage and the resulting
service inventory blueprint directly relates to the Balanced Scope
 consideration explained in the The Four Pillars of Service-
Orientation section in Chapter 3, as well as the possible application
of the Domain Inventory [338] pattern.

Service-Oriented Analysis (Service Modeling)

A fundamental characteristic of SOA projects is that they emphasize the need for
working toward a strategic target state that the delivery of each service is
intended to support. To realize this, some level of increased upfront analysis
effort is generally necessary. Therefore, a primary way in which SOA project
delivery methodologies differ is in how they position and prioritize analysis-
related phases.
Service-oriented analysis represents one of the early stages in an SOA initiative
and the first phase in the service delivery cycle (Figure 4.27). It is a process that
begins with preparatory information-gathering steps completed in support of a
service modeling subprocess.
 Figure 4.27 A generic service-oriented analysis process in which the first two
steps collect information in preparation for a detailed service modeling
subprocess represented by the Model Candidate Services step.
The service-oriented analysis process is generally carried out iteratively, once for
each business process. Typically, the delivery of a service inventory determines a
scope that represents a meaningful domain of the enterprise (as per the Balanced
Scope pillar discussed in Chapter 3), or even the enterprise as a whole. All
iterations of the service-oriented analysis then pertain to that scope, with each
iteration contributing to the service inventory blueprint.
Steps 1 and 2 essentially represent information-gathering tasks that are carried
out in preparation for the modeling process performed in Step 3.

Step 1: Define Business Automation Requirements

Through whatever means business requirements are normally collected, their
documentation is required for this analysis process to begin. Given that the scope
of our analysis centers around the creation of services in support of a service-
oriented solution, only requirements related to the scope of that solution should
be considered.
Business requirements should be sufficiently mature so that a high-level
automation process can be defined. This business process documentation will be
used as the starting point of a service modeling process.

Step 2: Identify Existing Automation Systems

Existing utility logic that is already, to whatever extent, automating any of the
requirements identified in Step 1 needs to be identified. Although a service-
oriented analysis will not determine exactly how Web services will encapsulate
or replace legacy utility logic, it does assist us in providing some scope of the
systems potentially affected.
The details of how Web services or REST services relate to existing systems are
ironed out in the service-oriented design phase. For now, this information will be
used to help identify utility service candidates during the service modeling
process.
Note that this step is tailored toward supporting the modeling efforts of larger-
scaled service-oriented solutions. An understanding of affected legacy
environments is still useful when modeling a smaller amount of services, which
does not require substantial research efforts.

Step 3: Model Candidate Services

A service-oriented analysis introduces the concept of service modeling, a process
by which service operation candidates are identified and then grouped into a
logical context. These groups eventually take shape as service candidates that are
then further assembled into a tentative composite model representing the
combined logic of the planned service-oriented application.

Note
 Chapters 6 and 7 provide service modeling processes for Web
services and REST services, respectively.

A key success factor of the service-oriented analysis process is the hands-on

collaboration of both business analysts and technology architects (Figure 4.28).
The former group is especially involved in the definition of service candidates
within a business-centric functional context because they understand the
business processes used as input for the analysis and because service-orientation
aims to align business and IT more closely.

Figure 4.28 A look at how the collaboration between business analysts and
technology architects changes with SOA projects. While the depicted
collaborative relationship between business analysts and architects may not be
unique to an SOA project, the nature and scope of the analysis process are.

Service-Oriented Design (Service Contract)

The service-oriented design phase represents a service delivery lifecycle stage
dedicated to producing service contracts in support of the well-established
“contract-first” approach to software development (Figure 4.29).
 Figure 4.29 Unlike the popular process of deriving Web service contracts
from existing components, SOA advocates a specific approach that
encourages us to postpone development until after a custom designed,
standardized contract is in place.
The typical starting point for the service-oriented design process is a service
candidate that was produced as a result of completing all required iterations of
the service-oriented analysis process (Figure 4.30). Service-oriented design
subjects this service candidate to additional considerations that shape it into a
technical service contract in alignment with other service contracts being
produced for the same service inventory.
 Figure 4.30 Subsequent to the analysis effort, services are subjected to a
service-oriented design process.
As a precursor to the service logic design stage, service-oriented design is
comprised of a process that ushers service architects through a series of
considerations to ensure that the service contract being produced fulfills business
requirements while representing a normalized functional context that further
adheres to service-orientation principles. Part of this process further includes the
authoring of the SLA, which may especially be of significance for cloud-based
services being offered to a broader consumer base.

Service Logic Design

By preceding the design of service logic with the service-oriented design
process, the service contract is established and finalized prior to the underlying
service architecture and the logic that will be responsible for carrying out the
functionality expressed in the service contract. This deliberate sequence of
project stages is in support of the Standardized Service Contract (291) principle,
which states that service contracts should be standardized in relation to each
other within a given service inventory boundary.
How service logic is designed is dictated by the business automation
requirements that need to be fulfilled by the service. With service-oriented
solutions, a given service may be able to address business requirements
individually or, more commonly, as part of a service composition.

Service Development
After all design specifications have been completed, the actual programming of
the service can begin. Because the service architecture will already have been
well-defined as a result of the previous stages and the involvement of custom
design standards, service developers will generally have clear direction as to
how to build the various parts of the service architecture.

Service Testing
Services need to undergo the same types of testing and quality assurance cycles
as traditional custom-developed applications. However, new requirements
introduce the need for additional testing methods and effort. For example, to
support the realization of the Service Composability (302) principle, newly
delivered services need to be tested individually and as part of service
compositions. Agnostic services that provide reusable logic especially require
rigorous testing to ensure that they are ready for repeated usage (both
concurrently as part of the same service compositions and by different service
compositions).
The following are examples of common Service Testing considerations:
• What types of service consumers could potentially access a service?
• Will the service need to be deployed in a cloud environment?
• What types of exception conditions and security threats could a service be
potentially subjected to?
• Are there any security considerations specific to public clouds that need to
be taken into account?
• How well do service contract documents communicate the functional
scope and capabilities of a service?
• Are there SLA guarantees that need to be tested and verified?
• How easily can the service be composed and recomposed?
• Can the service be moved between on-premise and cloud environments?
• How easily can the service be discovered?
• Is compliance with any industry standards or profiles (such as WS-I
profiles) required?
• If cloud deployed, are there proprietary characteristics being imposed by
the cloud provider that are not compatible with on-premise service
characteristics?
• How effective are the validation rules within the service contract and
within the service logic?
• Have all possible service activities and service compositions been mapped
out?
• For service compositions that span on-premise and cloud environments, is
the performance and behavior consistent and reliable?
Because services are positioned as IT assets with runtime usage requirements
comparable to commercial software products, similar quality assurance
processes are generally required.

Service Deployment and Maintenance

Service deployment represents the actual implementation of a service into the
production environment. This stage can involve numerous interdependent parts
of the underlying service architecture and supporting infrastructure, such as:
 • Distributed components
• Service contract documents
• Middleware (such as ESB and orchestration platforms)
• Cloud service implementation considerations
• Cloud-based IT resources encompassed by an on-premise or cloud-based
service
• Custom service agents and intermediaries
• System agents and processors
• Cloud-based service agents, such as automated scaling listeners and pay-
for-use monitors
• On-demand and dynamic scaling and billing configurations
• Proprietary runtime platform extensions
• Administration and monitoring products
Service maintenance refers to upgrades or changes that need to be made to the
deployment environment, either as part of the initial implementation or
subsequently. It does not pertain to changes that need to be made to the service
contract or the service logic, nor does it relate to any changes that need to be
made as part of the environment that would constitute a new version of the
service.

Service Usage and Monitoring

A service that has been deployed and is actively in use as part of one or more
service compositions (or has been made available for usage by service
consumers in general) is considered to be in this stage. The ongoing monitoring
of the active service generates metrics that are necessary to measure service
usage for evolutionary maintenance (such as scalability, reliability, etc.), as well
as for business assessment reasons (such as when calculating cost of ownership
and ROI).
Special considerations regarding this stage apply to cloud-based services, such
as:
• The cloud service may be hosted by virtualized IT resources that are
further hosted by physical IT resources shared by multiple cloud consumer
organizations.
• The cloud service usage may be monitored not only for performance, but
also for billing purposes when its implementation is based on a per-usage
 fee license.
• The elasticity of the cloud service may be configured to allow for limited
or unlimited scalability, thereby increasing the range of behavior (and
changing its usage thresholds) when compared to an on-premise
implementation.
This phase is often not documented separately, as it is not directly related to
service delivery or projects responsible for delivering or altering services. It is
noted in this book because while active and in use, a service can be subject to
various governance considerations.

Service Discovery
To ensure that reusable services are consistently reused, project teams carry out a
separate and explicitly defined service discovery process. The primary goal of
this process is to identify one or more existing agnostic services (such as utility
or entity services) within a given service inventory that can fulfill generic
requirements for whatever business process the project team is tasked with
automating.
The primary mechanism involved in performing service discovery is a service
registry that contains relevant metadata about available and upcoming services,
as well as pointers to the corresponding service contract documents (which can
include SLAs). The communications quality of the metadata and service contract
documents play a significant role in how successfully this process can be carried
out. This is why the Service Discoverability (300) principle is dedicated solely to
ensuring that information published about services is highly interpretable and
discoverable.

Service Versioning and Retirement

After a service has been implemented and used in production environments, the
need may arise to make changes to the existing service logic or to increase the
functional scope of the service. In cases like this, a new version of the service
logic and/or the service contract will likely need to be introduced. To ensure that
the versioning of a service can be carried out with minimal impact and
disruption to service consumers that have already formed dependencies on the
service, a formal service versioning process needs to be in place.
There are different versioning strategies, each of which introduces its own set of
rules and priorities when it comes to managing the backward and forward
compatibilities of services. (Chapter 10 provides fundamental coverage of
common service versioning approaches for Web services and REST services.)

Project Stages and Organizational Roles

Figure 4.31 revisits the SOA project stages and maps them to common
organizational roles. These roles are described in the SOA Governance:
Governing Shared Services On-Premise & in the Cloud text book.
Figure 4.31 Shown here are common associations of organizational roles with
different SOA project stages.