Redefining SOA Governance

My third post in a row about the notion of SOA Governance.  You'd think I was planning to speak about Governance this week.  (I am).

In general, Governance is a set of processes, responsibilities, and tools that reinforce good behavior and help avoid bad behavior.  With SOA Governance, we want to build a useful SOA environment, prove the ROI, and insure we don't screw up security.  We do this with policies and processes (mostly process).  Policy can only be applied to a small fraction of the governance problem.

Now, break it down further.  Only a fraction of SOA policies can be verified or reinforced with tools. 

Therefore, while SOA tools are useful, they don't deliver governance.   In my honest opinion, it is not rational to use the word Governance to refer to a tool at all.  After all, we don't refer to to Microsoft Operations Manager as a "systems governance tool," and SQL Server is not a "data governance tool." 

Here's a novel idea: Let's use similar words that have been successfully applied in other areas, so that the meaning is clear.  If MOM is a Network Management tool, then Systinet, IONA, and Amberpoint are Service Management tools. 

Tools manage.  People govern.