• Introduction
• Service Oriented Architecture
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• Introduction
• Motivation
• Key Principles
• Basic Concepts
• Overview of the SOA RA Layers
• Capabilities and the SOA RA
• Description of Layers
• Operational Systems Layer
• Service Component Layer
• Services Layer
• Business Process Layer
• Consumer Layer
• Integration Layer
• Quality of Service Layer
• Information Layer
• Governance Layer
• Related Work and Usages of the SOA RA
• Relationship to Other SOA Standards
• Relationship to Open Group Guide: Using TOGAF to Define and Govern SOA
• Acknowledgements
• Referenced Documents
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• SOA Ontology Technical Standard
• Navigating the SOA Open Standards Landscape Around Architecture White Paper

SOA Work Group

SOA Work Group Members Page

SOA Reference Architecture Technical Standard : Governance Layer

Overview

SOA governance ensures that the services and SOA solutions within an organization are adhering to the defined policies, guidelines, and standards that are defined as a function of the objectives, strategies, and regulations applied in the organization and that the SOA solutions are providing the desired business value. SOA governance activities shall conform to corporate, IT, and enterprise architecture governance principles and standards. The Governance Layer will be adapted to match and support the target SOA maturity level of the organization.

The Governance Layer includes both SOA governance (governance of processes for policy definition, management, and enforcement) as well as service governance (service lifecycle). This covers the entire lifecycle of the services and SOA solutions (i.e., both design and runtime) as well as the portfolio management of both the services and SOA solutions managing all aspects of services and SOA solutions (e.g., Service-Level Agreement (SLA), capacity and performance, security and monitoring).

This layer can be applied to all the other layers in the SOA RA. From a Quality of Service (QoS) and management perspective, it is well connected with Quality of Service Layer. From a service lifecycle and design-time perspective, it is connected with the Services Layer. From an SOA solution lifecycle perspective, it is connected to the Business Process Layer.

The goal of the Governance Layer is to ensure consistency of the service and solution portfolio and lifecycles processes. In this layer, the extensible and flexible SOA governance framework will ensure that all aspects of SOA are managed and governed, such as:

• SLAs based on QoS and Key Performance Indicators (KPIs)
• Capacity and performance management policies
• Design-time aspects, such as business rules

The value of this layer is to ensure that the mechanisms are in place to organize, define, monitor, and implement governance from an enterprise architecture and solution architecture view.

Context and Typical Flow

This layer features the following characteristics:

• Defines policies, compliance, and exception characteristics
• Monitors the health of SOA services, solutions, and governance
• Reports on compliance, exceptions, service health, and versions
• Provides a consolidation point for business rules

The Governance Layer is aligned with the standardized SOA Governance Framework [25] which defines an SOA Governance Reference Model and SOA Governance Vitality Method. These provide definitions and best practices for defining a customized governance regimen for the enterprise.

The SOA Governance Reference Model includes definitions and best practices for governance guidelines, roles/responsibilities, governing processes, governed processes, and governance technology.

The governing processes are used to fulfill the responsibilities of the Governance Layer:

• Compliance processes are the conformance processes and policies including vitality which ensure the continued relevance of key governance model constructs, such as reference models, lifecycle (activities, work products), etc.
• Dispensation processes are processes and policies to handle exception to compliances.
• Communication processes disseminate and educate the fundamental constructs of lifecycle, governance models, etc.

The Governance Layer would have elements that facilitate and enable the implementation of the above governance processes.

Governed processes for the SOA solution are defined across all the other layers of the SOA RA, but can be articulated as:

• Service lifecycle management processes – describe the activities, roles, and work products to the modeling of services throughout the lifecycle, from identification to instantiation and retirement. These are often an extension of the organization’s software development lifecycle.
• Solution lifecycle management processes – describe the activities, roles, and work products as they relate to the modeling of SOA solutions throughout the lifecycle, from identification to retirement.
• Service portfolio management processes – describe activities for selecting services to be developed and services to be re-used by solutions, ensuring an organization has the services appropriate to its needs. This influences the lifecycle management of those services.
• Solution portfolio management processes – describe activities for selecting solutions to be implemented and maintaining the correct mix of assets to support those solutions according the needs of the enterprise. Identifying services need by the solutions is one of the responsibilities and ties directly to input to the Service Portfolio Manager.

The SOA Governance Vitality Method phases, Plan/Define/Implement/Monitor, defined with best practices ensure that governance is a long-term process, keeping business and SOA solutions aligned:

• The Plan governance phase is responsible for analyzing, arranging, and scheduling solution-level monitoring and management.
• The Define governance phase is responsible for defining a solution-specific SOA-based governance control model and strategy.
• The Implement governance phase is responsible for enabling and realizing solution-level governance control.
• The Monitor governance phase is responsible for monitoring and managing solution-level system status according to predefined governance policies and plans.

These processes and tasks can be accomplished with a set of technical capabilities and Architecture Building Blocks (ABBs). ABBs implement the capabilities needed by the responsibilities and processes of the Governance Layer. Capabilities and ABBs will be needed for both dimensions of governance, the processes needed to create it, the governance vitality method, and the governance regimen itself. Capabilities and ABBs aligned with that standard are defined here.

The SOA Governance Vitality Method phases, Plan, Define, Implement, and Monitor, all require the capability to store and access governance information, define policies with a policy manager, and possibly develop and configure management tools. In addition, the Monitor phase needs the ability to monitor metrics, manage and enforce policies, and use change control and configuration management tools to react to policy changes. In addition, workflow can be used to implement the compliance processes.

The governance regimen – i.e., the customized compliance, dispensation, and communication processes to govern the SOA lifecycle and portfolio management – requires capabilities to store and access governance artifacts, manage and enforce policy, monitor metrics, and manage the configuration of the solution and governance. Change control may be needed to support changes to the system.

Governance applies to all phases of the SOA solution lifecycle, from architecture and design to implementation and maintenance.

Governance can be scoped to the enterprise as a whole, a line of business, a particular SOA solution, or a particular set of critical SOA processes and services.

Capabilities

There are a set of categories of capabilities that the Governance Layer needs to support in the SOA RA. These categories are:

• Governance Planning: This category of capabilities provides the ability to plan governance.
• Governance Definition: This category of capabilities provides the ability to define governance.
• Governance Enablement and Implementation: This category of capabilities provides the ability to implement governance.
• SOA Metadata Storage and Management: This category of capabilities enables storing and managing service metadata and governance artifacts.
• Business Rule Definition and Management: This category of capabilities provides the ability to define and manage business rules.
• Policy Definition and Management: This category of capabilities provides the ability to define and manage policies.
• Monitoring: This category of capabilities provides the ability to monitor application of policies, governance processes, and effectiveness of governance.
• Management: This category of capabilities provides the ability to manage governance artifacts and processes.
• Workflow: This category of capabilities provides the ability to capture and automate governance processes.

This layer features the following capabilities:

Governance Planning

1. Ability to analyze existing governance
2. Ability to identify governance goals, strategies, principles, and roles

Governance Definition

1. Ability to define governance processes
2. Ability to define governance artifacts

Governance Enablement and Implementation

1. Ability to enable governance
2. Ability to realize governance processes

SOA Metadata Storage and Management

1. Ability to store and search any kind of assets and artifacts
2. Ability to support the capture of service-related information at design time, and its dissemination to the other layers in the SOA in a standards-compliant interoperable manner
3. Ability to support the storage and dissemination of information supporting these capabilities: service contract definition (e.g., WSDL); service policy management; service version information management; service dependencies (e.g., the ability to integrate with a CMDB tool); service management descriptions; canonical form and domain model specification for integration with the Information Layer
4. Ability to store governance artifacts
5. Ability to access governance artifacts
6. Ability to advertise/query for governance artifacts
7. Ability to advertise for services and metadata about services
8. Ability to find or query for services and metadata about services

Business Rule Definition and Management

1. Ability to capture, author, and define business rules
2. Ability to change, manage, and maintain business rules
3. Ability to store business rules

Policy Definition and Management

1. Ability to define policies
2. Ability to correlate business rules into policies
3. Ability to distribute policies
4. Ability to change, manage, monitor, and maintain current policies

Monitoring

1. Ability to monitor solution-level system status according to predefined governance policies and plans
2. Ability to manage solution-level system status according to predefined governance policies and plans
3. Ability to measure and gather metrics on the SOA services, SOA solutions, governing processes, and policy enforcement
4. Ability to evaluate metrics and test against policy regularly
5. Ability to use metrics to determine appropriateness of the current governance regimen
6. Ability to trigger checkpoints in the compliance process
7. Ability to indicate the status of governing and governed processes and their metrics in real-time
8. Ability to report the results of governing processes and their effectiveness

Management

1. Ability to do configuration management to implement and maintain governance
2. Ability to do change control to implement and maintain governance
3. Ability to access control and apply security policies for governance processes

Workflow

1. Ability to capture governing processes as workflow documents
2. Ability to automate governing processes

Architecture Building Blocks (ABBs)

These capabilities align with the SOA Governance Framework, SOA Governance Vitality cycle phases, and technology capabilities. These capabilities may need to be provided in an ongoing or cyclical basis as part of the SOA and SOA governance roadmap.

ABB to Capability Mapping for the Governance Layer

The same ABBs may be used by the SOA solution directly and to implement and execute the governance regimen.

Details of ABBs and Supported Capabilities

The purpose of this section is to identify solution ABBs that can be used to perform the SOA governing processes, compliance, dispensation, and communication. The same ABBs may be used to support both the governing and governed processes (e.g., a repository or a policy enforcement tool).

SOA governance ABBs are the technology to be used to enable governance and the whole or partial automation of the governing processes. The instantiation of these ABBs can range in ability from manual processes to sophisticated software.

Details of ABBs

Repository

This ABB represents a generic storage and enables organizations to organize, govern, and manage their valuable artifacts and assets scattered throughout the enterprise and to encourage re-use of existing assets within the organization. It provides the ability to search for the artifact and asset by different perspectives such as for general description, classification, usage, and content.

Asset Repository

This ABB enables organizations to organize, govern, and manage their valuable assets scattered throughout the enterprise and to encourage re-use of existing assets within the organization. It provides the ability to search for the asset by different perspectives such as for general description, classification, usage, and content. Assets could be business processes model, service artifacts, components design and code, models, documents, etc. Standards for asset repository and management include Re-usable Asset Specification (RAS) from OMG.

Service Repository

This ABB integrates with the Service Performance Manager ABB to support the runtime information collection and storage in order for users to evaluate service performance.

It acts as a design-time repository to store and locate metadata about services, including descriptions of the service contract, information about the QoS policies and security, versioning information, and runtime information such as end-points.

It is responsible for storing and accessing governance artifacts and best practices for SOA solutions and governance of SOA solutions from various perspectives, including organizational aspect, development aspect, runtime operational aspect, and lifecycle management aspect. Artifacts stored to guide governance may include service registrations, policy, guidelines, and governance processes.

This ABB integrates with the Service Registry ABB to support the runtime binding and service virtualization needs of SOA.

Service Registry

The ABB is responsible for allowing advertising and discovery of available services and supports the runtime binding of services and service virtualization. Think of this ABB as a runtime service repository. Services are available to the solution as well as governance processes. Advertisement of services should be governed. It contains metadata about services, including descriptions of the service contract, information about the QoS policies and security, versioning information, and runtime information such as end-points. This ABB may leverage the design-time Service Repository ABB to fetch metadata about services to fulfill the runtime needs of SOA such as dynamic/runtime binding and service virtualization. Standards for registries include UDDI.

This ABB contains service definitions at runtime and it plays a key role in service virtualization and service discovery. Service virtualization in this context is the exposure of a service end-point through a “proxy” (the registry). This in particular supports agility through service versioning so that the impact of services being released can be addressed through versions of services. The other aspect is the administration of the service where there are changes to the location of a service. Location is expressed in terms of an “end-point”; aka, the location from which a service is invoked. This could be the service container’s address or some other unique identifier (URI).

Business Rule

This ABB defines a business rule constraining some aspects of business such as business processes, services, and information. Business rule is one of the fundamental constructs of an SOA solution and analysis and design based on the service-oriented paradigm. The business rules may apply throughout the SOA solution and governance lifecycle.

Business Rules Manager

This ABB is responsible for defining, distributing, and maintaining business rules and their correlation to policies. The appropriate resulting policies are defined by using a Policy Manager ABB. This ABB supports rule implementation across multiple SOA RA layers.

Business Rules Repository

This ABB is responsible for storing and accessing business rules artifacts. This ABB is used by the Business Rule Manager ABB.

Policy

This ABB defines a policy describing principles to guide decisions to drive to desired outcomes. Policy is one of the fundamental constructs of an SOA solution and analysis and design based on the service-oriented paradigm. Policies may apply throughout the SOA solution and governance lifecycle. Policies could be at multiple levels, such as business level, architectural level, and/or operational level. It is important to capture the policy-related decisions and rules and policy information and its sources while defining policies such that the policies can be evaluated during policy enforcement by the Policy Enforcer in the Quality of Service Layer.

Policy Manager

This ABB is responsible for defining, authoring, distributing, and maintaining policies using policy management tools. Sophisticated policy managers may also check for and resolve policy conflicts. This ABB represents the primary Policy Administration Point in the SOA RA. This ABB is responsible for the distribution of the policies to one or more Policy Enforcement Points (PEPs) represented by the Policy Enforcer ABB in the Quality of Service Layer and its intersection with the other layers of the SOA RA for evaluation and enforcement purposes.

It is important to note that this ABB supports the management of policies needed to support security and logically includes all the responsibilities of a Security Policy Manager. A key tenant of an effective security program is management of security based on well-defined policies.

Quality of Service Layer: Policy Monitor

See Policy Monitor ABB in the Quality of Service Layer.

Quality of Service Layer: Monitoring Metric Tools

See Monitoring Metric Tools ABB in the Quality of Service Layer.

Dashboard

This ABB represents a set of tools that provide real-time status of the governing and governed processes and their metrics and checkpoints. It leverages the Monitoring Metric Tools ABB and Policy Enforcer ABB in the Quality of Service Layer.

Reporting Tools

This ABB represents a set of tools that customize, create, and generate reports on the execution of compliance and dispensation processes as well as the execution of checkpoints and monitoring of metrics. These reports can be stored with the Repository ABB. These reports can be created during any governance phase and any of the governance processes.

Development Tools

This ABB represents a set of tools used in the plan, define, implement phases of SOA governance to document governance policies and implement SOA governance metrics, checkpoints, and processes.

Quality of Service Layer: Configuration Manager

See Configuration Manager ABB in the Quality of Service Layer.

Change Control Manager

This ABB is used to control the updating of configuration, policies, and services. Change control applies to both the SOA solution and SOA governance. Change control processes are key processes to be governed.

Quality of Service Layer: Access Controller

See Access Controller ABB in the Quality of Service Layer.

Governance Gateway

This ABB is the gateway of all the ABBs in the Governance Layer to the other layers. In other words, it provides a focal point for processing both outgoing and incoming requests for governance management to and from the other eight layers.

Workflow Process

This ABB enables the automation of compliance and dispensation processes. The Workflow ABB from the Business Process Layer enables a business process to support manual intervention. This is often a requirement in a situation where error handling has to be performed. Standards include BPEL.

Structural Overview of the Layer

The Governance Layer applies to all the other layers of the SOA RA. ABBs of the Governance Layer can be thought of as being logically partitioned into categories that support:

• Ability to store and access (i.e., with registries, repositories, web sites, or databases) artifacts related to governance. Artifacts can be organization documentation, business process documentation, policies, compliance records, etc.
• Ability to define and manage business rules
• Ability to author and manage policies based on business rules at all phases of the SOA solution (design and runtime), including the ongoing governance vitality phase
• Ability to measure, monitor, and access governance metrics, both for ensuring governance policies are adhered to and for ensuring governance regimens continue to be appropriate
• Ability to manage and maintain governance, including the ability to do configuration, change control, security, and reporting
• Ability to automate processes and capture the processes in workflows

ABBs in the Governance Layer

The Governance Layer leverages ABBs from the Quality of Service Layer to fulfill its core responsibilities. The ABBs from the Quality of Service Layer leveraged by the Governance Layer are: Policy Monitor ABB, Monitoring Metrics Tool ABB, Configuration Manager ABB, and Access Controller ABB.

SOA governance capabilities and ABBs are used during the governing of an SOA solution. Other layers in the SOA RA define what technologies should be used to develop, deploy, and operate an SOA solution. The same technologies can be used to support the SOA solution and governance of the SOA solution.

SOA technology help realizing the SOA solution also needs governance, but the governance of these technologies is part of the service and solution portfolio and horizontal layers.

Each of the phases of governance will use a different set of ABBs.

A Plan Governance phase is responsible for analyzing, arranging, and scheduling solution-level monitoring and management; therefore, it would use the Service Repository ABB, Asset Repository ABB, and Business Rules Repository ABB to store governance information artifacts like governance principles, organization roles and responsibility, and business rules.

A Define Governance phase is responsible for defining a solution-specific SOA-based governance control model and strategy; therefore, it would use the Service Repository ABB and Asset Repository ABB to store the information artifacts, governance processes, and transition processes for implementing governance. It may also use a Business Rules Manager ABB and Policy Manager ABB to author policies to be used in the implementation phase.

An Implement Governance phase is responsible for enabling and realizing solution-level governance control; therefore, it would use many of the governance ABBs, including the Service Registry ABB for governance information for services, Service Repository ABB for services and governance metadata, Policy Manager ABB to author policies, and the Quality of Service Layer: Configuration Manager to configure the Quality of Service Layer: Policy Enforcer ABB; Quality of Service Layer: Access Controller ABB to configure security policies and enforcement points.

A Monitor Governance phase is responsible for monitoring and managing solution-level system status according to predefined governance policies and plans; therefore, it would use the Quality of Service Layer: Policy Enforcer ABB, Quality of Service Layer: Monitoring Metrics Tool ABB, Dashboard ABB, and Reporting Tools ABB.

Each of the governing processes in the final governance regimen, compliance, dispensation, and communication, will use a different set of ABBs. An example compliance process is illustrated in the next section.

Inter-Relationships between the ABBs

Relationships among ABBs in the Governance Layer illustrates the different ABBs and their inter-dependencies.

Relationships among ABBs in the Governance Layer

The Governance Gateway ABB invokes and governs the governing processes captured as workflows in the Workflow Process ABB.

The Workflow ABB captures and documents the governing processes. The workflows find governed services and other services to support governance using the Service Registry ABB. The Workflow ABB interacts with the Access Controller ABB, Policy Enforcer ABB, and Configuration Manager ABB in the Quality of Service Layer and Change Control Manager ABB and Reporting Tools ABB in the Governance Layer to accomplish the goals of the governing process. The Workflow ABB also shares ongoing policy enforcement results with the Monitoring Metrics Tools ABB in the Quality of Service Layer which in turn shares policy enforcement results with the Dashboard ABB and Reporting Tools ABB.

The Business Rule Manager defines policies in the Policy Manager ABB. The Policy Manager ABB shares policies with the Asset Repository ABB or Service Repository ABB, Policy Enforcer ABB in the Quality of Service Layer, Access Controller ABB in the Quality of Service Layer, and governing process workflows.

The Policy Enforcer ABB in the Quality of Service Layer and governing process Workflow ABB shares policy results with the Monitoring Metrics Tool ABB in the Quality of Service Layer.

Sample Interactions among ABBs in the Governance Layer for a Governance Compliance Process shows a flow for an example compliance process:

Sample Interactions among ABBs in the Governance Layer for a Governance Compliance Process

In this example, a business rule has indicated that a policy must be set that services that have excessive failures shall be inactivated and operations notified via the Dashboard ABB. At (1a-d) the policy to inactivate a service after five failures in a day is defined and distributed to the service repository, policy monitor, policy enforcer, and compliance process workflow. When the policy monitor detects that the service has failed more than five times, it invokes the policy enforcer to inactivate the service and notifies the monitoring metrics tool. The compliance process is running and at (3) looks up the service information which retrieves the policies for the service from the repository using (4). Now the compliance process checks with the monitoring metrics for policy exceptions and finds that the service has exceeded its failure threshold. The compliance process interacts with the configuration manager to configure the service to be out-of-use, the configuration manager interacts with the status manager is the Quality of Service Layer to update the repository with the current service configuration set to out-of-use. Now the workflow reports that the service has been taken out of use, as does the monitoring metrics. The monitoring metrics update the dashboard with a new status for the service being out of use. Here it is clear that the Governance and Quality of Service Layers work cooperatively.

Significant Intersection Points with other Layers

The Governance Layer is related to all the other layers of the SOA RA. All of the horizontal and vertical layers have assets that are governed by the Governance Layer. Some of the layers, especially Quality of Service, Integration, Services, and Business Process Layers contain ABBs that the Governance Layer needs to leverage.

Interaction with Cross-Cutting Layers

The Governance Layer is responsible for governing all the other cross-cutting layers, namely, Integration, Information Architecture, and Quality of Service Layers. In addition, the Governance Layer relies on ABBs in the Quality of Service Layer to fulfill its core responsibilities.

Key Interactions of the Governance Layer with Cross-Cutting Layers

Governance defines the policies used to drive the aspects of QoS in the Quality of Service Layer. The Governance Layer is dependent on the Quality of Service Layer to provide the following capabilities:

• The Business Rule Manager ABB is needed to ensure that the appropriate policies are set to support the policy manager capability. It also supports the Policy Enforcer ABB in the Quality of Service Layer in fulfilling its responsibilities through the Policy Manager ABB.
• It leverages the Policy Enforcer ABB in the Quality of Service Layer to enforce policies related to change control processes as required by the Change Control Manager ABB to ensure that change control is performed appropriately. Similarly, it leverages the Policy Enforcer ABB in the Quality of Service Layer to enforce security policies and policy to configure the solution using the Configuration Manager ABB in the Quality of Service Layer. It also leverages the Policy Enforcer ABB in the Quality of Service Layer to enforce governance policy and monitoring metrics for a solution.
• It leverages the Access Controller ABB in the Governance Layer to define the policies used to configure the security for the SOA solution and the governing processes via the security manager capability.
• It leverages the Configuration Manager ABB in the Quality of Service Layer in solution configuration and changing governance workflow processes. The Governance Layer defines the policies used to configure the solution using the Configuration Manager ABB in the Quality of Service Layer. In case there are automated governing process workflows, the workflow adjusts and changes the configuration using the Configuration Manager ABB in the Quality of Service Layer in order to adhere to the governance policies.
• It leverages the Monitoring Metrics Tools ABB and Policy Enforcer ABB in the Quality of Service Layer to measure, gather, evaluate, and test metrics against policies on a regular basis. The Governance Layer defines the policies used to implement the monitoring of metrics of the Governance Layer and SOA solution. Metric monitoring and analysis is used to drive governing processes and workflows to correct any policy violations and use the dashboard. Metrics and policy exceptions are also used to drive re-evaluation of the current governance regimen. Metrics are gathered on SOA services, governed processes, and governing processes. The Dashboard ABB leverages the Monitoring Metrics Tools ABB in Quality of Service Layer to customize what metrics and events should be visible on the governance and solution dashboard.

Interaction with Horizontal Layers

Governed assets exist in all of the horizontal layers; for example:

• IT infrastructure and implementation assets are governed in the Operational Systems Layer.
• Enterprise component are governed in the Service Component Layer.
• Services are governed in the Services Layer. Policies defined by governance decide which services will be built and re-used.
• Business processes are governed in the Business Process Layer.
• Governance and integration intersection – policies defined by governance – govern the mediation of interactions. The Integration Layer will utilize the registry and repository to actually find an end-point as a result of service invocation.

These horizontal layers define the different kinds of policies by interfacing with the Policy Manager ABB. In addition to governing these horizontal layers, the Governance Layer uses the Business Process Layer to capture governance process and the Workflow ABB leverages the Business Process Layer to define the governance processes.

The Services Layer leverages the Service Repository ABB to store service definition/contracts, policy, and metadata about services during design time. The Services Layer leverages the Service Registry ABB to store service definition/contracts and policy and metadata about services to be used during runtime in order to discover services and bind to service provider/end-point enabling service virtualization.

The Integration Layer leverages the Service Registry ABB to determine the end-point for a service request and to enable service virtualization.

Key Interactions of the Governance Layer with Horizontal Layers

In summary, the Governance ABBs are used by other SOA RA layers:

• The Service Repository ABB is used by the Services, Quality of Service, and Integration Layers.
• The Service Registry ABB is used by the Services, Business Process, Consumer, Integration, and Quality of Service Layers.
• The Policy Manager ABB is used by the Integration and Quality of Service Layers.
• The Business Rule Manager ABB is used by the Business Process, Services, Service Component, and Quality of Service Layers.

Usage Implications and Guidance

At the heart of these processes is the Service Model, the unifying concept that binds these elements to together and makes them relevant.

Options and Design Decisions

Four of the design decision points that exist are:

• The use of a standard service registry and repository versus roll-your-own
• Collaboration technologies for communication and vitality
• Automation of service lifecycle and tracking
• Automation of compliance and exception handling processes

The information in this layer that is collected and made available via a repository consists of, for example:

• Guidelines for SOA governance
• Guidelines for service and SOA solution lifecycle and portfolio management
• Best practices
• Business rules
• Policies (e.g., security)
• Standards
• Service and SOA solution roadmaps
• Compliance, dispensation, and communication documentation

As a result, it is necessary that the Governance Layer capabilities and ABBs support all of governing all of these processes. The governance of each of these processes may require different ABBs.

Another important responsibility of the Governance Layer is to measure, gather, evaluate, and test metrics against policies on a regular basis. KPIs for this layer may include:

• Usage metrics of a service
• Downtime and failure statistics on a service or service set
• Policy violations
• Number of services compliant and number applied for exceptions