Want to be an architect? I don’t mean an “IT architect,” though that’s surely an appealing career target. Last month, The Open Group announced a new level in its IT architect certification program: Distinguished Certified IT Architect. It requires proving you have executive-level IT vision, governance expertise, and communication and leadership skills. That’s a VP-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 union 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 by a state to use that title — does a lot more than that.
His (or her) work begins when a client wants to build something. The architect’s first task: getting hired for the job. That often means 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. Then the client asks for changes, the architect explains how the changes will affect the budget and schedule, and usually additional changes are made, resulting in more budget and schedule changes.
Ambitious dreams sometimes get scaled back and fancy fixtures are frequently dumped in favour of plain ones.
Next, the plans are sent to an engineering firm, which converts floor plans into structural designs and plans for wiring, pipes and ducts. 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 and the client may need to make more changes. 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.
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 the readjusting and the selling to clients, 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.
