As you develop your service-oriented architecture, here are six key governance issues to keep in mind—and preferably begin to define—in the early stages:

* Business process definition: Because services are instances of business processes, you need to know what the right processes are. Typically, a joint business-IT group determines these processes and decides which should be standardized across the organization so that the services that deliver them also reflect both the standards and the exceptions.

* Architectural compliance: Just as a builder has to follow the architectural plans and code requirements for a house, so does an IT organization have to follow the service standards and development “blueprint.” Typically, a review board vets all application development proposals to ensure they conform to the architecture. Often, they also identify proposals that duplicate existing resources, to enforce reuse.

* Service management: A repository of services helps developers and ¿business users know what already exists and what they do. This encourages reuse by IT developers and helps business analysts see what capabilities they might be able to exploit in new ways.

* Data management: Just as services can be used and combined in ¿multiple ways, the data they access and act on can come from multiple sources whose context may not be known by all services. This requires a data architecture that makes this context (metadata) explicit so that all services are working from the same set of assumptions, or consistently translating and interpreting the data they use.

* Security and compliance: Because services are not standalone ¿applications, they can interact with each other and be accessed by users in unexpected ways. The development and provisioning policies need to test and validate that this mix-and-match approach does not introduce security or access violations.

* Provisioning management: Because services can be used by lots of ad hoc, composite applications, execution load may be unpredictable.

There should be policies for determining access priorities and performance levels under such severe usage, including policies for when to spin out clone ¿services and the supporting IT resources to handle high loads.