When people use the term 'software architect' they are using a
metaphor from building construction to help people understand the
architect's role.Ironically in doing this they misunderstand the
actual role of a building architect.

A software architect is seen as a chief designer, someone who
pulls together everything on the project. But this is not what a
building architect does. A building architect concentrates on the
interaction with client who wants the building. He focuses his
mind on issues that matter to the client, such as the building layout
and appearance. But there's more to a building than that.

In particular an architect is not responsible for the structural
integrity of the building. That's the role of the structural engineer,
such as my wife Cindy. An architect will call a structural engineer to
make his building stand up - usually, by this time, it's too late to
make changes that would allow the structure to be efficient. A
building will also require electrical and mechanical engineers too,
with the same consequences from the architect's initial role.

However despite the fact that the architect is one amongst
several professionals on the team, he is the one that handles all the
conversation with the client. An architect has overview training from
college as well as his gleamed experiences in all disciplines that
require a building to be designed, however, it is impossible that he
can speak for all disciplines without their input.

Given the focus on client interaction I think the closest
equivalent in software development is a user-interface designer. And
although I distrust these kinds of metaphors, this one does have a
useful corollary - the danger of putting an architect in charge of the
work. In a recent example Cindy was called in to do the structural
engineering for a hotel. As she started this she realized that the
architect's layout necessitate a particular form of framing. A
slightly different layout would allow a different framing approach
that could reduce the cost of building the structural portion by 30%.
The architect resisted this change,because his architectural design
had been signed off by the client.

The lesson of this is that if we put an architect, or a
user-interface designer, in charge of the customer relationship that
architect must communicate effectively with the other professionals.
One of the problems I've seen with the world of otherwise excellent
user-interface people is that they don't take into account the costs
of different user-interface schemes. This is particularly true when
these costs are introduced by deeper technological concerns. Dave Rice
likes to point out that an application's concurrency and locking
strategies cannot be separated from the user-interface experience. Yet
few user-interface people understand these issues. Nor need they,
providing they collaborate effectively with those who do - unlike the
typical building architect.

A final thought about the building architect metaphor. One of the
ongoing themes of Michael Pollan's A Place of
My Own is the conflict between architect and carpenter. Pollan
describes how architects have, on the whole, won the battle to take
charge of building design. Sadly, he points out, they are usually the
lowest paid of the skilled workers on the job. Software Architects: be
careful what you wish for!

Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement