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.