Replace SOA Governance with SOA Marketing

Many of the SOA marketeers have grouped around the notion of SOA Governance.  I have a bone to pick. 

For the sake of public discussion, let's pull apart "governance" into some buckets... and then attack one of those buckets.

• Bucket 1: EA Governance - This is the review of funded initiatives to insure that the IT components are aligned with business objectives.  This is useful, and in fact, is often a defining function of the Enterprise Architecture team in many organizations. 
   
• Bucket 2: Information Security Governance - This is the review of delivered code to insure that it protects corporate and individual information assets.  In modern companies, the risk of not doing this is high.  Web services offer an interesting interface for attack, and therefore, must be accounted for in any security reviews.  This is essential.
   
• Bucket 3 - SOA Governance - this is a design review, either before or after code is developed, to insure that the integration services meet particular technical and informational requirements designed to support integration goals.  This includes insuring that canonical schema are used (and used correctly), that correct namespaces are identified, that the services use particular patterns for message exchange, that they are hosted, tracked, and managed in a consistent manner.  All of these are useful exercises from the standpoint of operational efficiency and enterprise control.

Of these three, I have listed them in order of importance.  Yet they are in reverse order of tool avaliability.  In other words, there are more tools available for the least important than there are for the most important. 

In fact, I'm going to suggest something radical.  Let's not do the third.  Not as "governance" anyway. SOA Governance should be replaced with SOA Marketing.

Governance is a mechanism to enforce a particular set of behaviors.  Marketing is a conversation that  collects customers needs, crafts a product to meet them, and then informs the customer of the advantages of using that product. 

We need IT teams to choose to follow standards and conventions, not because some geeks in another team say so, but because it is less expensive for the projects if they do.  To make it easier, we need to listen to their needs.  We need to build a product to meet those needs.  We need marketing, not governance, in this space.

At the optimum, we want compliance with SOA standards to be optional yet ubiquitous.  When an electrician wires a house, he uses standard outlet fixtures.  In many cases, house inpectors care if the house is safe, not usable, so they won't complain if he used non-standard fixtures... yet he uses the standard... why?  Because it is cheap, easy to do, and the customers like the results.

That is the same reason that SOA service developers should give when you ask why they stuck to the standards.  It was cheaper and easier and the customer preferred the result.   

They should not say: "Because the SOA Police told me to."

Comments

• Anonymous
  November 07, 2007
  Nick Malik, writing in his Inside Architecture blog on MSDN, offers this interesting take on SOA Governance:  Governance is a mechanism to enforce a particular set of behaviors.  Marketing is a conversation that  collects customers needs,