Architecture drift
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
recognise drift from the approved architecture and decide what to do about it.
Planned topics
- Drift is the gap between the approved design and what teams actually build, usually through reasonable local shortcuts.
- Common signs: a service calling the ERP database directly, a new data copy no one approved, a skipped authentication step.
- Detect it with design reviews, code and configuration inspection, dependency checks, and asking teams to show, not tell.
- Not all drift is bad: either bring the build back to the design, or update the design and record a decision.
- Never ignore it: unrecorded drift becomes surprise at go-live.
Draft outline details
Demonstration
a drift log entry: what was approved (all ERP access via the stock API), what was found (batch job reads ERP tables directly), impact (bypasses validation and rate limits), decision (fix before pilot), owner and date.
Check your understanding
What are the two valid responses to drift?
Show answer
Bring the build back to the design, or consciously change the design and record the decision.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.