The SOA Governance Reference Model is a generic and complete model that can be used as a baseline for the development of an enterprise's tailored SOA governance regimen. It includes:

• A specimen set of SOA governance guiding principles;
• Generic descriptions of the activities that are subject to SOA governance;
• Generic descriptions of governing processes that control these activities; and
• Example roles and responsibilities.

This section contains a summary description of the SOA Governance Reference Model, based on the work of the SOA Governance project of The Open Group's SOA Working Group. The model is described definitively and completely in the SOA Governance Framework that is being developed by that project.

Governance Principles

Governance is based on making informed decisions. Each enterprise should have a set of guiding principles to inform decision-making in the design, deployment and execution of its SOA governance regimen. The specimen set in the SOA Governance Reference Model can be used as the basis for the particular set that the enterprise adopts initially and evolves over time.

The specimen set incudes principles such as the following:

• SOA governance activities shall conform to Corporate, IT and Enterprise Architecture governance principles and standards;
• The SOA services and solutions shall comply with the Enterprise Architecture or Reference Architecture;
• Existing services shall always be considered first when creating new SOA solutions;
• Contracts shall exist between service providers and consumers; and
• SOA Governance processes shall be tailored based on project scope and risk.

SOA Activities

Most of these are not specific to SOA. For example, the activities of the TOGAF architecture development method are carried out for SOA just as for other architectural styles, and the development of a software module for a service can be carried out in the same way as the development of other kinds of software module.

There are, however, four groups of activities that are specific to SOA. The SOA Governance Reference Model contains generic descriptions of the activities in these groups.

• Solution portfolio management determines which solutions are developed and maintained.
• Service portfolio management determines which services are developed and maintained.
• Solution lifecycle management is responsible for the development, operation, modification, and eventual withdrawal of solutions. It raises requirements for service development that are addressed by service portfolio management, and requirements for service modification that are addressed by service lifecycle management.
• Service lifecycle management is responsible for the development, operation, modification, and eventual withdrawal of services.

The descriptions of these activities identify checkpoints at which governance controls can be implemented. For example, the Service Lifecycle Management group includes a Service Definition activity, which produces service requirements and has an Approve Service Requirements checkpoint.

When developing its tailored governance regimen from the generic framework, an enterprise modifies the activity descriptions as necessary to fit its particular development and operational practices, and decides what control should be applied at each checkpoint. It is the detailed selection and definition of these controls that makes the difference between a heavy governance regimen and a light one, and care is needed to ensure that the weight of governance is appropriate for the enterprise concerned.

The analysis of roles and responsibilities will help to determine what controls should be applied, and who is resonsible for applying them.

Governing Processes

Governing processes realize the governance intentions of the organization. The SOA Governance Reference Model defines three governing processes: compliance, exceptions, and communications. In general, they will be integrated with the existing enterprise governance processes, rather than forming a separate special set of processes for SOA.

• The Compliance process ensures that the governed activities are carried out correctly by reviewing their outputs at the governance checkpoints.
• The Exceptions process allows a project or application team to obtain dispensation from the requirements of the compliance process in particular cases where blanket application of general policy is not appropriate.
• The Communications process is aimed at educating the people that take part in the governed activities, and communicating to them the systems architecture and the governance regimen. This includes setting up environments and tools to allow easy access to and use of governance information.

For example, service testing is a typical activity to be governed. The compliance process ensures that it is carried out correctly, perhaps by inspection of test plans and test results. The exceptions process allows dispensation in special cases, perhaps allowing a project to skip detailed testing for a service that will only be deployed internally and for experimental purposes. The commumnication process ensures that the testing team understands the role that each service will play in the overall architecture, and knows how each service should be tested.

Roles and Responsibilities

An enterprise's tailored SOA governance regimen should include an anaysis of the kinds of people involved in the activities being governed, and their degrees of responsibility for those activities.

The SOA Governance Reference Model identifies typical roles of people concerned with SOA, such as CIO, business domain owner, business analyst, chief architect, business architect, SOA architect, solution architect, service architect, developer, tester, integration specialist, project manager, service librarian, and operations manager.

Generally, rather than acting alone, these people work in teams to carry out the SOA activities, and form bodies that take governance decisions. For example, the teams might include solution development teams, service development teams, and IT operations teams, and the decision bodies might include an IT executive steering board, an SOA steering board, an SOA center of excellence, and an SOA governance board.

Each enterprise will have its own role definitions and its own set of teams and decision bodies. To apply the the SOA Governance Reference Model, the enterprise must match its roles, teams and decision bodies to those of the reference model. It can then develop its analysis of which teams are responsible for which activities, and which decision bodies are responsible for which governance controls.

Such an analysis often takes the form of a RACI chart, in which degrees of responsibility are indicated as follows.

• R - Responsible – people who are responsible for the execution of the activity and for preparing the materials related to the activity;
• A - Accountable – people who provide direction for, authorization of, and approval of the activity;
• C- Consulted – people who can and should be consulted during the activity; and
• I – Informed – people who are informed when the activity occurs and are informed of the outcome of the activity.

For example, for the SOA Funding activity, the SOA Steering Board might be responsible, the IT Executive Committee might be accountable, business domain representatives might be consulted, and the SOA Governance Board might be informed.