SOA Governance: Governing the Service Factory

This chapter is from the book 

The Service Development Domain

• "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance."
• —Kurt Vonnegut

The Service Development domain covers the lifetime of services or automated processes from an original concept through to deployment into production. This section covers advice on governance of this development domain. Chapter 6, "Managing the Service Lifecycle," looks in a little more detail at governing specific steps with the service lifecycle.

Most IT departments we have visited currently spend the majority of their resources on system maintenance. One reason for this is that most IT systems consist of applications where there is generally no clear separation between business logic, graphical user interface (GUI) management, and workflow. Any change to an application of this type risks damaging all of these three aspects, and maintenance becomes labor intensive without good design documentation—which is more often than not a major issue.

SOA makes a clear distinction between business logic and workflow. SOA is all about packaging pure business logic as reusable transactional services, and using executable models to manage workflow. SOA does not become involved with any particular style or fashion of GUI or GUI control. In a fully SOA-aligned world, humans will make requests to IT systems to perform tasks, make decisions, or initiate business processes using whatever GUI is best suited to that job; automated business processes can in turn initiate tasks by invoking services or by requesting human intervention or involvement.

In this world, IT solutions grow incrementally as new business processes become automated, and interactions with third parties are increasingly performed using service executions without direct human intervention. Whenever new business initiatives, market forces, or governmental regulations require changes to operating procedures, new or revised automated business processes can be constructed rapidly by reworking or extending existing automated processes. We can expect technology to continue to change rapidly, so the users can interact with the IT systems in radically different ways in the future. Because the SOA approach insulates the user interface from the physical implementation of business function, we can expect that most of the services we create now will probably still exist in some form for the next 20 years or more, whatever interface is used to access them.

End-to-end service development is a complex process. Planning and governance has to be meticulous because there are many complex tasks with many interdependencies. There are critical tasks for governing service development that the governance specialist needs to address in the form of a transition plan that is created and worked just like any other project plan.

Key Capabilities Needed to Govern Service Development

The Service Development domain is highly complex and involves technology that is changing rapidly. Governing such complexity requires a high level of organizational and political skills, together with good knowledge, not just of the SOA technology itself, but how to use it optimally. Few individuals can combine those skills at a world-class level, so practical governance relies on close cooperation between some key technical and nontechnical roles. Close collaboration, and complete trust, among the SOA governance lead, the business service champions, the lead SOA architect, and the lead service architect is critical to success.

Table 4.1 describes the capabilities that the organization needs to govern service development, and recommends some key work products that can assist this complex activity. It is organized in the same way as Table 3.1 in Chapter 3.

Table 4.1. Service Development Domain—Capabilities, Risks, and Remedial Work Ducts

Capability	Associated Issues and Risks	Risk Level	Governance Work Products	Cost of Remedy
1. Services development lifecycle controls	Need to have a streamlined reliable end-to-end development process that finds issues and problems early and corrects them immediately. IT resources should be used as efficiently as possible.	Critical	SOA development approach Service build plan Service construction estimation metrics Service construction monitoring plan SOA development performance report SOA reuse and ROI report SOA development lessons learned Control point minutes SOA governance policy exemption Service design walkthrough notes	High
2. Requirements gathering and prioritization	No IT solution will be of any value unless the requirements are accurate; need to keep requirements as simple as possible, and avoid unnecessary embellishments There is a risk of embarrassment/punitive fines if governmental regulations are ignored. Business process models should be incrementally developed into executable models. There must be no security violations that threaten data integrity or confidentiality.	Critical	Functional and nonfunctional requirements Enterprisewide requirements and business rules catalog Functional and nonfunctional requirements checklist Regulatory compliance approach Regulatory compliance checklist Executable modeling approach	High
3. Service identification	Different potential consumers may have incompatible requirements. Resources will be wasted if incorrect choices are made between delivering services or applications. Functionality should be sourced in the most cost-effective way; sometimes this will be using a commercial package that meets most of the requirements, sometimes it is necessary to develop solutions in-house. Need to define services of correct granularity to maximize their reuse.	Critical	Service granularity, visibility, and accessibility checklist Service reusability guidelines Service sourcing policy	Moderate
4. Service specification	Need to ensure QoS designs and documentation to avoid costly rework after flawed development. Good service design can minimize the need for managing multiple service versions.	Critical	Service specification Service specification checklist Service design checklist Service security approach Service security checklist	Moderate
5. Service realization	Effective software development tools can markedly increase productivity and accuracy. Services should be exhaustively tested to ensure they meet all functional and nonfunctional requirements. Bugs are costly to correct and embarrassing; zero errors is not an impossible target if testing is thorough. An efficient configuration management/build process is vital to efficiently transfer code between development, functional testing, performance testing, preproduction, and production environments.	Critical	SOA development tools Service build management approach Service security checklist Service version management approach Service test plan	High
6. Service certification	Testing services may require connectivity to systems and data that closely mimic operational systems, such as servers, mainframes, and realistic but artificial test data. Any problems that occur after deployment will damage the reputation of the SOA enablement team. Instituting a formal certification process helps to establish the enterprise's commitment to quality and value.	Critical	Service acceptance checklist Service deployment approach Service deployment checklist Service level agreement Service version management approach Service test results	Moderate

Service Development Domain Work Product Definitions

In the preceding section, we introduced a number of work products that have been proven to be effective in helping to govern successful SOA transformations. Although we will describe them as if they are individual text documents or diagrams, in practice, many of the technical work products are best managed as models within tools specifically designed for manipulating them. Models of service internals, for example, should be edited and distributed using a specialized tool that can visualize and validate the interactions between the service components, and then generate most of the service code. No text document or simple picture can do that.

Documenting requirements involves many subtleties and creates multiple opportunities for misunderstandings to occur. A process model contained in a specifically designed process modeling tool that ensures logical continuity, and that requires all possible logical branches to be handled, is much more likely to be interpreted correctly than a use case written as a textual document. Better still if the modeling tool supports full emulation of the process steps.

Many of these work products represent intermediate deliverables that are passed from one professional to another on the service production line. These artifacts must be seen as representing a formal contract between the work product producer and the work product consumer. Delivery of the work product should formally signify that it is of the necessary quality and degree of completeness, and delivery of a substandard work product should be seen as a serious breach of contract. The control points described earlier in this chapter represent checkpoints to assess the quality of the key work products.

Some of the work products that can help govern the Service Development domain have already been described in Chapter 3, where, in addition, the roles of those involved in their production were defined. When creating the SOA governance plan, the SOA governance lead will need to select and create the work products that best manage SOA development service development activities without detracting from the ability to get projects done on time. Some of these work products have already been defined in the preceding chapter. Here are the descriptions of those new work products you should consider adopting, in alphabetic order.

Control Point Minutes

Description: These serve as a record of the results of the key SOA governance reviews, and can provide useful input to any systemic issues and the vitality of the SOA governance approach. The SOA governance lead or program management office (PMO) should examine these minutes to look for any common patterns of issues that need to be addressed by the creation of additional architectural decisions, design standards, best practices, or additional training.

Purpose: Ensure continued vitality of the SOA development approach.

When needed: Should be completed immediately after any service control point.

Responsible: Control point reviewers, PMO.

Accountable: SOA governance lead or PMO.

Consulted: Control point reviewers.

Informed: SOA enablement team.

Executable Modeling Approach Work Product

Description: This defines standards and best practices for developing executable business models, helping to ensure their consistency and quality.

Purpose: Define how automated business processes will be created.

When needed: Create this as soon as the SOA development approach work product has been approved.

Responsible: Service architects, process modelers, process developers, business analysts, monitoring developer.

Accountable: Lead SOA architect or lead service architect.

Consulted: SOA enablement team.

Informed: Process modelers, process developers, monitoring developer.

Functional and Nonfunctional Requirements Work Products

Description: For each service, these define exactly what each operation does, and how well it is expected to do it. Nonfunctional requirements include such factors as performance, availability, systems management, and security. There will generally be a fairly standard set of nonfunctional requirements that apply to most services, and individual services should have to define only additions and exceptions to them. Targets such as latency should be defined in measurable terms; for example, "95% of individual executions of this operation should have a latency of less than 1 second, to the glass on a portal screen, and 90% of executions should complete in less than 1.5 seconds."

As already stated, a good practice for cataloging functional requirements is to maintain a requirements and business rules catalog in a database, indexed by the corresponding business entity in the enterprise data model (EDM) or messaging model (MM). This can avoid wasted effort in duplicating requirements analysis. Requirements should be classified into Mandatory, Valuable, and Optional. In the case where requirements are specific to a single line of business (LoB), this should be made clear in the text describing the requirement.

Purpose: Good management of requirements can avoid duplication of effort and help enable reuse.

When needed: A standard set of nonfunctional requirements should be created as soon as the SOA development approach work product has been approved; functional requirements should be assessed at the business requirements and service identification control point, and nonfunctional requirements should be assessed at both solution architecture and service design control points.

Responsible: Service architects and business analysts (for nonfunctional requirements), business analysts and process modelers (for functional requirements).

Accountable: Business service champion.

Consulted: All service architects, business analysts, process developers, service developers.

Informed: SOA enablement team, QA, testing team.

Functional and Nonfunctional Requirements Checklist Work Product

Description: This checklist is used at the business requirements and service identification point, and nonfunctional requirements should be assessed at both solution architecture and service design control points to ensure that all potential consumers are satisfied that their individual requirements have either been met or have been explicitly ruled out of scope in the current planned service release, and that the design approach for this service should be able to satisfy the NFRs and SLA terms and conditions.

Purpose: Ensure the highest possible quality of services.

When needed: Functional requirements should be assessed at the business requirements and service identification control point, and nonfunctional requirements should be assessed at both solution architecture and service design control points.

Responsible: SOA governance lead creates the template, lead business analysts and service designers complete the checklist for individual services.

Accountable: Business service champion.

Consulted: Business analysts.

Informed: SOA enablement team.

Regulatory Compliance Approach Work Product

Description: Specifies what regulations apply under which circumstances (for example, the country in which the service requestor is based), together with the processes that will be followed to ensure compliance.

Purpose: Avoid the embarrassment and potential punitive consequences of disobeying applicable regulations.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: SOA lead architect, PMO, business service champion, security architect.

Accountable: SOA executive sponsor or existing IT governance function.

Consulted: SOA enablement team.

Informed: PMO.

Regulatory Compliance Checklist Work Product

Description: The template for this document is created by the security architect and any existing IT governance group, and then approved by the lead SOA architect. Individual instances of this checklist are completed by the service designer and approved by the security architect. The regulatory compliance checklist for a given service should be endorsed at multiple control points to ensure that no changes have been made to the service that might invalidate the integrity of its security.

Purpose: Avoid the embarrassment and potential punitive consequences of disobeying applicable regulations.

When needed: Should initially be prepared in time for the service specification control point, then re-reviewed at the service build, service test, and service certification and deployment control points.

Responsible: SOA lead architect, PMO, service designer, service architect.

Accountable: Security architect.

Consulted: SOA enablement team.

Informed: PMO.

Service Acceptance Checklist Work Product

Description: A checklist used to confirm that IT operations agree that it can successfully operate and manage a specific service within the terms of its SLA.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed before the service certification and deployment control point, for which it is a prerequisite.

Responsible: IT operations.

Accountable: IT operations.

Consulted: Service architect, service designers, service testers.

Informed: SOA enablement team.

Service Build Management Approach Work Product

Description: The approach to build management must ensure that SOA components can be migrated easily among development, testing, preproduction, and production environments repeatedly, without error or omission.

Purpose: To maintain continuity of operation, it is essential that the approach to build management is error free, and that it is always possible to re-create any given build configuration.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: SOA lead architect, existing build manager.

Accountable: SOA lead architect.

Consulted: IT operations.

Informed: Service developers, process developers.

Service Build Plan Work Product

Description: This is the set of candidate service operations and automated business processes that comprise the formal SOA asset construction plan. This work product is an essential tool for managing SOA development in that

• It defines the results of the service prioritization.
• It's a key control document for service development project management.
• It communicates the SOA development plan and status to the rest of the organization.

Note that services, in general, have multiple operations—for example, a Customer service may have such operations as lookupCustomer and modifyCustomer. Not all operations will have the same development priority; there is no need to create all operations of each service at the same time.

Purpose: Manage the service development priorities and communicate those priorities to the stakeholders.

When needed: Should be created as soon as any services are planned, and it should be updated weekly.

Responsible: Lead service architect, service registrar, SOA business analysts.

Accountable: Business service champion.

Consulted: PMO, service architect, service developer service designer, process modelers, process developers.

Informed: SOA enablement team, PMO.

Service Construction Estimation Metrics Work Product

Description: These are the resource metrics captured as a result of the service construction monitoring plan. They provide invaluable input to the project management of new services and SOA projects. A steady improvement in these metrics is a sign of growing SOA maturity and effective SOA governance.

Purpose: These are important metrics to enable effective governance of the service factory.

When needed: Should be created as soon as any services are planned and data is captured for every service that is created.

Responsible: Lead service architect, SOA governance lead, PMO.

Accountable: Lead service architect.

Consulted: SOA enablement team, PMO.

Informed: PMO.

Service Construction Monitoring Plan Work Product

Description: This is the plan to capture and continuously update metrics on the resource efforts needed to complete each step in the service and automated business process lifecycle. Typically, resource estimates for each construction step are grouped into complex, intermediate, and simple services/processes.

Purpose: These are essential metrics to enable effective governance of the service factory.

When needed: Should be created as soon as any services are planned and data is captured for every service that is created.

Responsible: Lead service architect, lead SOA architect, SOA governance lead, PMO.

Accountable: Lead service architect.

Consulted: SOA enablement team.

Informed: SOA enablement team, PMO.

Service Deployment Approach Work Product

Description: The current IT deployment approach should be adjusted to allow for the characteristics of services. Typically, the number of deployments cycles in a traditional IT development approach is limited to a small number of major increments each year, to maintain stability of the operational systems, whereas the deployment of services can be almost an everyday occurrence.

Purpose: Ensure that services are deployed in the optimum fashion at the most advantageous times.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: IT operations.

Accountable: Lead service architect.

Consulted: IT operations.

Informed: Service developers.

Service Design Checklist Work Product

Description: This checklist is used to ensure that the service internals contained in the service specification work product are high standard, complete, and unambiguous.

Purpose: Ensures the highest possible quality of services and reduces the need for rework.

When needed: A checklist template should be completed as soon as the SOA development approach has been approved. Instances of this checklist should be completed for each service before the service design control point.

Responsible: Service architect, QA, security architect create the template; service developers complete individual checklists.

Accountable: Service architect.

Consulted: Service designer, service developer.

Informed: SOA enablement team.

Service Design Walkthrough Notes

Description: These are relatively informal notes that describe the results of service design walkthrough sessions (for example, "chalk and talk" working sessions where service architects, designers, and developers meet to discuss the design of individual services, both to optimize that design and to mentor the less experienced staff members).

Purpose: Ensure continued vitality of the SOA development approach by identifying any common concerns that might require the creation of additional architectural decisions, design standards, best practices, or additional training.

When needed: Should be completed after every service design walkthrough session.

Responsible: Service designers, service developers.

Accountable: Service architect.

Consulted: Lead SOA architect.

Informed: SOA governance lead.

Service Deployment Checklist Work Product

Description: This is a checklist used to ensure that services are deployed in the fashion described in the service deployment approach, based on a template created as part of the service deployment approach. It should take into account the fact that some services may have multiple instances, multiple access channels, and different QoS levels for different categories of consumer, according to the requirements specified by the service architect or service designer.

Purpose: Ensures that services are deployed in the optimum fashion.

When needed: The service deployment checklist should be completed before the acceptance process.

Responsible: IT operations creates the checklist template with assistance from service architects. Service developers and service architects fill in a checklist for each individual service.

Accountable: Service architect.

Consulted: IT operations.

Informed: Service developers, service registrar.

Service Granularity, Visibility and Accessibility Checklist Work Product

Description: This checklist is used to ensure that services have the optimum scope and are visible and available to any potential consumer that may need to access them.

Purpose: Ensures the highest possible QoS, with maximum business value and reuse potential.

When needed: Complete this before the solution architecture control point and revalidate it at the service design control point.

Responsible: SOA governance lead creates the template, and lead business analysts and service designers complete an individual checklist for each service.

Accountable: Business service champion.

Consulted: Business analysts, service registrar, service designers.

Informed: SOA enablement team, PMO.

Service Level Agreement Work Product

Description: SLAs represent the terms and conditions of a contract among service consumers and service providers. IT operations is responsible for monitoring that both parties comply with all their terms and conditions. SLAs should include the following:

• Guaranteed QoS levels, based on the corresponding service nonfunctional requirements
• Technical support terms and conditions (hours of operation of the help desk, incident response times by problem urgency, and so on)
• Constraints on the service consumer (specifying, for example, that QoS cannot be guaranteed if the service consumer exceeds a given threshold in the rate of service requests)
• For any services that are being offered for a fee, either internally or externally, the pricing structure of service requests
• How version management will affect consumers such as how many versions of services will be supported, length of time support will be available for deprecated services, how much warning service consumers will have of changes, or service retirement

Purpose: Define contractual terms for service usage.

When needed: Standard SLA terms and conditions should be established by the SOA governance lead as soon as practicable.

Responsible: SOA governance lead, business service champion.

Accountable: Business service champion.

Consulted: SOA enablement team, PMO.

Informed: Service owners, service consumers, PMO.

Service Reusability Guidelines Work Product

Description: Based on the SOA development approach, this work product contains guidance to service designers on how to design services with maximum reusability.

Purpose: Ensures that services are designed so as to maximize their reuse potential.

When needed: Should be created as soon as the SOA development approach work product has been approved.

Responsible: SOA lead architect, service architect, SOA governance lead.

Accountable: Business service champion.

Consulted: Business analysts, process modelers.

Informed: SOA enablement team, QA.

Service Security Approach Work Product

Description: The optimum approach for implementing SOA security to enforce the following:

• Authentication and authorization of all service consumers
• Nonrepudiation of service execution requests
• Protection of enterprise data assets
• Encryption of all data transmitted over channels such as the Internet

Purpose: Create and maintain a secure SOA production environment.

When needed: Should be created as SOA development approach work product has been approved.

Responsible: Security architect, lead service architect.

Accountable: Security architect.

Consulted: Operations management.

Informed: SOA enablement team.

Service Security Checklist Work Product

Description: Individual instances of this checklist are completed by the service designer and approved by the security architect. The service security checklist for a given service should be endorsed at multiple control points to ensure that no changes have been made to the service that might invalidate the integrity of its security.

Purpose: Ensure that services that do not comply with the requirements of the service security approach are never deployed into production.

When needed: Should initially be prepared in time for the service specification control point, then re-reviewed at the service build, service test, and service certification and deployment control points.

Responsible: The template for this document is created by the security architect and approved by the lead service architect; individual checklists are completed by a service developer and service tester, and then approved by a security architect.

Accountable: Security architect.

Consulted: IT operations.

Informed: SOA enablement team.

Service Sourcing Policy Work Product

Description: Based on the SOA development approach, the service sourcing policy describes how, once the need for a specific service or service operation has been established, the organization should choose between the options:

• Develop the service functionality from scratch.
• Use an existing IT asset or application, wrapped as a service.
• Buy a commercial, off-the-shelf (COTS) product that is or can be wrapped to be exposed as a service.
• Subscribe to an external software as a service vendor who performs that activity.

Purpose: Ensure consistency of approach in buy versus build decisions.

When needed: As soon as the SOA development approach has been approved.

Responsible: SOA governance lead.

Accountable: Procurement.

Consulted: Business service champion.

Informed: SOA enablement team, PMO.

Service Specification Work Product

Description: The service specification is not a single document, but rather a package that contains all necessary information needed to use, build, test, and certify that service or automated process. It should include the following:

• The service externals and service internals discussed earlier.
• Details of any interfaces to existing IT assets that the service will need to access.
• Functional and nonfunctional requirements for the service.
• Security information for the service (who can access it, authentication, encryption, nonrepudiation).
• Deployment options (for example, need for geographic diversity; "platinum," "gold," "silver" levels of service support)
• Monitoring and systems management requirements.
• Test plan and test data.
• The acid test of the level of completeness and accuracy of a service specification package is that it contains no ambiguity and that it provides a reasonably skilled offshore developer with all the information necessary to develop a high-quality code deliverable without the need for asking any questions to clarify any item it contains. For this purpose, models contained in sophisticated tools are much more valuable than words and pictures in most cases.

Purpose: Ensure the highest possible QoS.

When needed: Service externals need to be completed before the solution specification control point and the whole service specification completed before the service design control point.

Responsible: Lead service architect, QA, SOA governance lead create the templates; the service designer and service architect complete each service specification package.

Accountable: Business service champion.

Consulted: SOA enablement team.

Informed: Service consumers have access to the service externals, and only the SOA enablement team (specifically service developers and service testers) should be given access to service internals.

Service Specification Checklist Work Product

Description: This checklist is used to ensure that all service specification packages are created to the highest possible standards, contain all the information needed, and are clear and unambiguous.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed before the solution specification control point.

Responsible: Service designer, QA, and service registrar.

Accountable: Business service champion.

Consulted: SOA enablement team.

Informed: SOA governance lead.

Service Test Plan Work Product

Description: Thorough functional and nonfunctional testing of services is vital to ensuring their quality. For each service, this plan should describe all the tests that need to be carried out, and what the expected result should be.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed immediately after the service design control point.

Responsible: Service test manager, business analysts.

Accountable: Business service champion.

Consulted: Service architect, service designer, and business analysts.

Informed: Service testers.

Service Test Results Work Product

Description: These document the results of executing the service test plan, and cover both functional and nonfunctional testing. All tests must have been successfully completed before a service can pass through the service test control point.

Purpose: Ensure the highest possible QoS.

When needed: Should be completed after testing is completed successfully and before the service acceptance control point. These test results should be examined regularly to look for any systemic issues that need to be addressed, for example, by additional training or by changing standards or best practices.

Responsible: Service testers, QA.

Accountable: Service test manager or QA.

Consulted: Service architect, service designer, and business analysts.

Informed: SOA governance lead, PMO.

Service Version Management Approach Work Product

Description: This defines how services and automated business processes will be version managed, and assigns responsibility for performing and verifying that this approach is followed in practice. It should include advice on designing services that are as forward compatible as possible—that is, that can be incrementally extended without impact to existing consumers. Chapter 6, discusses service version management in more detail.

Purpose: Define how services will be version managed.

When needed: Should be created as soon as the SOA development approach work product has been approved.

Responsible: Lead SOA architect, service architects, SOA governance lead.

Accountable: Business service champion.

Consulted: IT operations.

Informed: IT operations, service consumers.

SOA Development Performance Report Work Product

Description: These reports are based on continuously monitoring the actual analysis, design, construction, and testing efforts associated with constructing services or automating business processes.

These reports should show actual resources, explain any discrepancies with established service construction estimation metrics, and show trends. In the best case scenario, they reveal a continuous improvement in productivity and decline in rework!

Purpose: Ensure continued vitality of the SOA development approach and the vitality of SOA governance.

When needed: Should be completed and distributed every one to three months.

Responsible: Lead SOA architect, PMO, SOA governance lead.

Accountable: Lead service architect.

Consulted: Service testers.

Informed: SOA enablement team, PMO.

SOA Development Tools Work Product

Description: There are many fine software tools to assist in the development and testing of services and automated business processes, and any organization embarking on a transition to SOA should select a set of tools to improve their productivity. The most effective tools support the principle of model-driven development—that is, the creation of models of services or automated processes that are progressively refined until they are considered complete, at which time the code is generated automatically. Chapter 6 describes this in more detail.

Purpose: Create and maintain a productive development and test environment.

When needed: Should be created as soon as the SOA development approach work product has been created.

Responsible: SOA lead architect, service architects.

Accountable: SOA lead architect.

Consulted: Service developers, service assemblers, SOA business analysts, process modelers, process developers, monitoring developer, enterprise architects.

Informed: SOA enablement team.

SOA Development Lessons Learned Work Product

Description: At the end of any significant task in the service or process automation lifecycle, it is valuable to hold a relatively informal session to discuss any lessons learned from the exercise. Lessons learned should cover areas such as the SOA development process, work products, governance approach and level of governance rigor, and tools and techniques. Whether the lessons learned are positive of negative, they provide valuable insight into the vitality of the SOA development and governance process vitality.

Purpose: Ensure continued vitality of the SOA development approach and the vitality of SOA governance.

When needed: Should be completed and distributed once every four months.

Responsible: All control point reviewers.

Accountable: SOA governance lead or PMO.

Consulted: SOA enablement team.

Informed: SOA enablement team, PMO.

SOA Governance Policy Exemption Work Product

Description: The ability to grant exceptions to having to conform to common standards, best practices, or policies in case of established business need is important, and the exemptions process must be defined in the SOA governance plan, along with a definition of who is empowered to grant such exemptions. The level and type of exemptions and the reasons they were granted or refused are important measures of the SOA governance vitality:

• If there are few exemptions requested, it is possible that either the standards are too lax, the degree of governance applied is inappropriate, or that some developers are ignoring the governance approach or rules altogether.
• If there are too many exemptions requested or granted, the standards might be too restrictive.

Purpose: Record the granting or refusal of requests for exemptions from compliance with standards or best practices.

When needed: Should be completed whenever a request is received for exemption from a policy or standard.

Responsible: SOA lead architect, SOA governance lead, QA, PMO.

Accountable: Lead service architect or enterprise architect.

Consulted: Service architects.

Informed: Exemption requestor (typically a service architect or service designer).

SOA Reuse and ROI Report Work Product

Description: Based on the SOA reuse and ROI monitoring plan, this regular report should assess, as objectively as possible, the real levels of reuse and ROI that have been achieved. Some of the data to produce this report will be obtained from IT projects, through the medium of the project benefits and ROI work product.

Purpose: Measure and report the real business value of the SOA transformation initiative.

When needed: Every one to four months, or alternatively displayed on a real-time governance dashboard.

Responsible: SOA governance lead, lead service architect, PMO.

Accountable: Business service champion.

Consulted: SOA enablement team, service consumers, IT operations.

Informed: Chief executives, PMO, SOA enablement team.

The dependencies among these work products are depicted in Figure 4.3. The format is the same as for Table 3.3 in Chapter 3. Again, those work products marked with an asterisk (*) should be revised every 6 to 12 months to ensure continued vitality.