redpaper adeola allison martin keen asit dan john falkl ... · this paper is one in a series of...

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.

Martin KeenAdeola Allison

Asit DanJohn Falkl

Andrew HatelyDinah PengJon Richter

© Copyright IBM Corp. 2008. All rights reserved. ibm.com/redbooks 1

http://www.redbooks.ibm.com/


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.

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.

Note: For more detailed information about the case study, refer to Case Study: SOA Account Open Project Overview, REDP-4376.

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 structureFigure 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.

Figure 1 JKHLE IT organizational structure

IT Executive Steering Committee

SOA Board

SOA Core TeamSOA CoE

ServiceRegistrar

ServiceDeveloper

BusinessAnalyst

FinanceDomain

BusinessAnalyst

TypicalDomain

ServiceArchitect

IntegrationSpecialist

SOA DataArchitect

ServiceTester

………Domains

BusinessRelationship

Directors

SOA SecurityArchitect

SOA OperationsArchitect

DevelopmentToolsmith

SOA Project Manager

CIO

BusinessAdmin Domain

Owner

New BusinessDev. Domain

Owner

SalesDomain Owner

ProductDomain Owner

FinanceDomain Owner

Head ITStrategist

SOAExecutiveSponsor

Release MgmtDomain Owner

Chief Architect

SOADirector SOA

Chief Architect

BusinessServices

Champion


Director


Director

Case Study: SOA Governance Scenario 3

Table 1 Groups within the JKHLE organization

Table 2 Roles 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.

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.


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

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.

Role Description


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.

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

REQ-01: Govern how new services are createdJKHLE 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.

REQ-02: Reuse existing services at every opportunityThe 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.

REQ-03: Enforce standards and best practices across JKHLEThe 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 “Regulation of New Service Creation” on page 9.

Note: For solution details, refer to “Getting More Reuse of Services” on page 11.

Note: For solution details, refer to “Enforcing Standards and Best Practices” on page 16.


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.


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.

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

AssembleModel Deploy Manage

Proj

ect T

eam

Verti

cal /

Hor

izon

tal

SOA

CoE

Ser

vice

Pro

vide

rH

oriz

onta

l / V

ertic

al

M1.Requestfor New Project

Or

PeriodicIT Review

(fiscalreview)

M2.Gather, Evaluate,

and PrioritizeService

Requirements

M3.Does

ServiceExist?

M4.Develop

NewService

N

M5Requires

Enhancement?

Y

M6.Accept

Enhancement?

Y

Y

N

M7.EnhanceService

A1.IntegrationRequired?N

A2.Developor ReuseMediation

N

YD1.

Deploy Serviceand/or

Mediations

New Service Version

Bug Fix

D2.Solution

Certified? N

N2.Manage

Availability

N1.SteadyState

Y

Solution Configuration Change

B1.Build

Service

N3.Request

For Change


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.


Proposed solutionTo 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.

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.

Star

t

M1.AIT

projects proposed

atbeginning

of fiscalyear

M2.1Assess

capabilitiesas

potential services

using common scoringcriteria

M2.2Should bea service?

N

M4.1Evaluate /prioritizeservice

candidate against other

candidates

Y

M4.2Is it a

high servicepriority?

NM4.0

Create newservice and

assignownershipconsidering

properdomain

M4.3Validatefunding

and assign roles

M4.5Does

specificationchange

prioritization?

M4.4Specifydesign

Y

M4.6Realize

lowlevel

design

Y

N

Star

t M1.B Emergency

Request

End: Out of Scope

End: Service Creation Scenario

M3.0Already exists?

M2.0 Gather businessrequirements and determine

functional capabilitiesto implement IT project.

Y

End: GettingMore Reuse of

Services Realization

N

Dom

ain

Ow

ner /

Dev

elop

men

t Tea

mSO

A C

oEIT

Exe

cutiv

e S

teer

ing

Com

mitt

ee


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.


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.


Proposed solutionJKHLE 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 termsJKHLE 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

M2.0.DIdentify

stewardship domain

Not found

M2.0.EDefine new

business terms

NM2.0.C

Define business item using new or existing business

terms

M2.0.ANew

business item required?

Y

NM2.0.B

Look for business terms in enterprise wide/ domain specific Business

Glossary Found

IT E

xecu

tive

Ste

erin

g C

omm

ittee

SO

A C

oED

omai

n O

wne

r /D

evel

opm

ent T

eam

M2.0.FSpecify service

M2.1Assess capabilities

as potentialservices


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 enhancementJKHLE 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.

Figure 5 Governing service enhancement sub-process

Y

M6.Accept

enhancement?

Y

Y

N

M7.Enhanceservice

NA5.

Developor reuse

mediation

NA1.BSpecify and

assess required functional and non-functional enhancements

A1.ASpecify required

non-functionalenhancements

Deploy operational enhancements

A4.Integrationrequired?

Develop new service functions

Reprioritize new functional requirements

D1.Deploy service

and/or mediations

D2.Solutioncertified?

Y

A1.Requires

enhancement?

N

Y

B1.Build

service

IT E

xecu

tive

Stee

ring

Com

mitt

eeSO

A C

oED

omai

n O

wne

r /D

evel

opm

ent T

eam

D1.ADeploy required non-functionalenhancements

N1.State steady



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 entitlementJKHLE 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.

Figure 6 Governing service entitlement sub-process

A1.Requires

enhancement?Y

M6.Accept

enhancement?

Y

Y

N

M7.Enhanceservice

A4.Integrationrequired?

NA5.

Developor reuse

mediation

NA1.BSpecify and

assess required functional and non-functionalenhancements

A1.ASpecify required

non-functionalenhancements

Deploy operational enhancements

Develop new service functions

Reprioritize new functional requirements

D1.Deploy service

and/or mediations

Y

N

Y

A1.CEstablish service entitlement via

service agreement

B1.Build

service

IT E

xecu

tive

Ste

erin

g C

omm

ittee

SOA

CoE

Dom

ain

Ow

ner /

Dev

elop

men

t Tea

m

D2.Solutioncertified?

Major event on service agreement violation/termination

D1.ADeploy required non-functionalenhancements

N1.State steady



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.


� 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 solutionJacob 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.

Figure 7 Framework to update the service life cycle

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

Defining or altering a service life cycle to support best practice processes such as ITIL


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

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

Ser

vice

Pro

vide

rH

oriz

onta

l / V

ertic

alSO

A C

oE

M1.Requestfor New Service

Or

PeriodicIT Review

(FiscalReview)

M2.Gather, Evaluate,

and PrioritizeService

Requirements

M3.Does

ServiceExist?

M4.Develop

NewService

N

M5.Requires

Enhancement?

Y

M6.Accept

Enhancement?

Y

Y

N

M7.EnhanceService

N

A2.Develop

Or ReuseMediation

N

A1.IntegrationRequired?

Y D1.Deploy Service

and/or Mediations

New Service Version

Bug Fix

D2.Solution

Certified? N

N2.Manage

Availibility

N3.Request

For Change

N1.SteadyState

Y

Solution Configuration Change

M7.Compliance

D1.Audit

A2.Compliance

N3.Audit

Pro

ject

Tea

mVe

rtica

l / H

oriz

onta

l

M4.Compliance


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.


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?topic=/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.


http://publib.boulder.ibm.com/infocenter/soasdbox/v1r0m0/index.jsp?topic=/com.ibm.soln.SOASandbox.nav.fw.doc/home_pages

© Copyright International Business Machines Corporation 2008. All rights reserved.

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.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 21

®

Redpaper™

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 OrganizationDept. HYTD Mail Station P099, 2455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

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

http://www.ibm.com/legal/copytrade.shtml


http://www.ibm.com/redbooks/

http://www.ibm.com/redbooks/

http://www.redbooks.ibm.com/contacts.html

redpaper adeola allison martin keen asit dan john falkl ... · this paper is one in a series of...

Documents