Architecture is decisions, not documentation
System architecture doesn't start when you open your diagramming tool. It starts when you decide what matters.
A full-stack engineer writing on their process makes a point worth considering: the "right" technology matters less than identifying what cannot fail. This aligns with how enterprise architects actually work - Architecture Decision Records (ADRs) formalize choices before any diagram exists, capturing rationale that survives personnel changes.
The distinction matters during platform modernization. Teams that document decisions separate from implementation details can change technology without losing institutional knowledge. When that government agency or bank eventually migrates off their current stack, the decisions about failure modes and acceptable trade-offs transfer. The Kubernetes YAML files don't.
MVP thinking beyond feature counts
The piece reframes MVP as "smallest system that teaches you something" rather than "minimal code." For enterprise teams, this translates to deployment safety, observability, and changeable direction - capabilities that look like over-engineering until the first production incident.
AWS documentation notes diagrams reduce migration risks by identifying issues early. That's true, but diagrams serve decision-making, not the reverse. vFunction's research on microservices decisions shows similar patterns - visual tools accelerate development by clarifying trade-offs, not by being comprehensive.
The boring technology trap
The author advocates "boring technology" as delayed complexity, not outdated tools. This echoes Martin Fowler's framing of architecture as evolving decisions about structure and behavior.
The contrarian view: sources like Lucidchart and Miro position diagrams as decision enablers - understanding impacts before changes, mapping relationships early. Both perspectives have merit. The real question is sequencing. Diagrams that emerge from decisions are useful. Diagrams that substitute for decisions create governance theater.
What this means in practice
For teams managing technical debt: architecture artifacts should capture "why" before "what." The decision to accept eventual consistency in a specific service matters more than which message queue implements it.
For platform teams: design for change velocity, not theoretical scale. Clear boundaries and replaceable components reduce the cost of being wrong - which matters more at most organizations than handling millions of users they'll never have.
The piece doesn't break new ground, but it articulates something experienced architects know: good architecture reduces the cost of changing your mind. Everything else is implementation detail.