.comment-link {margin-left:.6em;}

Uncommon Sense (for Software)

This blog has been moved to www.UncommonSenseForSoftware.com.

Thursday, September 22, 2005

How to Explain Good Architecture to the Non-Techie

How many times have you tried to explain the importance of good architecture to one of the many stake-holders in one of your software projects? Could be from sales, or marketing, or even your boss, depending on your company. If you have, you've probably seen their nose wrinkle, or their eyes glaze over. After an honest attempt to make them see the light, you probably got frustrated and thought that they just don't care, or just don't get it - and never will. The frustration that both of you feel actually creates a kind of tension and over time, this lack of being able to relate to each other makes it more difficult to be shooting for the same goals.

Wise people say that to be a good communicator isn't about having any particular mastery of the language, or about demonstrating through over use of industry jargon how incredibly smart you are. It's about being able to put yourself in your listener's shoes and hear what they hear - or, simply about relating.

Although I've been managing software teams for many years now, it finally just occured to me while walking the dogs at lunch, what good architecture is all about, and how to get the point across to your non-technical peers. Like many, I intuitively knew what it was, but couldn't quite nail the explanation when trying to describe it to a non-techie.

I'm a firm believer that good architecture is actually a pillar of a successful product company. It's just that it's not for reasons you would necessarily think.

It'll sound a bit funny at first, but stick with me: Good architecture has nothing to do with the quality of the product you're building. You can have a product that customers absolutely adore, that is about to fall over dead tomorrow if one more tiny little feature is added to it because nobody can see the house of cards it's built on, except you. Customers don't buy architecture (unless your product is a platform, then they do). Even if your product is extendable through some API, they still don't care too much about what goes on under the covers. Customers buy a solution to a problem. Even if the problem is simply that they're bored and they're buying a video game to amuse them (problem solved). They buy features, benefits, and capabilities, but they don't buy architecture.

Good architecture is not about the product. It is about operational effectiveness. Ahhh, now your boss is listening. It's about being able to react more quickly to customers and the market, even the competition. Ahhhh, now Sales and Marketing are listening.

Understanding good architecture comes from understanding the symptoms of bad architecture, and knowing that good architecture prevents those symptoms. So. Bad architecture: Can't scale the system up; can't increase performance; can't make it easier to install; can't add any more features because of the unforseen conflicts they create with existing features; takes too long to fix bugs and add what new features are possible. Most of these things are about the company's ability to innovate, to react quickly to threats, to support their customers, to solve problems, to add new features, and to pump out new products.

A good architecture can get you: faster turnaround time on fixes and new feature development, more flexibility for supporting customers, a stronger ability to compete in the market place, etc.

The difference between a good architecture and bad architecture can often affect each of those symptoms by as much as 2 or 3 times. It makes the product team more effective at doing their jobs, even multiplying their productivity in many cases. Good for the team, good for the company, good for all the stake-holders.

Those are things that your stake-holders care about. And hopefully, this is a way to help get the point across.


Post a Comment

<< Home