Case Study: SOA Governance Scenario

Citation preview

Martin Keen Adeola Allison Asit Dan John Falkl Andrew Hately Dinah Peng Jon Richter

Redpaper Case Study: SOA Governance Scenario

This paper is one in a series of service-oriented architecture (SOA) papers that features a case study involving a fictitious company called JKHL Enterprises (JKHLE). The focus of the case study in this paper is the challenges and solutions of applying SOA governance to the creation and reuse of services and the enforcement of standards and best practices. This paper describes how to apply the realization patterns of the SOA Governance Scenario to solve the business and IT challenges as they relate to the case study.

© Copyright IBM Corp. 2008. All rights reserved.

ibm.com/redbooks

1

Introduction to the case study JKHL Enterprises (JKHLE) is undergoing a set of fundamental business changes in an effort to ultimately maximize profits. JKHLE has decided to adopt SOA principles to address the business and IT challenges that it faces. The JKHLE team is focusing on solving the challenges that are presented by creating new customer accounts in a consistent manner throughout each of the sales channels. This SOA adoption initiative is known as the Account Open Project. Using an SOA approach will allow for a more rapid implementation and greater flexibility for future changes that the business might need. Note: For more detailed information about the case study, refer to Case Study: SOA Account Open Project Overview, REDP-4376. The case study that we described in this paper includes the following key actors and roles: ► ► ► ► ►

Jacob Freeman, Lead Business Services Champion Melissa Clark, Vice President of Finance, Americas Carol Jones, Service Registrar Samantha Williams, IT Portfolio Manager Adam Kloud, SOA Director

Account Open Project challenges JKHLE is plagued with certain dysfunctionalties surrounding their SOA implementation. Overall, they are not achieving the following intended business agility goals: ► They are struggling to identify new service candidates and to prioritize these candidates. ► They are having significant issues with service reuse (or lack thereof). ► Adoption of standards is haphazard at best. ► Governance of changes and versions for services is crude and unrefined. ► There is no way to enforce operational policies consistently across the SOA runtime environment.

2

Case Study: SOA Governance Scenario

Account Open Project requirements SOA governance helps with the proper definition of roles and responsibilities within an organizational structure. JKHLE plans to use the SOA Governance scenario to help govern the creation of new services, reuse existing services, and comply to standards and best practices. This section describes the organization structure of JKHLE and lists their requirements for SOA governance.

Organizational structure Figure 1 shows the IT organizational structure of JKHLE. The groups and roles shown in Figure 1 are defined in Table 1 on page 4 and Table 2 on page 4.

CIO Business Admin Domain Owner

New Business Dev. Domain Owner

Release Mgmt Domain Owner

Sales Domain Owner

Product Domain Owner

Finance Domain Owner

Head IT Strategist

Chief Architect

SOA Executive Sponsor

IT Executive Steering Committee

Business Relationship Director

Business Relationship Directors

Business Relationship Director

Business Services Champion

SOA Project Manager

Business Analyst

Finance Domain

Business Analyst

………

Typical Domain

Domains

SOA Director

SOA Board

SOA Chief Architect

Service Registrar

SOA Data Architect

Service Developer

SOA Security Architect

Service Architect

Integration Specialist

SOA Operations Architect

Development Toolsmith

Service Tester

SOA Core Team SOA CoE

Figure 1 JKHLE IT organizational structure

Case Study: SOA Governance Scenario

3

Table 1 Groups within the JKHLE organization Group

Description

SOA Board

Oversees SOA Governance process, provides recommendations to IT Executive Steering Committee.

IT Executive Steering Committee

Ultimate decision makers for decisions regarding service and IT related matters.

SOA Core Team

Group of business and SOA IT enablement expertise that oversees the implementation of SOA related activities.

SOA Center Of Excellence (CoE)

The larger SOA Core team, SOA CoE and business domain owners that decide on the business objectives, imperatives and decisions that drive SOA enablement.

Table 2 Roles within the JKHLE organization

4

Role

Description

SOA Chief Architect

Oversees all SOA architectural decisions.

SOA Security Architect

Oversees all security considerations for SOA.

SOA Project Manager (PM)

Manages all SOA related projects.

SOA Operations Architect

Orchestrates SOA related operations activities.

SOA Data Architect

In charge of date related management for SOA.

Service Tester

Tests services for SOA compliance.

SOA Integration Developer

Integrates services into SOA ecosystem.

SOA Director

Leads SOA Board and manages all SOA initiatives.

Business Relationship Director

Per Line of Business (LOB), manages SOA related business matters.

Business Service Champion

Champions business related SOA requirements. Drives business priorities into the service portfolio with the help of the Business Relationship Directors.

Business Analyst

Performs business analysis for SOA services.

Service Registrar

Manages the service metadata and ensures that the advancement of services through the life cycle is consistent with the standards defined.

Case Study: SOA Governance Scenario

Role

Description

IT Architect

Aligns SOA and Enterprise Architecture needs.

Service Architect

Architects individual services.

Service Developer

Develops individual services.

IT Portfolio Manager

Manages the portfolio of IT relates services.

Integration Specialist

Implements/integrated services into IT infrastructure.

Development Toolsmith

Ensures integration with business back-end as well as the proper functioning of the development environment.

Configuration Librarian

Generates CIs in change management database.

Release Specialist

Creates and certifies release packages.

Security and Operations Specialist

Determine significance of events from operations.

Compliance Auditor

Determine if events represent a compliance problem (intrusion, fraud or availability impacting financial reporting).

Availability Analyst

Determine outcome for monitoring events (real service outage, or something handled in IT capacity plan).

Change Manager

Decides and records decisions about how to handle an incident, change request or availability (service outage) report.

The organization is headed by an IT Executive Steering Committee (ITESC) that is led by the CIO. The domain owners within the ITESC own and are accountable for the business functionality within their proper business domain. These domain owners report to the CIO, but they also have direct reporting responsibilities within their business domain. The ITESC also lists key technical roles. These technical roles along with the domain owners strive to achieve a confluence between business and IT. The next layer of the organizational model shows the Business Relationship Directors and the SOA Board. The business relationship directors provide insight to the domain owners on priorities for that particular business domain. They also work with the SOA Board to give insight on what business functionality is needed. The SOA Board is in charge of defining and updating the strategy and direction for the SOA initiatives, the high-level direction of the architecture, and

Case Study: SOA Governance Scenario

5

properly directing the service portfolio with the guidance of the Business Relationship Directors. The SOA Core Team takes direction from the SOA Board to help implement the required services. The role of the SOA Core Team is one that helps define the various processes throughout the service life cycle as well as standards and best practices around those process to ensure that the processes are properly communicated, enforced, and evolved. Like the other layers of the Center of Excellence (CoE) organization, the SOA Core Team also has representation from both the business and IT perspectives.

Requirements The JKHLE ITESC has defined the following requirements to address the challenges of SOA governance.

REQ-01: Govern how new services are created JKHLE continues to introduce new services, particularly with the development of the Account Open process. Challenges exist on how to extend the current IT governance model to embrace these new services and to understand the roles involved. Note: For solution details, refer to “Regulation of New Service Creation” on page 9.

REQ-02: Reuse existing services at every opportunity The JKHLE ITESC is concerned that services with similar functionality exist across the enterprise. In many cases a pre-existing service could have been reused but differences in terminology, disputes about entitlement, and problems in enhancing services have prevented this. Note: For solution details, refer to “Getting More Reuse of Services” on page 11.

REQ-03: Enforce standards and best practices across JKHLE The JKHLE ITESC wants to see a greater use of standards throughout the organization to help reduce errors that arise throughout the service life cycle. The JKHLE ITESC also wants to see best practices compliance to ensure consistent development, deployment, and operations of services. Note: For solution details, refer to “Enforcing Standards and Best Practices” on page 16.

6

Case Study: SOA Governance Scenario

Applying the SOA realization patterns to the case study JKHLE intends to use the realization patterns of the SOA Governance Scenario to help solve their governance problems. By implementing these realization patterns, JKHLE can secure value from: ► Governing new service creation and determine priorities and funding for the establishment of services. ► Identify who owns services and drive better requirements against services to harbor reuse by establishing service level agreements. ► Establish consistent use of business terms across services and data sources. ► Ensure services are adhering to standards and best practices, thereby reducing risks across deployment and management. ► Ensure a consistent service change management capability and a more refined, explicit versioning process for services. ► Enforce a starter set of WS-Policy based domains across the runtime environment. By not implementing the realizations in this scenario, JKHLE stands to lose: ► Increased project risks due to inconsistent approaches. ► Increased cost due to non-interoperable services. ► Lengthened time to market (slower speed to market) due to longer project time frame. ► Increased business risks due to redundant services. ► Lack of data integrity across services and persistent business data. ► Audit exposures. ► Spiral increase in maintenance cost (due to multiple copies of similar/same services). ► Development and deployment of redundant and inefficient services. ► Redundancy and possible inconsistency of systems functions to support same business processes or requirements.

Case Study: SOA Governance Scenario

7

JKHLE has defined an end-to-end service life cycle process (shown in Figure 2). For governance to be effective, all aspects of the service life cycle need to be handled properly. All realization patterns of the SOA Governance Scenario use this process as the foundation of the realization. The process transcends all phases of the service life cycle—model, assemble, deploy, and manage.

Model

Assemble

Deploy

Manage

Project Team Vertical / Horizontal

New Service Version

Solution Configuration Change

Bug Fix

SOA CoE

M1. Request for New Project Or

Service Provider Horizontal / Vertical

Periodic IT Review (fiscal review)

Y M2. Gather, Evaluate, and Prioritize Service Requirements

M3. Does Service Exist?

N

M4. Develop New Service

M5 Requires Enhancement?

N

A1. Integration Required?

Y

A2. Develop or Reuse Mediation

D1. Deploy Service and/or Mediations

N

Y

D2. Solution Certified?

M6. Accept Enhancement?

Y

M7. Enhance Service

B1. Build Service

N

Y

N3. Request For Change

N N2. Manage Availability

N1. Steady State

Figure 2 Service life cycle process

This section discusses how JKHLE uses the service life cycle process with the following realization patterns: ► Regulation of New Service Creation ► Getting More Reuse of Services ► Enforcing Standards and Best Practices

8

Case Study: SOA Governance Scenario

Regulation of New Service Creation Melissa Clark, Vice President of Finance, has decided to submit an IT project to implement a credit check within the Account Open process. Melissa wants a new service created or an existing service reused to meet this aim. The introduction of new services into the JKHLE SOA environment presents a number of governance challenges: ► Extend the existing IT governance process properly so that it includes the current IT planning process that reviews project candidates and decides which projects to pursue. ► Understand the role ownership in various service domains plays when choosing appropriate services and who is accountable for those services. ► Place the necessary rigor around the service creation process, ensuring the method is followed and harvesting consistent results. ► Understand the importance of the funding process, which should outline common scoring techniques used to evaluate various service candidates and properly prioritize these candidates in a manner consistent with the goals of the business. ► Understand the importance of tooling to help cement the concept of business domains ensuring these domains become more than columns on a slide. ► Define a comprehensive approach that will take quality of service criteria defined in the specification phase and ensure that these criteria are enforced appropriately.

Case Study: SOA Governance Scenario

9

Proposed solution

Start

Domain Owner / Development Team

To determine whether a new service needs to be created for this customer credit check project, JKHLE uses the New Service Creation sub-process shown in Figure 3. This is a lower-level process of the service life cycle process. The codes in each activity (M1.A, M2.0, and so forth) relate to the codes shown in the service life cycle process in Figure 2 on page 8.

M1.B Emergency Request

End: Service Creation Scenario End: Out of Scope

M2.0 Gather business requirements and determine functional capabilities to implement IT project.

Start

SOA CoE IT Executive Steering Committee

M1.A IT projects proposed at beginning of fiscal year

M2.1 Assess capabilities as potential services using common scoring criteria

M2.2 Should be a service?

M4.3 Validate funding and assign roles

Y M3.0 Already exists?

Y

M4.6 Realize low level design

M4.4 Specify design

N

N M4.0 Create new service and assign ownership considering proper domain

M4.1 Evaluate / prioritize service candidate against other candidates

N M4.2 Is it a high service priority?

Y

M4.5 Does specification change prioritization?

N

Y

End: Getting More Reuse of Services Realization

Figure 3 Regulation of New Service Creation sub-process

JKHLE uses this process to determine if Melissa’s requirements define an SOA service and, if they do, whether an existing service should be reused (in which case the Getting More Reuse of Services realization pattern should be applied) or a new service should be created, ultimately leading to the implementation of a new service (as defined by the Service Creation SOA scenario, described in Case Study: Service Creation SOA Scenario, REDP-4377). JKHLE applies the Regulation of New Service Creation realization as follows: 1. The JKHLE SOA CoE looks at the capabilities outlined in the functional requirements specified by Melissa’s team. They quickly realize that this project has great potential for reuse and should be considered as a strong candidate for a service. 2. Carol Jones, JKHLE Service Registrar, looks through JKHLE’s federated repository structure to ensure that the service does not exist.

10

Case Study: SOA Governance Scenario

3. Upon confirming that the service does not already exist, JKHLE’s SOA CoE assigns ownership of this service to Melissa and works with Melissa’s team to weigh the value of this service candidate using a common scoring technique that JKHLE has adopted to objectively weigh all service candidates that are being proposed for JKHLE’s service portfolio. 4. When the SOA CoE scores the value of the customer information service, it prioritizes its value against other service candidates and decides that this service brings higher value relative to other proposed service candidates. The SOA CoE decides to approve funding for the service. 5. Because Melissa’s group owns the service, the funding comes from the marketing and sales group, and the proper resources are allocated to designing the service. 6. Because JKHLE’s development organization is centralized, the SOA core team works with the architecture team assigned to this service to specify the service criteria for a high-level design, which includes defining interfaces, message flows, non-functional requirements, and lower-level functional requirements. 7. Given the added information after this specification step, the SOA CoE re-examines the level of effort to ensure the value of the service is still at a high enough priority and then approves it for the next phase of design—the realization phase. 8. In the realization phase, the architecture team goes into the low-level design of the service and maps the service to technical tooling, implementation, and so forth.

Getting More Reuse of Services JKHLE are eager to implement a structure for the reuse of existing services. Jacob Freeman, Lead Business Services Champion, explains that service reuse helps drive down development and operations costs of services. Jacob explains some of the key characteristics of service reuse: ► Service reuse requires a centrally governed and managed process for reuse adoption. ► Service reuse is a cultural challenge as much as it is a technical one. It requires motivation and incentive to drive success. ► Service reuse requires a holistic approach to information and metadata management. For example, the use of a business glossary ensures consistent use of terminology and promotes clarity for service usage and consumption.

Case Study: SOA Governance Scenario

11

Jacob explains that there are several aspects of service development, deployment, and runtime management that need to be governed to get more reuse of services. He identifies three primary aspects that need to be governed: ► Governing enterprise-wide use of consistent business terms It is hard to identify if an existing service meets the requirements for reuse without governing enterprise-wide use of consistent business terms. For example the business terms address and customer have slightly different meanings in different departments of JKHLE. ► Governing service enhancement A service when first developed might not take into account a varied set of requirements across multiple use cases (spanning multiple business processes). Therefore, without further enhancement (and potentially re-implementing key aspects of a service in some cases), it will not satisfy requirements for reuse. ► Governing service entitlement Service entitlement addresses who can use a service, how often they can use it, and what qualities of service can be expected by consumers of the service. With each new consumer of a service there is the potential for impacting other users. For example, another user might generate a high workload that affects not just that business process but all other business processes that share this service.

12

Case Study: SOA Governance Scenario

Proposed solution JKHLE use the Getting More Reuse out of Services realization pattern to address the governance aspects of consistent business terms, service enhancement, and service entitlement.

Governing enterprise-wide use of consistent business terms

N M2.0.A New business item required?

Y

M2.0.B Look for business N terms in enterprise wide/ domain specific Business Glossary

Found

M2.0.C Define business item using new or existing business terms

M2.0.F Specify service

Not found M2.0.D Identify stewardship domain

M2.0.E Define new business terms

M2.1 Assess capabilities as potential services

IT Executive Steering Committee

SOA CoE

Domain Owner / Development Team

JKHLE use the sub-process shown in Figure 4 to illustrate the steps in governing enterprise-wide use of consistent business terms. This is a lower-level process of the service life cycle process. The codes in each activity in Figure 4 (M2.0.A, M2.0B, and so forth) relate to the codes shown in the service life cycle process shown in Figure 2 on page 8.

Figure 4 Governing enterprise-wide use of consistent business terms sub-process

Case Study: SOA Governance Scenario

13

JKHLE applies this sub-process as follows: 1. Carol Jones, Service Registrar, works with the service owners to determine if their services require additional business terms defined or whether existing terms in the business glossary are sufficient. 2. Upon identifying the need for a new business term, Carol works with the business domain representatives to document the associated metadata required for the new term and how the term will be used (context, scope, ownership, dependencies, and so forth). 3. The new business term is loaded into the business glossary and is made available to business owners (service definers). Usage of the new term is tracked to understand impacts to the term from modifications.

Governing service enhancement

SOA CoE

Domain Owner / Development Team

JKHLE use the sub-process shown in Figure 5 to illustrate the steps in governing service enhancement. This is a lower-level process of the service life cycle process. The codes in each activity in Figure 5 (A1, A1.A, and so forth) relate to the codes shown in the service life cycle process shown in Figure 2 on page 8.

Deploy operational enhancements

Y

A1. Requires enhancement?

IT Executive Steering Committee

Y

N

A1.A Specify required non-functional enhancements

Y A4. Integration required?

A1.B Specify and assess required functional and non-functional enhancements

M6. Accept enhancement?

Y

M7. Enhance service

N

B1. Build service

Develop new service functions Reprioritize new functional requirements

Case Study: SOA Governance Scenario

D1.A Deploy required non-functional enhancements

D1. Deploy service and/or mediations D2. Solution certified?

N

Figure 5 Governing service enhancement sub-process

14

A5. Develop or reuse mediation

Y N1. State steady

N

JKHLE applies this sub-process as follows: 1. Samantha Williams, IT Portfolio Manager, ensures that service enhancement is aligned with existing IT governance processes which will include the current IT planning process that reviews new service requirements against existing matching services, evaluate additional enhancements if required, and whether the existing service should be modified. 2. After changes, bugs, or required fixes are identified for an existing service, Samantha works with the service owner to document the enhancement within the portfolio management system. 3. The service owner manages the implementation of the enhancement, which could result in a patch to existing code or a new version of the service being created. 4. Samantha manages the overall portfolio of services and how they are effected by prerequisite service changes and enhancements. This is performed monthly within a service enhancement review meeting.

Governing service entitlement

SOA CoE

Domain Owner / Development Team

JKHLE use the sub-process shown in Figure 6 to illustrate the steps in governing service enhancement. This is a lower-level process of the service life cycle process. The codes in each activity in Figure 6 (A1, A1.A, and so forth) relate to the codes shown in the service life cycle process shown in Figure 2 on page 8.

Major event on service agreement violation/termination Deploy operational enhancements

Y

A1. Requires enhancement?

IT Executive Steering Committee

Y

N

A1.A Specify required non-functional enhancements

A1.C Establish service entitlement via service agreement

Y A4. Integration required?

A1.B Specify and assess required functional and non-functional enhancements

A5. Develop or reuse mediation

D1.A Deploy required non-functional enhancements

D1. Deploy service and/or mediations

N

N D2. Solution certified?

M6. Accept enhancement?

Y

M7. Enhance service

B1. Build service

Y

N1. State steady

N Develop new service functions Reprioritize new functional requirements

Figure 6 Governing service entitlement sub-process

Case Study: SOA Governance Scenario

15

JKHLE applies this sub-process as follows: 1. Jacob drives the stewardship of services by helping business domain owners decide what business services are important to them, including role ownership in various service domains when choosing appropriate services. 2. Jacob promotes the use of service agreement in managing dependencies and interactions across consumers and service providers during the service life-time, which assures service quality, therefore promoting service reuse. 3. Jacob helps service owners position their services with the appropriate amount of service contract detail so that provisioning, entitlement and SLAs are identified and managed as part of the services management process

Enforcing Standards and Best Practices Jacob Freeman, Lead Business Services Champion, and Adam Kloud, SOA Director, are faced with the following business challenges within JKHLE: ► Building, preserving, and applying intellectual capital and working knowledge. ► Institutionalizing governance best practices and standards compliance enterprise-wide. ► Maintaining consistency for IT projects, infrastructure, and so forth. ► Ensuring that standards are in line with business objectives. ► Complying with industry and government regulations such as Sarbanes Oxley or Basel II. ► Taking advantage of and co-existing with IT best practices such as Information Technology Infrastructure Library (ITIL®). ► Ensuring that services use enterprise definitions for data models, standard protocols, and so forth. ► Satisfying needs for auditing. ► Achieving compliance in a heavily outsourced environment. To solve these issues, Jacob and Adam want like to see JKHLE adopt better processes for best practice compliance and the enforcement of standards, such as: ► Standards enforcement: – Reduces errors throughout the life cycle of a service. – Provides pre-certification of services for various compliance criteria. – Drives towards a template driven approach for standards compliance.

16

Case Study: SOA Governance Scenario

► Best practices compliance: – Ensures consistent development, deployment, and operations of services. – Organizations with well-defined life cycle phases that understand each others’ artifacts and deliverables. – Higher level of expectation managed as organizations process artifacts consistently across the life cycle of services.

Proposed solution Jacob describes a governance framework to update the service life cycle to add compliance points and hooks into existing IT life cycle processes (ITIL) and WS-I compliance, as shown in Figure 7.

Defining or altering a service life cycle to support best practice processes such as ITIL Capturing standards/best practice requirements so service life cycle compliance, audit and approval checkpoints are traced back to requirements

Enabling service compliance checkpoints into the life cycle such as WS-I compliance

Figure 7 Framework to update the service life cycle

Case Study: SOA Governance Scenario

17

Project Team Vertical / Horizontal

Figure 8 illustrates the impact on the end-to-end life cycle.

New Service Version

Solution Configuration Change

Bug Fix

Service Provider Horizontal / Vertical

SOA CoE

M1. Request for New Service Or Periodic IT Review (Fiscal Review)

Y M2. Gather, Evaluate, and Prioritize Service Requirements

M3. Does Service Exist?

M5. Requires Enhancement?

N

A1. Integration Required?

Y

N

M4. Develop New Service

M4. Compliance

A2. Develop Or Reuse Mediation

N

A2. Compliance

Y

M6. Accept Enhancement?

D1. Deploy Service and/or Mediations

D1. Audit D2. Solution Certified?

Y

M7. Enhance Service

N

N3. Request For Change

N

Y

M7. Compliance

N3. Audit

N2. Manage Availibility

N1. Steady State

Figure 8 High-level view of standards enforcement points

Jacob performs the following steps to help JKHLE enforce standards: 1. Jacob ensures that new services comply with specific requirements. In this example, Jacob checks for compliance with Web Services Interoperability (WS-I). 2. Service developers follow prescribed work breakdown structures that ensure WS-I compliance. 3. Compliance checkpoints and audits are performed against the services to ensure completeness of compliance. For service modeling, this compliance check is shown in Figure 8 in the life cycle at step M3. For service updates, this compliance check is shown in Figure 8 in life cycle step M7. Finally for compliance of the overall SOA solution, the compliance check is shown in Figure 8 in step A2 4. Audit information regarding how the compliance was achieved are documented and archived by the service developer. 5. Jacob maintains the database of services compliance against standards and manages that within the broader IT portfolio management process. Adam works on service compliance. Adam identifies best practices for the various phases of service life cycle (model, assemble, deploy, and manage). In

18

Case Study: SOA Governance Scenario

this example, release management best practices from ITIL have been established for the change and release management of services. All queries against services and updates to service records are performed against a change management database (CMDB). Ensuring conformance to ITIL best practices is achieved through use of the IBM® Tivoli® Unified Processes (ITUP) which are implementations of the ITIL best practices that run on top of CMDB data: 1. An incident report results in a request to change a service. Conformance to the ITIL best practice requires that this incident report and change request are linked together and recorded as shown in N3 in the life cycle in Figure 8 on page 18. 2. A service has been updated by the owning organization and has been tested and verified to be ready for deployment. 3. Adam uses a release management process to: – Plan release rollout – Communicate, prepare, and train for the release – Distribute and install the release The release management processes of ITIL require a record of the release approvals as shown in D1 in Figure 8 on page 18.

Summary Through implementing the realization patterns of the SOA Governance Scenario, JKHLE has better defined roles and responsibilities within their organizational structure. They have defined governance processes for creating new services, making the most of existing services through reuse, and ensured that their processes enforce standards and best practices.

Case Study: SOA Governance Scenario

19

References This section includes reference information for further reading materials that are related to the Governance SOA Scenario: ► IBM SOA Sandbox found at: http://publib.boulder.ibm.com/infocenter/soasdbox/v1r0m0/index.jsp?t opic=/com.ibm.soln.SOASandbox.nav.fw.doc/home_pages ► Implementing Technology to Support SOA Governance and Management, SG24-7538 ► Case Study: SOA Account Open Project Overview, REDP-4376

The team that wrote this IBM Redpaper This paper was produced by a team of specialists from around the world working with the International Technical Support Organization (ITSO). Martin Keen is a Senior IT Specialist for the IBM ITSO in Raleigh, NC, U.S. Adeola Allison, IBM Product Manager, SOA Scenarios, Bethesda, MD, U.S. Asit Dan, IBM SOA Design Requirements Specialist, Somers, NY, U.S. John Falkl, IBM Chief Architect, SOA Governance, Somers, NY, U.S. Andrew Hately, IBM Senior Technical Staff Member, Software Standards, Austin, TX, U.S. Dinah Peng, IBM SOA Evangelist and Lead Consultant, Seattle, WA, U.S. Jon Richter, IBM SOA Governance Lead, Austin, TX, U.S. Thanks to the following people for their contributions to this project: ► Erica Carmel, IBM Program Director, SOA Platform Consumability, U.S. ► Cindy Macrafic, IBM Senior Project Manager, SOA Platform Consumability, U.S. ► John Ganci, Architect and Specialist, Scenario Analysis Lab, Raleigh, NC, U.S. ► Linda Robinson, Graphics Artist, IBM ITSO, Raleigh, NC, U.S.

20

Case Study: SOA Governance Scenario

Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. © Copyright International Business Machines Corporation 2008. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

21

This document REDP-4384-00 was created or updated on April 30, 2008.

®

Send us your comments in one of the following ways: ► Use the online Contact us review Redbooks form found at: ibm.com/redbooks ► Send your comments in an e-mail to: [email protected] ► Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099, 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper ™ Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo)

®

IBM®

Tivoli®

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Other company, product, or service names may be trademarks or service marks of others.

22

Case Study: SOA Governance