A Case Study of Service Oriented Architecture Implementation

A CASE STUDY OF SERVICE ORIENTED ARCHITECTURE IMPLEMENTATION AND GOVERNANCE Alexander Coppola, Bryant University, Smithfield, RI 02917, [email protected] Suhong Li, Bryant University, Smithfield, RI 02917, [email protected] 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 organization’s 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 company’s 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 today’s 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 today’s 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 world’s 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 SOA’s 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 Microsoft’s .NET Framework as well as the company’s 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 company’s 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 company’s 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-