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.
Leave a Reply