Software Architecture: It Might Not Be What You Think It Is

submited by

Style Pass

2022-05-13 05:00:05

InfoQ Homepage Articles Software Architecture: It Might Not Be What You Think It Is

Software architecture has a contentious reputation in the agile community. In the experiences of many, it is the cause of valueless meetings and irrelevant documentation that is aptly summarized by the expression “the map is not the territory.” And yet, applications with poor architecture can quickly become like vehicles abandoned by the roadside, broken and unrepairable. So is there a useful middle ground between these poles of pointlessness?

Part of the problem is that architecture is an inapt metaphor for the result of the work of architecting software systems. Inspired by the work of building architects, the word conjures images of beautiful designs that hint at utopian futures. But the work of architecting software systems is far more dynamic than the building architecture metaphor supports. Buildings are static, and the work of building architects is done just once. Software, by its nature, is ever-shifting and dynamic; when it stops changing, it starts to die.

To arrive at a better understanding of software architecture, we have to go back to the origins of the word architect: It comes from the ancient Greek word arkitekton, ἀρχι- (arkhi-, “chief”) +‎ τέκτων (téktōn, “builder”). Architecture is created by people building things. That sense has become lost in the work of building architects, many of whom have never poured a foundation, framed a building, or run plumbing or heating pipes. Design and building have become separated. Not so in software, where how something is built influences what is built, and vice versa.