Planning for the Service-Oriented Architecture (SOA)
Journey
Author: Tim Vibbert
Date: 1 Nov 2006

Overview..................................................................................................................................................3
SOA: A Mindshift....................................................................................................................................3
SOA Defined............................................................................................................................................3
Realizing SOA..........................................................................................................................................3
Effective Planning...................................................................................................................................4
The explosion of these stream will begin by addressing three of these jurisdictions
specifically business approach, business value, and architecture. The remaining
jurisdictions will be addressed later in this whitepaper. ...........................................................4
Business Value................................................................................................................................5
Architecture.....................................................................................................................................5
Requirements for an SOA Strategy.......................................................................................................6
...............................................................................................................................................................7
Building an SOA Roadmap...............................................................................................................7
Planning...........................................................................................................................................7
As-Is Assessment...........................................................................................................................7
End goal..........................................................................................................................................8
Definition........................................................................................................................................8
SOA Legos...............................................................................................................................................9
Projects...................................................................................................................................................11
Relationships and Outcome Management.........................................................................................12
Implementing a Pilot Project...............................................................................................................14
Important Steps in a Successful Pilot Project in SOA...............................................................14
Step 1: Identify the Objectives for the SOA Pilot..................................................................14
Step 2: Construct a Cross-Organizational SOA Team..........................................................14
Step 3: Ascertain the Appropriate Pilot Project.....................................................................15
Step 4: Measure Results..............................................................................................................17
Conclusion.............................................................................................................................................18

Overview
Service-Oriented Architecture (SOA) enables organizations to realize business and
technology advantages by combining business process innovation, effective governance, and a
service-centric technology approach.
SOA is a long term strategy that requires perpetual focus on transforming the IT
(Information Technology) delivery mechanism, but it must also answer immediate business
initiatives. The promises of SOA can only be realized by maintaining a balance between long-
term enterprise goals and immediate, short-term, business requirements.
SOA: A Mindshift
In order to conquer the complex issues that IT faces in delivering solutions that
provide success to the organization, a mindshift is required. SOA offers a mechanism to
facilitate that change for both developers and architects. There are a few questions that
organizations must consider:
♦ What preparation is required for such a fundamental change?
♦ What is required for such a migration?
♦ How can an organization ensure that the migration is performed in the most cost-
effective and impacts the organization the least?
SOA is more about a manner of thinking than about a technology. It is a reformation
of the infrastructure supporting IT delivery and is a representation of the cultural and
behavioral changes in how organizations employ technology and the internal organizations
interrelate.
SOA Defined
The OASIS Reference Model for Service-Oriented Architecture (SOA RM) defines
SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the
control of different ownership domains. It provides a uniform means to offer, discover,
interact with and use capabilities to produce desired effects consistent with measurable
preconditions and expectations.” 1
By organizing around distributed capabilities rather than applications, SOA provides
key benefits:
♦ Improved business and IT productivity, agility and speed
♦ Improved Time-To-Market schedules with increased alignment to the
objectives of the organization
♦ Improved respond to change and delivery of optimal experience
Realizing SOA
Many organizations have a difficulty on deciding where to begin the SOA journey. A
prescription is needed to assist organizations in beginning an SOA journey.

1. Strategically focused, tactically implemented: Begin the journey by identifying a
core process that spans multiple business organizations and realize that
process with simple, agnostic services.
2. Top-down, bottom-up, middle-out analysis: Identify the services required to
support the process, identify functionality in existing systems that can be
exposed as services. The analysis must be goal driven and the goals most align
with the strategic goals or the organization.
3. Consider core services: Identify any common, core, services and supporting
functionality.
4. Travel slowly: Once an organization has successfully deployed initial projects,
future technically challenging efforts can travel in parallel.
5. Construct an Enterprise Catalog: Once more and more projects are
developed utilizing this new paradigm called SOA, begin to harvest and reuse
services. This will begin to reduce cost over time.
6. Spotlight benefits: Undertake projects and efforts in an iterative fashion based
upon, partially, the expected return on investment and/or assets (ROI/ROA).
Effective Planning
As organizations begin to plan for their SOA journey, they must strike a balance
between the technical and non-technical elements. SOA requires the IT organizations and the
business to operate in new and ever changing manners. A framework is needed that addresses
each of the above practices. The Service-Oriented Architecture Framework (SOAF) is
comprised of jurisdictions, each with equal focus, which speak to the practices. The
jurisdictions are interrelated and interdependent. The success of an enterprise SOA journey is
dependent upon applying equal focus to each of the jurisdictions of concern.
♦ Business Approach
♦ Business Value
♦ Architecture
♦ SOA Legos
♦ Projects
♦ Relationships and Outcome Management
The explosion of these stream will begin by addressing three of these jurisdictions
specifically business approach, business value, and architecture. The remaining jurisdictions
will be addressed later in this whitepaper.
One of the goals of SOA is to provide better alignment between business processes
and the IT functions that delivery those processes. This mapping enables process, and
ultimately enterprise, improvement long term. In order to perform this mapping one must 1)
Examine current enterprise processes and identify the required support functionality, 2)
Cultivate functionality from existing systems and assets, give birth to new functionality where
required, and guarantee that all services provide clear service-level agreements (SLAs) and 3)
Exploit the enterprise services by orchestrating services into processes, measure the alignment
to the enterprise strategy, and recognize maturity opportunities.

Business Value
Providing the business case for an SOA journey is unlike defending traditional
software projects. This is due to the realization of SOA benefits on an enterprise-wide scale.
SOA provides opportunities for increased value that are excessively higher than those of
traditional software efforts. This is accomplished through the optimization of business
processes utilizing shared services. Innovation through SOA is a key differentiator in building
a business case.
It is important to prioritize the development of services so that the SOA exhibits ROI
from the start. The “on-ramping” cost can largely be immersed into existing budgets. The
business case must account for these initial “on-ramping” costs yield benefits that accumulate
and accelerate in the long term.
Initial SOA investment impact can be reduced by methodically selecting the
appropriate capabilities to spearhead the SOA journey. Reuse of assets and capabilities will
ensure lower on-ramp cost for new application. The IT funding model will change over time
due to increased ROI. Traditional IT investment continues to increase as over time and as the
number of capabilities increases, which is drastically different from the funding mode l for an
SOA delivery mechanism. As the level of SOA adoption penetrates the enterprise and the
level of reuse increase the investment level will begin to stabilize and increased at a predictable
rate.
Architecture
Enterprises typically providing funding for and construct IT based upon each line of
business. A Reference Architecture (RA) is essential for an enterprise SOA. This is a long
term vision of evolution, two to three years, for the enterprise. An enterprise should spend
time and effort in defining architectural guiding principles and policies. The guidelines must
NOT be an endpoint unto themselves.
The RA must be service-centric, standards based and enterprise focused. Traditionally IT
is obtained or developed as a response to the requirements of a particular domain within the
enterprise and deployed for utilization by that domain. Shared capability approaches
stemming from code or component reuse have failed due to the project-by-project focus of
development efforts. Many times functionality is replicated through project-by-project
development approaches due to the fact that each project addresses a specific set of
requirements. A service-centric approach to delivery IT requires a shift in the development
and deployment mindset. Capabilities are designed, developed, and delivered once for reuse at
all levels within the enterprise. This leads to the SOA promises of reduced cost, fast time-to-
market, and agility in order to respond to changing requirements.
IT projects are typically delivered through the most expedient approach that will satisfy
stakeholder requirements. This often leads to the proliferation of technologies throughout the
enterprise. This leads to serious integration issues when the technologies have to interoperate
and share information. There have been previous attempts to provide standards-based
component models, for example Common Object Request Broker Architecture (CORBA) and
Distributed Component Object Model (
DCOM). These types of models experienced failure due to the implementation technology

required and supporting standards stalling in development. XML (Extensible Markup
Language), Web Services, and UDDI (Universal Description, Discovery and Integration) are
the foundation for a standards-based SOA for supporting re-use. The technology for
supporting this approach is readily available and truly platform agnostic.
As mentioned earlier traditionally IT has been delivered on a project-by-project basis
within the individual lines of business of an enterprise, the response of many enterprises to
this approach has been to institute enterprise architecture organizations. These organizations
were focused on technology selection for the enterprise and were not authorized to enforce
other recommendations. An enterprise SOA requires that organizations of this type be
provided with the authority required for full lifecycle management of the SOA, a standards-
based mechanism for defining, deploying, monitoring, and managing functionality at the
appropriate granularity and visibility levels. The required provisioning ecosystem must be
constructed from service-centric enterprise architecture (EA) which contains the appropriately
enforced governance principles and policies.
Requirements for an SOA Strategy
In order to realize the benefits of SOA there needs to be a balance struck between the
long-term enterprise goals and the short-term, immediate, business requirements.
Institutionalizing a series of operational, design, budgetary, operational, and provisioning
practices in the initial stage of an SOA journey can assist in establishing and maintaining this
balance. The deployment of cultural changing disciples must be performed in an incremental
and iterative manner. This will allow for the required organizational learning curve. An SOA
roadmap provides an iterative and incremental mechanism to continuously describe an
organization’s journey as they progress. A path for the SOA journey has three critical
characteristics:
1. Scope: An SOA roadmap should be comprised of six distinct, but interrelated
and interdependent, jurisdictions (Figure 1). The fundamental success of an SOA
effort is directly related to the successful execution in each of these jurisdictions.
An organization’s SOA roadmap should define and delineate the boundaries of the
SOA effort as well as establishes a flexible timeline for achieving their SOA
objectives. The SOA objectives of an organization should be divided into phases
that are manageable and that can be iteratively and incrementally realized.
2. Quality: An SOA roadmap will remain relevant for the life of the SOA effort by
being iterative and incremental as well as through the application of a “Mature &
Change” process at each major exit-point, milestone.
3. Maturity: An SOA roadmap is an “organic document” that is continuously
describes organizational experiences and lessons learned. As the SOA effort
matures, along the SOA roadmap, it reaches higher levels of complexity and
sophistication, but does so in a govern fashion. An SOA roadmap is created by
first assessing the current capabilities and disciplines of an organization and their
applicability to SOA.

Figure 1 Transformational Model
Building an SOA Roadmap
Creating an SOA roadmap involves four phases: Planning, As-Is Assessment, End
goal, and Definition.
Planning
An SOA effort is organized and defined in this phase. The SOA stakeholders are
incorporated into the process through various communication avenues and briefing, and a
mutually agreed upon priorities and constraints are established. The appropriate level of clear
communication is essential in this phase due to the involvement of representation from across
the organization. The outcomes of this phase include:
♦ A defined scope for the SOA
♦ Establishment of boundaries and alignments with peer IT efforts
♦ An illustrated business case to justify the SOA effort
♦ Defined current and future business objective alignment
As-Is Assessment
The establishment of metrics and measures of the current state of affairs is conducted
in the assessment phase. Current services and capabilities need to be identified as a potential
“on-ramping” point for the SOA effort. Pilot projects need to be identified as well in this
phase. By interviewing and questioning the SOA stakeholders an organization should examine

the jurisdictions of concern. The “as-is” state of each of the jurisdictions of concern needs
to be analyzed, base-lined, and validated. A mechanism needs to be devised to assemble the
examination of the following:
♦ Business Approach: Business strategies and processes are examined beginning at
the top level of the organization and working downward into each level and area
of the organization.
♦ Business Value: Summary of current cost and budgetary structures and cases of
value add to the organization.
♦ Architecture: Examination of “as-is” architecture, policies, and standards
♦ SOA Legos: Investigation of existing services, technical processes, tools, and
technologies
♦ Projects: Examination of existing systems, and on-going and forecasted projects
♦ Relationships and Outcome Management: Investigation of current governance
and organizational relationships, policies, and processes.
End goal
The end goal phase involves the determination and definition of the “to-be” state of
the organization, as it related to the SOA effort, and ensuring that there is cross-organizational
agreement.
♦ Business Approach: Relationship of the SOA end goal with business strategies
and processes.
♦ Business Value: Definition of metric and measurement requirements.
♦ Architecture: Organizational guiding tenets, requirements, reference architecture,
policies, and standards.
♦ SOA Legos: Ecosystem requirements for supporting shared services and tool
standardization.
♦ Projects: Alignment of SOA effort with projects and applications
♦ Relationships and Outcome Management: Relationship, governance, and
compliance structures and policies.
Definition
Organizations begin defining an SOA roadmap in this phase. As per the information
findings from the previous phases, a complete gap analysis should be conducted for the
organization’s SOA objectives and suitable timelines. The immediate events will be well
defined and detailed with future events being more in flux and fluid in order to incorporate
the lessons learned during progression.
♦ Business Approach: Alignment of opportunities based on the value added to the
business.
♦ Business Value: Roadmap of future metrics, cost and budgetary structures, and
benefits cases.

♦ Architecture: Roadmap for the immediate, medium-, and long-term reference
architecture.
♦ SOA Legos: Prioritization of shared services strategy and standardized processes.
♦ Projects: Impacts to projects and applications.
♦ Relationships and Outcome Management: Projected relationship and governance
structures, policies, and processes.
An organization’s SOA roadmap must be treated as an “organic document” that
continuously describes experiences and lessons learned of the organization. As the
SOA effort matures, along the SOA roadmap, it reaches higher levels of complexity
and sophistication, but does so in a govern fashion (Figure 2).
Figure 2 SOA “Mature & Change” Roadmap
SOA Legos
One of the most crucial elements contributing to the success of an SOA journey is the
institutionalization of a culture, throughout the enterprise, which cultivates the notion, and
expectation, of reuse. The discrete, reusable services and architectural elements that can be
combined to author composite applications and service ecosystem for the building blocks, like
legos, of an SOA.. The “SOA legos” form the basis of a catalog of enterprise capabilities
over time and each is added to this catalog as it is implemented. The ROI of an enterprise is
demonstrable and steadily increases as the number of capabilities in the catalog increases.
This is due to the amount of new code development and service ecosystem needs for future
projects are reduced. There are two categories of “SOA legos”: software legos and
organizational legos. Software building blocks are such things as code, services, applications,
data models, processes, and components. Organizational building blocks as things such as
best practices, lessons learned, standards, tools (development, deployment, and management).

By utilizing a collection of building blocks organizations can develop applications. The
building blocks form the enterprise infrastructure and should be developed incrementally and
refined iteratively and build-up the enterprise’s target architectures.
The ability to clearly define and implement a service at the proper level of granularity and
with the appropriate level of coupling is essential to the success to the SOA journey. The
implementation process must be consistent and repeatable process. At the center of any SOA
is the notion of a service which is defined as “a mechanism to enable access to one or more
capabilities, where the access is provided using a prescribed interface and is exercised
consistent with constraints and policies as specified by the service description”2. A service can
be illustrated by three components:
♦ Interface: Provides a means for interacting with a service, which is standards-
based, by users in order to access the service functionality according to the
service contract.
♦ Contract: Is an agreement by two or more parties which specifies the
conditions of use of a service including the service purpose, functionality, and
constraints on the real world effect of the service.
♦ Implementation: Is composed of the actual code, application interface, or
other technology asset exposing functionality through a service. Services are
either exposed by creating new applications based upon services or from
existing applications.
Exposing services can be accomplished either from existing applications or by developing
new applications based on a service-centric paradigm. One of the initial technical questions,
and probably the most difficult to resolve, is which services to implement first? When
building the “SOA lego” baseline for the SOA journey, organizations typically begin with the
simplest services at the core of the enterprise. These services should be business-unit, line-of-
business agnostic and gradually migrate to business-unit specific capabilities. By following this
type of progression will allow organizations to be comfortable with the process of
constructing and reusing services without having to become mired in complexity. Some of the
initial services organizations build are typically services that perform infrastructure
functionality such as logging, monitoring, auditing, and error handling.
Services have both functional and non-functional characteristics. The main functional
service characteristics are its execution model, exchange model, and level of complexity. A
service’s execution model describes the manner in which a service is invoked and the
communications exchanged: synchronous or asynchronous. The exchange model of a service
describes the method, direction, of message exchanges: unidirectional or bi-directional. A
service’s level of complexity refers to the granularity of a service.
Service granularity is the level of abstraction of a service. Services are either fine-grained
or coarse grained. A fine-grained service is one provides specific capability, for example as
standards-based of invoking an application programming interface (API) or manipulating an
enterprise data object. Shared services that provide common business operations are also
typically fine-grained services. Coarse-grained services are those services that provide a
mechanism for accessing high-level, complex business capabilities, such as employee on-
ramping and mission planning. Coarse-grained services are often long running and involve the
coordination and collaboration of finer-grained service execution.

The non-functional characteristics of services involve things such as volume requirements,
quality of service (QoS), and execution length. Portions of the service contract are comprised
of these dynamics.
Service characteristics and functionality permit the categorization of services in layers of a
service-oriented architecture. This categorization serves in the decision making regarding
service utility and prioritization.
The IT disciplines required to realize SOA should also be considered as “SOA legos”.
Such disciplines include a versioning strategy, service provisioning, testing, and verification and
validation. It is essential that adherence to IT disciplines be strictly applied and enforced. One
of the principal roles of SOA governance is to ensure the scope and enforcement of such
standards.
An SOA ecosystem will be required to deliver the “SOA legos”. A common ecosystem
component is a service registry. A service registry provides a mechanism for service
consumers to discover available services and for service providers to broadcast the existence
of services. One of the critical features of SOA is the ability to discover and reuse capabilities
that conforms to a needed contract at the time it is needed. Several other ecosystem
components for developing and provisioning services exist and are considered “SOA legos”:
♦ SOA fabric or “Enterprise Service Bus (ESB)” which provide dynamic routing,
mediation, and translation capabilities
♦ Identity management and Enterprise Security frameworks that provide a
security infrastructure
♦ Configuration management for managing the deployable components and for
configuration of hardware and services provisioning at runtime
♦ Business Activity Management (BAM) for measuring SOA performance
against defined contracts and SLAs
♦ Portal technology for multi-user experience delivery
There are several technologies and platforms available for providing the necessary
ecosystem components. The basis for SOA must be standards based which allows for a best-
of-breed approach to acquiring the necessary components. It is best to deliver the “SOA
legos” and ecosystem in an iterative manner.
Projects
Upon establishing an SOA Reference Architecture (RA), enterprises need to begin to
considering which services are need to provide functionality and ROI required by the
enterprise, when and how they will be developed and deployed. This is an example of an SOA
Roadmap, strategy that is intended to guide an enterprise along the SOA journey by assisting in
prioritizing the tasks of developing, reusing and producing services.
Efforts must begin with an understanding of the existing projects, applications, and
functionality that can be reused. This process involves creating an application inventory and
project catalog. Functionality that is specific to and resides in applications or projects may be
safely deemphasized. It is important to capture relevant features such as:
♦ Current applications functionality, services and dependencies
♦ Level and capability of existing services

♦ Inter- and intra-dependencies of current applications, planned and in-progress
projects, and any related development and maintenance issues
♦ Current common service usage
♦ Application development metrics including budgets
♦ Application development information, accessed and delivered
♦ Application process and workflows
♦ Business information; SLAs, QoS, and related non-functional
♦ Project schedules and delivery milestones
The product of this process analysis will provide a base understanding of the current
enterprise capabilities and projects and will assist in identifying common functionality and
initial service selection.
Relationships and Outcome Management
The most significant challenges with SOA are the cultural and sociological changes
required. The establishment of tighter coupling between IT divisions is essential in order to
facilitate the focus on delivering overall business value rather than specific departmental value,
shared services versus siloed applications.
There seem to be two recurring fundamental themes associated with this aspect of
SOA. The first being, it is crucial to provide the necessary education to the organization not
only in the technical aspects and concepts of SOA but also the cultural impacts of SOA.
The second theme is that relationships and governance is about considering the
adoption of SOA as a change to the entire organization rather than simply the latest technical
trend. By achieving and retaining sponsorship from senior executive will provide assistance
for different divisions of the organization to interoperate with each other, and guarantee the
appropriate level of authority to obtain compliance along with the evangelization of the SOA
effort.
Organizations construct relationships and governance is various manners which suit
their maturity levels and the direction of their organization. The most effective mechanism,
for initial SOA implementations, is a centralized organization. This is followed by a federated,
distributed, governance model and ultimately followed by an autonomous hierarchical
mechanism. The governance organization must take a holistic view of organizational tenets,
structure relationships, funding, process for operations and tools, standards, change
management, and skills retention. This organization will assist with deciding,
institutionalizing, and enhancing the processes related to answering questions such as:
♦ Who defines and modifies the organization’s systems?
♦ What quality of service must be provided?
♦ Who is responsible for the payment of service development?
♦ Who is responsible for the payment of the service ecosystem?
♦ Who is allowed access to the services?
♦ How are services exposed to external consumers?

♦ How will success of the SOA be measured?
♦ How will the interdependencies among services be managed?
The relationship and governance phase will ensure that the maturity and business value
delivered by the SOA effort can be measured as well as define the corrective action that must
be taken if metrics are not being achieved.

Implementing a Pilot Project
Once an organization has developed its SOA roadmap the time comes to begin
executing against that roadmap, however many organizations struggle on how to get started
implementing an SOA. What is needed is a prescription that describes a mythology for
selecting the appropriate project or application. Many say that this pilot project should be one
that addresses some “low hanging fruit” and has minimal impact and risk to the organization
and not one that would have a “big bang” effect on the orgranization. One such prescription
is defined in this section.
Important Steps in a Successful Pilot Project in SOA
Step 1: Identify the Objectives for the SOA Pilot
The valuable SOA ecosystem insight gained from an SOA pilot project will be
extremely informative as an organization progresses to implementing an enterprise SOA. The
pilot project is an opportune time for experimentation and learning by trial and error. The
organization should clearly define and articulate the objectives for the pilot, which may include
this such as:
♦ Consolidation of duplicate applications or functionality
♦ Development of a reusable service for usage by multiple departments
♦ Gathering lessons learned that can be leveraged in the progression along the SOA
roadmap
♦ Gaining knowledge and understanding of the tasks involved in provisioning
services into production as well as the daily operational management tasks required
for an SOA.
♦ Demonstration of a successful SOA implementation in order to clearly showcase
the benefits of reuse and consolidation
Step 2: Construct a Cross-Organizational SOA Team
In order for an SOA pilot, effort, to be successful there must be support and
cooperation from across the organization. A key step is to establish a cross-organizational
team with representation from business development, operations, engineering, security, etc. It
is imperative that these stakeholders experience both the failures as well as the benefits by
participating in the SOA team, even though they may not be involved with the pilot on a daily
basis. By conducting regular meetings and communications, territorial issues and other
concerns will be exposed (Figure 3).

Figure 3 Notional Governance Structure
Team members must be selected wisely considering their ability, and willingness, to
participate in addition to their on-going responsibilities. Time commitments for both meeting
participation and reviews must be outlined and the team members need to be asked for
commitment agreements in the beginning. Another key element is a communication strategy,
which needs to be established and shared that includes a manageable amount of updates and
should be sent to each team member. It is essential that the organization adhere to its
schedule in order achieve credibility for the SOA pilot and obtain feedback, continued support,
and participation.
SOA migration involves a major shift in the development and provision of
applications paradigm. The most difficult challenge in migrating to SOA revolves around the
cultural and sociological aspects of organizations because many organizations see SOA as a
disruptive technology and view it as the demolition of traditional silo-based organization.
Selecting to appropriate demographics for the cross-organizational SOA team is probably the
most crucial aspect of a pilot.
Step 3: Ascertain the Appropriate Pilot Project
Selecting an appropriate SOA pilot is essential in order to dispel any misconceptions
by those who may be skeptical of the SOA paradigm. The SOA pilot must exhibit the benefits
of SOA and demonstrate the potential without greatly impacting the organization. A

successful SOA pilot provides credibility and could result in wider SOA adoption and
deployment.
There are many questions to consider when selecting an SOA pilot project some of
which are:
1. Develop new services or reuse existing?
While developing new service may be simpler initially, the typical first step, by many
organizations, is to wrap existing legacy systems with a Web service interface.
Wrapping legacy systems provides benefits that can be measured quickly.
2. Should the pilot be of high or low visibility?
Organizations struggle with the visibility of application to utilize in an SOA pilot and
must weigh the benefits and risks of choosing a pilot that would possess a high level
of visibility across the organization against those of a lower visibility pilot.
Low visibility pilots
♦ Are not as critical to the organization if issues should arise
♦ Allow for triage without constant inspection
High visibility pilots
♦ Organizational benefits are achieved sooner and across multiple
departments
♦ Determine stakeholder requirements and if a visible success is warranted
♦ Come with various attitudes and associated political agendas
3. What type of application should the pilot address?
Portals are the typical SOA pilot applications selected. Portals provide a provide users
a single view based on data gathered from multiple sources. Portals are often good
selections because they provide a tangible results and a hands-on way of experiencing
the benefits of SOA. In direct contrast are back-end integration pilots, which can be
valuable, such as data synchronization systems which make it difficult to experience
the benefits of SOA.
4. Who should the audience be for the pilot?
The selecting the audience of a pilot offers many advantages and disadvantages when
choosing between internal and external users. If the audience is only internal to the
organization users can be protected from any potential issues, however the expressed
reactions may not be as valuable in furthering SOA adoption. In direct contrast with
this is an external facing pilot where the reaction could provide greater value to SOA
adoption across the organization.
5. What type of service should the pilot be?
Along with selection appropriate type of application for the SOA pilot, for example
user-facing applications like portals or back-end application like data synchronization,
organizations must select the type of service the pilot should offer. Two possible
options are services that expose existing data for use by new consumers and

transaction-based services that generate new information or initiate new business
processes.
Many organizations select query-based services to remove barriers to existing data
assets and avoid transaction-based services due to their higher risk of issues that can
lead to data loss. Over time, these query-based services are extended with
transactional operations, since most services require both. As an example, a
telecommunications self-service web site should be able to provide information related
to things such as service requests and billing history as well as self-service provisioning
(transactional operations).
Step 4: Measure Results
The organization’s management staff often requires tangible proof of pilot success
and ROI. A technique is required in order to continuously capture data, especially is the pilot
timeline in a significant in length, in order to possess accurate and readily available data at pilot
completion.
Measuring factors for SOA
Business Agility
Organizations can compare the time required to modify or add a feature to a non-SOA
application against performing the similar tasks to a service in order to determine its ability to
respond to every changing environments and requirements.
Shared Service Reuse
Determining the number of reuse instances of shared services can be an effective
measurement of the ROI provided by an SOA. Reusing shared services leads to cost
avoidance or reduction of developing, maintaining, and operating services that are only useful
for a specific purpose or organizational element. For organizations to calculate ROI of shared
services there are some additional fundamental metrics required:
♦ Cost to build/maintain/operate a shared service. Cost of having a shared service
♦ Cost to build/maintain/operate pinpoint service. If organizations have deployed an
effective SOA ecosystem this should be similar to that of a shared service.
♦ Cost to reuse an existing service developed externally. This cost is incurred by
organizations when services, developed by someone else, are reused. It is crucial
that organizations control this metric in order for an SOA to succeed. Reusing a
service is in essence integration and an SOA must be structured to manage the
costs of integration.
Web Services Adoption
The number of Web services can provide an indication of the breadth of adoption for
the underpinning technology for SOA. It can also be a negative indicator as well, the larger
number of Web services would indicate that the reuse of services is low and that the SOA
effort needs to be revising.
Consumers of Shared Services

The number of consumers reusing shared services can assist organizations in
measuring the SOA adoption level and breadth. This indicates the level of shift in the cultural,
sociological, aspects of the organization. While this metric may not be directly correlated to
the business benefits for SOA, it is an important measurement nonetheless.
Conclusion
The goal of this whitepaper has been to provide a perspective on the necessary
considerations for planning and deploying an SOA within an organization using a blueprint for
creating a roadmap to be utilized in planning, development, deployment, and assessment. An
explanations were offered for why it is important to develop an SOA roadmap for an
organization’s SOA journey, describing how SOA relies on successfully institutionalizing a
organizational society of reuse, why it is essential for organizations to understand the current
reality in order to capture common capabilities, and how to establish an organizational model
that supports the SOA journey and a governance model.