Want to be an architect? I don’t mean an “IT architect”, though that’s surely an appealing career target. Recently, The Open Group announced a new level in its IT architect certification programme: Distinguished Certified IT Architect. It requires proving you have executive-level IT vision, governance expertise and communication and leadership skills. That's a vice president-level job, typically reporting to the CIO.
Nice work if you can get it.
In IT, we love titles and metaphors that come from the construction world. Of course, many of our “software engineers” don’t know the first thing about engineering, and the quality of IT infrastructure that we casually call “plumbing” would make a plumber cringe.
And architects? In IT, we think that means people who design systems.
When it comes to putting up buildings, yes, designing is part of the job. But a real architect — the professional who’s licensed to use that title — does a lot more than that.
His work begins when a client wants to build something. The architect’s first task: getting hired for the job. That means selling the client on what the architect can do, and often pitching ideas for the design of the building.
Once he’s hired, the real-world architect next discusses budgets, schedules and what the building will be used for. Those three interact, and a big part of the architect’s job at this stage is listening to the client — and helping the client understand what things cost, how long construction takes and what’s practical.
Then the first plans are drawn up. And the client asks for changes. And the architect explains how the changes will affect the budget and schedule. Changes are made. And more changes. And still more changes. Budgets are revised. Schedules are rejiggered. Plans are redrawn.
(Scope creep? It happens, but not often. More likely, ambitious dreams get scaled back, fancy fixtures are dumped in favour of plain ones, and the budget gets tighter, not looser).
Next, the plans are sent to an engineering firm, which converts floor plans into structural designs and plans for wiring, pipes and ducts. It’s all checked to make sure it meets functional requirements and building codes.
Then bidding starts. Shepherding that is part of the architect’s job, too. His cost estimates will collide with the bids of the contractors who will actually do the work. If the bids bust the budget, the client may need to make more changes. That means new plans, engineering changes and new bids.
And once the client has finally accepted the plans and the bids, the architect oversees construction. Yes, as in hard hat and muddy boots. And yes, plans get changed, and the budget and schedule are adjusted yet again as the blueprints meet construction realities.
And when the building is finally complete, there’s one piece left for the architect: liability. If anything is wrong with the building — no matter who actually fouled up — the architect is legally responsible. If the building falls down, it’s the architect who’s sued.
Full disclosure: My father was an architect, so I grew up with this process — bid openings, construction site visits, the whole works.
How much does our notion of an IT architect resemble the real thing? Not much.
But maybe it should.
Design and high-level plans are important. But so is all the negotiation, the estimation and communication, the readjusting and the selling to clients, the boots-in-the-mud supervision and especially the ultimate responsibility for a project.
We’re not good at all those things. We need to be — for the sake of IT’s reputation and our businesses’ success.
More “IT architects”? Sure, we can find a place for them.
More people who do for IT what architects do for buildings? That’s something we could really use.