While most people immediately think of enforcement when they hear the word "governance" in the context of software development, this is not where governance begins. SOA governance begins by establishing the desired behaviors you want to achieve through your adoption of SOA. If there are no desired behaviors, how will you know if your SOA efforts are successful? Likewise, if the desired behaviors cannot be measured, how will you know if your SOA efforts are successful? "Increasing business agility" is not a behavior that can be easily measured. "Decreasing the average delivery time for IT solutions by 20%" is a behavior that can be measured. As you refine your desired behavior, keep in mind that SOA governance includes pre-project activities, project activities, and run-time activities, and your desired behavior should reflect all of these. The earlier behavior that discussed decreasing the average delivery time really only impact project activities. If there is a need to change the way IT solutions are defined, as was the case for Advasco, there needs to be a desired behavior that reflects this. Likewise, what is the driver for policy-driven infrastructure in support of service interactions? This could be a behavior related to the responsiveness of IT to business change, or it could be a behavior associated with the up time of the IT systems.

Once the desired behaviors have been established, then the organization can establish policies that will yield this behavior. In order to establish these policies, the roles described earlier must be considered, and responsibility given appropriately, whether that is through a cross-functional Center of Excellence or in a more decentralized manner where the individuals in those roles work together as needed to establish enterprise policies for pre-project activities, project activities, and run-time activities.

The importance of this step cannot be understated. All too often, the people acting as "governors" are put in place, but the policies (and sometimes even the desired behavior) are never established. This can result in a dictatorial style, where the "governed" can only guess what the governors are looking for, and those guesses are usually wrong. In addition, the outcome is completely dependent on the particular governor involved. Another potential outcome is where the SOA effort slowly fades into the background. Some teams may claim they are "doing SOA," but there's nothing to either support or refute the claim. Over time, people will simply stop paying attention, since the claim doesn't mean anything.

Now that you have your desired behaviors and policies specified, the next process is still not enforcement, it is education and communication. While the governors may be aware of the policies, the governed may not be. In order to properly educate the staff, the people driving your SOA adoption efforts and establishing policy should also create a formal communication and education plan. The communication plan should include presentations that appeal to a broad audience, as well as presentations that are targeted toward particular audiences or toward a smaller group, such as an individual team. In addition to formal presentations, other communication techniques should be leveraged including whitepapers, blogs, and any other communication resources your organization has at its disposal.

Educational courses should be created for any skill sets the organization may lack, whether that is development technologies, such as Web Services, REST, or XML, analysis technologies, such as Business Process Modeling, or run-time management approaches such as ITIL v3 (Information Technology Infrastructure Library).

The people involved with your SOA governance effort must get the word out through presentations, documents, blogs, and whatever communication resources your organization has at its disposal. In addition to raising awareness of the effort, it will also build support for the effort such that people want to participate. People that may have questions about it will have the opportunity to voice those concerns, which can either lead to clarification on the reasons behind the policies, or to an adjustment of the policies. These conversations can be very constructive, because the policies must be connected to the desired behavior. If the connection between them is not clear, they should be questioned. If there is disagreement on whether the policy will lead to the desired behavior, alternative policies can be suggested, either by the governors or the governed. The one thing that is not questionable, however, is the desired behavior. For example, there should not be debate around the need to improve the average delivery time for IT solutions; however, there can be debate on the specific policies that will lead to that result.

Once again, there are strong parallels between SOA governance and traditional government. Constituents feel disconnected from their government when there is insufficient education and communication about the activities of the government. At its extreme, it can lead to a complete lack of faith in the government, which can have consequences ranging from revolt to the government becoming irrelevant. The same holds true for SOA governance. If the people involved in your SOA governance efforts are not educating and communicating, the people trying to make SOA a reality may simply ignore them or may be very resistant toward the enforcement efforts. Education and communication processes are the key to ensuring that governance is not seen with contempt in your organization, but rather as the key to enabling change for the better.

The next process that must be addressed is the one that most people associate with governance, and that is policy enforcement. Regardless of how much you've educated your organization and communicated the desired behavior and policies, you still need to ensure that you have compliance with those policies, and that requires enforcement. First and foremost, you must remember the golden rule when it comes to any enforcement process:

Education and communication are a big part of this, but there are also many opportunities beyond this, especially for project governance and run-time governance. For example, if you have a policy that states that average response time must be collected for all services, the easiest way to ensure this happens is to make it a zero-effort activity for the service development team. Their service needs to be deployed onto an application server in a production environment to be used. If those application servers already have a service management agent deployed on them, that agent will recognize the new service and immediately begin collecting metrics and storing them in the appropriate repository, generating reports, and so on.

There will be policies for which some effort is required, but the burden should be on the people establishing the policies to ensure that the required effort is as minimal as possible. In the Advasco story, a policy was established that required service development teams to seek out potential consumers from outside the project at hand. If the team has to arrange for meetings with every development manager to discuss this, clearly, it's not going to happen. The managers will get tired of the meetings, and the development team will struggle trying to figure out who to talk to, while at the same time, they will be pressured by the project manager who is wondering what is taking so long. Instead, if the act of entering a proposed service into the Registry/Repository kicks off notifications to other development managers, the effort can be significantly reduced. With appropriate analysis of the business domains and capabilities, the effort can be reduced even more by only sending notifications to managers most likely to be interested.

To further emphasize the need for the previous processes, enforcement processes can be streamlined when the people doing the enforcement are trusted to evaluate projects on their own. A possible approach recommended earlier was the use of review boards. Too often, review boards are only used because the policies have not been formally specified, and a room full of smart people is expected to make the decisions during the review process. This process is at risk for turning into a debate over policy between the people performing the review, rather than an effort

to review and improve (if necessary) the project under review. By formally stating policies and educating the project teams with solid communication, the focus can get back to where it belongs—making the projects better or simply adding them to the list of compliant efforts and getting out of their way.

The final process associated with SOA governance is that of measurement and improvement. While policy enforcement can tell you whether your efforts are compliant with the policies or not, policy compliance alone will not tell you whether you're achieving your desired behavior. If you're not, then something needs to change. Your organization is adopting SOA because something needed to be improved. Governance guides the organization through that change. If, however, you don't get there, then something else needs to change, and it could be the governance itself.

At each step along your SOA journey, you should be measuring whether or not your SOA governance efforts are achieving the desired outcome. This includes:

If your measurements show a problem, then something needs to change. It can be a change in process, policy, or people. If the policy compliance rate is low, one should look at the effectiveness of the communication and education, as well as make adjustments to how policies are enforced. If policy compliance is high, but the desired behavior is not achieved, then perhaps additional policies are necessary. If the effort is in complete disarray, then perhaps new people are needed, or a new organizational approach, such as switching from an Enterprise Architecture-driven approach to a Center of Excellence. This cycle of continuous improvement can also be leveraged by the IT staff itself, to measure the effectiveness of the people providing SOA governance. If policies are causing undue pain for the staff, there needs to be a way to bring attention to it, and either lead to a change in policy or a change in people.

Simply put, if you are not measuring your efforts, there is no way to state whether your SOA adoption efforts are successful or not.