Speaking Topic: Evolutionary Systems Architecture
Building with impermanence instead of around it, because in distributed computing, eternal systems are a folly.
In classical civil engineering, monuments were built to endure for millennia, carved from granite, reinforced with iron, defying the elements through brute mass. Software architecture that tries to imitate that instinct fails for a simple reason: the requirements it is defying change faster than granite ever did.
I use the Sand Mandala as the governing metaphor: Tibetan monks spend weeks constructing an elaborate, beautiful mandala from colored sand, then ritually destroy it. That is not nihilism, it is architectural discipline. Your perfect architecture must be willing to be dismantled, or it will dismantle the business trying to keep it alive.
New failure modes in modern distributed systems rarely come from the components you designed carefully. They come from the interactions between components nobody designed together at all.
Key Takeaways
- 01Architecture built for permanence fights the one constant in software: changing requirements.
- 02A system's willingness to be dismantled and rebuilt is a design strength, not a weakness.
- 03Most new distributed systems failures emerge from component interactions, not individual components.
Frequently Asked
What is "evolutionary architecture" as a design philosophy?
Designing systems to be dismantled and rebuilt as requirements change, rather than engineered for permanence, since in distributed computing the requirements always outlast the assumptions.
From the Q&A
“Isn't designing for permanence just good engineering discipline?”
It is good discipline for physical infrastructure. In software, the requirements change faster than the "permanent" design, which is what actually creates fragility.
“How do you convince a team to dismantle something that still works?”
You show them the Sand Mandala framing: the willingness to rebuild is what kept the system alive this long, not a failure of the original design.