SOA Governance Requires More than a Service Registry

By Regunath Balasubramanian

(Back to article)

The first thing most people in IT leadership think of at the mention of SOA governance is the service registry because software vendors have so successfully promoted the view of automating SOA governance through their respective products. Effective SOA governance requires more than just a service registry and, in fact, is much more dependent on people and processes rather than technology solutions.

SOA governance and consequently, the service registry, are merely enablers for SOA adoption. It is therefore logical to consider the drivers for SOA adoption and how they are realized through governance and the service registry.

The foremost drivers for SOA are integration and reuse. The latter when measured, is an indication of success of the initiative. Common challenges to reuse are fulfillment of business functionality, service level guarantees for hosted services, service ownership, incentives for reuse, and available service information. A multi-level and strong governance framework is needed to address these challenges with the service registry servicing mostly the information needs of the framework.

This article identifies the core elements of SOA governance and discusses how and where a registry may be used in the service life-cycle.

SOA and IT governance - The strategic nature of many SOA programs implies the need for strong governance. SOA governance is in fact an extension of IT governance:

governance chart

Enterprise IT principles and governance decisions drive SOA principles and decisions as SOA is but one of the many solution architecture paradigms used to produce an enterprise’s architecture deliverables. The governance framework is, therefore, mostly an extension of the responsibilities of existing stakeholders with the exception of a dedicated SOA centre of excellence created for large SOA initiatives.

Core elements of SOA governance - Almost all SOA governance aspects may be articulated into the three core elements (This categorization gives a bird’s eye view of decisions to be taken and managed in SOA adoption.):

Software vendor literature emphasize technology solution capabilities and seldom address the people and process aspects of governance. This gap has a profound impact in achieving reuse, which, then, negatively effects ROI measurements for SOA adoption.

Multi-level SOA governance - SOA governance has multiple implementation levels; each mandating involvement from distinct groups of stakeholders. The table below summarizes the typical levels and the related governance activities that are performed:

The various groups defined in governance activities need access to different sets of information on deployed and available services at different points of time. Service specification documents explain the externally visible features of the service to a service consumer and are mostly limited to the interface details (WSDL documents in case of Web services). Better and more comprehensive service specification documents may additionally define service level characteristics like reliability, policies, and state. Service specifications focus on describing the service in its static form but fall short in providing a real-time view of the deployed service being used as a reusable asset in the enterprise. The service registry addresses this shortcoming.

The service registry - The service registry has at least two antecedents: first is the document repository and the second a UDDI registry. The term service registry may be a misnomer since the registry is also a repository of service meta-data. A service registry is quite useful in the following stages of the service lifecycle as an information store of service meta-data:

A case for standards

Work is underway by consortia like OASIS, IEEE, W3C, IETF and WS-I , to define standards and specifications around SOA. While some may view it as standards overload, there undoubtedly is a case for defining guidelines on service specification and service life-cycle processes. Best practices for using service registries in SOA governance and feature-set specification of a service registry are useful too. Standards, specifications and guidelines when defined, provide a good framework for using the service registry in SOA governance and consequently realizing the benefits of SOA adoption.

Regunath Balasubramanian leads the Technical Achiever Program at MindTree and is a practicing architect. He is an advocate of open source both in using and contributing. He blogs frequently on technology at http://regumindtrail.wordpress.com.