I’ve even heard of cases where SOA governance itself has tended to go too far, strangling the innovation that service orientation and loose coupling is supposed to promote. One vendor executive I recently spoke with said he saw customers pull back on governance when they realized that the restrictiveness stifled the ability to effectively deploy and reuse services.

If your goal is to be a very innovative company, but your command and control structures prevent you from doing so in a timely fashion, that’s not a problem with governance per se, but with the governance model you’ve chosen.

Todd is dead on, of course: It's all about the model. SOA governance is the means by which you ensure that the SOA delivers business value. Agility and innovation are certainly part of that value for any business, but the specifics of where and when that innovation actually happens depends on the environment within the organization.

In designing the appropriate model, it's important to remember that SOA governance has to cover a lot of territory, but that doesn't necessarily mean that governance has to be applied with equal pressure over the entire service lifecycle.

For instance, if the objective is to allow unbridled innovation in the reuse of available services in the creation of composite applications, more control may be necessary over the design, development, and delivery of the services to be made available for that purpose. In that model, it's a matter of providing a limited portfolio of high-quality, high-performance services and letting development teams mash-up at will. Provide the kids with a clean, well-lighted sandbox and let 'em go nuts.

If the objective is more tightly controlled service consumption in the creation of composite applications, more SOA governance pressure may be required at that point in the life cycle. In this situation, the portfolio of available services may be much larger than in the previous scenario (and maybe even less consistent in terms of quality and performance), but the actual selection of the services to be used in specific app development projects will be made at the architectural level, and not left to the app development teams. This follows the prescriptive model discussed in a previous post.

The right SOA governance model for any organization depends entirely on the specific goals and the specific environment: available tools; skill levels; general level of SOA education, maturity, and commitment; and a plethora of other factors affecting the people, processes, and technologies involved in the SOA.

It's important to remember that the dynamic nature and interplay of these various factors makes the SOA a living thing. For that reason, governance must be equally organic. In the end, the right governance model is a matter of sustained balance rather than static, either/or decisions about where to apply the most stringent policies. Maintaining balanced SOA governance is a dynamic process that requires holistic visibility and understanding of what's going on in the SOA. That information will a provide the basis for decisions about how to evolve the SOA governance model in order to maintain alignment with goals that are very likely to be moving targets.