Services have a lot of potential for providing value to the enterprise, but their use also brings a level of risk. Some of these risks are financial, while others are operational. Fortunately, all of this risk can be satisfactorily mitigated through appropriate governance activities.
Simply put, governance is the process of risk management. Without proper governance, services may be built that are missing the basic functionality required, that only satisfy one use (a waste of the cost and resources involved in creating a service), or that require costly modifications to be reused. Even when services are well designed and appropriate for a variety of applications, they may not be reused simply because the chain of communication breaks down - the advertising 
of available services is inadequate, or the indexing and documentation associated with them is insufficient to support effective identification and deployment. Finally, changing business circumstances are also a risk factor, since they can end up changing the requirements for a particular service.
The important thing to remember is that the governance processes you put in place must not only determine the points at which you will assess risk, but confirm that the appropriate risk management strategies have been employed. But before you can define the governance, you have to define the process that is being governed. The actual processes used will vary greatly from enterprise to enterprise, driven by both cultural and organizational differences. Despite these variations, successful SOA processes all share some common features and governance points at which SOA risks are evaluated and mitigated:
1. Project Portfolio Planning Governance
Most enterprises already have some form of project portfolio planning whereby ideas for new projects are evaluated and prioritized. Budgetary estimates are prepared, outlining the anticipated project cost and time to complete. Finally, these proposals are compared against the available budget, and a certain number of projects are funded. Depending on the organization and how budgets are allocated, this may be a singular centralized activity or a series of planning activities, one for each IT organization holding a development budget.
To be successful with services, you have to extend this planning activity a bit. Recognizing that you won't get an ROI from the first use of a service, it is prudent to think about the portfolio of projects in terms of which ones will create services and which ones will be consumers of services. This obviously creates dependencies between projects, impacting the sequence in which the projects will be executed. It may also influence your thinking about project priorities. If a major project requires a service that does not yet exist, for example, the creation of that service must become part of the portfolio plan, whether it is in that project or another.
There is a measure of speculation in this exercise - about what is important to the business, about what the project cost and schedule will be, and about what services will be created and used. Because of this, expect that reality will render some of these speculations inaccurate and alter priorities.
The typical project portfolio planning process has an annual cycle that is synchronized with the fiscal calendar of the enterprise. At a minimum, you need to integrate services planning into this annual process. You also need to add an activity for developing a cross-project services plan, and a governance step for reviewing this plan before the project portfolio is finalized. Besides this annual exercise, it is prudent to add a quarterly or semi-annual checkpoint. This governance step compares the actual project progress against the plan, as well as cost and schedule progress, and determines whether adjustments to the project portfolio are warranted.
2. Service Design Governance
Deciding to build a service is an investment decision, and should be treated as such. Implementing functionality as a service always requires more work than a basic implementation of the functionality. The service, by itself, provides no value. Its value lies in its use, and its return on investment relies on its continued use in the light of business process and systems changes. So the decision to build a service requires weighing the savings to be derived through continued use (i.e., avoiding subsequent modifications) against the incremental cost of converting the functionality into a service.
Service Justification and Specification
Justifying a service means making a determination that the additional cost involved in implementing functionality as a service is justified by anticipated future cost avoidance.
Specifying a service means defining it so that it will support anticipated future use without further modification. Accomplishing this requires a due diligence analysis of these anticipated usages - a bit of "crystal ball" gazing.
While some projects may be chartered exclusively to build new services, most arise during the course of ordinary development initiatives when the project team recognizes that a particular set of functionality might make sense as a service. The problem that these project teams generally face is that the only use of the proposed service that they are intimately familiar with is the one associated with the present project. This narrow perspective presents a problem. To determine whether a service makes sense, other potential uses need to be examined. Who has the proper perspective to do this exploration?
The answer should be the most experienced architects in your organization - people who know the landscape of the enterprise and can determine whether the service will fit. These are the senior systems architects for infrastructure services, and the senior business process architects for business services. Most of the time these people are not actively involved in the current project, so you need a procedure to get them involved and to make their response to the request a priority.
For efficiency, the involvement of senior architects should be structured into two distinct tasks: justification and specification. Justification should focus on weeding out the proposals that don't make sense as services. When justification concludes that a service does make sense, a deeper exploration of these uses is required so that the service and its operations can be fully specified. Once the architects have completed the specification then responsibility for the implementation of the service can revert back to the project team. Specifically, governance of service justification and specification requires:
- A procedure to get the appropriate senior architects involved in evaluating and specifying proposed services
- Prioritization of senior architects' time to ensure responses to evaluation and specification requests in a timely manner
- Well-defined criteria for evaluating service proposals and specifying services
- A checklist item in the project's architecture review to ensure that proposed new services have been appropriately justified
Service Architecture, Implementation, and Deployment
Because the operation of other application components depends on the proper operation of services, more stability is expected from services in terms of functionality, performance, and reliability.
These expectations increase demand for service implementation governance in two areas: architecture and testing. With a service architecture, performance and capacity require particularly close attention. The obvious aspect of this is ensuring that the design is capable of providing the specified performance when loaded to its planned capacity. Not as obvious is the need to design the ability to measure into the service and to report the actual demands that are being put on it while it is in use. These measurements will enable you to determine when the demands being put on the service are beginning to approach the design limits and additional capacity is needed.
Another challenge to service architecture is scalability. The anticipated future use of the service may call for capacity well beyond the initial demand - so far beyond that it is not cost-effective to deploy full service capacity initially. In such cases, it is prudent to design the service in such a way that capacity can be incrementally added as new service users come on line. Documentation must be provided describing how capacity can be incrementally added, including instructions for calculating the resources required to support different demand levels. Finally, thorough testing of the service prior to its integration into the overall SOA - although sometimes tedious and time-consuming - will cost less than discovering and fixing problems after integration.
Service Documentation
Because services should be designed to support future use, an investment must be made in providing enough information to support those future uses, and in putting that information in the appropriate places. The required information must span an entire spectrum of inquiry, from a simple "What is it?" to a detailed "Is it capable of performing the xyz operation at a rate of 273 transactions/second with a 0.5 second response time on a 24/7 basis with 99.9% availability?" At a minimum, documenting a service requires:
- A one-line functional description of the service
- A one-paragraph abstract of the service outlining its intended purpose and important constraints
- A comprehensive description of the service, containing the full specifications, explanatory material that characterizes the intended use of the service, examples, and instructions on how to prepare an application for using it
- A formal specification of the service interfaces. If you are using SOAP, this is the WSDL description of the service
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:
- A work thread in the implementation project to generate the required documentation
- 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.
