Lesson 5 of 5
Revisiting decisions
10 min
Listen to this lesson
Good decisions can become wrong without anyone making a mistake. An acquisition adds a country, SAP changes a roadmap, a vendor contract renews, an incident reveals a weakness, a regulation changes. Architecture governance must make it normal to revisit decisions when facts change, and abnormal to revisit them because someone simply prefers another option.
Triggers for revisiting
| Trigger | Contoso example | Typical question |
|---|---|---|
| Business change | Acquisition of Alternadores del Norte (Wave 2) | Do integration and data decisions still fit a second country and currency? |
| SAP roadmap or terms change | Updated transition or maintenance terms; new clean core guidance | Does any decision depend on the changed date or capability? |
| Assumption review date | ADR-007 review after Wave 2 cutover | Is the rebuild capacity still there? |
| Incident or quality signal | Repeated interface failures in hypercare | Is the pattern or the implementation at fault? |
| Cost or contract event | Subscription renewal for a BTP service | Is the service still the best option at the new price? |
| Regulation | Electronic invoicing rules for the Mexican entity | Do output and integration decisions meet the new obligation? |
Common triggers for revisiting architecture decisions.
A disciplined revisit
- Trigger loggedWho raised it, which decisions it may affect
- Impact scanFind ADRs whose assumptions or context the trigger touches
- ReassessFor each affected ADR: do the original criteria and scores still hold?
- DecideConfirm the decision (and record the check) or open a new decision
- SupersedeNew ADR links to the old one; test consequences and migration plan included
Revisiting does not mean reopening everything. Most triggers touch a few records. The impact scan is quick when records list their assumptions and links. For each affected decision, ask whether the original criteria and their scores still hold with the new facts. Often the answer is yes, and the useful output is a dated note on the record: "checked after Wave 2 cutover; still valid".
Avoiding two classic errors
| Error | What it looks like | Guard |
|---|---|---|
| Sunk-cost persistence | Keeping a failing approach because of what it already cost | Compare options on future cost and risk only |
| Decision churn | Reopening decisions whenever a new person or vendor prefers something else | Require a new fact or a failed assumption to reopen |
| Silent drift | Teams quietly work around a decision without changing it | Architecture reviews of designs and code against accepted ADRs |
A review rhythm
Triggers catch the obvious changes; a rhythm catches the quiet ones. Many architecture boards review, once a quarter, every record whose review date has passed and every assumption tied to an external date, such as a maintenance deadline or a contract renewal. The review is short when records are well kept: confirm, note the date, or open a new decision. It also produces a useful governance signal for the PMO, the number of overdue reviews, which tells Grace whether architecture governance is keeping pace with the program.
Revisiting has a test cost too
Changing a decision late is a change like any other, and often a large one. Moving an extension from classic ABAP to ABAP Cloud, or an interface from synchronous to asynchronous, needs its own testing: the new implementation, the migration of data or configuration, and regression of everything around it. The new decision record should state those consequences, and the release plan should give them capacity. Where the original decision used a toggle or a contract, the change is much cheaper to test, which is one more reason to design those in.
What would you do?
Eighteen months after go-live, a new IT director wants to replace the integration platform decision because a different approach was standard at their previous employer. Nothing has failed and no assumption has changed. What should the architecture board do?
- Revisit on triggers: business change, roadmap or terms change, review dates, incidents, cost and regulation.
- Scan impact through ADR assumptions and links; confirm or supersede.
- Guard against sunk-cost persistence, churn and silent drift.
- A changed decision is a change with its own test scope; plan capacity for it.
Check your understanding · not graded
Lesson check
1. Which is a valid trigger for revisiting an architecture decision?
2. What is sunk-cost persistence?
3. What is often the useful output when a revisit finds the decision still valid?
4. Why are decisions designed with toggles or contracts cheaper to change later?