It’s highly controversial to claim that there’s no such thing as “the architecture” of a system. On the one hand, folks in R&D use the term to indicate that the technical debt in the system has reached a point where more resources need to be dedicated to architecture refactoring. On the other hand, those on the business side who have at least a modicum of technology understanding use it as an argument toward their peers to explain why things take longer than expected or why we need to divert resources to address architectural issues.
Another situation where the architecture is used is when a faction in the company wants to start a project to replace the existing system or platform. The argument tends to be that the architecture of the old system is so old and poorly suited for today’s needs that it can’t be fixed. Hence, we need to start from scratch.
In my view, this use of the term “architecture” is driven by a poor understanding and some misconceptions about the nature of software. There are at least three main ones I believe are worth discussing.
First, the use of the term “architecture” suggests that there’s a clear boundary between the architecture and the rest of the system. This is of course incorrect. Even if the system is broken down into a small number of large subsystems, this isn’t really what the notion of architecture is about. Instead, it helps to think of architecture as a continuously evolving set of design decisions. These design decisions may affect the breakdown of the system into large components but also low-level aspects such as task scheduling. Architects concern themselves with design decisions that have a system-wide impact – the latter example around scheduling affects the real-time behavior of the system and is hence an architectural concern.
Second, many view the architecture of a software system as a static structure. This is in part because we borrowed the term from the construction industry. As soon as we build things out of atoms, it becomes difficult or at least expensive to change the structure.
Interestingly, this isn’t even true for buildings. Instead, the concept of architectonics structures buildings into multiple levels where each higher level is more expensive to change. For instance, non-load-bearing walls can quite easily be moved whereas this is more difficult for the load-bearing ones. And although we often think that the location of a building is permanent and immutable, there are several examples of older, wooden buildings in Sweden that have been moved.
For software, changing the architecture of the system is a continuous process in response to the requirements put on the system, the evolution of technology and other factors. Earlier, we thought of software systems as we think of humans in that aging is unavoidable. However, we now know that the aging of software systems is basically the consequence of underinvestment in architecture refactoring. I claim that no software system that has received sufficient resources for managing its evolution will ever have to be retired as long as there’s a need for its functionality.
A third, important factor is that, especially outside of R&D, many fail to understand the connection between the business and business strategy of the company and the architecture of the systems aiming to realize that strategy. In many ways, the software architecture is an embodiment of the business strategy and a change in business strategy will, typically, necessitate a change in software architecture as well.
A contemporary example is the transition from one-off customer projects in many companies to adopting DevOps where all deployments of systems in the field need to receive software updates every couple of weeks. A company using a platform for one-off customer projects can afford to use a clone-and-own strategy and create a unique copy of the software for each customer project. When adopting DevOps, this approach becomes prohibitively expensive and the platform needs to become configurable so that each customer-specific version is simply a configuration of the platform. This has significant implications for the architecture of the platform as well as the build system, test infrastructure and deployment process.
Of course, this is an incarnation of the BAPO model, which states that the architecture and technology choices are or should be a consequence of the business and business strategy choices. When leaders lack the understanding that the design of a system is spurred by business drivers, it easily leads to a situation where R&D gets blamed for being slow and unresponsive while there’s often a fundamental disconnect between business and technology.
Numerous times I’ve heard that the architecture of a system is the root of all problems a company experiences. I think this is a gross oversimplification and it can be argued that there’s no such thing as a software architecture. At least not in the way that most people tend to use the term. There’s no clear boundary between the architecture and the rest of a software system. The architecture is continuously evolving in response to new design decisions and the evolution of existing ones. Finally, the architecture is the embodiment of the company’s business strategy and any change to the strategy affects the architecture as well. By all means, use the term architecture, but make sure that you know what you’re talking about. In the end, whatever good and beautiful things we build, these end up building us.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
