Governance: Enforcement (Part 2 of 3)

Posted by Mike Marshall On Tuesday, June 01, 2010
In the last section, Governance - A Definition (Part 1 of 3), we explained that governance is a process for setting out rules and guidelines that should be followed.  For the DMV, these rules and guidelines are the driver's license and vehicle registration laws.  For your architecture team, these rules and guidelines are the architectural strategies and best practices.  We also said that all things being equal, everyone understands why these rules exists and agrees to follow them.  But do they always follow them?  Why not?

Whether you work for the Department of Motor Vehicles or are a member of your Architectural Governance Group, you hear a lot of excuses.

You hear drivers say things like, "Standing in line takes too long!" or "Registrations are too expensive!"  People procrastinate and complain - and ultimately the only real reason they end up registering their vehicles and renewing their driver's license is the fear of being caught and fined by the police.  Even with a public consensus that the DMV's rules and regulations are necessary, true enforcement is the only thing that keeps us all on the right track.

Architectural governance is a very similar case.  Even though, developers will universally agree that the architectural guidelines are fair, necessary, and reasonable.  Only a true enforcement mechanism will keep them implementing systems along these guidelines.  Outside influences like close deadlines and short budgets are always going to push developers to code something short of the prescribed solution.  In today's resource-constrained world, a governance process must have a strong enforcement mechanism to be effective

In architectural governance, there are two types of enforcement, and one is much better than the other in the architectural arena.

The Speed Trap.

This enforcement mechanism is the post-violation type.  It waits for someone to do something wrong and then penalizes them.  It's foundation is set in the "blame game", and it breeds contempt for the architectural governance team, and unless the fines are big enough (like maybe getting someone fired!), it rarely works.  What you end up with is people who are asking for forgiveness instead of permission,  a long list of transgressions with meaningless penalties attached to them, and worst yet, the violations result in bad systems in production.

The Parking Gate.

This mechanism prevents violations before it happens.  It is built on some (usually mechanical) prevention mechanism in your software configuration management process that prevents a team from bypassing an architectural guideline.   The step must be completed prior to being able to deploy your solutions to production, and thus violations can only occur in  emergencies and then only with visibility.  Ultimately, these mechanisms are predictable and are accepted by the development teams as normal operating procedures.

Governance via the right enforcement mechanism keeps your architecture under control, but no enforcement mechanism can cover every situation.  When that is the case, you'll need to govern through "Influence".  That's covered next.

photo: Seattle Municipal Archives

0 Response to 'Governance: Enforcement (Part 2 of 3)'

Post a Comment