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
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
BusinessRelationship
Director
BusinessRelationship
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.
4 Case Study: SOA Governance Scenario
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
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.
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.
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.
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
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 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
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 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
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 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
14 Case Study: SOA Governance Scenario
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 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
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 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
Case Study: SOA Governance Scenario 17
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
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?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.
20 Case Study: SOA Governance Scenario
© 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
Top Related