In recent years I have come into contact with architecture. It is strange how in life one sometimes stumbles upon subjects one could never have predicted would become fascinating. By this I do not mean buildings and urban planning, but the more abstract and scientific concept of architecture – the kind that arises when one attempts to build complex technical systems, which I would argue is not quite what one first assumes it to be without studying it more closely.
Since in my work I deal with systems of electronics and software, it is natural to encounter the concept of system architecture. This text will not deal with systems themselves – which are also not entirely trivial to define – nor will it dive deeply into what architecture actually is.
Instead, I want to look at a text written as early as 2001 by the American software developer Joel Spolsky, about a concept he calls “Architecture Astronauts”, in the blog post Don’t Let Architecture Astronauts Scare You.
Joel has a point: if something is taken too far, it crosses the boundary into becoming unusable. One could make the same argument about abstract art that becomes art for its own sake, cooking where the act of cooking itself becomes more important than how the food is experienced, or really almost anything. Anything people do can be taken to absurd extremes, which of course is not wrong for someone who enjoys doing so. Others may appreciate it or simply ignore it.
Joel’s argument is that certain “architects” (I write this in quotation marks for a reason that we will soon see) become “architecture astronauts” and float out into space without oxygen, creating architectures (software in this case) that end up being of no practical use. This is surely true. I have probably ended up there myself in some programming initiative where I wanted to think through the plan for a home project one step too far.
One creates a plugin architecture for… one (1) plugin. One creates a layered architecture where function calls go down one layer, which then goes down another layer. Classic over-engineering, in other words. And if you are an engineer, you should not only solve the problem – you should also actually use the solution for something. Most of the time you are also short on both time and money, so over-engineering is not something you want.
In the world of software, the opposite of the architecture astronaut is the coder who writes without a plan and creates something that at best can be compiled, run and perhaps used, but that can never again be modified or extended. Nor is it possible to debug or understand – and fixing one bug produces three new unwanted behaviours or bugs.
This usually goes by the name spaghetti code or an anti-pattern called “big ball of mud”.
(There is another amusing term that corresponds to this, but for the development methodology itself: when you change something without a real plan, recompile, run, test again and realise you need to change it again. And so on. One of my oldest programming friends called this Norwegian programming. Yes, I myself am half Norwegian.)
So there is an optimal middle ground. And how do we reach it?
If one is to be an architect, one works with architecture. And what is architecture?
One way to find out is to read the ISO standards that define what it is and how one works with it. I generally think ISO standards are quite good things, since global committees gather and attempt to write down what they believe things are through some form of consensus. It may not be perfect, but there is a good chance that they are close to the truth and at least represent the best we have.
The standard that concerns how to work with this is called Software, systems and enterprise — Architecture processes (ISO/IEC/IEEE 42020:2019). The process is described there. I will not go through the entire thing, because we do not need to go that far to get the answer to the question.
In short, and somewhat simplified, it works roughly as follows.
- Find out what system you want to develop, what it should do (functions) and in what environment it operates.
- Find out how well it needs to perform those things and how good it must be at other aspects, for example how heavy it may maximally be or how expensive it becomes to purchase its components. These are usually called attributes. Other words are properties or qualities.
- Write requirements for the functions – functional requirements.
- Write attribute requirements for the system. (Sometimes these are also called non-functional requirements, but I personally think that sounds somewhat negative.)
When one begins to think about it, the attribute requirements can become quite numerous. And one discovers something worse: all attribute requirements stand in conflict with one or more other attribute requirements. If you say that something must have high performance, it may consume too much power and the battery life becomes too short. If you make something very reliable, development time and therefore cost becomes too high. But all engineers like reliability, and yes… right – time and money were things we were short on.
So we must take the next step. - Balance the attributes against each other.
Depending on the system you are developing, you operate at different points along the attribute scales. A passenger car cannot be arbitrarily expensive, because then it will not sell, but one can compromise somewhat on component reliability since a certain level of warranty cost can be tolerated during the car’s fifteen-year lifetime. A satellite, on the other hand, must be extremely reliable and survive its fifteen years without repair – because there are no service workshops in space. (Fifteen years happens to be a common denominator for these two systems.)
One must therefore find an optimum among compromises between all attributes and then derive requirements for the system architecture from this delicate balance. Note: not requirements for the system, but for the system’s architecture.
After that, if one follows the rules of the craft, one should produce several different architectural proposals that satisfy the requirements – perhaps more or less well – and then choose the one that best fits the balanced attribute requirements.
However, during my almost thirty years of contact with the development of embedded systems I have never seen this done explicitly in practice. Perhaps it actually happens very quickly – even in one’s head. Architects know that certain types of architectures will simply not meet the requirements. So perhaps it does happen after all, just somewhat quietly.
And here we approach the important point.
Note that this time I did not write architects in quotation marks. Because I mean that those “architects” who do not understand attribute balancing are not architects. When someone starts drifting off into space, it is usually because some attribute has fallen out of balance with another attribute. Most likely because there was never a well-thought-out set of requirements to begin with.
So the point is that Joel is probably right that astronauts exist. But I would argue that by definition (according to the ISO standard’s definition) they are not actually doing architectural work.
More generally, I am also somewhat unsure whether Joel is entirely correct about the concepts themselves. Toward the end of his text it seems to me that he is actually talking more about the latest trends (well, twenty-five years ago now) in product and technology development – perhaps even about competitive dynamics – rather than about architectures that have become overly ambitious.