lustratus LiteBytes

Dan Foody of Actional gives an excellent real-world analogy for how not to apply SOA governance in his blog:

The government of his home province of Quebec kept upping the taxes on cigarettes (in order to discourage smoking of course) but eventually:

“Then a funny thing happened [when the taxes were increased yet again] … without warning, smokers started rebelling and they started buying cigarettes that had been smuggled over the border through indian reservations because they were much cheaper.

Within weeks it went from a few die hard smokers buying these smuggled cigarettes to double digit percentages of all smokers in the entire province doing it.  The taxes hit a flash point without warning,  and no amount of additional police work was getting the smuggling problem under control.”

The analogy that he draws is the following:  If your SOA governance policies are working, this does not mean that more policies and controls will make the situation better – it may cause a revolt among the developers.  I strongly agree:  SOA Governance must be as light as possible – which typically means that you should start too light and build up carefully rather than attempt to design a complete set of rules at the beginning and then prune back when the backlash occurs.

Furthermore, governance procedures must engage and involve the participants and not be simply handed down from central IT.  As Dan also points out, this means that governance should include carrots as well as sticks.  If this isn’t done and governance is exclusively a set of police enforced control mechanisms, at the first opportunity a project will be declared too important and urgent to follow ‘all those stupid policies’ and the whole of governance will fade away like so much smoke from a smuggled cigarette.

Ronan