Is Your SOA Governance Strategy a Disaster Waiting to Happen?

Computerworld - As the service-oriented architecture (SOA) environment and marketplace matures, and the topic of SOA governance has moved to the forefront, I have noticed that industry discussion is increasingly centered on the topic of repositories and registries. What role should a repository and/or a registry play in an SOA initiative?

There are those that say "a registry is all you need," while others, including Ron Schmelzer and Jason Bloomberg at ZapThink LLC, argue that a repository with asset management and governance capabilities is just as important as the downstream registry. Before I explore this latter point of view, however, let's define those two terms within SOA.

A registry specifies the set of available deployed services (think of the Windows registry, which is used to manage the list of installed programs and some of their configuration settings), while a repository manages services and their artifacts (work products such as requirements documents, models, test plans and usage guides) through their full architectural, development and deployment life cycles. A repository may store those artifacts directly, or more likely, it may simply reference where those artifacts reside, such as in version-control repositories, requirements management tools and automated test tools.

Repositories are also used to manage the supporting software assets that make up the service implementation -- the myriad components, adapters, legacy application programming interfaces (API), SQL queries and other software elements that support the operations expressed by a Web service's Web Services Description Language document.

With these definitions, it becomes clear why a repository is just as important, if not more important, than a registry. A well-designed repository is where everything comes together on the architectural/development side of SOA, where new services can be proposed and managed through their development life cycle, then exposed to downstream application developers directly within their integrated development environments.

This production/distribution/consumption model is core to SOA, and applies not only to deployed services (the purview of a registry) but also to services under development or architectural review. Certainly, at some point, those produced services will be deployed and exposed through some form of registry function (be it Universal Description, Discovery and Integration, an enterprise service bus's native registry/proxy service, a repository's search and notification APIs or even Lightweight Directory Access Protocol), but thinking that you have solved your service management and governance problem by deploying a registry is like thinking that you've avoided an iceberg by avoiding the part you can see. The registry is 10% of the solution, and the bulk of our needs are "underwater" and invisible to