Architecture Is a Verb
· 1 min read
We like to think architecture starts with a problem. But often, by the time we’re brought in, someone has already chosen the answer — and the real work becomes understanding the problem they skipped.
That gap is what this blog is about.
Architecture is not a noun
For a long time, our industry treated architecture as a noun: a diagram, a document, a decision made once at the start and then defended. But businesses don’t hold still long enough for that to work. Markets shift, teams reorganize, constraints appear that no one could have predicted.
So I’ve come to think of architecture as a verb — something you do continuously, not something you have. The interesting question is never just “what’s the right design?” It’s “how do we keep making good architectural decisions, together, as everything around us changes?”
The socio-technical part
The hardest problems I meet are rarely purely technical. A retail client once arrived certain that containerizing everything and deploying Kubernetes would fix their operational pain. Underneath that confident prescription was a twenty-year-old system nobody fully understood.
The fix wasn’t a technology. It was running an impact map with the decision-makers, an event storming workshop with the people who actually knew the domain, and asking a deceptively simple question: compared to what?
That’s the socio-technical view. Architecture lives in the space between people, their language, their incentives — and the systems they build.
What you’ll find here
- Continuous Architecture — making and governing decisions over time
- Domain-Driven Design — Event Storming, Domain Storytelling, bounded contexts
- Modernization — evolving legacy systems without pretending they’re greenfield
- Cloud-native on AWS — the engine room, where the ideas have to actually ship
Written in English first, with a Chinese edition alongside. Welcome.