It enforces compliance with the architecture and common semantics, and facilitates managing the enterprise wide development, use and evolution of services.

• Design time governance - Policies and procedures to ensure that the right services are built and used.
• Run-time governance - Policies that affect the binding of consumers and providers.
• Change-time governance - Policies and procedures that affect the design, versioning and provisioning of service enhancements.
  Run-time governance is implemented by a repository or other component of the infrastructure and is not the subject of this article. Design-time and change-time governance are implemented through processes and are the responsibility of the SOA program. Governance of SOA should include:
• Policies regulating service definition and enhancements, including ownership, roles, criteria, review guidelines, etc.
• Identification of roles, responsibilities, and owners.
• Procedures for designing conformant service interfaces.
• Procedures for ensuring correct and appropriate services are used.
• Review of service interface definitions for new services and enhancements to existing services. The review ensures that the service definition conforms to standards and aligns with the business and information models. The review is typically done by a service review board or the unit responsible for the service.
• Architectural review of applications and services to ensure that they conform to the SOA and enterprise architecture. This review is typically done by an Architecture Review Board. Often, these two reviews are done together.
• Guidelines, templates, checklists and examples that make it easy to conform to governance requirements.

An organizational and governance structure will need to be established to manage governance. But care should be taken to avoid the common mistake of over governance, typified by too much process. It is clearly the responsibility of the SOA program, and typically the architecture group, to ensure that services and applications conform to the architectural standards and requirements. However, it is much more effective to aid and enable applications to easily conform, than it is to try and force them into alignment after the fact. Architecture should be viewed as a help, not a hindrance to delivering business value. While part of governance is a final approval for conformance, the thrust of governance should be enablement.

Experience has shown that a proactive approach is generally more effective than a purely compliance based approach. This can be accomplished through the use of standard templates and conformance questionnaires. But, the SOA organization can go much farther than that. Providing examples of designs that conform to the architecture and standards (and why) is another important step. Most effective is to provide architecture assistance to projects to help them during the design phase to understand the architecture and develop conforming designs.

As with most enterprise issues, there is no one right solution for governance. It must match the culture and structure of the enterprise and meet the requirements of their development styles (e.g. in-house development has different governance requirements than outsourced development).

The primary responsibilities of the governance organization are to:

• Keep architecture current - There must be a mechanism for managing the lifecycle of the architecture itself. This includes feedback loops, periodic updating, releases, versioning, roadmaps, etc.
• Manage lifecycle of shared services - Resources that are shared across the enterprise, such as common services, need to be managed by a central organization. The governance model will have to decide how those services are managed throughout their lifecycle, including both design-time and change-time issues.
• Decision and issue resolution - Governance needs to define who is responsible for making certain decisions and how issues are resolved, escalated and appealed.
• Conformance - Finally, the governance organization needs to ensure that applications conform to architectural standards. This includes a clear definition of how conformance will be verified and measured and how exceptions will be handled.

Be forewarned: Developing the governance structure is not the first thing that should be addressed by the SOA organization as part of an adoption strategy. A common mistake is to put too much focus on the governance structure too early in the program. However, governance and conformance are not really needed until after the pilot phase of the rollout and can be developed during that phase. As with the adoption of any new technology or processes; start slow, figure out what works, grow it a little first, figure out how to scale it before rolling it out enterprise wide, and keep it current with feedback.

By Mike Rosen

Chief Technical Officer

Azora Technologies