• Introduction
• Service Oriented Architecture
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• Introduction
• Background
• SOA Governance
• SOA Governance Reference Model (SGRM)
• SOA Governance Vitality Method (SGVM)
• SOA Governance Process Activities
• SOA Governance Process Information Entities
• SOA Governance Metrics Example
• Acknowledgements
• Referenced Documents
• SOA Ontology Technical Standard
• Legacy Evolution to SOA
• Navigating the SOA Open Standards Landscape Around Architecture White Paper

SOA Work Group

SOA Work Group Members Page

SOA Governance Technical Standard : SOA Governance Reference Model (SGRM)

The SOA Governance Reference Model (SGRM) is a generic model that is utilized as a baseline SOA Governance Model to expedite the process of tailoring an SOA Governance Model for an organization. All aspects of the SGRM are reviewed and considered for customization to the organization’s environment.

The SGRM defines a number of constituent parts, including:

• SOA governance guiding principles
• SOA governing processes
• Governed SOA processes
• SOA governance process artifacts
• SOA governance roles and responsibilities
• SOA governance technology

SOA Governance Guiding Principles

SOA Governance Guiding Principles assist in the prioritization and decision-making for the design, deployment, and execution of the SOA Governance Regimen. This includes aspects of people/roles, processes, and technology. In addition, the SOA Governance Guiding Principles should be utilized to aid an organization to achieve stakeholder commitment to the SOA Governance Regimen.

Below are the SOA Governance Guiding Principles of the SGRM. The organization’s SOA and governance maturity will affect how these principles are selected and how strictly they are applied. It is expected that a subset of these principles will be selected and modified. It is also expected that the principles will be expanded upon with principles unique to the organization.

There is also a set of important SOA principles that should be governed:

Organizations may need to create their own SOA and SOA governance principles that target their needs.

SOA Governing Processes

Governing Processes realize the governance intentions of the organization. These are the processes that a governance model uses to govern any particular process. Governed processes are the actual processes being controlled, monitored, and measured (e.g., testing, design, deployment); they are further expanded in Governed SOA Processes.

The SGRM defines three governing processes: Compliance, Dispensation, and Communication, which are performed on an ongoing basis. It is expected that organizations will define Compliance processes, but they should be customized and extended as appropriate for the SOA solution.

Compliance

The purpose of this activity is to define a method to ensure that the SOA policies, guidelines, and standards are adhered to. The Compliance process provides the mechanism for review and approval or rejection against the criteria established in the governance framework (i.e., principles, standards, roles, and responsibilities, etc.). In many cases, it is an add-on to the existing quality review process.

A suggested method is to insert SOA Governance Checkpoints into the defined SOA processes defined below (Service & Solution Portfolio and Lifecycle). These checkpoints can be manual reviews by responsible parties or automated, programmatic checkpoints. A set of possible checkpoints can be found in SOA Governance Process Activities.

The Compliance process is an ongoing process. When a checkpoint review is not approved or passed, then an exception to the Compliance process has occurred. The cause of the exception should be adjusted or realigned in order to meet the compliance requirements. If it cannot or should not be brought into alignment with policy, then the risk should be evaluated. To facilitate this evaluation, risk analysis criteria should be defined to determine the impact of the non-compliance to the organization, such as increased cost, deferred strategies, and implementation delays. If the organization chooses to accept the risks, then the Dispensation process is initiated.

Dispensation

The Dispensation process is the exception and appeals process that allows a project or application team to appeal non-compliance to established processes, standards, policies, and guidelines as defined within the governance regimen. Examples include service funding, service ownership, service identification, etc. The result would be a granted exception.

The following results may happen from a failed checkpoint assessment:

• Dispensation: Provides an alternative route to conformance by granting permission to remain non-conformant. These are granted for a given time period and set of identified service and operational criteria that must be enforced during the lifespan of the dispensation. Dispensations are not granted indefinitely, but are used as a mechanism to ensure that service levels and operational levels are met while providing a level of flexibility in their implementation and timing. The time-bound nature of dispensation ensures that they are a major trigger in the Compliance process.
• Comply: If dispensation is not granted, then the source of the failing checkpoint assessment must be brought back into compliance. The other option is to re-evaluate the risk using the risk analysis criteria, as additional facts may have been identified during the Dispensation process. Even if the dispensation is not granted, in some cases, an organization may still choose to assume the risk. While this is not the ideal scenario, it may occur, so the governing processes should address it during the process definition.
• Appeal: If the activity has caused an exception in a checkpoint and cannot or should not be adjusted to pass compliance, the activity exception can begin the appeals process to ask governance authority for a re-evaluation of the dispensation decision. Additional information to influence the decision should be brought forward.
• Escalation: Should the appeal not bring about a satisfactory result, an Escalation process can begin with the next level of governance authorities.
• Trigger for Vitality: Excessive exceptions and dispensations should trigger re-evaluation of the governance framework and possibly an iteration of the SGVM. Numbers of exceptions, appeals, and dispensations should be tracked as a Key Performance Indicator (KPI) for SOA governance vitality. Excessive dispensations may be caused by an error in the policies or guidelines as well as by a new business condition which impacts the current SOA solution or SOA Governance Regimen.

Communication

Communication processes educate, communicate, and support the SOA Governance Regimen and SOA policies, guidelines, and standards across the organization. This also includes ensuring that the governing processes are acknowledged within the governed processes. Communication processes should ensure that the governance is understood. It should also ensure access to and use of governance information.

Essential information to be communicated and available may include:

• Value of SOA and SOA governance
• Policies, standards, and guidelines
• Compliance processes
• Dispensation process including escalations and appeals
• Organization, role, and responsibilities
• Technology being governed and used by the governing processes
• Governed processes and checkpoints

Parties to be communicated with may include:

• Parties who are stakeholders; i.e., Business/IT Steering Group and Business Domain Representatives
• Parties responsible for SOA governed processes to ensure they understand and deploy the governance checkpoints appropriately; this includes the SOA Solution Architect, SOA Center of Excellence, Solution Development Team, Service Development Team, and IT Operations Team
• Parties responsible for enforcing SOA governing processes to ensure they understand the Compliance process and the Dispensation process; this includes the SOA Governance Board
• Parties responsible for the Compliance processes, including the SOA Governance Board and the Solution and Service Development Teams
• Parties responsible for the Dispensation processes, including the SOA Governance Board
• Parties responsible for defining and executing the SGVM to ensure it is re-evaluated appropriately; this includes the SOA Governance Board and the SOA Center of Excellence

Communication and information should be easily accessible via the use of technologies such as repositories and the Internet. A technology framework should be available for storing and accessing governance artifacts, such as the governance processes, stakeholders and responsible parties for those processes, current policies, guidelines, standards, and dispensation.

Communication is an ongoing process since changes in the policies and governance framework will need to be communicated. These changes come from either natural changes in business policy or iterations of the SGVM to keep the SOA governance current with business strategies.

Using service testing as an example of adding governance to an SOA governed process in an enterprise illustrates these processes. When an organization is doing service testing, it must ensure that application teams comply with the correct way to test services by defining checkpoints within the service testing process. These checkpoints have to be enforced in the Compliance process. The application teams are provided with means to challenge the test process through the Exception and Appeals process as part of the Dispensation process. Finally, application or project teams cannot be expected to follow the agreed process to properly test services unless this process was properly disseminated across the organization, which incorporates the Communication process. Of course it is also possible to do a much lighter governance in a smaller organization where compliance checkpoints might only occur in testing exception processes.

Governed SOA Processes

SOA governance begins with alignment to Business, IT, and EA governance. This starts with alignment of organizational governance and concludes with continuous enforcement and compliance during operation. The governed SOA processes include planning, design, and operational aspects of SOA as shown in Governed SOA Processes.

Governed SOA Processes

Instantiations of SOA should result in a set of SOA processes to provide ongoing management of the SOA solution. As shown in Governed SOA Process Relationships, at the project level, the Solution Portfolio Management process focuses on planning and prioritization of individual SOA solutions. These individual solutions may consume existing services as well as define new services. Following the guidance of the Service Portfolio Management process, these solutions may consume the re-usable services developed by the Service Lifecycle process and/or define new services for Service Portfolio Management. The new services are thereby prioritized by Service Portfolio Management for the Service Lifecycle process to manage for consumption by the individual SOA solutions. The Solution Lifecycle then enforces the Solution Portfolio Management plans during the development, deployment, and management of the individual SOA solution. This Technical Standard does not provide detail on these SOA processes (those can be found in other SOA Reference Architecture standards), but focuses on governance of those processes.

Governed SOA Process Relationships

SOA governance applies to the full lifecycle of SOA. To align with the SOA Guiding Principles within the SGRM, a number of additional process activities and governance checkpoints need to be defined and deployed in existing and new SOA processes to enable the governing Compliance process.

The SOA Governance Compliance process ensures continuous alignment and guidance of governance goals and policies, business goals, and the SOA solutions and services. The governance processes influence the goals and constraints of Service and Solution Portfolio Management which in turn focus on planning how to implement SOA governance at the applicable organizational level.

The next section details how to apply the SGRM to the SOA processes just discussed. Process activities, issues, and governance checkpoints have been provided as examples of SOA process activities and issues which are particularly important to govern. The important issues will certainly vary for organizations and SOA solutions. The governance checkpoints are examples of governance which could be applied to these processes. These are a starting point for customization for an SOA Governance Regimen for an SOA solution. A subset of these processes, process activities, and governance checkpoints could be selected; it is expected that additional ones unique to the organization will be defined.

Service Portfolio Management

Service Portfolio Management is the SOA process of ensuring that the organization has a set of services appropriate to its needs. Service Portfolio Management is normally a new set of activities not previously performed within the organization. It has some of the properties of Solution Portfolio Management, but many activities are brand new.

SOA Service Portfolio Management processes provide the most value when performed at an enterprise level. By establishing service planning strategies in accordance with Business, IT, and EA governance principles and goals, Service Portfolio Management has the responsibility to plan for, assign implementation to specific projects, and deploy the services at the right time. An important element of the Plan process is identification of services via decomposition of business processes. Projects should also be identified for implementing one or more of the planned services. The key is the correct services at the right time with the appropriate functional and non-functional requirements (e.g., capacity) in accordance with the long-term Business, IT, and EA strategies. It must also define proper service ownership, funding models, and usage plans based upon re-use plans and fiscal responsibility as well as SOA maturity progression strategies.

Key issues that arise for SOA:

• Planning for the appropriate identified services to create business agility and maximize re-use
• Funding models that support business agility and re-use across the organization
• Resolving service ownership issues across the organization

Service Portfolio Management governance helps ensure that these goals are achieved by:

• Inserting checkpoints into the services planning process, project planning process, service development lifecycle process, service ownership process, and service funding process at levels appropriate to the governance maturity of the organization
• Defining and monitoring metrics to trigger adjustment to the Service Portfolio Management process
• Service planning for decomposing services

Service Portfolio Management Activities

Below is an illustrative set of activities for Service Portfolio Management:

• Service Portfolio Planning
• Service Identification and Business Justification
• Service Ownership
• Service Funding
• Service Change Management

Further details including governance opportunities can be found in SOA Governed Processes.

Service LifecycleManagement

SOA Service Lifecycle Management is the extension of the organization’s Software Development Lifecycle (SDLC) by adding or putting emphasis on activities necessary for Service Lifecycle. Service Lifecycle processes cover the design, development, deployment, management, and ultimate retirement of services.

Key issues that arise for SOA:

• Adapting organization current software development lifecycle to service development lifecycle
• Establishing and approving service contracts (e.g., business processes will have the necessary capacity)
• Publishing services to enable re-use
• Managing multiple versions of a service
• Detecting unexpected service usage
• Meeting SLAs and architecting to enable this
• Managing to policies

Service Portfolio Management governance helps ensure that the goals of Service Lifecycle are achieved by, e.g.:

• Inserting checkpoints in the Service Lifecycle at both design time and operation time at levels appropriate to the governance maturity of the organization
• Defining and monitoring metrics to trigger adjustment to the Service Lifecycle process
• Changing management governance to ensure changes are coordinated across projects
• Ensuring service registries and repositories stay current

Service Lifecycle Activities

Below is an illustrative set of sub-processes for Service Lifecycle Management:

• Service Definition
• Service Realization Planning
• Service Modeling
• Service Implementation, Assembly, or Acquisition
• Service Testing
• Service Deployment
• Service Management and Monitoring
• Service Support

Further details including governance opportunities can be found in SOA Governed Processes.

Solution Portfolio Management

SOA Solution Portfolio Management is the process of ensuring that the organization has a set of SOA solutions appropriate to its needs and capability to implement and understand those solutions. Solution Portfolio Management processes identify the solution scope and develop solution plans for service re-use and new development in order to meet the solution requirements. SOA Solution Portfolio Management is the extension of IT Portfolio Management, adding or putting emphasis on a few activities necessary for managing the portfolio of SOA solutions. There is normally no need to create a new process for SOA Solution Portfolio Management since there will still be non-SOA solutions created and managed in the portfolio.

Effective enterprise transformation is assisted by the application of SOA principles to enterprise architecture in a synergistic fashion. SOA principles enable flexibility and improved time-to-market in IT supported processes and business solutions. Enterprise architecture merges strategic business and IT objectives with opportunities for change through portfolio gap analysis, transition planning, and architectural governance. Leveraging service-oriented portfolio gap analysis, the enterprise planning cycle transforms strategy into a roadmap of specific change initiatives, and governs the execution of that resulting roadmap. The SOA lifecycle then drives solution delivery in the context of one or more specific projects in the roadmap.

In addition to common Solution Portfolio Management processes, SOA Solution Portfolio Management has particular key requirements due to the nature of SOA:

• Ensuring SOA is a valid solution pattern for addressing the business problem
• Ensuring return-on-investment analysis for SOA is performed
• Ensuring SOA solution funding is available
• Educating and training stakeholders on the SOA Solution Portfolio and its benefit to the business

Solution Portfolio Management governance helps to ensure that the goals of Service Lifecycle are achieved by:

• Inserting checkpoints to ensure the quality of the Solution Portfolio at levels appropriate to the governance maturity of the organization
• Defining and monitoring metrics to trigger adjustment to the Solution Portfolio Management process
• Ensuring training/communication is done and maintained as the needs of the organization change

Solution Portfolio Management Activities

Below is an illustrative set of activities for Solution Portfolio Management:

• Solution Portfolio Planning
• SOA Solution Funding
• SOA Solution Validity
• Solution Change Management

Further details including governance opportunities can be found in SOA Governed Processes.

SOA Solution Lifecycle

The SOA Solution Lifecycle supports the design, development, deployment, management, change, and ultimate retirement of SOA solutions. SOA Solution Lifecycle processes are where the majority of the solution development is governed. Key SOA-related challenges during the SOA solution development lifecycle include, but are not limited to:

• Ensuring business processes for the SOA process orchestrations include business rules, business process management, and associated technologies
• Ensuring Service Portfolio Management interfaces include service identification and service contracts used by providers and consumers
• Enabling service assembly for building composite services and applications
• Ensuring service certification during deployment includes the validation of service contracts as well as functional and non-functional requirements
• Enabling service operational management which includes Service Level Agreement (SLA) verification, service monitoring, and reporting
• Ensuring change management for SOA services which includes accurate impact analysis of deployed services
• Ensuring proper cost allocation for service development and execution

SOA Solution Lifecycle governance helps ensure that the goals of Solution Lifecycle are achieved by:

• Inserting checkpoints into Solution Lifecycle processes (design, development, deployment, management, change, retirement) at levels appropriate to the governance maturity of the organization
• Specifying all the solution elements as a coordinated program, and identifying and coordinating stakeholders and organizing authority to proceed
• Managing solution responsibilities and providing solution management capabilities including scope management, issue management, and change management
• Providing a solution review process and adjusting contributing factors to attain optimum overall solution performance
• Preparing complete, comprehensive accurate estimates of solution effort and schedule including recognizing dependencies, resources required, and expenses and identifying risks and contingency plans
• Defining and monitoring metrics to trigger adjustment to the Solution Lifecycle process

Solution Lifecycle Activities

Below is an illustrative set of activities for Solution Lifecycle:

• Solution Definition
• Solution Realization Planning
• Service Re-use Planning and Re-use Exceptions
• Solution Deployment
• Solution Modeling
• Solution Implementation, Assembly, or Acquisition
• Solution Testing
• Solution Management and Monitoring
• Solution Support
• SOA Entitlement/Usage

Further details including governance opportunities can be found in SOA Governed Processes.

SOA Governance Roles and Responsibilities

Below are example roles and responsibilities that should be considered as part of an organization’s SOA Governance Model. Which roles apply will be a function of the governance principles and SOA governance maturity. The role name is not as important as the responsibilities highlighted. Each organization has their own role naming conventions and it is more important to adopt/align the new governance responsibilities with the existing internal structures.

These roles and structures are exemplary and provided as a starting point for customization for an SOA Governance Regimen for an SOA solution. A subset of these roles and/or structures could be selected. Different organizations might decide, for simplicity, to have combined organizational structures to support the roles displayed in the table below. Additional roles unique to the organization may be defined.

Example Roles and Responsibilities is a diagram of how these organizations could relate to one another:

Example Roles and Responsibilities

SOA Governance Process Artifacts

SOA governance artifacts are new artifacts created explicitly to support SOA governance. These artifacts should be available to governance stakeholders and kept current. These artifacts are exemplary and provided as a starting point for customization for an SOA Governance Regimen for an SOA solution. A subset of these artifacts could be selected or additional ones unique to the organization may be defined.

The categories of artifacts are:

• Business-level: Business-level artifacts include those developed from a business perspective to guide the development of a governance regimen for the organization. Business-level artifacts may include documentation of SOA goals, requirements, and use-cases for the business, SOA solution, and services. More specifically for SOA governance, business-level artifacts would document the governance guidelines, governance vision, and scope.
• Organizational: Organizational artifacts would include documentation of the organization charts, roles, and responsibilities for those affected by SOA governance. RACIs are one way to document this information.
• Roadmaps: Roadmap documentation would be based upon the current and target SOA and SOA governance maturity assessments. It would also include documentation of the governance roadmap which identifies future iterations of the SGVM.
• Descriptions: Descriptions define solution and service descriptions, including interface descriptions, schemas, service-level descriptions, and documents of understanding.
• Processes: Process descriptions document governed processes and governing processes for compliance and dispensations.
• Policies: Policies document business policies, SOA solution policies, SLAs, as well as governance policies. Governance policies include policies and metrics for monitoring SOA governance and SGVM iteration triggers.
• Plans: Plans document Transition Plans for the organization, process, and technology. Plans for communication and implementation for SOA governance are also key artifacts.

Examples of artifacts used to drive the SGVM are as follows:

Artifacts are also used to feed governing processes; example processes and the artifacts used by them are found in SOA Governance Process Activities. The extent of these artifacts depends on the principles and the maturity of the organization. The detailed content is described during the Define phase of the SGVM. A sample set of governing process artifacts used in the SOA governing processes have been identified as follows:

SOA Governance Technology

The purpose of this section is to identify technology capabilities that can be used to perform the SOA governing processes. It will not discuss or identify capabilities for the governed processes, but in some cases the identified capabilities might support both the governing and governed processes (e.g., a repository or a policy enforcement tool).

SOA Governance Technology is technology to be used to enable governance and the whole or partial automation of the governing processes. A framework for technology capabilities can range in ability from manual processes to sophisticated software. Technology capabilities used by the governing processes include:

• Store and access capability – A technology framework should be available for storing and accessing governance artifacts, such as internal or external web sites, registries, repositories, configuration databases, or knowledge management repositories.
• Policy enforcement capability – An SOA governance policy framework helps to support and possibly automate the monitoring for violations of governance policy. This can include both design time and run-time governance.
• Monitoring capability – An SOA monitoring framework can be used to measure and gather metrics on the SOA services and policy enforcement and the appropriateness of the current governance regimen. A monitoring framework can be used to implement governance enablement and trigger the checkpoints in the Compliance process.
• Management capability – SOA management tools, such as change control or configuration management, can be used to implement and maintain governance. There may also be governance guidelines regarding the usage of these tools. Security management capabilities are also key to ensure visibility of the results of governed processes to appropriate stakeholders. This is especially important for the governance Compliance and Vitality processes.
• Workflow capability – Capturing Compliance and Dispensation processes as workflow documents and enabling automation of the processes.

SOA Governed Technology is technology that is used by the governed SOA processes. Other specifications, such as SOA reference architectures, define what technologies should be used to develop, deploy, and operate an SOA solution. SOA Governed Technology also needs governance, but the governance of these technologies is part of the Service and Solution Portfolio and Lifecycle Management processes, not detailed in the present document, just like the governance of SOA processes and SOA communications.