A design is reviewed and approved. Months later the system goes live and does not quite match it. Nobody decided to depart from the architecture. It happened through a hundred small, individually reasonable decisions taken under deadline pressure by people who did not have the whole picture.
This is drift, and it is the normal behaviour of delivery rather than a failure of discipline. Treating it as negligence produces blame. Treating it as expected produces checkpoints.
Nobody decides to depart from the architecture. It happens through a hundred small, reasonable decisions.
Where drift actually happens
Drift rarely shows up in the large components. It accumulates at the edges. An interface that was meant to be asynchronous becomes a synchronous call because that was quicker to implement. A shared library is copied rather than referenced. A security control is deferred to a later sprint that never arrives. A temporary table becomes permanent.
Individually each is defensible. Collectively they erode the properties the architecture was chosen for, and the system becomes harder to scale, harder to change, and carries risk nobody wrote down.
The cost curve is the argument
An architectural problem found at design time is a conversation. Found during build it is rework. Found in production it is an incident, then a remediation project, and often a permanent constraint the organization works around for years.
That curve is the entire case for keeping architecture engaged through delivery rather than treating design as a phase that finishes. The cost of staying involved is small and predictable. The cost of finding out late is neither.
Checkpoints worth having
Useful assurance is specific and infrequent. Three checkpoints cover most of the risk: a design review before build begins, an interface review when the first real integration is attempted, and a pre-production review covering security, operability and the decisions that changed along the way.
The last is the one most often skipped and the most valuable. Asking what changed since the design, and why, surfaces drift while it is still cheap to correct, and it leaves a record of decisions that outlives the team that made them.
Assurance without slowing delivery
Architecture assurance earns its place only when it is proportional. It should apply to the initiatives where being wrong is expensive, not to every change. It should produce decisions rather than documents. And the person carrying it out needs enough standing to say that something is not ready, which is why assurance performed by someone with no authority reliably degrades into a formality.
Architecture-led delivery is not about controlling how teams work. It is about making sure the reasons a design was chosen survive contact with the schedule, and that when they cannot, somebody decides that deliberately rather than discovering it afterwards.
Key takeaways
- Drift is normal delivery behaviour rather than negligence, so plan for it with checkpoints.
- It accumulates at the edges: interfaces, shared code and deferred controls.
- A problem found at design time is a conversation; found in production it becomes a lasting constraint.
- The pre-production review asking what changed, and why, is the highest-value checkpoint.