Why it shows up in your week
Architecture drift is quiet. Each change may be reasonable on its own, but the system slowly stops matching the model in the team's head.
In plain language
Drift often shows up as outdated diagrams, services nobody owns, duplicated logic, hidden manual steps, or integrations that only one person understands.
The risk is decision-making based on a map that no longer describes the territory.
Where it bites
Architecture drift bites during incidents, due diligence, migration work, or feature planning. Estimates become unreliable because the team discovers the real system only after work has started.
What to check
- Does the current architecture diagram match production traffic, data flows, and ownership?
- Which integrations or services exist only because of an urgent workaround?
- What would a new engineer misunderstand after reading the docs?
Common questions
What is architecture drift?
Architecture drift is the gap between the intended system design and how the production system actually works after many small changes.
What causes architecture drift?
Common causes include urgent fixes, undocumented integrations, new vendors, team turnover, missing ownership, and architecture decisions that were never revisited.
What should you check first for architecture drift?
Compare diagrams, code, infrastructure, data flows, and ownership against production reality. The mismatch is where risk usually starts.