Category: Softwares

“Architecture is a social act and the material theater of human activity.”—Spiro Kostof

How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions among the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?

“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”—Frank Lloyd Wright

What more strongly marks out the architects in your organization: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?

“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”—ibid

Is the “maintenance” of “legacy” systems anything more than pruning those vines? Would you, as an architect, have the intestinal fortitude to scrap a piece of work that had failed? Or would you cover it up? Wright also said that the architect’s best friend was the sledgehammer. What have you demolished recently?

“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”—Karen Moyer

For “God” read “customer”.

“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton

When was the last time you saw a piece of software who’s architecture gave you any delight? Do you aim to give delight with your work?

“No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder”—John Ruskin

Does artistry play its proper part in your architecture? Is the assemblage of components to make systems informed by a painterly concern for shape and texture, with a sculptural sense of balance and implied motion, of the importance of negative space?

And finally, no gloss is required on this comment, a sure remedy for the software architect’s most damaging syndrome.

“It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect.”—ibid

In Cryptonomicon, Randy Waterhouse explains his classification system for the different types of people he meets. Dwarves are hard workers, steadily producing beautiful artifacts in the dark loneliness of their caves. They exert tremendous forces moving mountains and shaping earth, and are renowned for their craftsmanship. Elves are elegant, cultured, and spend their days creating new and beautiful magical things. They are so gifted they don’t even realize that other races view these things as otherworldly almost. The wizards are immensely powerful beings almost completely unlike all others, but unlike the Elves, they do know about magic, and its power and nature, and wield it with supreme effect. But there is a fourth type of character that Waterhouse alludes to but does not mention specifically. The Kings are the visionaries who know what must be done with all of these different characters.

An Architect is a King of sorts. The Architect must be familiar with all of these characters, and ensure that the architecture has roles for all of these characters. An architecture designed only for one will only attract that one character to the project, and even with the best dwarves, or elves, or wizards, the team will be severely limited in its reach if it can only approach problems in one way.

A good king will lead all types through a quest, and help them work together to complete it. Without the quest, there is no vision for the team, and it ultimately becomes a partisan mess. Without all characters, the team can only solve one class of problem, and is stopped at the first barrier impassable to that solution.

The architect creates the quest with all the characters in mind. The architecture then becomes a guide for finding tasks for the different characters to perform while learning about each other. When a project encounters difficulty, the team will already know how to approach solving it because the architecture gave them the opportunities to grow into a team.