Is your IT architecture up to code?

When it comes to developing sound enterprise technical architecture, we probably should have chosen a different word. What we mean by “architecture” has too little in common with what real architects — the people who design buildings, that is — do.

While the choice of words may seem a minor detail, the distinction tells the larger story. For those involved in enterprise technical architecture, the punchline may not be pretty. In many ways, we share a lot more characteristics with the bureaucrats who regulate buildings than those who create them.

[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | Get expert advice about planning and implementing your BYOD strategy with InfoWorld’s 29-page “Mobile and BYOD Deep Dive” PDF special report. | For more of Bob Lewis’ continuing IT management wisdom, check out his Advice Line newsletter. ]

Waterfall vs. agile

In IT, waterfall development is our closest correspondence to real architecture. A building starts with a sketch, then drills down into floor plans and so on based on how it will be used. From there, it’s designed even more deeply, until we have a complete set of blueprints that show the electrical, plumbing, HVAC, and wiring plans in enough detail that builders know exactly what has to go where. Waterfall development is pretty much the same thing, applied to software. (Any real architects reading this: Yes, I’m oversimplifying.)

Waterfall is the right way to create buildings. I experienced a home remodeling effort that was handled more like an agile project — I don’t recommend it.

Real architects are responsible for detail. Most enterprise technical architects I know consider detail to be someone else’s problem. In that, they’re wrong, though this doesn’t mean waterfall is the way to go or that enterprise technical architecture’s boundary is application development.

What it means is that while enterprise technical architects have no involvement in systems designs, they have a great deal to say about the rules to be followed in designing them, whether they’re designed through waterfall or agile methodologies. The analogy to building codes is, by now, hackneyed, but its validity is still frequently obscured by the inappropriate use of “architecture” to refer to what is really the work of government regulators.

Can you blame the enterprise technical architects? Given the current insistence that government regulation is a horror visited on business victims, it’s no wonder that the practitioners of a nongovernmental regulatory craft prefer nearly any other characterization.

What building codes teach IT The reality is that the tangible product of enterprise technical architecture is entirely parallel to that of government regulators — specifically, to those involved in building codes.

These regulators ensure buildings are designed so that they don’t collapse under their own weight; use cabling with insulation that won’t burn or emit toxic gases in the event of a fire; have means of egress in the event of a fire that maximize the likelihood of their occupants surviving; use electrical wire that won’t melt when current runs through them. Also, the plumbing must be, well, you know, and the systems mustn’t overload the public infrastructure they’re connected to.

For those who’ve heard the popular argument that regulation doesn’t work because business executives will always be smart enough to find loopholes: Think about the implications in the context of building codes. Were they to do so, we’d have buildings falling down, burning down, and melting down due to preventable structural flaws that were almost but not quite covered by the loophole-ridden building codes.

But architects and builders don’t do that. The probable reasons lie in the building codes themselves, which have a number of interesting characteristics for enterprise technical architects to mull: They are about specific characteristics of buildings without being building designs; they are detailed; their purposes are clear and useful; they are practical; and they not only make sense to architects and builders, but they also make their lives simpler. All of this comes about because they’ve been developed by experts who have firsthand knowledge of what it takes to design and construct buildings.

The IT architect as regulator Analogies are powerful things. Once we’ve chosen one, we look to it for guidance about just about every aspect of what we’re analogizing. With a well-chosen analogy, this provides a lot of help. Choose our analogy poorly and we end up making ourselves incredibly stupid.

With that in mind, whether you are an enterprise technical architect, have enterprise technical architects reporting to you, or work with people who have this title, constantly remind yourself that title or no title, the proper analogy for what these folks do has nothing to do with architecture.

They (or you) are regulators. That’s nothing to be ashamed of — quite the opposite. It’s vitally important work, and it should be specific, detailed, practical, and sensible to the people on the receiving end of the regulations.

This also means those on the giving end need to be experts with firsthand knowledge of what it takes to do the work the regulations (or, in IT parlance, standards) cover.

This story, “Is your IT architecture up to code?” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.