Origins of software architecture study

Yesterday, I read a short article by Paul Clements, Origins of Software Architecture Study. A week ago, I wrote about Fred Brooks’ definition of architecture – see here – and according Clements’ article, Brooks first defined architecture as the “conceptual structure of a computer [...] as seen by the programmer.”. Some years later, in his The Mythical Man-Month, he’d begun to view architecture as the specification for the UI (as I wrote in the previous post).

Clements writes that the architecture as UI definition is still used in some places, while software architecture “refers to the structure of the system quite hidden from the user”. He continues: “[The] notion of architecture as a common description of a class of systems – i.e., an abstraction where all the instantations are said to exhibit the architecture – endures, and is at the heart of the concept.” This is the first time I’ve read something along these lines. Perhaps it is more commonly understood than I have thought. My feeling is that people generally mean, literally, the structure when using the “A” word.

The article gets more interesting, though. Clements continues to briefly describe Dijkstra’s (who passed away three days ago) work concering the structure of programs, upon which David Parnas built his ideas in the seventies. Clements writes about Parnas’ concept of program families>

A program family is a set of programs [...] for which it is profitable or useful to consider as a group. [...] A program family can be enumerated in principle by specifying the decision tree that was [...] traversed in order to arrive at each member of the family. [...] The point of the decision tree representation is to make clear the advantage of late binding and of prudently ordering – and recording – one’s design decisions. Early design decisions shuld be ones that will most likely remain constant across members of the program family [...] The significance of the program family concept to software architecture is that software architecture embodies those decisions at or near the top [of the tree].

I like this definition, because it allows one to discuss architecture at different levels of a system. For each subsystem, there are paths of design decisions (however formal or informal) where the architecture can be said to constitute the beginning of the path. I think discussing architecture at all levels is beneficiary to the quality of the software produced. But even though the decision tree concept allows for architecture to be considered at all levels of a system, I don’t think this is the intention of Clements and others. He writes, referring to the work of Dijkstra and Parnas, that “[structure] is important, and getting the structure right carries benefits.”

I would say that structure and design are important at all levels. And even if you try to defer “architectural decisions” (XP-style) you do in fact always make such decisions initially, by choosing a particular programming language, technology (choosing J2EE is an “architectural decision” even though there are multiple vendors), etc. (I quote “architectural decision” because my view of architecture is different. What is usually meant by such a decision, which is made more clear by using the program family decision tree concept, is those early decisions which are thought hard to change at a later time, such as switching from J2EE to, say, Apple WebObjects, or switching the brand of database after having relied on a brand-specific database library.)

So, what do I want to say with this post? I like Clements’ article because it is the closest to my view on architecture that I have ever read, because the idea that an architecture is a class, not of system as Clements writes, but of structure/design. It is meta-structure/meta-design. He also writes that “[work] in software architecture can be seen as attempting to codify the commonality among members of a program family, so that the high-level design decisions inherent in each member of a program family need not be re-invented, re-validated and re-described.” (Pattern form of course is the ideal choice for this codifying.) He gives the example of compilers, where many years of experiments have matured the concepts and structure/design of compilers to the point that “no one today would think for a moment of building a compiler from scratch, without re-using and exploiting the codified experience of the hundreds of prior examples”, documented in numerous books and articles.

But an unprecedented design/structure also has an architecture. There is a meta-design/meta-structure that can be detected in the set of ways in which it can evolve. When you add to or alter the design, you do so based on your intuition, based on what you think make sense. This is the architecture guiding you. Little over a month ago I wrote about storytelling and architecture – see here – which I think is an effective analogy to understand this. I have to do some work now, but I’ll return to this later. I have no choice. It haunts me.