By Paul C. Brown

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. The decision to build a service thus 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.

Governance is the process of making sure that things are being done the way they are supposed to be done. Governance generally employs two techniques: education and enforcement. The point of education is to ensure that it is done right the first time. The point of enforcement is to catch mistakes before they become serious.

There is a tendency in services governance to rely too heavily on enforcement. An architecture review is certainly an appropriate place to catch a mistake in either the design or use of services. Unfortunately, by that point the design team has made a significant investment in the design. While the review catches the mistake before you make any additional investment in implementation, fixing design mistakes still takes time and resources.

Education will help to avoid design mistakes. Education, however, requires investment. How to “do it right” has to be defined and documented by the SOA leadership team, and this knowledge must be transferred to the project design team through some combination of formal training, mentoring, and reading.

You will have a hard time with SOA if your entire approach to governance is enforcement. It will be like establishing a speed limit on a highway without posting signs to tell drivers what the speed limit is. For your SOA efforts to be successful, you enterprise-specific vision of SOA and your enterprise-specific best practices for achieving that vision must be captured and shared.
The governance of service creation is centered around the following points:

1. Ensuring that the creation of the service is appropriately justified and specified
2. Ensuring that the service is implemented appropriately
3. Ensuring that the service development process produces artifacts required to support its future usages

The details of precisely where these governance activities will fit within your development processes will vary greatly depending upon your development practices and organizations. It is up to you to determine the details and ensure that it actually happens!

(This article is an excerpt from a chapter on SOA Governance from the book, “Succeeding with SOA: Realizing Business Value Through Total Architecture,” published by Addison Wesley in 2007. The author is principal software architect at TIBCO.)