Your enterprise will likely develop its own repositories for service-related information, and some (or all) of it may end up in a UDDI registry. But documentation, by itself, has no value unless people are able to find and use it efficiently. Whatever your strategy for disseminating information about your services, you must ensure that the documentation for each service finds its way into your service advertising, repositories, registries, and indexes. Thus, governance of service documentation requires:

1. A work thread in the implementation project to generate the required documentation
2. A checklist item in the pre-deployment review to ensure that the required documentation has been created and deployed in the appropriate registries and repositories and has been indexed appropriately.

3. Service Utilization Governance
As has been discussed, the existence of a service does not, in and of itself, provide any value. It is the use of the service that provides value, and the second and subsequent uses that provide the return on the services investment. The most convenient way to ensure service utilization is to integrate its governance with the normal project governance. As a result, there are two key places in the project lifecycle at which service utilization should be considered: the architecture review and the pre-deployment review.

The architecture review should determine whether services are being used appropriately, with reviewers (business process and system architects) considering whether new services have been justified and specified, as well as whether there is other functionality that ought to be evaluated as a potential service.

The pre-deployment review for the project is the appropriate time to determine whether proper planning has been done for utilizing existing services. Has the organization responsible for each service been engaged to determine whether the service has the capacity required to support the intended utilization? Are there plans in place for granting access to the production version of the service and establishing access rights? In each instance, a checklist step in the project's architecture review and pre-deployment review are essential to ensure proper governance.

4. Service Operational Governance
Services typically require operational support after their deployment, across three broad areas: performance monitoring, new usage planning, and upgrade planning.

First, service monitoring is required to ensure proper operation - an important consideration given that many other components will be dependent on the service. Service performance must be measured to ensure that the service is meeting its service-level agreements. Service utilization levels must also be measured and compared against current deployed capacity. When demand begins to approach these limits, additional system resources will have to be deployed. This comparison must project far enough into the future to account for the time it will take to acquire the additional resources needed to increase capacity.

Another operational responsibility is new usage governance, which covers activities that are required when new projects want to use existing services. These include: ensuring that the new use is appropriate for the service; capacity planning associated with the increased demand that will result; and managing the actual access to the service.

Finally, the third operational governance responsibility is careful planning and coordination of service outages and upgrades (especially since a service outage will impact all service clients) as well as the deployment of new versions.

Summary
When it comes to SOA, the biggest financial and operational risks revolve around getting services used. It always costs more to build a service than to implement the functionality in a conventional manner. This additional cost is recovered by avoiding subsequent development use either through reuse of the service or the isolation of service clients from internal service implementation changes. But you won't get the ROI you want unless the service interface represents a point of stability in the overall enterprise architecture - a result that requires a systematic, process-oriented approach to governance across project portfolio planning, as well as service design, utilization, and operation.