Digital and Cloud Scale Architecture · Module 4

Evolution and governance

Glossary Tip.

45 min 3 outcomes Software Development and Architecture Advanced

Previously

Resilience and performance under failure

Caching helps, but it creates new risks.

This module

Evolution and governance

Glossary Tip.

Software Development and Architecture Advanced practice test

Test recall and judgement against the governed stage question bank before you move on.

Progress

Mark this module complete when you can explain it without rereading every paragraph.

Why this matters

Glossary Tip.

What you will be able to do

1 Explain what keeps architecture decisions coherent over time
2 Write an ADR with clear options, rationale, and review trigger
3 Describe a lightweight fitness check that prevents drift

Before you begin

Comfort with earlier modules in this track
Ability to explain trade-offs and risks without jargon

Common ways people get this wrong

Stale governance. If governance never updates, teams ignore it.
No feedback loop. If learning does not update standards, the same failures repeat.

Main idea at a glance

ADR lifecycle

Keep architecture decisions short, testable, and reviewable.

Stage 1

Propose options

Frame the decision with clear options and constraints. Include at least two real alternatives.

I think a single option is not a decision, it is a fait accompli.

ADR lifecycle with governance checkpoints

Interactive lab

Glossary Tip

This module includes an interactive practice component. Open the deeper tool or workspace step when you want to test the idea rather than only read it.

Interactive lab

Glossary Tip

This module includes an interactive practice component. Open the deeper tool or workspace step when you want to test the idea rather than only read it.

Architects guide change with small decisions, not massive documents. ADRs make intent visible. Fitness checks catch drift early.

Worked example. The same argument every quarter because nothing is written down

Teams re-litigate the same decisions: “monolith vs services”, “SQL vs NoSQL”, “build vs buy”. The debate burns time because context and trade-offs are not captured, so new people restart the argument from scratch.

Common mistakes in governance

Governance mistakes to avoid

Governance fails when decisions are hidden or not enforceable.

Recording conclusions without rationale

Every ADR should include context, options, and trade-offs, not only the chosen answer.
Meetings without decision rights

Define clear owners who can decide and be accountable for architecture outcomes.
No enforcement in automation

Use fitness checks and review gates so architecture rules stay true during delivery pressure.

Verification. A healthy ADR set

ADR quality checks

Use these checks to keep decision records useful over years, not weeks.

Complete ADR structure

Include context, options, chosen decision, trade-offs, and expected consequences.
Explicit lifecycle status

Mark each ADR as proposed, accepted, deprecated, or superseded.
Clear review trigger

Define which constraint or signal should trigger ADR re-evaluation.

Reflection prompt

Which decisions in your system should be recorded as ADRs this quarter.

CPD evidence (advanced, still practical)

Advanced CPD evidence pack

Keep evidence aligned to real delivery behaviour.

What I studied

Bounded contexts, distributed patterns, resilience under failure, and architecture governance.
What I practised

One context split, one event-projection flow, one resilience review, and one ADR from real constraints.
What changed in my practice

Example habit: I now define retry budgets and failure modes during design, not after incidents.
Evidence artefact

A four-page pack: context map, event flow, resilience checklist, and one production-oriented ADR.

Mental model

Evolution and governance

Systems evolve safely when governance enables change and prevents accidental harm.

1

Standards
2

Change
3

Measure
4

Learn

Assumptions to keep in mind

Decision rights are clear. Clear decision rights prevent endless debate and accidental divergence.
Evidence is captured. Evidence is how you learn and defend decisions.

Failure modes to notice

Stale governance. If governance never updates, teams ignore it.
No feedback loop. If learning does not update standards, the same failures repeat.

Check yourself

Quick check. Evolution and governance

0 of 8 opened

Why use ADRs

They make architectural intent visible and reviewable.

What is a fitness function

An automated check that protects architecture rules.

Why is technical debt risky

It compounds and slows delivery over time.

What keeps governance lightweight

Small decisions, clear boundaries, and automation.

Why revisit decisions

Context and constraints change over time.

What is a sign of architecture drift

Teams bypass shared rules to deliver quickly.

Why involve security and operations

They protect reliability and trust in production.

What makes refactoring safer

Tests, clear boundaries, and staged rollout.

Artefact and reflection

Artefact

One ADR and one short fitness check idea

Reflection

Where in your work would explain what keeps architecture decisions coherent over time change a decision, and what evidence would make you trust that change?

Optional practice

Capture decisions, status, and risk tags.