Why Architecture Is a Really Long Four Letter Word

Before I start, let me just say that I've held positions as "Chief Architect" at a startup, as well as managed a group called "Systems Technology Architecture" at a large Fortune 500 company.

OK, now that we've got that out of the way, architecture is often the bane of successful software development. Focusing on creating the proper architecture for all systems can reduce the ability for a company to manuever quickly, and increase expenses to a level that only companies with huge IT budgets can afford.

Now, before the flame-throwers come out, let me explain.

Once upon a time, there were programmers. Programmers were responsible for talking to the customers, figuring out what they needed, building it, testing it, and maintaining it when things went wrong.

After a time, programmers decided that they wanted better titles, since "programmer" sounds about as glamorous as "light-bulb changer". Hence, we saw the rise of "software engineers", "software developers", and even "systems analysts".

Of course, with titles that reflected more traditional industries, it was inevitable that point-haired managers would decide that software development was just like construction, down to the blueprints, manual labor, and yes, architects.

"If we could get one guy to figure everything out, document it, and explain it to other people, we could hire some low-skilled manual laborers, er...programmers, to build from the plans, and save a bundle!"

Riiiiiight.

Problem is, even the construction industry doesn't really work that way. An architect carefully draws plans, but when the builders start working, they discover flaws in the materials, or the plumbing needs special routing, or that fancy space heater needs an extra two feet of clearance, and so on.

Reality inevitably intrudes on theory, no matter how carefully we plan.

But isn't a solid architecture important before development begins in earnest? Don't we need a solid foundation to build the house on?

Maybe, but the best foundation for software is not always one that can handle every possible feature we can think of. Software has a cost, both to build it, and later to maintain it. Every extra line of code makes software more difficult to understand, test, and expand in the future.

Many software teams get caught up in building enormous infrastructures in order to future-proof their applications. What usually happens instead is that they sacrifice their future because their projects get cancelled for taking too long to deliver value.

Clean, simple design is far more effective as a means of future-proofing. An application that is simple lends itself to easy maintenance and change. For integration projects, loose coupling and simple message exchanges can often provide better solutions than overarching enterprise-wide standards.

So architects of the world, add value by participating in creating simple designs. Don't just plan, implement. Get your hands dirty.

Maybe then we'll come up with a new job title - Software Deliverer.