A recent Forrester report describes service repositories as the foundation for service governance:
The vision and purpose of effective service management is to efficiently develop, operate, and deliver services with value and alignment to the business. To do this, IT must transform itself from an organization with many silos of technical and functional silos into a business with reliable and cost-effective service offerings. The attitude, behavior, and culture of the organization must shift to a service provider organization. The first step in this transformation is to develop a service catalog that describes the IT services supporting the business services and in turn the business process.
Although WebLayer's Chandu Natarajan agrees with this statement:
There's no question that a registry and a repository can play a critical role in the success of service-oriented architecture. After all, as part of a larger governance strategy, a registry and a repository can be key to managing service artifacts and their lifecycles, eliminating redundancies and encouraging reuse.
In his opinion the necessity for deploying of a full fledged registry-repository depends on the size of the company and the amount of services that the company has.
Based on customer experiences and feedback, a registry and repository is optimal in environments that need to:
Manage more than 50 services that are either created
- in house or will traverse the architecture through external sources.
- Dynamically discover services located throughout the organization.
- Expose services to public registries for community reuse.
- Adhere to extensive compliance regulations using advanced security, policy enforcement and auditing capabilities.
- Perform extensive and continuous auditing and logging of these services, check against SLAs at runtime etc.
According to Chandu, existing enterprise code repositories (such as a source control system), which are used to store SDLC artifacts during design time can, in many cases, be used for management of services, service related metadata and additional artifacts associated with services.
Of course, governance can and does complement a registry and repository. However, a governance strategy doesn't require a registry and repository to help architects enforce policies and obtain greater visibility to mitigate the risks associated with developing software that's designed to support the business goals of the SOA.
And so, the quest for simplifying SOA implementations continues. Of course one can argue that as long as SOA governance is in place, it does not matter what tools are used:
... govern any way you can, but govern
But this is not really a point. Firstly, service registries and repositories are very different and serve completely different purposes in SOA governance. Secondly, it is questionable whether SLDC tools (intended to support the creation of IT work products) are not really appropriate for service governance, which requires a close cooperation of both IT and business people. And finally, why the tipping point is 50? What is so special about it?