For a long time, I didn’t like the software architecture metaphor much. Software felt too malleable for such a static comparison. I preferred other analogies. But in recent years, I’ve come to appreciate it much more. The architecture metaphor actually works quite well.
Part of this realization stems from a better understanding of physical construction: how architects, civil engineers, electricians, plumbers, roofers, and interior designers collaborate.
Let’s make the parallel with a typical web project:
| Software Work | Construction Work | How Hard Is It To Change? |
|---|---|---|
| Choosing the stack (e.g., Angular, Spring Boot) | Choosing materials (Concrete, wood, building fabric) | Foundation. Changing this may mean rewriting the whole system. |
| Decomposition (Domains, key cross-cutting concepts) | Structural layout (Load-bearing walls, space for conduits, navigation) | Support Structures. Changing it requires major effort; it shapes the system. |
| Defining constructs (Key entities, services, etc.) | Systems selection (Kitchen, flooring, non-load-bearing walls, plumbing, elevators) | Substantial Effort. Can be modified, but it is messy and disruptive. |
| Detailed design and implementation | Interior design | Easy. Like repainting a room or swapping furniture. |
The upper items are harder to change than the lower ones1.
Detailed design and implementation is easy to change, like interior design. If a button is in the wrong place or a form field is confusing, you can fix it in an afternoon. It’s like deciding to paint the living room blue instead of beige, or replacing the carpet with hardwood. The structure remains untouched, and the work is contained.
Key constructs in the project, like the domain model, can be modified with substantial effort. Imagine you need to move the main water heater, remove a non-bearing wall, or reroute the electrical panel because the building codes changed or your needs evolved. You can’t just paint over it; you have to shut down power, drain pipes, and carefully navigate around existing walls. In software, this is like changing how a “User” entity relates to an “Order” or splitting a service into two. It breaks existing integrations, requires data migration, and forces the whole team to pause while the “plumbing” is reworked.
How the software is decomposed is even harder to change. The decomposition shapes the system and changing it requires major effort. You are changing key support structures. Think of it as realizing halfway through construction that the staircase is in the wrong place, blocking the flow of the entire house. To fix it, you might have to tear down a load-bearing wall, install temporary supports, and rebuild the second floor. In software, this is the nightmare of trying to move from a monolith to microservices, or redefining your core business boundaries after years of development. It’s not just a refactor; it’s a reconstruction of how the teams and systems communicate. Extensions are far easier, like a new business module for software or a veranda for a house.2
Finally, the technologies that are used lay the foundation. Changing them may mean rewriting the whole system. This is the equivalent of deciding three years into a build that you want to switch from a concrete foundation to a timber frame. You can’t just patch it; you have to dig up the site and start from zero. In software, this is the decision to migrate from Java to Go, or from SQL to NoSQL. It often means the old system becomes obsolete, and the only path forward is a complete rewrite.3
I disliked the architecture metaphor because I had categorized too much work under it. Over the lifetime of a software system, architecture happens intensely at the beginning and then occasionally later on. Most of the work isn’t architecture work. It’s interior design and systems selection. People move in and out, swap furniture, and do light renovations. It requires taste and care and is valuable—but it isn’t architecture.
- This is similar to concept of “shearing layers” from Duffy and Brand. The layers in the table are a variation of their concept. ↩︎
- Over long period of time, buildings can still change significantly, as shown in the book “How Buildings Learn” from Brand. ↩︎
- Some pretty impressive can happen to buildings nevertheless, like rotating a building 90°! ↩︎
://ewernli 