Did you ever notice that "governance" and "compliance" have the same nearly ominous tone to them? It's as if they should be preceded by some dark music normally associated with a Vincent Price movie.

The two are also similar in that they both focus on process, not product.

I know that sounds nearly heretical, and I'm sure some of those entrenched in the world of SOA Governance might take umbrage with that statement, but after a few drinks I'm sure they'd agree that fundamentally SOA governance, like compliance, is really about the process - and enforcement of the policies that go along with it.  

That's not to say there isn't a place for products within SOA Governance. In fact, products exist to help automate and manage these processes. But as is true of SOA in general, there is no single product that can automate all the processes and requirements needed to enable governance. In fact, building out a governance infrastructure is likely to be as difficult and expensive as building out your SOA. There's design-time and run-time governance, policy enforcement, and policy management. There's integration with IDEs and registry/repositories, with a lack of standards making the integration of a fully functional governance framework nearly an impossibility primarily because no single vendor has all the products necessary to automate the processes around governance and integration between products in any market has always been a painful proposition.

SOA Governance is an important part of a successful SOA initiative, to be sure, but it's important to remember that without a solid definition of the process, no technology or set of technologies is going to solve the problems allegedly addressed by governance in the first place. You need to decide what it is you're trying to accomplish via governance before you can (or should) jump into the quagmire and purchase up products.

A few ideas to help you start thinking about why you need a SOA governance process and, probably, solutions:

  1. Reuse of services. Is this paramount to the success of your SOA initiative? If so, look to design-time governance solutions to help enforce (and encourage) the reuse of services.
  2. Service performance. Is the performance of services important? If so, look to run-time governance solutions to help manage and enforce performance-focused goals.
  3. Security. If you're concerned about the security of services look to run-time governance solutions as well as policy enforcement points within your SOA architecture to enforce security policies around services.
  4. Lifecycle management. Are you concerned about development and maintenance of services? Look to design-time services as well as a registry/repository to help manage service development efforts and enforce lifecycle management policies.

Like security (and thus compliance) you must have a solid understanding of what you're trying to achieve before you can implement it with technology. Consider what it is you are trying to accomplish and the process thorugh which you plan to achieve those goals before you get crazy with your purchase orders. With the number of diverse technologies associated under the umbrella "SOA governance" it's important to remember that process comes first, and products come second.