SOA Governance: Carrot or stick?

"Back when I was on the Architecture Committee, the developers never listened to me.  But, now that I'm Enterprise Architect, I'll show them.  I'll put in so many governance policies that they won't know what hit them.  And there's nothing they can do about it - because these rules are good for our company."

OK, I exaggerate a bit.  I know a lot of great enterprise architects that would never think this way.  But, I wanted to illustrate my point:  In life, the most effective policies are supported by both carrots and sticks.  Speeding on the road? Your insurance company gives you price breaks if you don't get caught, and the government gives you fines if you do.  Carrot and stick.

So, what does this have to do with SOA governance?

SOA governance, today has two key components: sticks (a.k.a. policies) and tools to automate putting the sticks where the sun doesn't shine.  Where's the carrot?  How are you, oh great and powerful enterprise architect, helping developers get their day-to-day job done quicker and more easily?

You may be thinking "short term pain for long term gain," which would make sense, except for one thing... human psychology.  Any rule that makes someone's daily life harder is a rule that they will find a way around - either consciously or unconsciously.  "But that's why I've automated my governance: so they can't get around it."  Hah! Good one.  Translated, this just means, "I won't find out when they get around the rules."

Even if you do find a way to catch everyone, you will cause such an impact to overall productivity that you will never be allowed to see whether your SOA governance initiative resulted in the promised long term benefit.  The business will only accept so much "short term pain" before they decide that the (totally unquantifiable and unproven) long term improvement in "business agility" you promise isn't worth the measurable pain they feel today.  Like it or not, first and foremost public companies have to meet their quartly numbers - regardless of the richness of their long term strategy.

SOA what?  I'm done with all the doom and gloom.  So, what can you do to introduce a carrot?  For every SOA governance policy you institute, think of a corresponding way to improve developer productivity.  For example, give the developer tools that are easy to use and that solve problems they feel in their day-to-day lives (and these tools just happen to make sure that the path-of-least-resistance is to follow your governance policies).

Let's be more concrete: Let's say you want policies to ensure all of your services are secure.  One way to address this is to automate a "security test" of a service when the service is deployed.  That's a good stick.  But, here's the carrot, developer's don't like coding security, so why not give them a tool which offloads them, with a few clicks, from having to code the security in the first place - SOA Management tools and XML appliances can do just this.  Want some concrete evidence that this works? Take a look a this survey done just about a year ago today.  'Nuf said.