Moreover the approach taken to SOA governance must be in tune with the overall governance requirements and political climate. We have therefore distilled these experiences into an SOA Governance Framework - embracing policy, process, infrastructure and capability maturity - that can be tailored to each organization's specific needs. At the same time we are finding increasingly that SOA governance represents an opportunity to improve overall governance capabilities, which are all too often well short of the bar. Indeed successful SOA governance has to be seen as one component in organizational change management.

SOA Governance Defined

It is now clear that SOA provides huge potential for agility, both in response to technology and business change, and in terms of initiating change for organizational advantage. The problem is however a price tag, which includes difficult governance issues. For example:

• if services are to be widely reused then this requires profound and difficult issues in ownership, funding and project management.
• If services are widely reused this requires a significant increase in complexity of service specification - how do we make sure services can be specified clearly and consistently in a manner that satisfies multiple consumers with possibly varying requirements, timescales and change cycle times?
• And in today's offshore, outsourced world, we need governance over the choice of service provider and critically the delegation of architecture, design and test.

SOA governance is essentially a response to these problems that we define thus:

The part of IT governance that refers to the organizational structures, policies and processes that ensure that an organization's SOA efforts sustain and extend the organization's business and IT strategies, and achieve the desired outcomes .

SOA Governance in Context

An understanding of the idea of business governance is necessary to provide organizational context for SOA governance. Business governance refers to the leadership and organizational structures and processes that ensure that an organization's resources (including its services and supporting IT resources) sustain and extend the organization's business processes and goals. Moreover, SOA governance does not sit in isolation, but is part of IT governance which in turn should be an enabler of business governance.

The Full Spectrum of Governance

An important part of SOA governance concerns technology. Frequently we see vendors promoting a fairly narrow view of governance that just so happens to reflect the capabilities of their products, often focused on the operational activites.

However if an IT organization focuses solely on how its services are deployed and managed without paying sufficient attention to the business architecture drivers and the development processes and practices used to build services in support of that architecture, that organization is very likely to have a set of well-managed "service spaghetti," not a true SOA. Implementing a series of point-to-point services masquerading as an SOA will simply revive the integration nightmare of a few years ago with just another layer of technology.

The Need for a Framework

What is needed is an SOA governance framework that is aligned to the desired business and IT outcomes of the organization and that is compatible with your organization's current approaches to both IT and business governance. At the same time as we argue strongly in this article the SOA Governance Framework should not only be seen as a tool for dealing with these challenges. It is also provides an opportunity to put IT's house in order. Many organizations are at a very immature level of overall IT governance. SOA really forces you to address governance issues if it is to work effectively beyond the state of toy projects. This in turn has a positive effect on improving overall IT governance; see figure 1.

Figure 1: SOA Governance in Context

The CBDI-SAE SOA Governance Framework

It is important that SOA governance is approached in a balanced and complete fashion that addresses the What, How, Who and When aspects of the topic; see figure 2.

Figure 2: The CBDI-SAE SOA Governance Framework

Policy View

Figure 3: SOA Policy Categories

We have been busy cataloging and defining SOA policy types within the CBDI SAE Knowledgebase with respect to typically associated outcomes and risks; table 1 shows an analysis for a small portion of this hierarchy, which is too big to publish in its entirety in a report of this nature.

Table 1 - Policy Hierarchy Examples: Usage Policy Category

Process View

The process view focuses on the discipline of SOA Governance, its constituent process units, tasks and deliverables. Too often the complexity of SOA governance processes is exacerbated by mixing management with operational concerns. The discipline therefore separates these concerns, which are reflected in two different sets of process units.

The management level, which should be centrally controlled, ensures the SOA Governance Framework - in terms of policy, organization, process and infrastructure requirements - is aligned to the requirements of the organization before embarking on detailed policy definition and enforcement.

The day to day activity of SOA governance is spread across different disciplines according to the type of policy being dealt with. For example policies of the architectural policy type are set up as part of the SOA Architecture and Design discipline, specifically in Service Portfolio Planning.

Organization View

The organization view sets out the roles necessary for SOA governance with guidelines on organizational structure. Some of these roles are specifically focused on governance matters; for example, the SOA Governance Board and the SOA Governance Lead. Others such as the SOA Review Board may have a “leaning” toward governance. And yet others, such as the SOA CoE, Enterprise Service Architect and Service Level Manager, may well be charged with significant governance responsibilities, but as part of a much wider brief.

Certain roles, such as the SOA CoE are group roles that may map to new organizational units or may be subsumed within existing units. In contrast, other roles such as the SOA Governance Lead are likely to be assigned to one (or more) individuals.

It is also important to define policy that states which roles are accountable for which SOA artifacts in terms of responsibility (R), authority (A), expertise (E) and work (W); RAEW analysis is used to assist here ².

Infrastructure View

The infrastructure view sets out the infrastructure capabilities necessary for SOA governance. There is a wide variety of implementation types, both automated and manual, the purpose of which often extends beyond governance alone to areas such as SOA modeling and service execution. The rationale of the infrastructure view is to focus on the governance capabilities in terms of:

• Policy Management: how is policy defined and maintained, what level of support is available for assertion languages? For example, using a service catalog and repository with links to modeling tools using a standardized SOA meta model
• Enforcement Mechanisms: what is the actual means of achieving different types of compliance, how often is it checked and to what degree of precision? For example, using an ESB to provide run time policy rule checking and routing.
• Communication: how can governance be communicated and demonstrated? For example using a service level management dashboard to demonstrate compliance with Quality of Service thresholds.
• Change Management: how can governance changes be audited? For example, using a service catalog to enforce service life cycle state change policies (e.g. publish and discovery) with support for system of record via a repository.

SOA Maturity View

We have developed a rich SOA Governance Framework that identifies expected SOA governance capabilities at each of five stages of SOA maturity as defined in the CBDI SOA Maturity model ³ to provide overall consistency. The maturity view includes capability maturity tables for policy, process, organization and infrastructure; table 2 provides some overall examples together with outcomes and risks.

The SOA governance capabilities indicated in the cells are mapped to the organization's “as is” state of SOA governance and to the “to be” state in terms of projected SOA outcomes. An SOA Governance Roadmap is then constructed forming a foundation for transition plans.

While the SOA Governance Maturity Model is rich, in order to provide comprehensive coverage, the intention is that it should be workable in small manageable chunks within its target context. This is where outcome and risk analysis, together with a good understanding of organizational context, come into play as described in the second part of this article.

Table 2 - Overall Governance Requirements by Maturity Stage

1. SOA Policy, Allen, P., CBDI Journal , June, 2007 http://www.cbdiforum.com/secure/interact/2007-06/soa_policy .php
2. Towards the Service-Oriented Organization, Veryard, R., CBDI Journal, Jan 2004 http://www.cbdiforum.com/secure/interact/2004-01/towards_service_oriented_org.php
3. SOA Maturity Assessment Survey, Sprott, D., CBDI Journal, March 2007 http://www.cbdiforum.com/secure/interact/2007-03/soa_maturity_assessment_survey.php

  Images used in CBDI Journal April in Powerpoint format (Gold subscribers only)

  CBDI Journal April in Adobe PDF format (Gold subscribers only)

Reports in April Journal

• Main Menu
• Editorial
• SOA Testing - Managing Testing in an SOA Environment
• SOA Governance: Challenge or Opportunity

Print this page