A CASE STUDY OF SERVICE ORIENTED ARCHITECTURE IMPLEMENTATION

AND GOVERNANCE
Alexander Coppola, Bryant University, Smithfield, RI 02917, acoppola@bryant.edu
Suhong Li, Bryant University, Smithfield, RI 02917, sli@bryant.edu
ABSTRACT
Service Oriented Architecture (SOA) has received increased attention from practitioners and
academicians. SOA allows companies to reuse available components/services and build flexible
systems that implement changing business processes quickly. However, SOA is not well
understood and few studies have addressed its concepts and implementation. The purpose of this
study is to discuss the implementation and governance issues of SOA based on a detailed case
study at a large financial services company. The results show that SOA can transform an
organizations information technology infrastructure and reshape project deliverables. However,
developing an SOA infrastructure can take multiple iterations and years to develop. The results
also demonstrate the importance of understanding not just technology, but also business value
and processes when implementing SOA.
Key words: Service Oriented Architecture (SOA), IT Governance, Service Repository
INTRODUCTION
Technology changes at a very rapid pace and for businesses to stay competitive they are forced
to adopt new processes. Information Technology (IT) investments can account for a significant
portion of a companys expenses. Infrastructure is managed by those with different expertise in
the IT field. Whether they are application specific or programming language specific, there are a
lot of intricate balances between resources and technology. A company can become tied to
certain systems, languages, applications, and skills which can make technology migration a
difficult process. Companies have long sought to integrate existing systems in order to
implement IT support for business processes that cover all present and prospective systems
requirements needed to run the business end-to-end. The inception of Service Oriented
Architecture (SOA) is rooted in the idea, that a company can become more flexible by utilizing a
standardized architecture to better support the connection of various applications and the sharing
of data [2]. The ability of SOA processes to create an architecture that would let IT develop and
modify the supporting applications as business needs change is important in todays dynamic
business environment. Because SOA is still a new concept, it is not well understood by
practitioners and academicians. Confusions exist in its definition and few studies have discussed
its implementation and governance issues. To fill this gap, this paper first discusses the concept
of SOA and then presents a case study of a SOA implementation at a large financial services
company.
CONCEPTS OF SOA
IBM defines SOA as an integration architecture approach based on the concept of a service. The
business and infrastructure functions that are required to build distributed systems are provided
-5041-

as services that collectively, or individually, deliver application functionality to either end-user

applications or other services. In SOA, information systems are decomposed into services.
Every service should perform a meaningful unit of work that is related to a business process.
SOA allows businesses to retain their existing assets, instead of replacing them with more
expensive systems. A new layer can be established to add new functionality on top of existing
assets to respond to market changes without the need to spend time and money on new systems.
There are many benefits of SOA, including increased business agility and flexibility; reduced IT
development costs; ability to re-use existing assets and to integrate them with future assets;
ability to integrate disparate IT systems so they can communicate with each other; ability to
create a flexible IT infrastructure that can meet the business needs with the ability to support
future enhancements; and reduced total cost of ownership (TCO) by extending the life of assets
and by utilizing non-proprietary technology [2]. These benefits highlight why SOA has become
a buzzword into todays business world as organizations need to deliver richer business solutions
faster and at lower costs.
There are three stages in the maturity of an SOA model including: Develop Web Applications,
Develop Composite Applications, and Automate Business Processes. The Web Application
Stage focuses on providing rich client based solutions for internal and external users. This can
include web-based CRM, ERP or other applications that can be accessed through a browser [1].
The second stage of Developing Composite Applications includes providing information and
data from a variety of sources and making this available to internal and external customers.
These requests would include building multiple applications that could be accesses through a
single portal, web based desktops for users, and role based access for different users [1].
Automating Business Processes is the stage where the application, data, and infrastructure allow
users to access data in a timely manner to perform their roles. At this stage the organization
should be able to consolidate multiple business systems into a single system [1]. This should
allow business users to transition their processes into one end-to-end business process
management, requiring new governance and organizational models that will represent this new
single system.
As organizations mature around their own implementation of SOA, a governance process must
be established in order to continue to reap these benefits. Governance is defined as a set of
processes, tools, and organizational structure that is essential to delivering SOA benefits. The
primary responsibilities of the SOA governance should include: publication of standards and best
practices, advertisement of SOA achievements, and the promotion of re-use at a project level [3].
There are many tools available to help facilitate the management of these governance processes
and to store all of the metadata throughout the lifecycle of a service. These tools are commonly
referred to as SOA Repositories [3]. The primary purpose of the repositories is to store detailed
metadata in order to manage and govern the assets through development and into production.
The repository should also store other types of metadata that include process mappings, business
rules, relationships, reference data, documentation, etc. Beyond storage the repository allows
greater governance as workflows can be setup to trigger certain approvals to make sure that
services are reviewed by decision makers.

-5042-

RESEARCH METHODOLOGY
The aim of this research is to investigate the experiences of an organization on a SOA
implementation. Specifically, the research questions include: status / history of SOA
implementation; organizational changes; implementation challenges and benefits; and
governance processes involved. This study is based on a real financial institution although the
name of the company as well as certain details about the nature of its business, its geography and
the names of its employees has been changed to protect confidentiality. Four subject matter
experts were interviewed for the case analysis: lead architect, data warehousing architect, and
two project managers. The material gathered is from both interviews and infrastructure / project
documents.
CASE ANALYSIS
Background
This company is one of the worlds largest providers of financial services. They provide services
for retirement savings plans and are a leading provider of retirement plans for not-for-profit
institutions. In addition to more than 300 mutual funds, they also offer discount brokerage
services, retirement services, estate planning, wealth management, securities execution and
clearance, life insurance and much more. This company is responsible for many innovations that
are standards in the industry today. They reinvest a substantial portion of their revenues each
year back into technology to deliver new products and services to investors. And they are
consistently recognized by industry surveys and publications for providing some of the highest
levels of customer support.
Status/History of SOA Implementation
In 2002 this company formed a development group that was made up both Java and Mainframe
developers to begin a proof of concept on the idea of using services to support applications
instead of the commonly used thick client approach. This pilot produced twenty Java services
that were called by three different applications. At the time these services could loosely be
identified as the web services that are commonly referred to in today SOAs definition. But at
the time, the pilot proved to reveal great insight into how this organization could migrate from an
environment where the data layer and business layer were tightly coupled with the presentation
layer consisting of GUIs and screens produced by the application.
Organizational Changes
By 2005 there were two hundred unique services that supported both mainframe and distributed
applications throughout this organization. The Business Engineering team was formed which
consisted of subject matter experts who oversaw the implementation of new services and the
updates of existing services. Each group member was assigned to one of the technology
projects. As the number of services grew, it became crucial to effectively govern them.

-5043-

A web service or business service as it was commonly referred to, was defined with certain
characteristics, including: platform neutral (XML, SOAP over HTTP(s)), programming language
agnostic, distributed / network addressable, loosely coupled, and implements business in a
vendor neutral industry standard. Most of these characteristics are very common for services in
SOA. The business service interface should consist of: service name, request document,
response document, SOAP fault codes and messages, visibility for designers-developers-testers,
and operational definition (WSDL).
Each business service was defined through a WSDL. This specification provides an XML format
for the document that describes a service as a set of endpoints containing either documentoriented or procedure-oriented information. A master XML schema was also stored for all of the
WSDLs as a reference document. Most services were written in Java, later being followed by
.NET technologies. But the language itself did not matter since the service does not have a
reference to which application it is being used by. Each developer was encouraged to utilize the
service framework that provided certain standards that all services should be used. These
standards include Logging, Authentication, Authorization, SOAP headers, Errors for SOAP
fault, business specific XML, and logical access to the physical databases. These frameworks
helped to reduce the amount of testing for quality assurance engineers as this piece of code can
be eliminated from their test routines.
Implementation Challenges and Benefits
The implementation challenges and benefits of SOA can be illustrated by a project implemented
at this company. The long-term goal of this project was to replace a number of disparate
workstation applications currently installed on desktop workstations used by client facing
associates. The current suite of applications performed numerous business functions including:
Financial Transactions and Updates; Account, Client and Fund Inquiry; Account, Client and
Fund Maintenance; Customer Correspondence, Reporting and Analysis; Resource Management;
and Relationship Management. The use of disparate systems within the client facing group leads
to fragmentation of client data, and inefficient workflows and processes to bring that data
together while servicing the client. In addition, each workstation application implements its own
proprietary architecture, including decisions workstation code base, frameworks, backend data
sources, and the use of business services and third party integration. This leads to increases in
time and the cost to maintain and support these business functions.
Starting in 2004, this company began to build new workstation applications to address the
problems in the old system. Currently, the majority of the functionality is available to associates
while certain components are still being worked on. The new application is connected to backend
data sources via XML business services. Each set of business functionality was implemented as
an independent sub-system component based upon the .NET Framework. Each sub-system will
be integrated into the application, but can be reused independently from the application by
another client application that implements the framework. The application employed the use of
XML/Http web services for connectivity to business data and also utilized a telephony client to
accept screen pops for incoming calls via VRU. The only specific hardware requirements that
were needed on the workstation were Windows XP and Microsofts .NET Framework as well as
the companys own framework. The proposed architecture solution was to provide a central
-5044-

application infrastructure for client facing associates functionality. This provided the
opportunity to migrate non-integrated legacy applications off the associates workstations and to
replace them with a single desktop application. The application also provided a single user
interface with a common look and feel.
This project exemplifies one of the challenges that SOA can present: transforming the
application architecture is a difficult process. This project has been in development for 4 years
and is considered a major initiative that has been supported by senior management. The process
of disseminating the business model is especially difficult as this system was supposed to replace
a number of systems that provided all of the access for these associates. As mentioned earlier,
the decision of how granular and coarse the service should be developed is always an issue.
This issue caused performance problems in the first inception of the new system, associates
claimed the performance between the different functional screens decreased as they used the
system heavily. Design changes were implemented to avoid switching between interfaces less
frequently. Associate performance testing is still performed quite often as the design team has
revised the system through multiple iterations.
One of the primary benefits of SOA is to its ability to allow a company get solutions to market
faster and to anticipate and respond to competitive threats quicker. The new architecture has
reduced the companys time in releasing new functionality. It also will reduce integration costs
for future systems, providing improved business agility and flexibility, improved asset reuse, and
an improved return on investment. The standardization of such technologies as XML, SOAP,
and WSDL that address the service security and management also supports the reduction of
future integration costs. Another benefit is the development of new skills and knowledge among
the IT professionals involved in the project. The people who were involved with introducing
SOA will be able to make more informed decisions about technology selection, the timing of
adoption of the various Web Service standards, and hopefully help manage other large-scale
SOA projects. This knowledge is not always mentioned as a benefit of SOA, but each companys
architecture is unique and having resources who understood this architecture and can apply it to
current business processes is very valuable.
Governance Process
As the complexity of the SOA environment grew from multi-year projects like the one described
above, the need to govern services also grew. In 2004 a service repository was chosen to store
all of the services present in the environment. The metadata stored about each service was very
detailed, including request and response documents, WSDL references, database tables that were
accessed, producing project, application dependencies, etc. This tool became very valuable for
many different resources. Analysts could use the tool to look up the current version of the
service being developed or one that was already in production. Data engineers could quickly
research which services accessed certain databases and the exact columns being used. Impact
analysis could be performed since the repository also stored applications, databases and server
information. As the number of services grew so did the importance of the repository. Analysts
could research opportunities to reuse components by looking at which applications used specific
services through the repository. The repository is also integrated with the project management
tool so that release managers can produce reports for release meetings containing all of the
-5045-

components that the current release entails. The company is currently looking into a discovery
tool that will integrate with the repository and identify all of the services in each environment
(prod, dev, sandbox, etc) and then relay this information to the repository. The tool will also
provide performance metrics that can be used by developers for testing.
The repository provides a great knowledge base on which governance can be established.
Governance is also performed at the architect level through a review process called Pathfinder.
One of the objectives of Pathfinder is to enforce the best practices and coding standards that are
published for this business unit. The Pathfinder review team consists of project managers,
architects as well as project participants. One debate that has occurred about the reusability of
services is the notion of redundancy. As the number of applications decreases, so too will the
opportunity for reuse, but at the same time this reduces the number of redundant systems. This
same debate occurred when services were first developed. On one hand, mainframe services
were too big and encompassed many different functions which caused performance issues and
complicated development and testing. On the other hand, the distributed applications had
services that were too granular, and the changes came at a faster rate which incurred more
development time. These services were also less efficient and were hardly reused. In both of
these scenarios all parties have tried to find the balance between the two opposites so that they
can satisfy their needs for better performance and stability.
CONCLUSION
As more and more organizations embark on major enterprise-wide business initiatives such as
SOA, they will need to think more strategically about how to integrate their diverse portfolio of
applications. However as the financial services case shows, developing an SOA infrastructure
can take multiple iterations and years to develop. Considerable thought must be given as SOA
needs approval from an architectural and managerial standpoint. The need for organizational and
role changes in SOA are evident, although naming and defining the specific changes is
dependent on the unique structure of the organization. It is no longer sufficient to just
understand the technology when broad understanding of business value and business process is
required. It changes the way we design, develop, and maintain IT systems. It is not about
building systems anymore; it is about the reuse of components and services. Nor is it about
building specific functions; it is about implementing cross-organizational processes. These
challenges are the biggest mitigating factors for an organization that is implementing SOA.
REFERENCES
[1] Cox, D.; Kreger, H.(2005). Management of the service-oriented-architecture life cycle. IBM
Systems Journal. 44(4), 709-726.
[2] Koch, C. (2007). Reaping the Big Business Benefits of SOA, CIO Magazine, July 2, 2007,
Retrieved March 1, 2008 from http://www.cio.com/article/print/121952
[3] Lamont, J.(2008). Leveraging SOA for Business Value. KM World. 17(1), 20-23.

-5046-