• 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 : Introduction

Objective

This document describes a framework that provides context and definitions to enable organizations to understand and deploy SOA governance.

This document defines:

• SOA Governance, including its relationship between Business, IT, and EA governance; this assists organizations in understanding the impact that the introduction of SOA into an organization has on governance
• An SOA Governance Reference Model (SGRM) and its constituent parts, which assists organizations in specifying their appropriate governance regimes; and capturing best practice as a basis for a common approach
• The SOA Governance Vitality Method (SGVM) which assists organizations in customizing the SGRM and realizing their SOA Governance Regimen

This document is not intended to be used as provided; it is intended to be customized to create appropriate SOA governance for the organization. Many of the lists are non-normative and exemplary and intended to be filtered and as input to the customization process.

This document does not include an explanation of the fundamentals and value of SOA which is important for being able to understand and apply SOA governance. Many other specifications and books, some of which are referenced, are available on SOA basics.

Overview

Many companies have adopted Service-Oriented Architecture (SOA) as an approach to architecture to assist in closing the business and IT gap by delivering the appropriate business functionality in a timely and efficient manner. For more details on this, refer to available books and standards on SOA (see Referenced Documents).

Many companies that have approached SOA via a pilot project have not been seeing the same demonstrated SOA benefits once they have deployed a fully-fledged SOA project. While pilot projects achieved a level of re-use, they have tended to be within one division, but as soon as a project boundary crosses multiple divisions, new challenges are encountered.

One of the key disciplines to assist in addressing these challenges is governance. Whilst governance has been around a long time, SOA has heightened the need and importance of having a formal SOA Governance Regimen that sets expectations and eases the transition of an organization to SOA by providing a means to reduce risk, maintain business alignment, and show business value of SOA investments through a combination of people, process, and technology. The role of the SOA Governance Regimen is to create a consistent approach across processes, standards, policies, and guidelines while putting compliance mechanisms in place.

Most organizations already have a governance regimen for their IT department covering project funding, development, and maintenance activities. These tend to have been defined using either one of the formal standard IT governance frameworks – such as COBIT, ITIL, etc. – or an informal in-house governance framework that has been built over many years. The focus of The Open Group's initial release of an SOA Governance Framework is primarily based on the IT aspects of SOA governance.

This document contains a description of the governance activities that are impacted by SOA, and puts forward some best practice governance rules and procedures for those activities. In order to specify the changes necessary to accommodate SOA in an existing governance regime, the governance activities described in this document must be mapped and integrated to the activities being utilized in the existing regime. Many of the lists provided with the explanations of the SGRM and SGVM are non-normative examples intended to provide a starting point for customization to the SOA solution.

This document is organized as follows:

• This chapter provides a general introduction.
• Background discusses the background to SOA governance, describing the reasons why governance is important for SOA, the challenges involved, and the benefits that should be achieved.
• SOA Governance defines SOA governance and explains The Open Group SOA Governance Framework.
• SOA Governance Reference Model defines the SGRM, which is the generic model used as a baseline for tailoring an SOA Governance Model for an organization.
• SOA Governance Vitality Method defines the SGVM, which is a method that uses the generic SGRM to instantiate an organizational unique SOA Governance Model.
• SOA Governance Process Activities describes the SOA governing and governed processes.
• SOA Governance Process Information Entities describes governing and governed process artifacts, and SGVM artifacts.
• SOA Governance Metrics Example contains examples of SOA governance metrics.

Conformance

The SOA Governance Framework does not have strict compliance statements or testing. It is expected that this Technical Standard will be customized appropriately into a governance regimen for the industry or organization applying it.

For those SOA Governance Regimens to be conformant with this Technical Standard, they must have at least the following processes defined:

• Compliance process
• Dispensation process
• Communication process

The SGVM must also be defined for the organization.

The nature and extensiveness of the guidelines and the governed processes depends upon the SOA maturity of the organization; therefore, SOA governance conformance does not assert any requirements on them.

Terminology

Can

Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Implementation-dependent

(Same meaning as “implementation-defined”.) Describes a value or behavior that is not defined by this document but is selected by an implementer. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior cannot be assured to be portable across conforming implementations. The implementer shall document such a value or behavior so that it can be used correctly by an application.

Legacy

Describes a feature or behavior that is being retained for compatibility with older applications, but which has limitations which make it inappropriate for developing portable applications. New applications should use alternative means of obtaining equivalent functionality.

May

Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.

Must

Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.

Shall

Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Should

For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. For an application, describes a feature or behavior that is recommended programming practice for optimum portability.

Undefined

Describes the nature of a value or behavior not defined by this document that results from use of an invalid program construct or invalid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Unspecified

Describes the nature of a value or behavior not specified by this document that results from use of a valid program construct or valid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Will

Same meaning as “shall”; “shall” is the preferred term.

Future Directions

The current version of this Technical Standard defines a core SOA Governance Framework. Future versions could evolve the material and expand on a variety of relevant topics. The following are some possible areas:

• Meta-model: The current document expands on a variety of topics. It would be beneficial to have a meta-model that explicitly represents the various framework elements. This would help avoid possible ambiguities, and enable possible tool automation.
• Compliance: Most of the current conformance text – see Conformance – is not normative. Future versions could provide more specific guidance regarding what constitutes adherence to this specification.
• Maturity Model: The method and model shown in this document provide key conceptual tools for defining an SOA governance effort. Complementary to them is an SOA Governance Maturity Model, which can be used within the Plan phase, helping to define more robust roadmaps. This maturity model would be synchronized with the OSIMM effort.
• Policy: The topic of policy is important to governance. Further versions expect to expand on its relationship with the rest of the model concepts.
• Control Gates: The topic of control gates is important to governance. Further versions expect to expand on its relationship with the rest of the model concepts.
• Business Governance: Business governance refers to the set of processes, customs, policies, laws, and institutions affecting the way in which an organization is directed, administered, or controlled. The primary focus of this SOA Governance Framework version is on the IT aspects of SOA governance, with a small number of key business governance items. However, additional business governance aspects will enhance the completeness of an overall SOA governance program.
• Governance Model Maps: More detail positioning to other relevant governance models; e.g. COBIT, ITIL, etc., could be added.
• Other Topics: For example, description of SOA governance for particular contexts; e.g., external ecosystems, and positioning of SOA governance with TOGAF governance, as well as working with OASIS and OMG to ensure alignment around SOA governance.
• Examples: Future versions will have given time for examples of specification to be defined. These examples could be added to the effort to provide further clarity.