What Makes a Good Policy?

Anyone ever see David Letterman's stupid pet tricks? I think we should have a tech show called stupid IT tricks. I recently heard that one CIO's strategy for meeting user requirements was to forbid users to submit feature requests. Software would be installed, and the way it works out of the box is what the users get. His policy of "no more user requirements" ensures a 100% success rate of meeting his IT policy. I applaud his brilliance.

As silly as that sounds, check these two policies out...

• Please don't ride the subway if you have a cold. These signs are posted throughout the NYC subway system.
• Don't drink and drive.

These sound like pretty good policies, right? The former benefits everyone by preventing sick people from getting others sick. The latter, well, it saves lives.

But let's take a closer look... This first policy is totally unenforceable and really doesn't reflect user's realities. Whoever thought of this "marketing campaign" did nothing but waste tax-payer dollars. Most people would love to not come into work when they're sick, but that's just not a reality. If we wanted that policy to work, we'd have to make a realistic alternative for sick people. After all, what's their motivation for following a policy if it's not enforceable, especically when they may not have any direct benefit from following the policy?

On the subject of enforcement, let's look at the second policy. Clearly, this is an enforceable policy. Why then do people continue to drink and drive? There are realistic alternatives to drinking an driving, and would-be drunk drivers benefit directly. A sick person is already sick so not riding the subway doesn't help them, but a drunk who doesn't get behind the wheel is stopped from hurting themselves, or worse, others.

Unfortunately, as Mayor Rudy used to say, "common sense is, unfortunately, not all that common." I think, in part, it's because enforcement is subject to "user interpretation."

But apparently, people are more worried about being embarrassed by having their names/photos published if they are caught drunk driving, than they are about hurting someone, losing their license, or jail time. A new policy started on Memorial Day in Long Island that stated that people arrested with blood alcohol levels over the limit will have their names and photos published on Monday mornings. It's an effective enforcement procedure but has been called "controversial" - probably because it's a government program that works.

SOA What? I commend the person at the MTA who is trying to instill manners on subway riders (though I still think that they should be fired for wasting money/time). But it's a noble cause doomed to fail. And, for those officials on LI willing to risk controversy and continue to publish drunk's names and photos, you set a good example for those of us trying to police our SOA infrastructure.

What can we learn here? Again, it's about the carrot and the stick. Both need to be in place organizationally in order to make policing the SOA practical. You've heard it before, SOA (and SOA Governance) is as much about people and process as it is about technology.

1. Carrot. Enforcement depends upon user behaviors. You can threaten to cut off access to a service if an application doesn't follow policies, but... if that application is mission critical, you probably won't be able to do that. What you'll have to do is adjust your governance policies! It may not be obvious, but there are probably low cost ways to encourage user behaviors without making them political battles. How about posting a list of insecure applications? You may not be able to cut them off, but perhaps users will think twice before depending upon the application. Put the onus back on the developer rather than being the bad guy yourself.
2. Stick. Policies need to be enforceable. And that simply means watching what's happening. Let's compare our SOA to the subway... When we create a list of policies stored in a registry and then test our application against those policies once, when it comes time to place the application into production, it's like making sure we only sell metrocards* to healthy people. Once you have a metrocard (once you're app is in production), you can get sick and ride the subway (you can violate your governance policies), but we have no way to tell because you have no visibility into your run-time environment. If you laughed when you read the policy above, and do this in your SOA, I suggest you rethink your approach to SOA governance.