Top-Down Vs. Bottom-Up Software Architecture

More pragmatic advice from James McGovern, this time about top-down versus bottom-up IT initiatives. In other words, CEO mandate versus workers-know-best. Both are needed, but when is which one appropriate? My favorite quote:

One of the more interesting things is that a person debating top-down vs bottoms-up needs to take into consideration is historically which one has had better results. Of course, top-down has the advantage that even mediocre delivery will be declared success while bottoms-up mediocrity will probably result in throwing daggers.

Consideration? Sure, OK. That's the politically expedient thing to do for bottom-up... but it misses a vital point: is the technology something that people will absolutely love? If so, mediocre implementation will be forgiven, and the top-down criticism will eventually be won over. As I always say, its easier to get forgiveness than permission.

I was a part of multiple skunk works projects at Stellent, some of which got me into a teensy bit of trouble with executives. Some of these projects languished, but many of them took off like gangbusters because people loved them. In the words of Cathy Sierra, these systems helped people kick ass. In the words of Clay Shirky, they were systems where people took care of one another, and that more than anything else guaranteed their existence the next day.

James feels that Outsourcing, CMMi and/or PMI, and Identity Management are best done top down... I agree with everything but Outsourcing, unless its on a large scale. There's nothing wrong with giving your middle managers a budget to outsource. Heck, I see nothing wrong with giving every developer a $5,000k budget, and let them "outsource" some tricky code to another developer who can do it in half the time. Or buy a awesome monitor. As long as there's modest oversight, and your developers aren't idiots, there's very little harm that can be done.

James also says Agile, SOA, and Open Source are best done bottom-up... whereas I agree its easier from a bottom-up perspective to sneak-in cutting edge technology, I'm not sure if its best. This problem is by no means unique to the software world. Its the same age-old question: when should I let my employees take the initiative? The same rules apply across the board, whether the "initiative" is a software methodology, an innovative marketing plan, or sales incentives. The two most important questions are:

  • How does this decision affect the rest of the organization?
  • Do the people making this decision fully understand its risks and benefits?

No matter what you're doing, the answer is always the same: unless your employees are bound by a genuine shared purpose, bottom-up initiatives will do more harm than good! In a typical company, you'll be OK if your IT department sneaks in Agile techniques... but in a dysfunctional company, you run a significant risk of making things worse. This is bad, because in dysfunctional companies, bottom-up initiatives are sometimes the only way to get anything done.

Unless you have some folks at the bottom who have a 50,000 foot view of the entire company, or are genuinely dedicated to helping your customers kick ass, then bottom-up initiatives are just spinning wheels on systems that go nowhere. If your IT department wants to take the initiative, they better be keenly aware how their changes effect everybody else. They had better understand that all change has positive- and negative-effects, and keep track of them all. Finally, they had better have a plan to roll-back the changes, should the negatives dominate for too long.

This way, you're more likely to have bottom-up initiatives that kick ass! Also, you'll have a nice paper trail of successes to prove its value to your inevitable critics.

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
CAPTCHA
This form prevents comments spam...