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.