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!