How to identify architecture drift before planning modernisation
A review sequence for separating visible system symptoms from the technical and organisational causes behind them.
Architecture drift accumulates when interfaces, ownership and deployment paths move independently until the system no longer matches its intended boundaries.
Architecture drift is the accumulated gap between how a system is expected to work and how it is actually changed, operated and owned.
Collect evidence before drawing the target state
Start with the deployed topology, runtime dependencies, data flows, release paths, service ownership and operating cost. Compare these with diagrams, standards and team responsibilities.
- Deployed services and environments
- Dependencies and data movement
- Release cadence and failure history
- Named technical and operational owners
- Cost by workload or capability
Test for structural causes
Look for boundaries that changed without a decision, duplicated capabilities, integrations no team owns and local optimisations that move risk elsewhere.
- Boundary and ownership mismatch
- Duplicate business capability
- Unmanaged integration or data contract
- Shared component without an owner
- Operating design blocking delivery
Produce a decision-ready output
Show the current state, root causes, material risks and viable change options. Each option needs dependencies, ownership, sequence and an explicit first decision.
- Current-state system model
- Evidence-linked findings
- Options with trade-offs
- Sequenced change plan
- Decision owners and next actions