Failure in Slow Motion
Business-critical systems rarely die. They stiffen.
Every quarter, it costs a little more to touch them. Releases turn from routine into ritual, and then into risk. Workarounds appear at the edges: a spreadsheet here, a manual step there, a shadow process nobody dares to document. And then comes the quiet turning point: the organisation starts adapting itself to the system, instead of the system adapting to the organisation.
The researchers at Ink & Switch describe this beautifully in their essay on malleable software. Modern software, they argue, was promised to us as clay (something we could reshape at will) but arrived as an appliance: sealed, finished, built far away. When the tool no longer fits, it's the workflow that bends.
Here's the uncomfortable part: this doesn't only happen with off-the-shelf products. Your own bespoke, business-critical system (the one built precisely for your organisation) can harden into that same appliance. Not because anyone chose it, but because nobody chose otherwise while the original design intent drifts quietly out of view, until nobody dares to change what nobody fully understands. And a business-critical system that can no longer change has already failed, even while it's still running. The failure just hasn't reached the balance sheet yet.
Future-Proof Is Not a Prediction
"Toekomstvast" is often misread as a bet on the future: pick the right platform, the right vendor, the right paradigm, and you're safe. But nobody guesses the future right. Regulation shifts. Companies merge. Markets invert. AI rewrites the economics of software in real time. Pick your disruptor or one will pick you.
Future-proof means something humbler and far more valuable: cheap to be wrong. Amazon's language for this is the two-way door: a decision you can walk back through. A future-proof system isn't the one that anticipated everything. It's the one where most decisions turned out to be two-way doors (where being wrong costs a sprint, not a rewrite) and where slow, careful deliberation is saved for the few doors that only open one way.
That is what architecture is actually for. Not diagrams, not governance theatre, but converting one-way doors into two-way ones, and keeping the cost of change flat over time. Explicit contracts between components, so teams can move without ambushing each other. Seams placed where change is most likely, so tomorrow's requirement lands in one module instead of twelve. Events as the durable record of what happened, so new consumers can join without renegotiating the past. Versioning as a strategy, not an apology. Parts you can replace without a heart transplant.
None of this is free. Seams, contracts and versioning discipline all cost you something on day one. That's the premium on the insurance and you find out what the policy was worth on the day the future disagrees with you.
Stewart Brand observed that the buildings people come to love are the ones that adapt to their occupants, buildings that learn. The same holds for systems. The systems an organisation loves are never the perfect ones. They're the ones that kept learning.
"A future-proof system is not one that never changes. It's one that never learned to fear change."
AI Raises the Stakes
There's a tempting thought going around: with AI-assisted development, who needs architecture? We'll simply generate our way out.
Fred Brooks explained decades ago why that won't work. The hard part of software was never writing the code. That's what he called accidental complexity. The hard part is conceiving the design: the essential complexity. AI collapses the cost of the first and barely touches the second.
Ink & Switch have a sharp image for the same point: bringing AI coding into a closed ecosystem is like bringing a brilliant chef to a food court. All anyone can do is order off the menu. In a rigid architecture, AI doesn't remove the constraint. It produces rigidity faster.
But flip it around: in a well-architected system, AI becomes a genuine force multiplier. The architecture decides whether all that new speed compounds or collapses. Which means architecture hasn't become less important in the age of AI. It has become the difference between acceleration and pile-up.
How We Build
At Infodation, we've been building business-critical systems for over fifteen years. We have built n telecoms, energy, logistics. Long enough to have inherited other people's stiffened systems, and long enough to know how to keep our own supple.
So we put architecture before code. Contracts before integrations. We rehearse migrations until they're boring. We don't do big-bang. We don't do disposable. We build systems that can learn.
If your system has started dictating how your organisation works instead of the other way around, that's not a maintenance problem. That's an architecture conversation worth having.
