Somewhere in your organization, there's an architecture diagram that's wrong. Maybe it shows a microservice that was merged into another six months ago. Maybe it lists Redis as the caching layer when the team switched to Memcached during a production incident. Maybe it describes a clean hexagonal architecture in a service that's accumulated enough shortcuts and workarounds to look like spaghetti.
This is architecture drift: the gradual, silent divergence between how your system is documented and how it actually works. Unlike bugs, drift doesn't trigger alerts. Unlike performance regressions, it doesn't show up in monitoring. It sits quietly until someone makes a decision based on outdated documentation -- and that decision turns out to be wrong.
Architecture drift is universal. Every team experiences it. The question isn't whether your documentation will drift, but how quickly you'll detect it and what you'll do about it.
What is Architecture Drift?
Architecture drift occurs when the actual implementation of a software system diverges from its documented or intended architecture. The term was coined in the academic software engineering community, but the concept is painfully familiar to any practicing engineer.
