Software Architecture is a (Poor) Metaphor

At FAU, we are now holding our so-named “software architecture” seminar for the second time. It is important to realize (for students as well as the general public) that “software architecture” is a metaphor (or, maybe more precisely, an analogy). Architecture is a discipline several thousand years old, while software architecture is only as old as software engineering, probably younger, if you make Shaw and Garlan’s book the official birth date of software architecture, at least in academia.

Why should we care? Buyer beware! If architecture was a proper metaphor of what we do in something named “software architecture” then we would have to accept all the ancillary things that come with architecture. Most notably a clear separation of roles between architect, engineer, and craftsman. This is already confusing, given that we educate students to become software engineers, with software architecture being a subdiscipline of this. But industry for one picked up the distinction and if only to create a new salary band for more senior engineers.

The mismatch becomes apparent when you read (or watch) Stewart Brand’s most excellent “How Buildings Learn” that shows how removed many architects are from the objects they create. The visual appearance of a building, i.e. “making a statement”, is frequently more important than its inhabitability. Fortunately, we aren’t there in software (yet). Software architects have (or should) take overall responsibility for a piece of software as to its usefulness for clients. There are other aspects of traditional architecture that don’t seem to fit software development. For one, under many circumstances, architects can protect their buildings against change by the owners or clients to preserve the artistic expression they made through building. Imagine a software architect were to prevent his or her employer to evolve a system as needed just because the architect has left the company and wants to have their orginal artistic vision preserved!

In summary, we should be cautious as to using architecture as a metaphor for some of the things we do in software engineering. Some already even object the notion of “engineering”. One alternative, mostly popular with agile methods enthusiasts (outside large corporations), is software craftsmanship, going back to a Master/Apprentice model rather than an Architect/Engineer/Craftsman model. I’m sure we haven’t seen the end of it yet and may well have to evolve our own new understanding, letting go of poor metaphors to help explain what we are doing.

3 thoughts on “Software Architecture is a (Poor) Metaphor”

  1. Excellent observation. I would like to point out an additional aspect. The software architecture metaphor is not only about roles and tasks (and salary), but it is also a way to express a desired power structure. The architect role has been introduced into software development to give a person special entitlement to decisions about system structure. Agile method proponents removed this role to shift this power from one person to the team as a whole. (Side remark: funnily, in SCRUM they bestow themselves with the title ‘master’ to gain power over that same team.) So it is always useful not only to have a look at the appropriateness of a metaphor, but also at its social purpose.

  2. In the offshore industry it is also used to denote technical people who persist with their careers unmoved by the lure of a management hierarchy. Engineers tend to move up the hierarchy quite fast in this industry and that leaves a perpetual vacuum at the top of the technical ladder.

  3. Re: “software architecture is only as old as software engineering”
    Software architecture existed long before software engineering performed by humans:
    “The genetic information system is segregated, linear and digital. It is astonishing that the technology of information theory and coding theory has been in place in biology for at least 3.850 billion years [see original text for sources]. The genetic code performs a mapping between the sequences of the four nucleotides in mRNA to the sequences of the 20 amino acids in protein. It is highly relevant to the origin of life that the genetic code is constructed to confront and solve the problems of communication and recording by the same principles found both in the genetic information system and in modern computer and communication codes.” – Hubert P. Yockey, “Origin of life on earth and Shannon’s theory of communication”, Journal of Computational Chemistry, Jan. 2000

Leave a Reply