Introduction

A service, be it physical like a shipping service, or implemented by a software agent, is always designed and refined to be reused by as many consumers as possible. This is the essence of Service Oriented Architecture: lowering the costs, risks and delays of building solutions by factoring and implementing IT assets such that they can be reused, often in situations unknown at design time. As such SOA governance is no different than data and IT governance which aim at designing information models or selecting technologies which can be reused beyond the boundaries of a given project. Services must be governed to become reusable: all foreseeable consumers must be able to express their requirements which are subsequently prioritized and phased, while a service owner is assigned and a funding model is defined.

In a previous article, Stefan Tilkov looked more specifically at the roles in SOA governance (1). My goal here is to help you establish a Service Governance organization in terms of people, process and technologies.

Service Governance Charter

The main objective of Service governance is to achieve the benefits of a Service Oriented Architecture by fostering the creation of reusable, enterprise class services. As a cross functional organization, Service governance ensures the timely resolution of issues and conflicts due to the necessary tradeoffs that are made when shared requirements are defined.

In particular, the Service Governance organization is chartered to define clear service ownership boundaries and specify a fair funding model.

Service Governance monitors the deployment and reuse of services across the organization. A high degree of service reuse, a steady flow of enterprise class service deployments, as well as trouble free service retirements are the indicators of successful governance.

Service governance should not overlap with traditional IT governance and Enterprise Architecture; they define the standards of SOA technologies and the roadmap leading increased levels of SOA maturity, while the Service Governance organization is tasked with evolving the service landscape.

In general, the role of Service governance is passive and process service candidates identified by specific projects or at the business unit level. It is only when an organization has reached a high level of maturity that Service governance may initiate a systematic top-down identification of enterprise services and charter their realization independent of any project.

In any case, the governance organization should be empowered to build enterprise services independent of the budget and resource restrictions of the project that will initially consume the service candidate. The reason is because reusability usually comes with a larger scope which translates into a higher price tag.

The governance organization is the steward of service definitions which are expected to be managed as corporate assets. It is also responsible for maintaining the traceability and compliance with other enterprise assets such as business process models and the reference data model. We will come back on the ties to a reference or enterprise data model in the last section of the document.

People

The article mentioned before described roles1 involved in Service governance activities from a service implementation perspective. When an organization is starting its Service Oriented Architecture, these roles are sufficient to guarantee the delivery of enterprise class services, especially when they belong to a SOA Center of Excellence.

As an organization mature and the number of service candidates increases it is helpful to introduce a governance leader who will own the process and resources to make sure that governance activities are executed appropriately and issues are resolved in a timely manner. He should be assisted by a cross functional governance council and a service librarian.

We see three main levels of maturity with respect to the Service Governance organization.

Figure 1 represents some of the interactions between the roles involved in Service governance.

Figure 1. Interactions between different governance constituents

The key in building a successful Service governance organization is again to be agile and assemble just enough resources, processes and technologies to meet your needs but not more. A large Service governance organization without a reasonable pipeline of service candidates will quickly lose steam and miss the opportunity to give adequate feedback on some service candidates.

You want to build an organization that will promote reuse of services, nothing less, nothing more.

Process

Processes and activities

There are five types of activities performed by the SOA governance organization:

• Service Candidate Management
• Service Change Management
• Service Consumer Management
• Service Roadmap Management
• SOA Governance Policy Changes

Figure 2 represents some of the activities that can be performed during the Service Candidate Management process. A project team may identify a service and create a service proposal. This proposal is then approved, approved with modifications or rejected (as an enterprise service) when this service candidate is not potentially reusable by other parts of the enterprise.

Once the service candidate is accepted, the ownership and funding model are defined and the SLAs and OLAs are specified with the help of the service owner and potential consumers.

Once the service is realized, its metadata is published to the registry and repository. In large organizations, it is advised to keep track of the services under construction to avoid concurrent service proposals.

Change Management activities are often identical to activities performed during a service candidate review. Activities such as service ownership, funding model or SLAs/OLAs specification might be optional.

One critical aspect of change management is the effective management of forwards compatible services (2).

Service Consumer Management activities are mostly performed by the service librarian unless there are changes that are necessary to allow this new consumer to consume the service. The librarian may help the service consumers identify the target service and acquire a copy of its metadata.

Service Roadmap Management activities are provided if the Service Governance acts proactively to identify services without specific project requests. At that point the Service Governance should have budgets to commission the development of these services ahead of the projects that will consume them. This is critical success factor of governance since the design and implementation of reusable services might go well beyond the scope, the means and the schedule of a given project. Governance activities themselves take time and may recommend lengthy upgrades to a service candidate. This is why it is so critical that the governance organization manages schedules and phases consumer specific requirements in a timely manner, minimizing the impact of solution delivery schedules.

Figure 2. Service Candidate Management Activities

Finally a governance organization might engage IT governance to define or change its operations policies.

Service Metadata

The service candidate proposal contains a description of the service interface (not necessarily in a machine readable form) as well as all the functional and non functional requirements associated to the service that will be used for instance to define the SLAs and OLAs. The CBDI Forum Service Architecture & Engineering meta model for SOA (3) provides a good view of the information relative to a service that is captured during the early stages of the lifecycle and refined over time.

The CBDI Forum SAETM metamodel contains a service definition, including proposed operations, policies and related services, as well as a service classification. The CBDI forum also recommends including a business level service definition which relates business processes, business capabilities, business rules... to the service definition.

All this information could potentially be used when a consumer is searching for a particular service. This is why it is important to capture it in a structured way even if machine readable description standards such as WSDL don't (yet) support this type of information.

The CBDI Forum SAE™ metamodel provides a separate section for the service specification. The interesting aspect of this part of the metamodel is that it keeps track of the information types that are involved in the service as operation arguments. This capability is not well supported by WSDL, for instance, which only defines the representations of the business types that are exchanged as parts of operation invocations but not the business types themselves.

The traceability of information types is critical because it prevents the introduction of operation specific semantics. A message type should always be defined with close ties to the reference data model. As a matter of fact, the SOA governance processes should make sure that no additional semantics are defined in the message type when compared to the reference data model.

The CBDI Forum SAE™ metamodel also keeps track of the business components that are used in a service implementation.

Service Reusability factors

There are three important factors to consider when helping promote the specification of reusable services. First a service interface must be complete with respect to its current and potential consumers. A good metric to track is the number of interface and implementation changes as new consumers come on board, for both the ones that are forwards compatible and the ones that are not.

Second, we must consider the appropriate Service and Operations Level Agreements (SLAs and OLAs). Some SLA might work perfectly for one consumer and be a show stopper for another one. SLAs and OLAs may also be difficult to achieve. The SOA governance organization should keep track of the incidents and monitor the number of changes to SLAs and OLAs that resulted from these incidents as well as the number of changes to the service implementation to effectively meet its SLAs and OLAs.

Lastly, a Service Governance organization should seek to identify all potential consumers of a service candidate and involve them in the process of ratifying the service interface proposal. A good metric to track there is the number of unexpected customers found after a service was designed. This metric should be interpreted carefully since it could mean that the service was well designed and attracted a lot of consumers, or it could mean that not enough time was spent to identify the right consumers which resulted in a lot of subsequent changes.

Technology

Service Governance activities and roles are often supported by a governance solution which is built around a service registry and repository. Even though it is quite trivial to say this, it is important to always keep in mind that an asset can only be reused as much as it can be found. A registry is the catalog or index that acts as the "system of record" for services within an SOA (4).

An SOA registry and repository typically support the following functions:

• Stores service metadata such as descriptions (message formats and operations), bindings (communication protocols), endpoints (the network accessible resource that implements the service)
• Provides a classification mechanism to help categorize and organize services
• Allows users to publish new services (as they are identified, realized and deployed) into the registry and to browse and search for existing or planned services
• Notify service consumers of planned changes
• Manage SLA and OLA reports as well as consumption statistics
• Manage securely governance processes and deliverables
• Provide audit capabilities to track the trail of changes and authorization applied to asset descriptions

Governance processes are geographically distributed in nature and collaborative. The management of these processes is critical to bring different parties for a consensus on the service definition and realization.

Since the registry and repository are the system of record for service information both at design time and run time, the security surrounding the "service record" is critical to avoid any substitution of end points for instance.

Relationship to other Governance activities

Service Governance is a new type of governance as part of the broader IT governance activities lead by Enterprise Architecture groups. IT governance should remain in control of the SOA platform governance itself, while Service Governance should focus its activities on designing services for reuse at the Enterprise, Service Realization and Solution delivery levels (Figure 3). At the enterprise level, Service Governance should work closely with IT governance to harvest the company's business process model to help identify service candidates based on a top-down analysis and establish a roadmap for the deployment of these services. As we have seen in the process section earlier, the service level is where most of the activities of SOA governance take place. All of these activities are supported by a registry and repository.

At the solution level, the Service Governance organization should evaluate and direct the level of compliance with respect to SOA infrastructure and service guidelines.

Service Governance has strong ties with Data Governance via the utilization of the enterprise Reference Data Model. The Service Governance team should enforce the utilization of the reference data model semantics for the design of operation message types.

The goal here is not to create a "Canonical Information Model". In a Service Oriented Architecture it would be naïve to think that consumers will always be in the position to adopt the point of view of the provider or that both the provider and the consumer can always adopt the same point of view. Even if this were true today, overtime, consumers and providers may not be in the position to evolve at the same time towards a newer version of the interface (be it forwards or backwards compatible).

Figure 3. Relationship between SOA governance and other governance activities

This divergent evolution is often handled using a mediator, and in particular message transformations. Even though mediation is not explicit in the W3C's web service architecture (5), SOA practitioners have long ago used it systematically to achieve a higher level of loose coupling and enable autonomous evolutions between the consumers and providers. These transformations are inevitable and this capability should be built into your SOA infrastructure. Incidentally, mediation does not require a "Common Information Model". If you were to use such "common information model" independent of the provider and consumer interface and still want to achieve loose coupling, you would incur the cost of two transformations, not to mention that you still need to transform your message format into a data set consumable by the implementation of the provider and consumer.

The first steps towards more manageable transformations, is to derive consumer and provider interfaces from the reference data model. In the reference data model, the data structure is less important than the normalization of the semantics. These semantics are managed with great precision by Data governance. Usually, the reference data model establishes traceability to physical artifacts such as database schemas and COBOL copy books. This traceability can prove very handy during the implementation of the service while the use of normalized semantics will help simplify the development of transformation maps between consumers and providers.

Conclusion

Service Governance is an essential aspect of a successful Service Oriented Architecture. Its establishment has to be planned and tested out early in the initial phases of a SOA initiative. However, a full scale governance organization driven by a rigorous process should be launched only when the service pipeline is big enough to keep the team motivated and knowledgeable. If governance activities are too distant in time, the team might lose interest and the critical knowledge to execute its activities properly. The Registry & Repository is a key ingredient for successful governance as it manages the "service record". The ultimate goal of Service Governance is to enable the specification, realization and operation of reusable IT assets. Overtime it is expected that Service Governance will evolve towards being a lot more proactive in commissioning the implementation of mission critical services.

References

1. S. Tilkov "Roles in SOA Governance"
2. J.J. Dubray "W3C Published an Update to Guide to Versioning XML Schema 1.1",
3. J. Dodd et al "CBDI-SAETM META MODEL FOR SOA VERSION 2.0", (requires registration), Everware-CBDI Inc.
4. webMethods, "SOA Governance, Enabling Sustainable Success with SOA", White Paper, October 2006
5. D. Booth et al "Web Services Architecture", W3C,