Article: SOA Governance: An Enterprise View

Areas of Applicability

Policy Examples

Governance Process

• Service Governance Roles include: Service Owner, Service Provider, Service Consumer, Service Steward, Service Registrar, etc.

• Service Governance Board includes representation from business, architecture, delivery and systems operations groups. The governance group is responsible for:

  • Defining and maintaining governance directives and policies

  • Granting of design and implementation exceptions when possible

  • Compliance reporting to the Management.

• Governance policies and controls may be monitored and enforced by the Service Registrar as well as by corresponding Review Boards and Architectural Bodies

Development Stage

• Design and development of the service has to have very strong reason(s) to be allowed going with an exception from the policies compliance

• Service design has to be based on and take into consideration business execution context of the required business task. The business execution context should be able to outline what elements of the service are likely to be changed in the future.

• Service design has to consider recommendations on the business operational scenarios for those who might use the service. If such scenarios are identified, business approval and sign-off are required.

• Services should minimise or totally hide their internal constraints from the consumers.

• A Service has to compensate for internal problem processing transparently to the consumers and never expose its internal execution constraints on to the consumers.

• Service interfaces and service body (implementation) must adhere to the corporate security policies

• The Service owner must provide service classification (business, infrastructure, etc.) and scope definition (business unit, enterprise, external, etc.) for each released service

• “Avoid setting up processes that demo well for three services without considering how it will work for 300” (SOA RA PRD 1).

Production Stage

• All business services are required to maintain a Service Contract for each consumer they support.

• All services are required to publish Service Descriptions

• If the service does not require a Service Contract, its service level agreement has to be published in the Service Description

• All services are required to adhere to a versioning strategy that provides all consumers with opportunities to migrate to the latest supported version(s) of a service.

• All Service Descriptions have to be published in the Service Description Repository

• All run-time service policies have to be published in the Service Policy Repository

• Run-time service Policies may refer to other policies. Policies may be applied by the Policy Enforcement Point (PEP) interceptors and enforced by the Policy Decision Point (PDP) mechanisms

• “…consider whether the display of status and activity for a small number of services will also be effective for an operator in a crisis situation looking at dozens of services, each with numerous, sometimes overlapping and sometimes differing activities” (SOA RA PRD 1)