Tuesday, February 3, 2009

Unintended Consequences of Architecture

Bonus plans are one of those incredibly tricky things to devise, because you know you’re going to get the behavior you’re incenting for – but that may not be the behavior you meant to elicit. Offer your employees large bonuses for big quarterly numbers, and you’re likely to get some big quarterly numbers – but the quality and durability of those results are likely to be sacrificed.

NYT economics columnist David Leonhardt’s essay “The Big Fix” talks about policy decisions having unintended impacts on social and cultural norms. Key quote:

Economists don’t talk much about cultural norms. They prefer to emphasize prices, taxes and other incentives. And the transformation of the American economy will depend very much on such incentives: financial aid, Medicare reimbursements, energy prices and marginal tax rates. But it will also depend on forces that aren’t quite so easy to quantify.

[…]

When Washington sets out to rewrite the rules for the economy, it can pass new laws and shift money from one program to another. But the effects of those changes are not likely to be merely the obvious ones. The changes can also send signals. They can influence millions of individual decisions — about the schools people attend, the jobs they choose, the medical care they request — and, in the process, reshape the economy.

Enterprise architecture goes hand-in-hand with governance. Which means you’re devising architecture policies and enforcing those policies. In simpler terms, your architecture sends signals about what is important to the organization. But an architecture’s impact on corporate culture may not be what you expect it to be.

Unintended consequences are, by definition, impossible to predict. Hindsight is all we have - here’s what I’ve seen from my own past experience:

  • Monocultures suppress potentially worthwhile solutions – a policy that limits you only to Microsoft products only even the airing of alternative solutions. If you need to worry about distributed systems or high scalability, you need to look beyond Microsoft.
  • Imperative (as compared to declarative) policies create a command & control culture – policies that focus heavily on “thou shalt…” commands without explaining “why” only communicate that there are rules to be followed. There’s a good reason you limit who is allowed to deploy code to production systems, but your fresh-out-of-college developer isn’t likely to have experienced that oh-my-God-I-think-I-just-brought-down-the-server moment of terror – and the lockdown rule is there to make sure he never does.

Photo: path
by edmondo

No comments: