As software engineers and system designers, we're often tempted to think in abstractions — flowcharts, diagrams, layered architectures. But what if we started thinking like an architect, not of code, but of buildings? What if we saw code not as lines in a file, but as bricks in a cathedral — each with purpose, material, and connection?
This isn't about aesthetics. It's about the construction mindset — how meaningful systems are assembled, joined, and made to last. Let's explore how the architectural thinking of Peter Zumthor applies to software architecture, especially in how we build.
Construction is Composition: Code is Material
In building architecture, construction is not just technical execution. It's where design meets materiality. Every beam, joint, and material choice affects the total presence of the structure.
In software, the same principle applies: code is not abstract — it's concrete. Frameworks, libraries, modules, interfaces — these are your building materials. A well-architected system isn't just about having the right features — it's about how the parts come together, and what happens at the joints.
Analogy: A join in construction = An API boundary in a software system. A good join is seamless and supportive. A bad one is brittle and cracks under pressure.
Joints Define Quality
Zumthor emphasizes that “every join should reinforce the total presence.” In software, we tend to obsess over components in isolation — microservices, modules, plugins — but often overlook the contracts and integrations between them.
These "joins" are where bugs happen, latency creeps in, and systems collapse. Think about how two services talk — REST, gRPC, event buses, shared databases. It's not just whether they work — it's how they come together.
In software, integration is design. Interfaces, boundaries, and contracts are architectural elements — not afterthoughts.
Material Knowledge = Technical Literacy
Zumthor's work is rooted in deep material understanding — how wood bends, how stone absorbs light, how concrete weathers. Similarly, good software architects must understand their materials: not just what a framework does, but how it behaves under load, how it scales, how it fails.
You can't design a resilient system if you don't understand how Redis behaves under memory pressure or how Docker containers handle file I/O.
Knowing what to use is junior. Knowing how and why it behaves as it does is senior. Understanding the materiality of software components is architectural.
The Details Set the Tone
Zumthor says, “We are faced with the challenge of filling out the whole with innumerable details.” That's exactly how software architecture works. Architecture isn't just the high-level diagram — it's the cascade of decisions about deployment, observability, state consistency, logging, failure handling.
You know you're thinking like an architect when details like retry policies, error propagation, idempotency, and timeouts become design decisions, not just implementation tasks.
Build First, Then Abstract
Zumthor flips the order of traditional design: he starts with the concrete object, not the abstract plan. This mindset is crucial in software too. Don't fall into the trap of overdesigning. Build, observe, reflect, refactor.
A symphony on paper is not music. Architecture diagrams are not systems. They only come to life through construction — through code, deployments, and usage.
In software, start small, get real, and abstract later. Model reality, not hypotheticals. As Dijkstra put it, “the question of whether a computer can think is no more interesting than the question of whether a submarine can swim.” Reality is what matters.
Emotional Response in Systems?
It might sound odd, but Zumthor urges us to feel architecture — not just think it. We remember buildings not for their blueprints but for the spaces they created, the way light filtered through a room, the sound of footsteps on stone.
Shouldn't our systems feel the same? Not emotional, but visceral: fast, responsive, clean, reliable. What if we asked:
- What does it feel like to use our system?
- Is it inviting or intimidating?
- Does it feel safe to change, or like a house of cards?
Your architecture isn't just for the compiler. It's for humans — developers, operators, users. Feel matters.
Conclusion: The Craft of Assembly
To start thinking like an architect — of buildings or systems — you must move beyond abstraction into construction. That means:
- Studying your materials (frameworks, protocols, patterns)
- Designing your joins (interfaces, APIs, contracts)
- Honoring the details (resilience, observability, testing)
- Building before abstracting
- Caring about the feel, not just the function
Architecture isn't just about how systems look on paper. It's how they come together, how they hold together, and how they make others feel — now and long after you're gone.