Architecture as Code: teacher's guide

All courses / Architecture as Code / Teacher's guide

How to use this guide

The guide holds everything a teacher needs to run the course on Architecture as Code: the lecture of each module with a timed outline, the teaching plan of every lesson, the discussion questions, the exercises and the answers to the self-tests. The agendas of the three formats are on the course page; the slides are in the deck of the book.

Executive briefing (90 minutes): A decision-oriented briefing. It explains why static architecture drifts, what changes when architecture becomes executable, what readiness the organisation needs before buying tools, how governance and audit evidence become continuous, and which anti-patterns sink programmes. Participants leave with a first readiness score and a shortlist of pilot candidates.
One-day seminar (1 day): A working day that follows one architectural change from decision to evidence. Participants score readiness, write a decision record, model a system at two C4 levels, design a promotion ladder, write a policy rule with its control mapping and evidence manifest, and finish by diagnosing anti-patterns in their own programme. Each block produces an artefact that can be taken back to the workplace.
Full course (7 weeks, one module a week): The complete programme of seven modules and thirty-one lessons, one module per part of the book. Each week combines a lecture on the argument of the part, lessons with exercises that produce real artefacts, and a quiz per chapter. The artefacts accumulate in a repository and feed the capstone, an Architecture as Code blueprint for one system in the participant's organisation.

Keynote on the whole book · 45 minutes

Architecture as Code: when the architecture is checked on every change

For architects, engineers, security and governance professionals and IT leaders at a conference or internal architecture day

Most organisations have an architecture on paper and another one in production. The keynote presents the argument of the book: when architectural specifications become executable, governance becomes continuous instead of periodic, and the distance between intent and implementation collapses. It shows what that takes in practice, a readiness the organisation must earn, a platform that validates every change, controls that are assured once and mapped to many obligations, and an organisation that codifies even its management intent. It ends with the ways programmes fail and the question of accountability for machine-authored decisions.

6 min	Two architectures: the one in the slides and the one that runs Slideware syndrome and architectural entropy: unchecked artefacts lose coherence with implemented systems. Microservice estates add contracts and topologies faster than static diagrams can follow. Delivery in hours turns manual governance checkpoints into bottlenecks that teams bypass.
7 min	The claim: executable specifications Architecture as Code describes, version-controls and automates the whole architecture in machine-readable form. It learned from model-driven development: lightweight textual models that evolve alongside the implementation instead of replacing it. Five causes of drift each meet a countermeasure in a version-controlled workflow.
8 min	The platform: decide, model, validate, promote Decision records keep the rationale; one model generates the views. Pipelines fail fast in four validation layers and promote with evidence bundles. Declarative platforms reconcile the running state with what was declared.
8 min	Assure once, comply many A control is written, tested and evidenced once and mapped to every framework it satisfies. Governance moves into pull requests, with exceptions as code that expire. Evidence is generated and signed by the pipeline, not reconstructed at audit season.
8 min	The organisation that can carry it Readiness is a synthesis of culture, technology and economics, and automation without alignment amplifies disorder. Teams move from siloed functions to product-aligned teams that are autonomous within guardrails. Management intent, budgets and norms can be versioned and reviewed like any other artefact. AI agents draft and check; named people approve consequential decisions.
8 min	How it fails, and what remains open The recurring anti-patterns: a tool purchase in place of change, audit theatre, hero culture, scaling without maturity gates. Four leading indicators give early warning before drift escalates. Version control records what changed, not who held responsibility for a decision a language model proposed.

What the audience takes away

When architecture is executable, governance becomes continuous and the gap between intent and implementation can be measured and closed.
Tools come last: readiness in culture, technology and funding, and people who own the practice together, decide whether it lasts.
Start with a contained pilot, keep the rationale in decision records, and keep human accountability explicit for every consequential decision.

Module 1 · Part A · Foundations

Part A lays the conceptual foundations: what Architecture as Code is and why microservice complexity drives it, how to assess whether an organisation is ready, the principles that keep architecture declarative, immutable and testable, the version control practices that make the repository a single source of truth, and the Architecture Decision Record that keeps the rationale visible. Participants leave with a readiness scorecard, a drift analysis, a repository design and a written decision record.

Lecture · 45 minutes

From slideware to executable specifications: the foundations of Architecture as Code

The lecture carries the argument of Part A. Traditional architecture drifts away from operational reality because its artefacts are static while delivery moves in hours. Architecture as Code answers by making the architecture a live, executable specification under version control. The lecture shows why readiness in culture, technology and economics comes before tooling, which principles follow from learning the lessons of model-driven development, how Git workflows act as a countermeasure against drift, and why decision records are the memory that keeps the whole practice auditable.

8 min	The problem: slideware syndrome and architectural entropy Static decks, diagrams and committee reviews drift away from operational reality, and teams then improvise workarounds that bypass the guardrails. Large microservice estates are the tipping point: each service adds APIs, contracts and deployment topologies faster than static diagrams can follow. The core claim of the book: when specifications become executable, governance becomes continuous rather than periodic.
7 min	Readiness before tooling Automation without alignment merely amplifies disorder, so a readiness review slows the rush to tool selection. Readiness is a synthesis of culture, technical maturity and economic discipline, assessed in four loops and scored on a scorecard. The anti-patterns to name early: tool-first enthusiasm, heroic ownership, budget whiplash, governance bypass and metrics myopia.
10 min	The principles: declarative, immutable, testable Declarative definitions state the desired state at every level and make deviations visible. Model-driven development promised generated implementations and fell out of sync; Architecture as Code prefers lightweight textual models, explicit version control and continuous validation. Architectural drift has five named causes, and each has a countermeasure in a version-controlled workflow. Requirements as Code separates what can be tested automatically from what needs stakeholder validation.
10 min	Version control as the contract between layers Architecture as Code sits one abstraction layer above Infrastructure as Code: one publishes guardrails, the other consumes them. Repository topology and branching strategy are foundational decisions with real trade-offs, and the hybrid topology is often the pragmatic one. Branch protection, required status checks and signed commits turn the repository from a passive store into an active countermeasure.
10 min	Decision records as institutional memory An ADR is the commit message of the architecture: context, decision, consequences and status. Numbers are permanent and a changed decision is superseded by a new record, never edited in place. Treated as code, ADRs can be scaffolded, linted, reviewed and reminded about, and their metadata feeds dashboards such as the review debt tracker.

What the audience takes away

Architecture as Code is a governing discipline, not a tooling choice: the architecture becomes a live, executable specification that stays synchronised with the running estate.
Readiness in culture, technology and economics is the evidence that an organisation can use executable architecture responsibly.
Version control, automated validation and decision records together are what stop the documented architecture and the running system from drifting apart.

Chapter 1 · 60 minutes

Introduction to Architecture as Code

The lesson introduces Architecture as Code as the practice of describing, version-controlling and automating the entire system architecture through machine-readable code. It explains why microservice complexity is the primary driver, what the chapter criticises in traditional architecture, the three design criteria the book uses to evaluate practices, and how the different as-code practices reinforce one another in an interconnected flow.

Learning objectives

Define Architecture as Code and state what its scope covers beyond infrastructure.
Explain why large microservice estates are the tipping point for adopting the practice.
Describe slideware syndrome and architectural entropy and how fast delivery amplifies them.
Apply the three design criteria of adoptability, extensibility and productivity to a tooling proposal.

Key concepts

Architecture as Code: The practice of describing, version-controlling and automating the entire system architecture through machine-readable code. It produces live, executable specifications that stay synchronised with the running estate and covers application components, integration patterns, data architecture, infrastructure and organisational processes.
Slideware syndrome: The chapter's name for architecture practised through expansive decks, static diagrams and committee reviews that rapidly drift away from operational reality.
Architectural entropy: The gradual loss of coherence between documented intent and implemented systems that accumulates when architectural artefacts go unchecked. It erodes trust and leaves teams to improvise workarounds that bypass the guardrails.
Adoptability, extensibility, productivity: The three design criteria by which the book evaluates practices and tooling: teams can adopt it without wholesale tooling upheaval, the platform can evolve with the landscape, and codification gives faster feedback and fewer approval bottlenecks.
The interconnected flow: The ecosystem in which Requirements as Code, Compliance as Code, Documentation as Code, Design as Code, coding, CI/CD, Infrastructure as Code and Management as Code reinforce and validate one another through feedback loops, rather than forming a linear process.

Teaching plan

10 min	Opening round: each participant names one architecture diagram in their organisation that no longer matches reality. The teacher links the answers to slideware syndrome and architectural entropy.
15 min	Teacher presents the definition and scope, the microservice driver with the survey figures the chapter cites, and FINOS CALM as an example of the direction of travel.
10 min	Walk through the interconnected flow diagram and trace two feedback loops, for example infrastructure changes triggering compliance checks.
20 min	Exercise in pairs: the entropy inventory, followed by a short comparison of results in plenary.
5 min	Close with the core claim of the book and a preview of the parts A to G.

Discussion

Where in your organisation do manual governance checkpoints become bottlenecks that teams circumvent, and what happens to architectural intent when they do?
The chapter includes organisational processes in the scope of Architecture as Code. What would it mean in practice to codify one of yours?
Which of the three design criteria is hardest to meet in your organisation today, and why?

Exercise · 20 minutes

An entropy inventory of one system

Choose one system in your own organisation that you know well. List its architectural artefacts (diagrams, decks, review minutes, configuration repositories) and for each one note where it lives, when it was last updated and whether anything checks it against the running system. Mark the artefacts that show slideware syndrome. Then pick the one artefact whose drift causes the most harm and describe how it could become an executable specification that travels through the same pipeline as the application code. Judge your proposal against adoptability, extensibility and productivity.

Deliverable: A one-page table of artefacts with their drift status, and a short proposal for codifying one artefact, assessed against the three design criteria.

Self-test

According to the chapter, what is the tipping point for most organisations adopting Architecture as Code?
1. The licence cost of commercial diagramming and modelling tools
2. The complexity created by large-scale microservice estates
3. A regulatory requirement to keep architecture in version control
4. The retirement of experienced enterprise architects
How does the chapter describe the specifications that Architecture as Code produces?
1. Aspirational design artefacts that guide delivery teams through each quarterly planning cycle
2. Annual reference models approved by an architecture board
3. Generated source code that replaces manual implementation
4. Live, executable specifications synchronised with the running estate
Which three design criteria shape how the book evaluates Architecture as Code practices and tooling?
1. Adoptability, extensibility and productivity
2. Scalability, availability and security
3. Traceability, immutability and testability
4. Simplicity, portability and affordability

Chapter 26A · 75 minutes

Prerequisites for Architecture as Code Adoption

The lesson treats readiness as the evidence that an organisation can use Architecture as Code responsibly. It covers the cultural, technical, knowledge, economic, skills, toolchain, governance and change management prerequisites, the four loops of the readiness assessment framework, the readiness scorecard with its scoring bands, a case study of a financial services group, and the five readiness anti-patterns.

Learning objectives

Explain why a readiness review should come before tool selection.
Describe the four loops of the readiness assessment framework.
Score an organisation on the readiness scorecard and interpret the result against the scoring bands.
Identify the five readiness anti-patterns in a described situation.

Key concepts

Readiness as a contract: The chapter's position that readiness is not a gate to appease governance but evidence that the organisation can absorb executable architecture: when the prerequisites are visible, teams earn the right to automate architectural intent.
Readiness assessment framework: Four iterative loops: Contextual Discovery of stakeholder expectations, Capability Baseline of automation, testing, modelling and knowledge management, Cultural and Economic Diagnostics, and a Remediation Roadmap that closes cultural, technical and financial gaps together.
Readiness scorecard: A template of fifteen criteria in five dimensions, each rated 1 (not started) to 5 (fully implemented). A total of 60 to 75 means ready for a focused pilot, 40 to 59 partial readiness, and below 40 foundation work first.
Readiness anti-patterns: Five familiar mistakes: tool-first enthusiasm, heroic ownership, budget whiplash, governance bypass and metrics myopia.
Sequencing readiness investments: Start with a narrow architectural domain backed by supportive stakeholders; establish cultural and governance guardrails first, stabilise tooling second, and adjust funding models alongside early wins.

Teaching plan

15 min	Teacher explains why readiness matters and walks through the prerequisite areas, from cultural foundations to change management infrastructure.
10 min	Present the four loops and the scorecard, including the scoring bands and what each band asks the organisation to do next.
10 min	Read the case study of the multinational financial services group together and name its three gaps and the three remediation measures.
30 min	Exercise: participants score their own organisation on the scorecard and draft the top of a remediation roadmap.
10 min	Plenary: which anti-patterns appeared in the scores, and which dimension scored lowest across the room.

Discussion

The chapter says automation without alignment merely amplifies disorder. What would be amplified first in your organisation if architecture were automated tomorrow?
Why does the chapter insist that funding models and procurement practices are prerequisites for an architecture practice?
How would you tell the difference between governance that participates in pull request reviews and governance that remains a periodic toll booth?

Exercise · 30 minutes

Score your organisation on the readiness scorecard

Use the chapter's readiness scorecard. Rate your own organisation from 1 to 5 on each of the fifteen criteria in the five dimensions (Contextual Discovery, Capability Baseline, Cultural Readiness, Economic Viability, Remediation Roadmap) and write one line of evidence for every score: no evidence, no score above 2. Add up the total and place it in one of the three scoring bands. Then identify the top three capability gaps, rank them, scope one low-effort, high-visibility pilot, and write down a 90-day and a 12-month milestone. Note which of the five readiness anti-patterns your scores point to.

Deliverable: A completed scorecard with evidence notes and total, the three ranked gaps, one scoped pilot, and the 90-day and 12-month milestones.

Self-test

An organisation totals 52 points on the readiness scorecard. What does the chapter's scoring guidance say?
1. Ready to proceed: begin with a focused pilot
2. Foundation work needed: follow the Remediation Roadmap first
3. Partial readiness: address critical gaps before scaling
4. The score is invalid and the assessment must be repeated
In the case study of the multinational financial services group, which of these was one of the three gaps the readiness assessment uncovered?
1. Funding remained tied to annual projects
2. CI/CD pipelines were missing altogether
3. No team had been trained in an Infrastructure as Code tool
4. The regulator had rejected the cloud strategy
Which readiness anti-pattern does the chapter describe as buying modelling platforms without addressing the cultural foundations?
1. Budget whiplash from one-off project funding
2. Metrics myopia
3. Heroic ownership
4. Tool-first enthusiasm

Chapter 2 · 90 minutes

Fundamental Principles of Architecture as Code

The lesson covers the principles on which Architecture as Code rests: declarative definition, holistic codification, a single source of truth governed through Git, immutable patterns, testability, Documentation as Code and Requirements as Code. It examines the lessons of model-driven development, the causes and consequences of architectural drift and the workflow practices that prevent it, and the different ways functional and non-functional requirements are verified.

Learning objectives

Explain the declarative approach and contrast it with imperative specification.
Classify an observed deviation by the chapter's five causes of architectural drift and choose a response.
Describe the workflow practices that make version control a countermeasure against drift.
Distinguish how non-functional and functional requirements are checked when expressed as code.

Key concepts

Declarative architecture definition: Describing the desired system state at every level, from application components to infrastructure, rather than specifying each step as imperative programming does. It lets an architecture's intended state be expressed and compared with the actual state.
Architectural drift: A gradual, often unintentional deviation of a system's actual implementation from its intended design, as incremental changes, workarounds, emergency fixes and undocumented modifications accumulate. Its causes are manual configuration changes, emergency patches, knowledge loss, tool and process fragmentation, and lack of validation.
Single source of truth: One authoritative repository of architectural knowledge. The chapter's proven pattern is a hardened command-line interface for contributors and an API from which downstream governance and reporting systems synchronise diagrams, catalogues and service metadata.
Lessons from model-driven development: Model-driven development promised generated implementations from models, but brittle round-trip engineering, tool lock-in and ambiguous semantics let artefacts fall out of sync. Architecture as Code favours lightweight textual models, explicit version control and continuous validation that evolve alongside the implementation.
Requirements as Code: Turning requirements from textual documents into machine-readable code that can be executed, validated and automated. Quantitative non-functional requirements translate into automated tests; functional requirements need validation gates where stakeholders confirm business intent.

Teaching plan

15 min	Teacher presents the declarative and holistic principles and the historical lesson of model-driven development, including the warning by Selic that the chapter quotes.
20 min	Work through the drift table: causes, impacts and consequences. Participants match each cause to one of the five workflow practices, from review gates to refactoring disciplines.
15 min	Teacher explains Requirements as Code with the V-Model pairs and the comparison table for functional and non-functional requirements.
30 min	Exercise in groups of three: drift analysis and requirements classification, with one group presenting.
10 min	Close: the three responses to detected drift, and why a policy that was not loaded must be reported as an error and not a pass.

Discussion

When drift is detected, how should a team choose between reapplying the codified architecture, updating the code, and investigating the root cause?
The chapter says Architecture as Code evolves alongside the implementation rather than trying to replace it. What does that rule out, and what does it leave to developers?
Why can a functional requirement not be fully enforced by a policy engine, even when its implementation is tested automatically?

Exercise · 30 minutes

Drift analysis and requirements classification

Part one: describe three real or realistic deviations between documented and actual architecture in your own organisation. Classify each by the chapter's five causes of drift, state its consequence, name the workflow practice that would have prevented it, and choose one of the three responses to detected drift with a reason. Part two: write down six requirements for one system, three functional and three non-functional. For each, state whether it is checked predominantly by automated testing or by stakeholder validation, what the pass or fail criterion is, and what it traces to: an automated test result or a validation decision.

Deliverable: A drift table with three classified deviations and chosen responses, and a requirements table with six entries showing check method, criterion and traceability target.

Self-test

By default, administrators are exempt from protected branch rules. What does the chapter say is needed for the review gates to bind them as well?
1. Removing administrators from the CODEOWNERS file
2. Enabling the option that disallows bypassing the settings
3. Requiring a second administrator to countersign each merge
4. Moving the architecture definitions to a private repository
How does the chapter characterise the predominant way non-functional requirements are checked as code?
1. Stakeholder review cycles at major releases
2. User acceptance testing that confirms the business intent was met
3. Automated testing with objective, quantitative thresholds
4. Expert inspection of the architecture diagrams
Which of the following is listed in the chapter as a cause of architectural drift?
1. Excessive automated validation in the pipeline
2. Too frequent releases of new immutable versions
3. Overuse of declarative definitions in version control
4. Emergency patches applied without the standard process

Chapter 3 · 75 minutes

Version Control and Code Structure

The lesson shows how version control forms the backbone of Architecture as Code. It separates the responsibilities of Architecture as Code and Infrastructure as Code as two abstraction layers, covers code organisation, branch protection and testing harnesses, compares mono-repo, multi-repo and hybrid topologies and the GitFlow and trunk-based branching strategies, and explains how the repository creates transparency for teams, leadership and auditors.

Learning objectives

Distinguish the responsibilities of Architecture as Code and Infrastructure as Code across the chapter's five dimensions.
Compare mono-repo, multi-repo and hybrid topologies and justify a choice for a given organisation.
Compare GitFlow and trunk-based development for architecture assets.
Specify the branch protections and automated checks an architectural repository needs.

Key concepts

Layered abstraction of AaC and IaC: Architecture as Code sits one abstraction layer above Infrastructure as Code. It defines the opinionated guardrails that keep architectural intent enforceable, while Infrastructure as Code implements the concrete runtime changes. Version control is the contract between the layers.
Hybrid topology: A single canonical repository holds the architectural source of truth (models, policies, ADRs and golden-path templates) while service teams run their own repositories that reference the shared modules and policies. Governance stays centralised without forcing a mono-repo.
Trunk-based development: Nearly all work stays on a single main branch, with short-lived feature branches merged within a day or two. It suits architecture assets because definitions should reflect reality continuously, but it depends on reliable automated validation.
GitFlow with release gates: Long-lived develop, release and main branches give clear checkpoints for governance sign-off. Teams should codify release gate criteria, such as all ADRs having the status accepted and all diagrams rendering without errors, as automated checks.
Branch protection for architectural repositories: Mandatory rules that require status checks (documentation build, diagram generation, infrastructure linting), pull-request reviews, signed commits and linear history, so that architectural artefacts cannot bypass the agreed quality gates.

Teaching plan

15 min	Teacher presents the comparison table of Architecture as Code and Infrastructure as Code and the idea of version control as the contract between the layers.
15 min	Structured debate: half the room argues for a mono-repo, half for multi-repo, using only the trade-offs the chapter gives. The teacher then introduces the hybrid topology.
10 min	Compare GitFlow and trunk-based development and the conditions under which the chapter prefers each.
25 min	Exercise: participants design the repository topology, layout and protection rules for their own organisation.
10 min	Close on transparency: the four questions an auditable trail answers, and who benefits (leadership, auditors, new team members).

Discussion

The chapter says trunk-based development works best when the team trusts its automated validation. What would have to be true of your pipelines before you trusted the main branch at all times?
What does it change for an auditor when compliance is verified through repository history instead of bespoke documentation?
Where should the line between the architectural source of truth and the execution artefacts run in your own repositories?

Exercise · 25 minutes

Design an architectural repository

For your own organisation, choose a topology (mono-repo, multi-repo or hybrid) and justify it by scale, team maturity and coupling between components. Sketch the top-level directory layout of the canonical repository, for example architecture, modules and docs, and write for each directory the three things its README must summarise: ownership, usage patterns and change controls. Choose a branching strategy and state where it will be documented. Finally list the branch protection rules and the required status checks that must pass before a merge, and say what evidence each check leaves behind.

Deliverable: A one-page repository design: topology with justification, directory layout with README content, branching strategy, and a list of protection rules and required checks.

Self-test

In the chapter's comparison, what is the primary artefact of Architecture as Code as opposed to Infrastructure as Code?
1. Codified guardrails, architectural policies and structural models
2. Environment templates, resource modules and orchestration logic for deployment
3. Plan, apply and monitoring reports on the runtime state
4. Container images, build pipelines and deployment manifests
Why does the chapter say Architecture as Code workflows generally benefit from trunk-based development?
1. Because it removes the need for pull-request reviews
2. Because organisations with formal change-control requirements always demand a single branch
3. Because definitions are long-lived and should reflect reality continuously
4. Because long-lived release branches cannot be protected
What is the principal drawback of a mono-repo that the chapter names?
1. Cross-cutting changes cannot be made in one pull request
2. Scale: clone times, CI durations and merge conflicts increase
3. Shared tooling has to be configured separately per team
4. Access control can only be granted to one owning team

Chapter 4 · 75 minutes

Architecture Decision Records (ADR)

The lesson teaches the Architecture Decision Record: a short document that captures an architecture decision with its context and consequences. It covers the four core sections, permanent numbering and supersession, the status lifecycle, the two worked examples on Terraform and PostgreSQL, the management of ADRs as code through discovery, review and supersession automation, and the use of ADR metadata for dashboards and handovers.

Learning objectives

Describe the four core sections of an ADR and the purpose of each.
Explain the status lifecycle and why a changed decision is superseded by a new record.
Draft an ADR for a real decision, with consequences and mitigation.
Outline how discovery, review and supersession of ADRs can be automated in a Git workflow.

Key concepts

Architecture Decision Record: A short text document that captures an important architecture decision together with its context and consequences. The method was introduced by Michael Nygard in 2011, and the chapter calls ADRs the commit messages of the architecture.
Status lifecycle: An ADR is proposed, accepted, deprecated or superseded. A deprecated decision is no longer recommended but may remain in the system; a superseded one is replaced by a newer ADR and references its successor.
Permanent numbering and supersession: ADRs are numbered sequentially and keep their number even when deprecated or replaced. Versioning lives in the Git history: when a decision changes, a new ADR supersedes the original, preserving the historical context.
Code-managed discovery, review and supersession: A bot scaffolds a draft ADR when a backlog item carries a label such as architecture-impact, continuous integration lints the front matter and fails on missing metadata, and a scheduled pipeline posts reminders when the next review date passes.
Review debt tracker: A dashboard widget derived from ADR metadata that flags records whose next review date has passed, so that leadership can prioritise refresh work in sprint planning.

Teaching plan

10 min	Teacher introduces the ADR, its four sections and the status lifecycle, and why numbering is permanent.
15 min	Participants read ADR-0003 on Terraform and ADR-0007 on PostgreSQL and mark where context, decision, consequences and mitigation are each done well.
10 min	Teacher explains ADRs as code: discovery, review and supersession automation, the three dashboard widgets and the handover checklist.
30 min	Exercise: each participant drafts an ADR, then swaps with a neighbour for a review against the template.
10 min	Plenary on what the reviews found, closing with the summary point that an ADR takes minutes to write while the decision is fresh.

Discussion

Why does the chapter prefer a new superseding ADR to editing the original, and what would be lost by editing in place?
Which architecture decisions in your organisation would be impossible to reconstruct today because the people involved have moved on?
What makes a negative consequence worth writing down in a record that is meant to justify the decision?

Exercise · 30 minutes

Write and review an Architecture Decision Record

Choose a significant architecture decision that your own organisation has recently made or is about to make. Write it as an ADR following the chapter's structure: a sequential identifier and short title, status, context (problem statement, constraints, driving forces, affected stakeholders), decision (clear statement of choice and rationale), consequences split into positive and negative, and mitigation. Add the review metadata the chapter mentions, including the date of the last review and the date the next review is due, and note where the decision was discussed. Swap with a neighbour and review each other's record: is the negative side honest, and could a newcomer understand why the choice was made?

Deliverable: One complete ADR of about a page with front matter, the four core sections and mitigation, plus the neighbour's written review comments.

Self-test

What happens to the number of an ADR when the decision it records is replaced?
1. The number is released and reused for the next new decision
2. The successor takes over the number with a version suffix
3. The record is deleted and its number is retired from the log
4. The original keeps its number and a new ADR supersedes it
Where does the chapter, following the Lightweight Architecture Decision Records technique, recommend storing decision records?
1. In the organisation's wiki, where they are easiest to edit
2. In source control, so that they stay in sync with the code
3. In the minutes of the architecture review board
4. In a dedicated document management system for auditors
In the worked example ADR-0003, which negative consequence of choosing Terraform is recorded?
1. Complexity in state file management
2. No support for multiple clouds
3. An imperative syntax that conflicts with policy requirements
4. A small community with few available providers

Module 2 · Part B · Architecture Platform

Part B builds the technical platform that turns architectural intent into something checked on every change. The module covers CI/CD pipelines with their validation layers, promotion evidence and telemetry, architecture modelling with the C4 model and the Structurizr DSL, container platforms whose desired state is declared and reconciled, and microservice estates held together by contracts, golden paths and guardrails as code. Participants leave with a pipeline design, a C4 model, a guard rail plan and a service blueprint.

Lecture · 45 minutes

The platform that makes architecture checkable on every change

Part B argues that pipelines are where Architecture as Code stops being a description of intent. The lecture follows one architectural change through the platform: it is modelled once in a single source of truth, validated in layers that fail fast, promoted through environments with evidence attached, deployed to a container platform that reconciles declared and actual state, and governed in a microservice estate through contracts and reusable golden paths. The thread is the division of labour between Architecture as Code, which states what must be true before runtime, and Infrastructure as Code, which makes it so.

8 min	Which pipeline stage owns which decision Architecture as Code codifies what must be true before runtime; Infrastructure as Code consumes those policies to produce compliant infrastructure. The shift from infrastructure as pets to infrastructure as cattle made systematic automation possible. Pipeline telemetry flows upwards, so that architecture standards evolve with evidence rather than assumption.
10 min	Fail fast, promote with evidence Four validation layers: syntax and static analysis, security and compliance scanning, cost estimation, and policy validation. Promotion through environments is deterministic: template-driven parity, policy-controlled approvals and evidence bundles. Approvals belong on the protected environment, not in the pipeline definition, so authors cannot weaken a gate by editing the pipeline. Maintainability telemetry such as the pipeline stability index and policy breach density makes automation debt visible.
9 min	One model, many views The C4 model gives four levels of abstraction, each narrowing audience and scope. Diagram decay is the divergence that follows when diagrams are updated by hand; generating views from one model removes the manual step. The DSL holds the model and the views, the workspace JSON holds the manual layout, and both belong in version control.
9 min	Declared state and reconciliation The Kubernetes control plane continuously reconciles actual state with the declarations, enforcing Architecture as Code in real time. GitOps treats the Git repository as the source of truth, so a rollback is a reverted commit. Guard rails validate every manifest before production, and scheduled diffs detect drift that reconciliation alone does not explain.
9 min	Autonomy with guardrails in a microservice estate Each service is a bounded context whose architecture definition lives beside its code. Contract-first integration and an executable catalogue reveal coupling before it breaks consumers. Golden paths give autonomous teams approved defaults, and deviations are reviewed through decision records.

What the audience takes away

A pipeline for Architecture as Code validates applications, data, infrastructure, security and governance as one whole, and leaves evidence at every stage.
A single architecture model that generates its diagrams is the practical answer to diagram decay.
Declarative platforms and reusable golden paths let teams move independently while the architecture stays coherent and auditable.

Chapter 5 · 90 minutes

Automation, DevOps and CI/CD for Architecture as Code

The lesson shows how CI/CD pipelines make the whole architecture something that is checked on every change. It covers the division of automation responsibilities between Architecture as Code and Infrastructure as Code, pipeline design for regulated organisations including GDPR Article 25, the parallel tracks of an architecture pipeline, the four validation layers, progressive deployment strategies, environment promotion with evidence, and maintainability telemetry.

Learning objectives

Explain which pipeline decisions belong to Architecture as Code and which to Infrastructure as Code.
Describe the four validation layers of fail-fast feedback and what each detects.
Design an environment promotion ladder with mandatory evidence and automated enforcement for each environment.
Select maintainability signals and thresholds for a pipeline dashboard.

Key concepts

Fail-fast feedback and progressive validation: Errors are detected as early as possible through multilayer validation: syntax and static analysis, security and compliance scanning, cost estimation and budget validation, and policy validation, all before any infrastructure reaches production.
Architecture pipeline tracks: An Architecture as Code pipeline runs parallel tracks that converge at decision points: application architecture, data architecture, infrastructure architecture, security architecture and governance.
Data protection by design in the pipeline: The chapter reads GDPR Article 25 as requiring pipelines to validate data protection automatically: scanning for personal data patterns, enforcing encryption by default, validating data residency and generating an audit trail for every change.
Evidence bundle: The change set, policy reports and integration-test telemetry attached to each promotion, so that reviewers can confirm architectural parity without reconstructing the run. Bundles are archived for internal audit and retrospectives.
Maintainability telemetry: Signals such as the pipeline stability index, mean time to recovery for IaC rollbacks, policy breach density and architecture drift diff count, combined on dashboards with the five DORA software delivery metrics.

Teaching plan

15 min	Teacher presents the automation responsibilities table and the four principles for automating Architecture as Code, with the history from pets to cattle.
15 min	Walk through the regulated pipeline: Article 25, data discovery and classification, automated compliance validation and audit-trail generation.
15 min	Teacher explains the validation layers, the three deployment strategies and the promotion ladder with its evidence table.
35 min	Exercise in groups: design a promotion ladder and a telemetry panel for one system, then present it to another group for challenge.
10 min	Close on the balance between automation and human oversight for production deployments and compliance-critical changes.

Discussion

The chapter says approvals should be configured on the protected environment rather than in the pipeline definition. What risk does this remove, and who should administer those resources in your organisation?
Which of the three deployment strategies fits your most critical system, and what would have to be automated before you could use it?
What does it mean to treat automation debt with the same urgency as a production outage?

Exercise · 35 minutes

Design a promotion ladder with evidence

Take one system in your own organisation that handles personal data. Design its promotion ladder for development, staging and production. For each environment state the mandatory evidence and the automated enforcement, following the pattern of the chapter's table. Place the three test categories (unit, integration, compliance and resilience) as distinct jobs and say what each job blocks. Decide where the four validation layers run. Then choose three maintainability signals from the chapter, define how each is calculated for your system, and set one threshold-driven alert, for example on the pipeline stability index.

Deliverable: A promotion table for three environments with evidence and enforcement, a placement of test jobs and validation layers, and three telemetry signals with one alert threshold.

Self-test

Which GDPR article does the chapter cite for data protection by design and by default as a requirement on pipeline design?
1. Article 5
2. Article 17
3. Article 25
4. Article 32
According to the chapter's promotion table, what must be present before the traffic switch executes in production?
1. Explicit architect approval plus an uploaded policy-as-code attestation
2. A successful run of the validate-modules unit checks on the feature branch alone
3. A cost estimate that is lower than the previous release
4. A signed statement from the supplier of the cloud platform
How is policy breach density calculated in the chapter?
1. Count of manual overrides found by drift-detection jobs
2. Average time between a failed deployment and a successful rollback
3. Rolling proportion of successful runs in each environment
4. Failing policy checks divided by total runs in each environment

Chapter 6 · 90 minutes

Structurizr: Architecture Modelling as Code

The lesson teaches architecture modelling as code with the C4 model and the Structurizr DSL. It covers the four levels of abstraction and their audiences, diagram decay, the workspace with its model and views, the local, server and export commands, governance patterns for large workspaces, quality gates and manifest checks in CI/CD, the contribution workflow, and a comparison with traditional diagramming tools, PlantUML and Mermaid.

Learning objectives

Describe the four levels of the C4 model and the audience of each.
Explain why generating views from a single model prevents diagram decay.
Draft the structure of a workspace with people, software systems, containers and views.
Choose between Structurizr, Mermaid, PlantUML and drag-and-drop tools for a given scenario using the chapter's recommendation matrix.

Key concepts

C4 model: A hierarchical approach to software architecture diagrams with four levels: System Context, Container, Component and Code. Each successive level narrows the audience and scope, and the Code level is optional.
Diagram decay: The gradual divergence between architecture diagrams and the systems they represent when updates rely on manual effort. Model-based tooling answers it by generating diagrams from a single source of truth.
Workspace: model and views: A Structurizr workspace holds a model of people, software systems, containers, components and relationships, and a set of views that define which diagrams are generated from it. One model yields many consistent views.
DSL and workspace JSON: The DSL holds the model and view definitions, while the JSON file saved by the diagram editor holds the manual layout. Both are committed, so a diff on the JSON shows when an element moves.
Governance patterns for enterprise workspaces: A sequence for large workspaces: a domain folder structure, intent-revealing include files, centrally enforced naming conventions, documented relationship expectations and local validation before review.

Teaching plan

15 min	Teacher presents the C4 levels with their audiences and the reason the model fits Architecture as Code: hierarchical, technology agnostic, lightweight and composable.
15 min	Demonstration: the teacher builds a small workspace live, from person and software system to a container view, and shows the three commands local, server and export.
15 min	Teacher explains governance patterns, quality gates, the manifest digest check and the seven-step contribution workflow with dual review.
35 min	Exercise in pairs: model one system at the context and container levels and review another pair's model.
10 min	Close with the comparison tables and the recommendation matrix: when another tool is the better choice.

Discussion

The chapter's comparison gives drag-and-drop tools a lower learning curve. What does an organisation pay later for that convenience?
Why does the contribution workflow ask for dual review by a platform engineer and a product architect, and what would each miss alone?
Which capability metric from the adoption playbook would tell you earliest that modelling has become a heroic effort by one maintainer?

Exercise · 35 minutes

Model a system at two C4 levels

Choose a system from your own organisation. Write, in outline or in DSL, a workspace with one model: at least two kinds of people, the software system in scope, two neighbouring systems, and four to six containers with their technology and responsibilities. Describe every relationship with a verb phrase and a protocol, following the chapter's advice to document relationships. Define two views from the model, a System Context view and a Container view, and add tags that would let you filter external integrations. Finally write three naming rules a quality gate could check in the pipeline, and exchange models with another pair for review.

Deliverable: A workspace outline or DSL file with one model and two views, a list of three checkable naming rules, and the review notes from the other pair.

Self-test

Which C4 level illustrates how the software system in scope fits into its environment of users and neighbouring systems?
1. Component
2. System Context
3. Container
4. Code
Why does the chapter say both the DSL file and the workspace JSON belong in version control?
1. The JSON is an encrypted backup of the DSL
2. The JSON contains the licence needed to run the prebuilt server binaries
3. The DSL is generated from the JSON on every build
4. The DSL holds model and views, the JSON holds the manual layout
In the chapter's recommendation matrix, which tool is recommended for quick diagrams in a README?
1. Mermaid
2. Structurizr
3. PlantUML
4. Lucidchart

Chapter 7 · 60 minutes

Containerisation and Orchestration as Code

The lesson shows how container platforms express Architecture as Code at runtime. It covers images and registries defined as code, Kubernetes as a declarative orchestration layer whose control plane reconciles actual and declared state, service meshes, GitOps with Argo CD and Flux, the guard rails that validate manifests before production, proactive drift detection, and storage and data protection defined declaratively.

Learning objectives

Explain how the Kubernetes control plane enforces a declared architecture through reconciliation.
Describe the GitOps model and what it changes about rollback and audit.
List the guard rails that keep manifests trustworthy before they reach production.
Plan drift detection for a container platform beyond workload reconciliation.

Key concepts

Declarative orchestration: Kubernetes manifests capture the desired state for workloads, services and platform components. The control plane continuously reconciles the actual state with those declarations, which the chapter describes as enforcing Architecture as Code in real time.
GitOps: A practice that treats Git repositories as the source of truth. Continuous delivery tools such as Argo CD and Flux reconcile the declared state with running clusters when a pull request is merged; a rollback is a reverted commit.
Manifest guard rails: Schema and conformance checks in the pipeline, admission policies such as an OPA Gatekeeper constraint that prohibits privileged containers, image scanning and signing, so that every manifest is validated before it reaches production.
Service mesh as code: Meshes such as Istio and Linkerd provide a programmable data plane. Routing rules, mutual TLS, zero-trust access rules and traffic shaping such as retries and canary roll-outs are written as configuration and stored with the services.
Proactive drift detection: Scheduled comparisons of live configuration against Git, in addition to reconciliation loops, extended beyond workloads to backup jobs, storage policies and service mesh routes.

Teaching plan

15 min	Teacher presents containers, registries and Kubernetes as declared state, and explains the reconciliation loop on a whiteboard.
10 min	Read the two example manifests together: the Gatekeeper constraint against privileged containers and the Argo CD Application. Participants say what each one enforces.
10 min	Teacher covers service mesh, multi-cluster management, drift detection and declarative storage and backup.
20 min	Exercise: participants write a guard rail and drift plan for one cluster or platform.
5 min	Close with the transition the chapter makes: delivery speed creates security and governance demands that Part C answers.

Discussion

If the control plane already reconciles state continuously, why does the chapter still call proactive drift detection essential?
What changes for an incident team when a rollback becomes a matter of reverting a commit?
Which registry policies would you express as code first, and what would they stop from reaching production?

Exercise · 20 minutes

A guard rail and drift plan for a container platform

For a container platform in your own organisation, or one you plan, write a guard rail plan. List the checks that run before a manifest reaches production, in order: schema and conformance validation, policy checks, image scanning, signing and provenance. For each check name what it blocks and who owns the rule. State three admission policies you would enforce, starting with the prohibition of privileged containers used in the chapter. Then add a drift section: which scheduled comparisons run, against which source of truth, and what happens when a difference is found. Include one control outside workloads, such as backups or mesh routes.

Deliverable: A one-page plan listing ordered pre-production checks with owners, three admission policies, and a drift detection schedule with a response for each finding.

Self-test

What does the example OPA Gatekeeper constraint in the chapter prohibit?
1. Unsigned images
2. Privileged containers
3. Deployments without resource requests
4. Services exposed outside the cluster
In the GitOps model the chapter describes, how is a rollback performed?
1. By restoring the cluster from the latest volume snapshot
2. By editing the live resources directly and recording the change afterwards in Git
3. By reverting the commit, after which the tool reconciles the cluster
4. By disabling the reconciliation controller until the fix is ready
Which tools does the chapter name as exposing cloud resources as custom resource definitions, so that they are provisioned through the same API as workloads?
1. Crossplane and the Operator Framework
2. Helm and Docker Compose
3. Podman and kubeconform
4. Istio and Linkerd

Chapter 8 · 75 minutes

Microservices Architecture as Code

The lesson applies Architecture as Code to microservice estates. It covers bounded contexts mapped to repositories, contract-first integration with API specifications and event schemas as code, golden paths built from reusable modules, policy-aware pipelines and maintainability guardrails, the executable catalogue and coupling telemetry, escalation playbooks, data ownership with the saga and event sourcing patterns, resilience testing as code, and migration from monoliths with feature flags.

Learning objectives

Explain how bounded contexts, contracts and golden paths keep a federated estate coherent.
Design the repository layout of a service so that architecture, infrastructure and evidence travel together.
Describe how an executable catalogue reveals coupling hotspots.
Compare the saga and event sourcing patterns for data across service boundaries.

Key concepts

Bounded context mapped to a repository: Each microservice is treated as a bounded context with a defined purpose, data contract and operational envelope. Its architecture definition is stored beside the application code and IaC modules, so that diagrams, manifests and compliance evidence travel together.
Contract-first integration: API specifications and event schemas are declared as code, for example with OpenAPI or AsyncAPI, and registered in an architecture catalogue. Automated linting checks backwards compatibility and alerts owners when downstream consumers would break.
Golden paths: Shared Terraform modules, Helm charts and service mesh policies that encode approved defaults for security, observability and networking. Pipelines verify that services consume the authorised modules, and deviations are reviewed through architecture decision records.
Coupling telemetry: An executable catalogue indexes every API specification, event schema and data contract, derives dependency graphs after each merge, and flags hotspots where a service has many synchronous consumers or repeatedly changes its schema.
Saga: A pattern that breaks a long-running business transaction into a sequence of local transactions, each publishing an event or message that triggers the next step. If a step fails, compensating transactions reverse the completed steps.

Teaching plan

15 min	Teacher presents the three architectural principles for federated teams and the reference repository layout of a service.
15 min	Case discussion: a merge request introduces an illegal dependency. Participants trace what the pipeline, the catalogue and the escalation playbook each do.
10 min	Teacher explains data ownership, saga and event sourcing, compliance by default and resilience testing as code.
30 min	Exercise in groups: write a service blueprint and present the boundary rules to the room.
5 min	Close on migration from monoliths: executable target boundaries, phased cut-overs and feature flags.

Discussion

The chapter warns against accidental monoliths. What signs in your own estate suggest that services share data they should consume through documented interfaces?
When a policy gate fails repeatedly, the chapter lets an architecture council review whether the guardrail or the service boundary needs to change. How would you decide which?
What would it take for teams to experience golden paths as help and not as constraint?

Exercise · 30 minutes

A service blueprint with boundary rules

Pick one service, existing or planned, in your own organisation. Write its blueprint as the chapter structures a service repository: purpose and data it owns, the API specification and event schemas it publishes, the shared modules it consumes from the golden path, its decision records, dashboards, alert routing and runbooks. Then codify three boundary rules in plain language that a policy engine could check, choosing among permitted dependency directions, latency budgets between domains and data residency constraints. For each rule write the escalation: who is alerted when the check fails, with which link, and within what resolution timeframe. Name one failure injection experiment and its expected outcome.

Deliverable: A two-page service blueprint with repository layout, published contracts, three checkable boundary rules with escalation, and one resilience experiment.

Self-test

In the saga pattern as the chapter describes it, what happens if one step fails?
1. The whole transaction is retried from the first step
2. A distributed lock holds all services until an operator intervenes
3. The failed step is skipped and reported at the end
4. Compensating transactions reverse the steps already completed
What should a pipeline verify about golden paths, according to the chapter?
1. That each team has written and versioned its own modules for security, observability and networking
2. That each service consumes the authorised modules and deviations go through decision records
3. That golden paths are optional for services with fewer than three consumers
4. That every service uses the same programming language and framework
Which hotspot does the chapter say the executable catalogue should flag?
1. A service with many synchronous consumers or a repeatedly changing schema
2. A service whose repository has more than one maintainer
3. A service that publishes events instead of exposing an API
4. A service that is deployed to production more often than the average for the estate

Module 3 · Part C · Security, Governance & Assurance

Part C shows how security, policy, governance, compliance and evidence become code that runs on every change. The module moves from Zero Trust and threat modelling through advanced security patterns, risk registers and threat playbooks in the repository, Open Policy Agent and OSCAL, pull-request governance, the compliance loop with its Control Mapping Matrix, and machine-generated evidence. Participants leave with a threat model, a risk definition, policy rules, a governance workflow, a control mapping and an evidence manifest.

Lecture · 50 minutes

Assure once, comply many: security, governance and evidence as code

Part C argues that controls written in natural language and checked by hand cannot keep pace with continuous delivery. The lecture follows one control objective, multi-factor authentication for human identities, through the whole part: it is motivated by Zero Trust and threat modelling, tied to a risk definition, written as a policy, approved through a pull request, mapped once to several frameworks in a Control Mapping Matrix, and proven by evidence that the pipeline generates and signs. The principle that holds the part together is assure once, comply many.

8 min	From perimeter to Zero Trust The hard shell, soft centre model fails when workloads, staff and service-to-service calls are spread across clouds and home networks. Never trust, always verify becomes trust as code when segmentation, mesh rules and identity configuration are declared and enforced consistently. STRIDE must be applied to infrastructure definitions, pipelines and secrets management, not only to the application.
8 min	Patterns that run on every change Infrastructure state holds inventories and secrets, so it needs a remote backend, locking, encryption, versioning and monitored access. Risk registers and threat playbooks belong in the repository: a risk has an owner and a review date, and a playbook subscribes, assesses, acts and documents. Exceptions are code artefacts with explicit expiry dates and approval chains.
10 min	Policy engines and a language for controls Security management matured through four phases, from manual validation to holistic governance frameworks. Open Policy Agent enforces policies; OSCAL describes controls, evidence and assessments in machine-readable form. Policies are themselves tested, positively and negatively, before they gate anyone else's work.
8 min	Governance through pull requests Draft, review, validation, documentation and production stages give governance artefacts an explicit state and a formal audit trail. Governance professionals keep ownership through repository roles, training, pairing and low-code tooling. Six metrics, from policy coverage to remediation lead time, show whether automated controls can be relied upon.
8 min	The compliance loop and one matrix Regulatory intelligence, policy templates, automated controls, evidence collection and governance reinforcement form a closed loop. The Control Mapping Matrix links one control identifier to its assurance artefacts and to every framework it satisfies. The worked control SEC-ID-001 executes once and satisfies several attestations.
8 min	Evidence as the currency of trust Evidence is captured deterministically from automated checks, not manual screenshots, and links back to commits and pull requests. A software bill of materials and signed provenance make the supply chain verifiable without taking the producer's word. Evidence has a lifecycle from capture to expiry, with access control on the store itself.

What the audience takes away

A control that is expressed, tested and evidenced once can be mapped to many obligations, which is what reduces audit fatigue.
Risk, threat handling, policy and governance approvals become reviewable and testable when they live in the same repository as the architecture.
Machine-generated, signed and versioned evidence turns compliance from a periodic reconstruction into a continuous by-product of delivery.

Chapter 9 · 90 minutes

Security Fundamentals for Architecture as Code

The lesson establishes security as code. It covers the four dimensions of security in Architecture as Code, the shift from perimeter protection to Zero Trust Architecture, threat modelling with STRIDE applied to infrastructure and pipelines, continuous risk assessment, Policy as Code with shift-left enforcement, the secrets lifecycle, data classification, the protection of infrastructure state, micro-segmentation and service mesh security, and security maturity models.

Learning objectives

Explain the shift from perimeter protection to Zero Trust Architecture and what trust as code means.
Apply the six STRIDE categories to infrastructure definitions, pipelines and secrets management.
Describe the stages of the secrets lifecycle and why infrastructure state is a sensitive artefact.
Break a high-level control objective into declarative assertions that can be executed in a pipeline.

Key concepts

Zero Trust Architecture: Security thinking guided by the principle never trust, always verify: every user, device and network transaction is validated explicitly regardless of location or prior authentication. Declared in code, it yields what the chapter calls trust as code.
STRIDE for code-based architectures: A structured framework of six threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege. In Architecture as Code it must also cover infrastructure definitions, deployment pipelines, secrets management and runtime environments.
Continuous risk assessment: Risk evaluation embedded in the development life cycle through automated tooling and policy engines, so that every infrastructure change is assessed before deployment. Blast radius can be calculated automatically from dependency mapping.
Secrets lifecycle management: Management of secrets from generation through distribution, rotation and retirement, with automated generation, delivery through secure channels or runtime injection, and central storage encrypted in transit and at rest.
Micro-segmentation: Granular, application-aware network control in which traffic policies use application identity, user context and data classification, reducing opportunities for lateral movement compared with traditional VLANs or subnets.

Teaching plan

15 min	Teacher presents the four security dimensions and the paradigm shift from hard shell, soft centre to Zero Trust.
20 min	Walk through the STRIDE table. For each category participants add one concern from their own delivery pipeline, and the teacher adds supply chain and insider threats.
15 min	Teacher covers Policy as Code and shift-left enforcement, secrets, data classification, state protection and network segmentation.
30 min	Exercise in groups: a STRIDE threat model of a delivery pipeline, with countermeasures as code.
10 min	Groups compare their highest-ranked threat. Close with the NIST Cybersecurity Framework 2.0 functions and the place of Govern.

Discussion

The chapter argues that manual security reviews as gateways frustrate teams and delay releases. What has to be automated before a security team can credibly act as an enabler?
Why does threat modelling for Architecture as Code have to include the CI/CD pipeline and the automation tooling as attack surfaces?
Where does human judgement remain essential in data classification, according to the chapter, and how would you combine it with automated discovery?

Exercise · 30 minutes

A STRIDE threat model of a delivery pipeline

Take the pipeline that deploys infrastructure for one system in your own organisation. Draw its main elements: repository, pipeline runner, secrets store, state backend and target environment. For each of the six STRIDE categories identify at least one threat against these elements, using the concerns in the chapter's table as prompts, for example malicious commits to infrastructure code or secrets in repositories. Rank the threats and choose the three most serious. For each of the three, write one countermeasure as a declarative assertion that a pipeline or runtime monitor could check, and say what evidence the check would leave. This is a design exercise on your own systems only.

Deliverable: A threat table covering all six STRIDE categories and three countermeasures written as checkable assertions with the evidence each would produce.

Self-test

Which guiding principle does the chapter give for Zero Trust Architecture?
1. Trust the internal network, verify the external one
2. Never trust, always verify
3. Verify once at the perimeter, then trust the session
4. Trust owned devices
In the chapter's STRIDE table, which concern is listed under Repudiation?
1. Secrets stored in code repositories
2. Stolen credentials for a service account
3. Resource exhaustion through misconfiguration
4. Missing version control history and untracked deployments
Why does the chapter say infrastructure state files must be treated as sensitive artefacts?
1. They capture live inventories, secrets and enforced policy decisions
2. They are the only copy of the application source code
3. They are required by auditors in their original, unmodified binary form
4. They cannot be regenerated once a deployment has completed

Chapter 9B · 75 minutes

Advanced Security Patterns and Implementation

The lesson turns the security principles into patterns that run on every change. It covers security orchestration and automated incident response, the use of AI and machine learning in detection together with the need to protect those systems, multi-cloud policy and identity federation, security observability measures, the secure state management pattern with its monitoring rules, a security foundation module, and GDPR Article 32 expressed as policy.

Learning objectives

Describe how security orchestration integrates with Architecture as Code to give infrastructure-level responses.
Specify the controls of the secure state management pattern for a remote backend.
Define monitoring rules that detect anomalous access to infrastructure state.
Select indicators that measure the effectiveness of a security programme.

Key concepts

Security orchestration, automation and response: Platforms that turn incident handling into automated workflows with predefined playbooks for containment, evidence collection and notification. Integrated with Architecture as Code, compromised components can be isolated or redeployed from known-good definitions.
Secure state management pattern: Standardising on encrypted remote backends with customer-managed encryption keys, lockfile or blob-lease locking and object versioning for forensic recovery, codified in modules and policy checks so that every workspace inherits the verified practice.
State access monitoring rules: Alerts on repeated state initialisation attempts without a change request, manual state downloads or unlock operations outside approved pipeline identities, and versioning churn or deletions outside scheduled maintenance windows.
Security observability indicators: Quantitative measures of programme effectiveness: mean time to detect, mean time to respond, false positive ratios, control coverage and compliance drift.
Algorithm agility: The ability to change cryptographic algorithms, which the chapter asks organisations to build into Architecture as Code frameworks in preparation for quantum-resistant cryptography.

Teaching plan

15 min	Teacher presents the advanced patterns: orchestration, AI and machine learning in detection, multi-cloud policy and observability indicators.
15 min	Walk through the state management pattern: remote backend, locking, encryption keys, versioning, key custodianship and telemetry to the governance dashboard.
10 min	Read the description of the security foundation module and the Article 32 policy example, and identify what each automates.
30 min	Exercise: participants write a state protection standard with monitoring rules and a response for each alert.
5 min	Close on the chapter's strategic recommendations: collaboration forums, skills and continuous improvement.

Discussion

Automated containment can isolate or redeploy a component within minutes. Which responses in your organisation should stay with a person, and what makes them different?
The chapter says organisations must also defend the AI systems used for detection. What would that mean for a model that flags anomalous access?
Why is it not enough to encrypt infrastructure state, and what does monitoring of access add?

Exercise · 30 minutes

A state protection standard with monitoring rules

Write a one-page standard for the infrastructure state of your own organisation, following the chapter's pattern. State where state is stored and why not on workstations, how it is locked during writes, how it is encrypted and who is custodian of the key, how rotation and break-glass decryption work, and how versioning supports forensic recovery. Then write three monitoring rules based on the chapter's examples: initialisation attempts without a change request, manual downloads or unlocks outside pipeline identities, and deletions outside maintenance windows. For each rule give the alert destination and the automated or manual response. Finish with two policy checks a pipeline should run against every workspace.

Deliverable: A one-page state protection standard with key management decisions, three monitoring rules with responses, and two pipeline policy checks.

Self-test

Which GDPR article does the chapter's Open Policy Agent example translate into automated checks?
1. Article 6
2. Article 15
3. Article 32
4. Article 44
Which of these does the chapter list as a signal that should raise an alert on a state backend?
1. Manual state downloads outside approved pipeline identities
2. A pipeline run that completes faster than the weekly average
3. A state file that grows after new resources are added
4. A key rotation that follows the documented cadence
What does integrating orchestrated incident response with Architecture as Code make possible, according to the chapter?
1. Removing the need for threat intelligence feeds
2. Replacing tamper-evident audit logging with automated summaries of each incident
3. Skipping post-incident evidence collection
4. Isolating or redeploying compromised components from known-good definitions

Chapter 9C · 60 minutes

Risk as Code and Threat Handling as Code

The lesson extends the repository to risk registers and threat playbooks. It covers why risk and threat handling belong in the codebase, risk definitions as declarative documents validated in CI, metrics as code, exceptions with expiry dates, threat intelligence ingestion, threat models generated from the codebase, response playbooks as state machines with four duties, continuous exercising through security chaos engineering, and the operating model with risk stewards.

Learning objectives

Explain the four benefits of keeping risk and threat handling in the codebase.
Draft a risk definition with context, probability, impact, ownership and review date.
Describe a response playbook as a state machine with the four duties the chapter lists.
Outline how risk and threat artefacts are integrated into pull requests, CI, delivery gates and dashboards.

Key concepts

Risk as code: Risk definitions structured as declarative YAML or JSON documents that capture context, probability, impact and ownership. The schema is a contract that tooling validates in pull requests, rejecting missing data, outdated review dates or invalid owners.
Time-bound exception: An exception that is itself a code artefact with an explicit expiry date and approval chain. Deployments may proceed only when every high or critical risk is mitigated by automated controls or covered by such an exception.
Playbook as a state machine: Incident response expressed as a workflow in which each state is a containment or eradication step with guard conditions, rollback logic and evidence capture. A playbook should subscribe to signals, assess risk ratings, act and document.
Security chaos engineering: Automated scenarios that inject simulated breaches or infrastructure failures on a schedule or after configuration changes, validating that playbooks execute correctly. Findings become backlog items captured as code changes.
Risk steward: A product-aligned owner who approves updates to risk artefacts through code reviews, so that accountability remains close to the delivery teams.

Teaching plan

10 min	Teacher presents why risk management as paperwork fails and the four benefits of the codebase: traceability, consistency, speed and learning loops.
15 min	Read the example risk document and discuss which fields a CI check should reject. Teacher explains metrics as code and exceptions.
10 min	Teacher explains threat handling: structured intelligence ingestion, generated threat models, playbooks and chaos drills.
20 min	Exercise in pairs: write a risk definition and the playbook that responds to it.
5 min	Close on culture: celebrate the remediation pull request, not only the discovery.

Discussion

The chapter says automated pipelines remove subjective scoring from risk evaluation. What judgement remains with the people who write the risk definitions?
What would change in your organisation if a failing control metric failed the pipeline and forced remediation before release?
How would you keep exceptions from becoming permanent once they are written as code with expiry dates?

Exercise · 20 minutes

A risk definition and its response playbook

Choose one real resilience or security risk for a system in your own organisation. Write it as a structured risk definition with an identifier, category, context, probability, impact, owner, the controls that mitigate it, the metric that shows the control is healthy and a review date. State which missing or stale fields should make a CI check reject the document. Then describe the response playbook for this risk as a state machine: the signal it subscribes to, how it assesses the rating from the risk catalogue, the action it takes (for example revoking credentials or isolating a workload), its rollback logic, and what it documents. Name one chaos drill that would exercise the playbook.

Deliverable: One risk definition in structured form with validation rules, a four-state playbook description, and one drill scenario.

Self-test

Under the governance logic the chapter gives as an example, when may a deployment proceed?
1. When the risk steward is on call during the deployment window
2. When all risks have been reviewed in the past twelve months
3. When every high or critical risk is mitigated automatically or has a time-bound exception
4. When the total number of open risks in the catalogue is lower than it was at the previous release
Which four duties should a response playbook fulfil, in the chapter's order?
1. Subscribe, assess, act, document
2. Detect, escalate, restore, close
3. Plan, do, check, adjust
4. Identify, protect, respond, recover
In what structured formats does the chapter say threat intelligence feeds should be ingested?
1. OSCAL and SPDX
2. STIX and TAXII
3. OpenAPI and AsyncAPI
4. CycloneDX and SLSA

Chapter 10 · 75 minutes

Policy and Security as Code in Detail

The lesson examines Policy as Code in detail. It covers the four phases through which security automation matured, Open Policy Agent and the Rego language with three architectural patterns for enterprise policy management, OSCAL with its catalogues, profiles, component definitions and System Security Plans, the tagging of policies with framework metadata under the assure once, comply many mindset, and a five-step implementation roadmap.

Learning objectives

Describe the four phases in the evolution of security management and the limitation of each.
Explain the three architectural patterns for enterprise policy management with Open Policy Agent.
Distinguish the four OSCAL models and what each contributes to audit evidence.
Sequence a Policy as Code programme using the chapter's five-step roadmap.

Key concepts

Policy as Code: Governance requirements expressed as version-controlled code, giving traceability, repeatability, peer review, automated testing and rapid rollback. It removes the delay of manual approvals and paper-heavy audits.
Open Policy Agent and Rego: A widely adopted policy engine with a declarative language built for rules over structured data. Decisions are evaluated locally, so the same rules run in unit tests and enforce guardrails in Kubernetes, Terraform pipelines or API gateways.
Decoupled evaluation, flexible distribution, bundle packaging: Three enterprise patterns: the engine runs as sidecar, admission controller or CLI verifier separate from applications; agents pull signed bundles or receive pushed updates; policies, data, metadata and signatures are packaged together for atomic roll-outs and rollbacks.
OSCAL: The Open Security Controls Assessment Language, developed by NIST, which describes controls, evidence and assessment data in machine-readable formats. It acts as the translation layer between Terraform states, pipeline runs and external auditors.
System Security Plan: The OSCAL model that assembles controls, components and operational context into a single auditable document connecting requirements to implementation. The chapter shows it generated automatically from Terraform and component definitions.

Teaching plan

15 min	Teacher presents the four phases from manual validation to holistic governance frameworks. Participants place their own organisation in a phase and say why.
15 min	Teacher explains Open Policy Agent, the three architectural patterns and the structure of a policy module covering encryption, segmentation and residency.
10 min	Walk through the OSCAL table: catalogues, profiles, component definitions and System Security Plans, with the financial institution example.
30 min	Exercise in groups: a policy inventory and pilot plan following the roadmap.
5 min	Close on the first key takeaway: governance as a continuous safety net that keeps pace with daily releases.

Discussion

Scripted automation improved speed but brought duplication and brittle scripts. What does a dedicated policy engine change about ownership of the rules?
Why does a programme need a language for describing controls and evidence in addition to an engine that enforces policies?
The roadmap begins with an inventory of manual controls. Which of yours would you automate first, and what would you measure in the pilot?

Exercise · 30 minutes

Policy inventory and pilot plan

Follow the first three steps of the chapter's roadmap for your own organisation. Step one: list eight existing manual controls, mark overlaps and rank them by risk, for example public exposure of administrative ports. Step two: choose two controls for a pilot in a non-production pipeline. Write each as a rule in plain structured language: the input it inspects, the condition that is a violation, the message it returns and a control identifier. Say which metric of prevented misconfigurations you will capture. Step three: for each pilot rule, name the catalogue entry or framework requirement it maps to and what a profile for your organisation would need to add.

Deliverable: A ranked inventory of eight controls, two pilot rules in structured form with identifiers and a pilot metric, and a mapping of each rule to a catalogue entry.

Self-test

Which OSCAL model tailors catalogues to an organisation's specific needs by selecting, modifying or adding control language?
1. Component definitions
2. System Security Plans
3. Assessment results
4. Profiles
What limitation does the chapter assign to Phase 2, scripted automation?
1. Findings were logged manually weeks after release
2. Duplication, drift and brittle scripts that were hard to share
3. Policy languages were too declarative for engineers
4. Audit evidence was produced continuously but never used
What is the first step of the chapter's implementation roadmap?
1. Policy inventory of existing manual controls
2. Operational integration with security operations
3. Evidence harmonisation with OSCAL catalogues
4. Pilot automation in a production pipeline

Chapter 11 · 75 minutes

Governance as Code

The lesson treats governance itself as code. It covers the assure once, comply many principle, the five-stage approval workflow for governance artefacts built on pull requests, the competency gaps that appear when governance professionals move into repositories and how to close them, tooling for non-developers, policies for encryption at rest and tag compliance evaluated against a plan and tested in CI, and six metrics of governance effectiveness.

Learning objectives

Explain the assure once, comply many principle and why it reduces audit fatigue.
Design a pull-request-based approval workflow for governance artefacts with stakeholders and automated controls per stage.
Identify competency gaps in a governance-as-code transition and choose enablement measures.
Select governance effectiveness metrics with targets.

Key concepts

Assure once, comply many: The principle that governance guardrails are expressed, tested and evidenced once, then reused across frameworks such as ISO 27001, SOC 2, NIST 800-53, GDPR and internal control catalogues.
Governance workflow stages: Draft and proposal on feature branches, review and approval through pull requests with templates, validation and testing in the CI pipeline, documentation and traceability through ADR linking, and production deployment by merge to a protected main branch.
Competency gaps in transition: The skills governance owners, risk managers and compliance leads lack when work moves into repositories. The chapter answers with explicit repository roles, targeted training, pairing with engineers and starting with low-risk components.
Tooling for non-developers: Low-code policy editors that generate policy language from guided forms, template-driven pull requests, documentation portals, chat integrations for review and approval, and automated policy explainers in natural language.
Governance effectiveness metrics: Policy coverage (at least 95 per cent), policy pass rate (at least 90 per cent), time to policy adoption (at most 5 business days), exception rate (decreasing), audit readiness score (at least 80 per cent) and remediation lead time (at most 48 hours).

Teaching plan

10 min	Teacher presents the governance pipeline around a single repository and the assure once, comply many principle.
15 min	Walk through the five workflow stages. Participants role-play a pull request for a new tagging policy as policy author, security officer and business sponsor.
15 min	Teacher covers competency gaps, tooling for non-developers, the two policy examples and the testing of policies with a test runner.
25 min	Exercise: design the approval workflow and the metric set for one governance artefact.
10 min	Plenary: which targets are realistic today, and what the backlog of state backend controls shows about sequencing.

Discussion

How can a pull request give a more formal audit trail than a signed approval document, and what must be configured for that to hold?
The chapter keeps governance owners' expertise at the centre by giving them folders and review rights. What would they need before they could use those rights with confidence?
Why must governance policies themselves be tested, and what could go wrong with an untested policy that blocks or passes everything?

Exercise · 25 minutes

An approval workflow for one governance artefact

Choose one governance rule from your own organisation, for example that all storage must be encrypted at rest with an approved key, or that every resource carries tags for owner and cost centre. Design its journey through the chapter's five stages. For each stage name the mechanism, the stakeholders, the automated controls and the outcome. Write the pull request template fields a reviewer must see, including risk assessment and the mapping to control identifiers. Describe one positive and one negative test case for the policy. Finally pick three of the six effectiveness metrics, set a target for each and say where the data comes from.

Deliverable: A five-row workflow table for the chosen rule, a pull request template outline, two policy test cases, and three metrics with targets and data sources.

Self-test

What target does the chapter set for time to policy adoption, from proposal to production merge?
1. At most 48 hours
2. At most 30 calendar days
3. At most 5 business days
4. At most one quarter
Which mechanism does the chapter assign to the review and approval stage of the governance workflow?
1. Feature branches
2. Pull requests with templates
3. A merge to the protected main branch
4. A quarterly meeting of the governance board
How does the chapter recommend staging the transition to Governance as Code?
1. Move all critical controls first to prove the value quickly
2. Migrate one regulatory framework at a time in order of audit date
3. Wait until every governance professional has completed training
4. Start with low-risk governance components and scale after feedback

Chapter 12 · 60 minutes

Compliance and Regulatory Adherence

The lesson covers the organisational and process side of compliance. It presents the five-stage compliance loop from regulatory intelligence to governance reinforcement, the role of AI as a triage layer under human oversight, requirements traceability from regulatory statement to test, the Control Mapping Matrix with the worked control SEC-ID-001, compliance for serverless and edge workloads, and the forward-looking topics the chapter marks as speculative.

Learning objectives

Describe the five stages of the compliance loop with the outputs and feedback of each.
Explain how the Control Mapping Matrix puts assure once, comply many into operation.
Trace a compliance requirement through functional control, code artefact and verification activity.
Distinguish current-state requirements from the topics the chapter labels as speculative.

Key concepts

Compliance loop: A closed feedback loop of five stages: regulatory intelligence, policy template creation, automated control execution, monitoring and evidence collection, and governance reinforcement, which informs the next cycle of regulatory intelligence.
Control Mapping Matrix: One reusable matrix that links each control identifier to the assurance artefacts captured in CI and to the external frameworks they satisfy, replacing bespoke spreadsheets for each framework.
Requirements traceability: Demonstrable links from business, compliance, performance and cost requirements to functional controls such as encryption, network segmentation and audit logging, to the Terraform configuration that implements them and the test suites that validate them.
AI as a triage layer: An AI compliance engine that ingests telemetry, policy breaches and regulator feedback to classify incidents, enrich them with evidence and recommend automation or escalation paths, with human oversight in the loop.
Crypto-agility baseline: A configuration that still relies on classical algorithms but keeps keys and certificates rotatable, so that post-quantum alternatives can be adopted when services expose them. The chapter files quantum readiness under speculative considerations.

Teaching plan

15 min	Teacher presents the compliance loop stage by stage, with activities, outputs and feedback mechanisms.
10 min	Work through the matrix row for SEC-ID-001: which artefacts, which framework references, and what the Internal column records.
10 min	Teacher covers traceability, the AI triage layer, serverless and edge controls, and the two topics marked speculative.
20 min	Exercise: participants build three rows of a Control Mapping Matrix for their own organisation.
5 min	Close with the bridge to evidence: the matrix references artefacts that the pipeline must actually produce.

Discussion

Which stage of the compliance loop is weakest in your organisation, and what breaks downstream because of it?
The chapter limits the AI layer to triage and keeps human oversight in the loop. What tasks would you be comfortable assigning to it, and which not?
What is gained by labelling quantum readiness and sustainability as speculative instead of writing them into today's control baseline?

Exercise · 20 minutes

Three rows of a Control Mapping Matrix

Build a small Control Mapping Matrix for your own organisation using the chapter's columns: control identifier, control title, assurance artefacts, the external frameworks your organisation must satisfy, and the internal catalogue entry. Write three rows for three different controls, for example multi-factor authentication for human identities, encryption at rest and audit logging. For every row name the artefact a pipeline could generate as proof and where it would be stored. Use only framework references you can verify in your organisation's own control catalogue; where you cannot verify a reference, leave the cell marked as to be confirmed instead of guessing. Then trace one row backwards to the requirement it serves and forwards to the test that validates it.

Deliverable: A three-row matrix with artefacts and verified or to-be-confirmed framework references, plus one written trace from requirement to verification.

Self-test

Which control does the worked matrix row SEC-ID-001 record?
1. Enforce MFA for human identities
2. Encrypt all storage at rest
3. Restrict workloads to EU regions
4. Rotate customer-managed keys annually
What closes the compliance loop in the chapter's model?
1. The regulator signs off the complete evidence package at the end of every quarter
2. Automated controls delete non-compliant resources
3. Governance reinforcement informs the next regulatory intelligence cycle
4. The policy templates are archived after each audit
How does the chapter characterise its section on quantum computing readiness and green computing?
1. As mandatory controls for all regulated organisations today
2. As forward-looking, exploratory guidance and not current-state requirements
3. As topics outside the scope of Architecture as Code
4. As requirements that apply only to public authorities

Chapter 15A · 75 minutes

Evidence as Code and Continuous Assurance

The lesson shows how the proof of compliance is generated by the delivery pipeline. It covers the four characteristics of machine-collected evidence, a pipeline job that exports multi-factor authentication evidence with a manifest, the software bill of materials and vulnerability reports as evidence, SLSA provenance and image signing as tamper-evident attestation, and the evidence lifecycle from capture to expiry with access control.

Learning objectives

Describe the four characteristics of machine-generated evidence and why deterministic capture is preferable to manual attestation.
Design a pipeline job that produces, packages and publishes an evidence bundle with framework metadata.
Explain what a software bill of materials and a provenance attestation each prove.
Plan the lifecycle of an evidence artefact from capture to expiry.

Key concepts

Evidence as Code: The artefacts that prove compliance are generated automatically, stored alongside the controls they verify and versioned so that their provenance is unquestionable. The chapter calls evidence the currency that lets Architecture as Code demonstrate trustworthiness at scale.
Deterministic capture: Evidence is generated from automated checks, not manual screenshots. Together with traceability to commits and pull requests, reusability through framework metadata and version control, it is one of the four key characteristics.
Evidence manifest: A file produced by the pipeline job that links evidence artefacts to control identifiers and framework mappings. Governance and compliance teams consume it instead of requesting bespoke proof.
Software Bill of Materials: A machine-readable inventory of every component, library and dependency in a software artefact, produced for example in CycloneDX or SPDX format. The chapter notes that the EU Cyber Resilience Act, Regulation (EU) 2024/2847, increasingly requires producers to generate one.
SLSA provenance attestation: A signed record of the build platform, the external parameters that defined the build, the resolved dependencies and the output digests, letting consumers verify an artefact's build chain without trusting the producer's word alone.

Teaching plan

10 min	Teacher introduces evidence as currency and the four characteristics, contrasting them with screenshots collected at audit season.
15 min	Walk through the MFA pipeline example: the test step that gates the job, the evaluation step that produces the evidence, and the manifest with its mappings.
15 min	Teacher explains the bill of materials, vulnerability reports as evidence, provenance, image signing and admission control that admits only signed images.
30 min	Exercise: design an evidence bundle and its lifecycle for one control.
5 min	Close on the structural shift: compliance as a continuous by-product of delivery.

Discussion

The pipeline example separates the step that tests the policy from the step that produces the evidence. Why does that separation matter to an auditor?
Evidence value erodes if consumers cannot verify how it was produced. Who are the consumers of your evidence, and what would each need to verify?
What are the risks of keeping evidence too briefly and of keeping it without limit, and who should decide the retention period?

Exercise · 30 minutes

An evidence bundle and its lifecycle

Choose one control in your own organisation that a pipeline could verify, for example multi-factor authentication for human identities or image signing. Design the pipeline job that proves it: the inputs it reads, the check that gates the job, the evaluation that produces the evidence, and the files it writes. Draft the evidence manifest in outline: control identifier, artefact paths, commit reference, environment, timestamp and the frameworks the evidence supports. Then complete a lifecycle table for the bundle with the chapter's stages: capture, packaging, storage, indexing, retrieval, expiry and access control. For each stage state the activity and who may write, read and delete.

Deliverable: A job design, a manifest outline with the listed fields, and a seven-row lifecycle table with access rules for the evidence store.

Self-test

Which of these is one of the four key characteristics of Evidence as Code in the chapter?
1. Annual attestation signed by the control owner
2. Screenshots taken by compliance staff
3. Deterministic capture from automated checks
4. Evidence stored separately from the controls it verifies
What does a SLSA provenance attestation record?
1. The retention period, storage location and expiry date of each evidence file in the catalogue
2. The list of auditors who have accessed the evidence store
3. The licence terms of every dependency in the artefact
4. Build platform, external parameters, resolved dependencies and output digests
In the evidence lifecycle table, what happens at the indexing stage?
1. The artefact is signed with a key held in a hardware module
2. The manifest is registered in an evidence catalogue for audit queries
3. The pipeline step produces the artefact from an automated check
4. Artefacts past their retention period are archived or deleted

Module 4 · Part D · Delivery & Operations

Part D connects the technical capabilities to delivery and operations. The module covers the test pyramid for codified infrastructure, the adoption roadmap from discovery to optimisation with its resilience checklist, cost as a property of the architecture governed through FinOps, and migration from manually configured infrastructure as a sequence of small, reversible steps. Participants leave with a test strategy, a pilot plan with a completed resilience review, a cost governance design and a migration wave plan.

Lecture · 45 minutes

Testable, recoverable, affordable: delivering Architecture as Code in practice

Part D asks what it takes to run Architecture as Code as an everyday delivery practice. The lecture argues that four questions must be answerable for every change: how it is tested before anything is deployed, how the organisation adopts the practice in stages without overwhelming teams, what the change costs and who sees that cost in the pipeline, and how the estate that is still managed by hand shrinks step by step. The common thread is that every change request must show how it stays testable, recoverable and reversible.

10 min	The test pyramid for codified infrastructure Infrastructure testing targets configuration, resource compatibility and environmental consistency, not business logic. Unit tests run without deploying anything; mocks and built-in test frameworks have narrowed the gap between programmatic and declarative tools. Policy engines act preventively in the pipeline, while detective rules evaluate resources after deployment. Start with security scanning and policy testing, and add end-to-end tests where the risk justifies their cost.
10 min	An adoption journey in four stages Discovery, Pilot, Scale and Optimise, each with a lead team and one milestone. Front-loaded stakeholder alignment avoids the most common integration issues later. The resilience checklist asks every change for artefacts on pre-change validation, state resilience, recovery drills and rollback readiness.
8 min	Cost as a property of the architecture Cost is declared in code, estimated in the pipeline and reviewed alongside the change that causes it. Allocation tags and chargeback make spending transparent and give developers an incentive to design cost-consciously. Commitments are made only after a usage baseline and after rightsizing, because committing to the wrong size locks in waste.
10 min	Migration as small, reversible steps Assessment comes first: inventory, dependency mapping, risk assessment and cost-benefit analysis. Four strategies, from lift-and-shift to application retirement, suit different applications; lift-and-improve fits the majority of enterprise migrations. Existing resources are imported into code and then checked for drift, so that the template is proven to describe reality before any further change.
7 min	Why the technical part is not enough Pilots with non-critical systems let teams learn before critical systems are touched. Systems administrators and network engineers need training, mentorship and cross-functional teams to move into code-based workflows. Technical migration succeeds only with the organisational readiness that Part E describes.

What the audience takes away

A layered test strategy catches problems early in the development cycle, when they are cheaper and simpler to fix.
Every change should carry evidence that it is testable, recoverable and reversible, and cost should be visible in the same review.
Adoption and migration both proceed in stages: pilot on something non-critical, prove value, then scale with repeatable patterns.

Chapter 13 · 90 minutes

Testing Strategies for Infrastructure as Code

The lesson builds a testing strategy for codified infrastructure. It covers the test pyramid, unit testing with mocks and built-in test frameworks, a shared pipeline scaffold for Pulumi and Terraform, testing of configuration generators and validators with Vitest, integration and environment parity testing, chaos experiments with guardrails, security and compliance testing with preventive and detective policy evaluation, performance testing, and traceability through Requirements as Code.

Learning objectives

Explain how testing codified infrastructure differs from testing application logic.
Design a four-stage pipeline scaffold that gives the same assurance gates on different tooling.
Distinguish preventive policy evaluation in the pipeline from detective evaluation after deployment.
Define guardrails for a chaos experiment described as code.

Key concepts

Architecture as Code test pyramid: A structured progression from rapid developer tests to comprehensive integration and end-to-end validation, each layer serving a distinct quality purpose. The multilayered approach finds problems early, when they are cheaper and simpler to fix.
Unit testing without deployment: Validation of individual modules and resources without deploying infrastructure. Tests check resource configurations, variable validations, output consistency and module interface contracts, using mocks so that assertions run before any cloud cost is incurred.
Shared pipeline scaffold: Four complementary stages, lint and format, contract and unit tests, policy enforcement and integration rehearsal, implemented for both Pulumi and Terraform paths so that both pass the same assurance gates and platform parity is maintained.
Preventive and detective policy evaluation: Open Policy Agent evaluates policies preventively in the pipeline, before deployment. AWS Config Rules are detective by default, evaluating resources after they have been deployed.
Chaos experiments as code: Failure scenarios such as instance loss or degraded dependencies described alongside infrastructure definitions. Failure injection policies, scheduling rules and opt-in environments live in version control, which keeps the blast radius controlled and every change reviewable.

Teaching plan

15 min	Teacher presents the test pyramid and the dimensions of infrastructure testing, then unit testing with mocks on programmatic and declarative tools.
15 min	Walk through the four-stage scaffold table and the Vitest practices table, including the 80 per cent coverage guideline and the under 100 milliseconds rule for unit tests.
15 min	Teacher covers integration and parity testing, chaos experiments with their four guardrails, security, compliance and performance testing, and requirements traceability.
35 min	Exercise in groups: write a test strategy for one infrastructure module and present the order of investment.
10 min	Plenary on the testing strategy quadrant: where to start and where end-to-end tests are worth their cost.

Discussion

The chapter says each pipeline stage should block deployment on critical failures while allowing warnings to proceed. How would you decide which findings are hard failures in your organisation?
Why does the chapter warn that coverage goals should focus on meaningful tests and not on the metric?
What must be communicated, and to whom, before a fault is injected deliberately into an environment?

Exercise · 35 minutes

A test strategy for one infrastructure module

Choose one reusable infrastructure module in your own organisation, for example a network, a storage bucket or a database. Write its test strategy across the pyramid. List five unit tests that need no deployment, naming the property each asserts, such as an approved region, mandatory tags or encryption. Define the four pipeline stages for the module and what blocks at each. Add two policy tests, one positive and one negative. Describe one integration test in a temporary environment with automated clean-up. Finally describe one chaos experiment with the chapter's guardrails: lower environment first, limited concurrent faults, announced window and how the learning is recorded. This is a design exercise on your own systems.

Deliverable: A two-page test strategy with five unit tests, a four-stage pipeline table, two policy tests, one integration test and one guarded chaos experiment.

Self-test

According to the chapter, at what point does Open Policy Agent evaluate policies, in contrast to AWS Config Rules?
1. Only during the annual compliance audit
2. Preventively in the pipeline, before deployment
3. Detectively, after resources have been deployed
4. Only when a resource is deleted from the estate
What should unit tests for codified infrastructure validate, according to the chapter?
1. Auto-scaling behaviour under realistic production load
2. Failover between regions during a simulated outage
3. End-to-end deployment from a source change through the pipeline to a running system
4. Resource configurations, variable validations, outputs and interface contracts
Which order of investment does the chapter's summary suggest, based on the testing strategy quadrant?
1. Start with security scanning and policy testing, then add end-to-end tests where risk justifies it
2. Start with end-to-end tests of whole environments, then add unit tests once the pipeline has become stable
3. Start with performance testing, then add compliance tests before each audit
4. Start with chaos experiments in production, then add static analysis

Chapter 14 · 75 minutes

Architecture as Code in Practice

The lesson turns the principles into an adoption practice. It covers the four stages of the adoption journey with their lead teams, the three implementation stages with success criteria and deliverables, tool selection, protected delivery workflows for architecture modules, the resilience checklist with four areas and expected artefacts, and three common challenges: state management, dependency coordination and version compatibility.

Learning objectives

Describe the four stages of the adoption journey and the lead teams for each.
Plan a pilot with a constrained workload, success criteria and deliverables.
Review a change against the four areas of the resilience checklist.
Propose mitigations for state management, dependency coordination and version compatibility problems.

Key concepts

Adoption journey: Four stages with one milestone each: Discovery (adoption vision and platform readiness), Pilot (landing zone and first reusable module), Scale (automated guardrails and onboarding of product teams) and Optimise (measured outcomes and a continuous improvement loop).
Front-loaded alignment: Aligning platform, security, finance and architecture on priorities early, through a current-state assessment, a cross-functional working group and agreement on vocabulary and service level objectives. Organisations that do so avoid the most common integration issues later.
Enablement flywheel: The cycle that keeps programmes sustainable by connecting cross-functional teams, skill development, knowledge sharing, communities of practice and career progression.
Resilience checklist: A review aide for change advisory boards and platform teams with four areas, pre-change validation, state resilience, recovery drills and rollback readiness, each with prompts and expected artefacts such as pipeline run identifiers and stored rollback plans.
Protected delivery workflow: Protected branches on production-aligned infrastructure repositories that demand successful status checks, review approvals and signed commits before merge, with infrastructure unit tests prominent among the gates.

Teaching plan

15 min	Teacher presents the adoption journey table and the three implementation stages with success criteria and deliverables.
10 min	Discuss tool selection criteria: community support, managed service availability, licence terms and vendor roadmap alignment, and the role of testable platforms.
15 min	Tabletop: the teacher describes an infrastructure change and the room reviews it against the four areas of the resilience checklist, asking for each expected artefact.
25 min	Exercise: plan a pilot for the participant's own organisation and complete the checklist for its first change.
10 min	Close with the common challenges table and the mitigation each calls for.

Discussion

The chapter says a culture must treat infrastructure change as a product in its own right. What would be different in how your organisation funds and staffs it?
Which of the expected artefacts in the resilience checklist could your pipelines attach automatically today, and which would still be assembled by hand?
What makes a workload a good pilot candidate, and what makes one a poor choice even if the team is enthusiastic?

Exercise · 25 minutes

A pilot plan with a resilience review

Plan the Pilot stage for your own organisation. Select one constrained workload and justify the choice. Name the working group across platform, security, finance and architecture and what each must agree to beforehand. Define the first reusable module and three success criteria taken from the chapter: automated provisioning, observable change history and rapid rollback. List the deliverables, including how lessons learned will be recorded. Then take the first change the pilot will make and complete the resilience checklist for it: for each of the four areas answer the prompts and state the artefact you will attach as proof. Mark any area where you cannot yet produce the artefact.

Deliverable: A one-page pilot plan with workload, working group, success criteria and deliverables, and a completed four-area resilience checklist with artefacts or marked gaps.

Self-test

Which activities belong to the Pilot stage of the adoption journey in the chapter's table?
1. Define the adoption vision; assess platform readiness
2. Automate guardrails; onboard product teams
3. Establish the landing zone; deliver the first reusable module
4. Measure outcomes; run the continuous improvement loop
Under which area of the resilience checklist does the chapter ask whether a tested rollback script or inverse plan exists?
1. Rollback readiness
2. State resilience
3. Pre-change validation
4. Recovery drills
What mitigation does the chapter give for the version compatibility challenge, where provider and module upgrades break workflows?
1. Remote state backends with mandatory locking, frequent backups and reconciliation
2. Modular designs with explicit dependency declarations
3. A freeze on all upgrades until the next annual review
4. Staged rollouts, compatibility matrices and automated integration tests

Chapter 15B · 75 minutes

Cost Optimisation and Resource Management

The lesson treats cost as a property of the architecture. It covers FinOps and cost governance, allocation tags and chargeback, cost estimation in the pipeline, automatic scaling and rightsizing, cost monitoring with budget alerts and anomaly detection, multi-cloud cost considerations including data transfer and residency, Kubernetes resource governance, and commitment-based pricing with the considerations that should precede a commitment.

Learning objectives

Explain how FinOps practices are integrated into Architecture as Code workflows.
Design cost allocation tags and budget alerts for a workload.
Describe the Kubernetes components that govern resource consumption and their cost effect.
Evaluate a proposed commitment against the chapter's five considerations.

Key concepts

FinOps in Architecture as Code: A discipline that combines financial management with cloud operations to maximise business value from cloud investments. In this context it means automated policies for resource configuration, budget alerts and regular cost analysis built into the workflow.
Cost allocation tags and chargeback: Metadata on all resources, such as cost centre, project, environment and owner, with chargeback models that distribute costs transparently between teams, projects and business units and give developers an incentive to make cost-optimal design decisions.
Rightsizing: Adjusting resource allocation to actual usage. Provider recommendations based on historical usage become actionable only when turned into reviewed code changes within Architecture as Code workflows.
Kubernetes resource governance: ResourceQuotas set hard limits per namespace, LimitRanges define default and maximum container resources, the Vertical Pod Autoscaler adjusts resource requests to actual usage, and the Horizontal Pod Autoscaler scales the number of replicas with demand.
Commitment-based pricing: Discounts received for committing to a defined usage level over a one-year or three-year term. The chapter advises a baseline of at least 30 to 90 days of usage data, flexible instruments, governance, rightsizing first and periodic review.

Teaching plan

15 min	Teacher presents the cost optimisation workflow, the FinOps cycle and why cost estimation belongs between plan and apply.
15 min	Walk through the cost-aware configuration table and the Kubernetes table. Participants identify which mechanisms their organisation already uses.
10 min	Teacher explains commitment-based pricing and the five considerations, stressing that the published maximum discounts are provider figures and realised savings vary.
25 min	Exercise: design cost governance for one workload.
10 min	Close on the chapter's summary sentence about cost being declared, estimated and reviewed with the change that causes it, and on data residency as a cost constraint.

Discussion

The chapter says transparent cost distribution creates incentives for developers. What could go wrong with chargeback, and how would you design against it?
How do data residency requirements under GDPR change what cost optimisation can mean for a European organisation?
Why should reservation purchases pass through the same approval workflows as infrastructure changes?

Exercise · 25 minutes

Cost governance for one workload

Choose one cloud workload in your own organisation. Define its cost allocation tags using the four the chapter lists: cost centre, project, environment and owner, and say which pipeline check rejects a resource without them. Set a budget and two alert thresholds, following the pattern of notifications at 80 and 100 per cent, and name who is notified and what they are expected to do. State where in the pipeline a cost estimate appears and which threshold triggers an approval gate. List three kinds of unused resource to detect. Finally assess whether the workload is a candidate for a commitment by answering the five considerations from the chapter.

Deliverable: A one-page cost governance design with tag policy, budget and alert thresholds, pipeline cost gate, unused resource checks and a reasoned commitment assessment.

Self-test

How much usage data does the chapter say should be analysed before committing to reserved capacity?
1. At least 7 days
2. At least 30 to 90 days
3. At least 12 months
4. At least one full budget cycle of 3 years
Why does the chapter say rightsizing should be acted upon before making multi-year commitments?
1. Because providers refuse commitments on oversized instances
2. Because rightsizing recommendations expire after one year
3. Because committing to the wrong instance size locks in waste
4. Because commitments cannot be tagged with a cost centre
Which Kubernetes component sets hard limits on CPU, memory and pod count per namespace?
1. ResourceQuotas
2. LimitRanges
3. Horizontal Pod Autoscaler
4. Vertical Pod Autoscaler

Chapter 16 · 75 minutes

Migration from Traditional Infrastructure

The lesson covers migration from manually configured infrastructure to Architecture as Code. It treats assessment and planning with inventory, dependency mapping and wave planning, the four migration strategies and what each suits, gradual codification by importing existing resources and eliminating drift, the transition of teams and competence, and the import of legacy resources followed by drift detection.

Learning objectives

Describe what a migration assessment must contain before a strategy is chosen.
Compare the four migration strategies and match each to a type of application.
Plan migration waves that balance technical dependencies with business priorities.
Explain why imported resources are checked for drift before any further change.

Key concepts

Migration assessment: The foundation of a migration: inventory of existing resources, dependency mapping, risk assessment that identifies critical systems, single points of failure and compliance dependencies, and cost-benefit analysis that informs strategy and timeline.
Lift-and-improve: A hybrid strategy that selectively re-architects critical components while keeping most unchanged. It balances speed with modernisation and suits phased, risk-balanced approaches and the majority of enterprise migrations.
Migration wave planning: Planning that balances technical dependencies with business priorities to minimise risk and maximise value. Pilot projects with non-critical systems enable team learning and process refinement before critical systems are migrated.
Gradual codification: Systematic conversion of existing resources to code management through import tooling, standardisation into reusable modules, reconciliation of existing configurations with the desired state, and Git-based tracking of progress with rollback.
Import followed by drift detection: The chapter's pattern for legacy import: a reviewed change set that neither creates nor deletes resources, followed by drift detection, so that the template is proven to describe reality before any further update touches the resources.

Teaching plan

15 min	Teacher presents the migration process from assessment to full adoption and the hybrid period in which legacy and code-managed resources coexist.
15 min	Sorting activity: participants receive short descriptions of applications and assign each to one of the four strategies, defending the choice with the table's criteria.
10 min	Teacher explains gradual codification, the import pattern and the transition of systems administrators and network engineers.
30 min	Exercise in groups: a wave plan for part of the participant's own estate.
5 min	Close with the summary: migration is a sequence of small, reversible steps, and it depends on organisational readiness.

Discussion

Lift-and-shift is the fastest route but brings limited cloud-native benefits. When is that trade-off the right one, according to the chapter's criteria?
What does a team learn from a pilot on a non-critical system that it could not learn from planning alone?
How would you support experienced systems administrators so that code-based workflows build on their knowledge instead of displacing it?

Exercise · 30 minutes

A migration wave plan

Take six to eight systems from your own organisation that are still configured by hand. For each, record its criticality, its main dependencies, any compliance dependency or downtime restriction, and its business value. Assign each system one of the four strategies: lift-and-shift, re-architecting, lift-and-improve or application retirement, with one sentence of justification from the chapter's table. Group the systems into three waves, beginning with a pilot wave of non-critical systems, and state what the team must have learned before the next wave starts. For the pilot wave describe the codification steps: import, review, drift detection, and the rollback available at each step.

Deliverable: A system inventory table with strategy per system, a three-wave plan with entry conditions, and the codification steps with rollback for the pilot wave.

Self-test

Which migration strategy does the chapter's table describe as suited to the majority of enterprise migrations?
1. Lift-and-shift
2. Re-architecting
3. Application retirement
4. Lift-and-improve (hybrid)
Why does the chapter follow an import of existing resources with drift detection?
1. To prove the template describes reality before any further update
2. To delete resources that were not part of the import
3. To calculate the cost saving achieved by the migration
4. To transfer ownership of the resources to the platform team
What does the chapter recommend doing before critical systems are migrated?
1. Re-architecting all strategic applications in one programme
2. Running pilot projects with non-critical systems
3. Retiring every legacy application of limited value
4. Moving the whole estate by lift-and-shift first

Module 5 · Part E · Organisation & Leadership

Part E turns to the people and the organisation. The module follows the transformation from siloed functions to product-aligned teams, the team models, skills matrix and communities of practice that sustain it, the codification of management intent, budgets and decisions, the interplay between compliance, architecture, documentation, knowledge and culture as code, a team of AI agents under human direction, and digitalisation within European sovereignty requirements. Participants leave with a transformation assessment, a team charter, a management artefact, a norms file, an oversight policy and a provider selection policy.

Lecture · 50 minutes

People, process and technology in equal measure: the organisation behind Architecture as Code

Part E argues that Architecture as Code succeeds only when organisations invest equally in people, process and technology. The lecture traces how the same operating model, structured representation, version control and automation, moves from infrastructure into the softer fabric of the organisation: team charters, competency frameworks, budgets, decisions, norms and lessons learned. It then examines two extensions of that idea, a team of AI agents that drafts and checks under named human approval, and a digitalisation strategy in which provider choice and data sovereignty are written as policy. The constant is transparency: decisions leave a searchable record.

8 min	From siloed functions to product-aligned teams Organisations move through four stages, each with its own team structure, decision making and automation maturity. Psychological safety and blameless retrospectives let teams learn from incidents without defensive behaviour. Resistance often signals legitimate concerns about job security, skill gaps or process disruption.
8 min	Designing teams and growing competence Platform teams act as internal service providers and treat infrastructure as a product. A skills matrix with four levels and a balanced scorecard make expectations and progression explicit. Communities of practice and co-maintained runbooks reduce the bus factor.
9 min	Management intent as executable artefact Management as Code differs from management documentation in three ways: it is executable, it follows change management discipline, and it is instrumented with telemetry. Issues record decisions and Discussions host deliberation, and both link to the code change that implements them. Budgeting as Code defines budget envelopes that are adjusted through pull requests and validated by tests.
8 min	The soft disciplines compound All share a common DNA: structured representation, version control and automatability. Compliance as Code is the quality engine, Architecture as Code the hub and Documentation as Code the communication layer. Codified rules do not capture every interpretation, so manual controls and clear governance remain necessary.
8 min	AI agents as structured participants Specialist agents work from a single backlog, common documentation practices and shared quality thresholds. Four categories of decision remain with people; agents draft and humans approve. Every agent-generated artefact stays traceable to a commit, a pull request and an accountable individual.
9 min	Digitalisation within European boundaries Regulatory drivers such as the GDPR and the NIS2 Directive shape cloud-first strategies in the EU. Provider selection is written as policy that distinguishes inherently sovereign providers from those acceptable only with EU-only controls in force. A keyword search for encryption in a pipeline is not a meaningful compliance check; policy-as-code tooling is.

What the audience takes away

Tools create possibilities, but sustained transformation depends on culture, capability development and structures that reward collaboration over individual heroics.
Management intent, budgets, norms and lessons can be versioned, reviewed and measured like any other code artefact, which makes leadership auditable.
AI agents and cloud providers alike are governed through explicit, codified guardrails with named human approval for consequential decisions.

Chapter 17 · 60 minutes

Organisational Change and Team Structures

The lesson examines the organisational change that Architecture as Code demands. It covers the four transformation stages from siloed functions to product-aligned teams, the cultural foundations of psychological safety and blameless learning, cross-functional team design with decision rights, learning pathways and evolving roles, change management that treats stakeholders as partners, and measurement that balances technical, business and cultural dimensions.

Learning objectives

Describe the four transformation stages by team structure, decision making and automation maturity.
Explain how psychological safety and blameless retrospectives sustain cross-functional collaboration.
Design a change approach that engages stakeholders as partners and uses pilots to build momentum.
Select leading indicators that connect technical improvement to business and cultural outcomes.

Key concepts

Transformation stages: Four progressive stages: siloed functions with ticket handoffs, basic collaboration with shared goals but separate execution, cross-functional teams with collective ownership, and product-aligned teams that are autonomous within guardrails on self-service platforms.
Psychological safety: A condition in which teams can learn from incidents without blame. The chapter describes high-performing organisations as treating failures as tuition fees for valuable lessons, with senior leaders modelling vulnerability.
Decision rights with shared standards: The pairing that keeps autonomy and alignment in harmony: teams know which decisions are theirs, and shared standards keep their choices compatible.
Dual-ladder career structures: Career frameworks that recognise deep expertise and cross-disciplinary breadth so that people can advance without leaving technical tracks, alongside technical leadership programmes and rotation opportunities.
Leading indicators: Measures that teams can influence directly, such as deployment frequency, recovery time and developer satisfaction, preferred over lagging indicators that confirm success or failure only after the chance to correct has passed.

Teaching plan

15 min	Teacher presents the transformation stage table. Participants place their own organisation, or parts of it, in a stage and give one observation as evidence.
10 min	Teacher covers culture, cross-functional team design, learning pathways and evolving roles.
10 min	Discussion of change management: stakeholders as partners, the meaning of resistance, and pilots as reference stories.
20 min	Exercise: a transformation assessment and next-stage plan for one department.
5 min	Close on measurement: why activity metrics invite premature claims of victory.

Discussion

The chapter says resistance often signals legitimate concerns about job security, skill gaps or process disruption. Which concerns would you expect in your organisation, and how could they be addressed directly?
What do senior leaders have to do, visibly, before staff believe that an honest mistake will not be penalised?
Why does the chapter warn against promoting the best engineers into management roles, and what alternative does it offer?

Exercise · 20 minutes

A transformation assessment and next-stage plan

Choose one department or delivery area in your own organisation. Using the chapter's table, determine which transformation stage it is in for each column separately: team structure, decision making and automation maturity. Give one piece of evidence per column. Identify the column that lags behind and describe what the next stage would look like there. Then plan the move: name the stakeholders in finance, security, procurement and operations to engage early, one low-risk, high-visibility pilot, the concern you expect to meet as resistance and how you will respond, and three measures, one technical, one business and one cultural, that will show progress.

Deliverable: A one-page assessment with stage and evidence per column, and a next-stage plan with stakeholders, pilot, expected concern and three measures.

Self-test

How does the chapter's table characterise decision making in product-aligned teams?
1. Handoffs through tickets and change requests
2. Autonomous within guardrails
3. Meetings and shared backlogs
4. Approval by a central architecture board
What dual purpose do pilot projects serve, according to the chapter?
1. They reduce headcount and shorten procurement cycles
2. They replace formal training and remove the need for sponsorship
3. They test business-critical systems first and expose the teams with the weakest skills
4. They prove feasibility and create reference stories for sceptical stakeholders
Which kind of indicator does the chapter's measurement guidance emphasise?
1. Leading indicators that teams can influence directly
2. Lagging indicators confirmed at programme end
3. Activity counts such as the number of training sessions held
4. Infrastructure metrics alone, without cultural measures

Chapter 18 · 60 minutes

Team Structure and Competency Development for IaC

The lesson designs the operating model for Architecture as Code teams. It covers platform teams as internal service providers, the competency domains of specialists, a skills matrix with four technical levels and interpersonal skills, structured learning programmes, agile team models that treat infrastructure as a product, platform and product team charters, communities of practice, and balanced scorecards for performance and career progression.

Learning objectives

Explain the role of the platform team as an internal service provider.
Assess a team against the four levels of the technical skills matrix.
Draft a team charter with responsibilities, service levels and measures.
Design a community of practice with roles, cadence and success criteria.

Key concepts

Platform team: An internal service provider that owns the common toolchains, guardrails and reusable modules which let application teams move quickly without sacrificing governance, balancing central expertise with decentralised autonomy.
Skills matrix: A shared view of expectations at four levels: Foundation (basic operations), Practitioner (infrastructure automation), Advanced (architecture design) and Expert (platform leadership), complemented by communication and leadership skills and revisited in quarterly development conversations.
Infrastructure as a product: A team model in which cross-functional teams work from a prioritised backlog, product owners represent internal customers, and service level objectives, error budgets and deployment frequency tie platform work to business value.
Community of practice: A structure that connects practitioners across product lines with defined roles, cadences and collaboration platforms, so that insights from talks and workshops reach documentation, reusable modules and the operating model.
Balanced scorecard: A performance view that combines operational indicators drawn from the DORA software delivery metrics with contributions to knowledge sharing and cross-team collaboration, supporting career progression for specialists.

Teaching plan

10 min	Teacher presents why traditional organisation charts hinder the practice and how platform teams and product-aligned delivery teams divide the work.
15 min	Participants rate themselves or their team privately against the technical skills matrix, then discuss in pairs which level transitions are hardest.
10 min	Teacher covers learning programmes, agile team models, the charter and the community of practice framework.
20 min	Exercise: write a platform team charter and a community of practice outline.
5 min	Close on the balanced scorecard and what it rewards beyond delivery numbers.

Discussion

What would have to change in how your platform team is funded and measured for it to act as a service provider with internal customers?
The Expert level of the skills matrix is defined by mentoring, tool selection and roadmaps more than by technical depth. What does that say about how seniority should be recognised?
How can a manager track completion of training while still placing the emphasis on practical demonstration, as the chapter asks?

Exercise · 20 minutes

A platform team charter and a community of practice

Write a charter for a platform team in your own organisation, in structured form. State its mission, the internal customers it serves, what it owns (toolchains, guardrails, reusable modules), what the product teams own, two service level objectives, and three measures that tie its work to business value, drawing on deployment frequency, error budgets or adoption. State how often the charter is reviewed, following the chapter's quarterly alignment reviews. Then outline a community of practice that connects the platform team with product teams: its coordinator role, its meeting cadence, its channels, and two success criteria that show knowledge reaches documentation and reusable modules.

Deliverable: A structured team charter of about one page and a half-page community of practice outline with roles, cadence and success criteria.

Self-test

Which focus area does the skills matrix assign to the Practitioner level (Level 2)?
1. Basic operations
2. Platform leadership
3. Infrastructure automation
4. Architecture design
What do platform teams own, according to the chapter?
1. The common toolchains, guardrails and reusable modules
2. The backlog and release dates of every product team
3. The budget approval for all cloud spending
4. The performance reviews of application developers
What do the balanced scorecards in the chapter combine?
1. Cloud cost per team with the number of certifications held
2. Lines of infrastructure code with hours of training completed
3. Audit findings with the number of incidents per quarter
4. DORA-based operational indicators with knowledge-sharing contributions

Chapter 19 · 90 minutes

Management as Code

The lesson extends as-code principles to organisational leadership. It defines Management as Code and the three ways it differs from management documentation, shows how management artefacts enter the DevOps loop and change management pipelines, explains transparent decision-making through Issues and Discussions with five implementation steps, and covers Budgeting as Code, competence management as code, team-of-teams leadership and the measurement of management effectiveness.

Learning objectives

Define Management as Code and explain the three ways it differs from traditional management documentation.
Distinguish the use of Issues for decision records from Discussions for strategic deliberation.
Design a transparent decision workflow with templates, a labelling taxonomy and links to code changes.
Describe Budgeting as Code and the metrics used to evaluate management effectiveness.

Key concepts

Management as Code: The systematic translation of management artefacts, such as policies, playbooks, delegation models, role definitions and decision guardrails, into declarative specifications that tooling can enforce. The artefacts are executable, follow change management discipline and are instrumented with telemetry.
Issues as transparent decision records: Structured, permanent and searchable records of how a decision evolved, giving visibility, traceability, accountability through named owners and milestones, and collaborative resolution within one thread.
Discussions for strategic deliberation: The forum for exploratory thinking, strategy formulation and community building before work is formalised. Threads allow open ideation and asynchronous participation, and the consensus links to the code change that implements it.
Budgeting as Code: A subset of Management as Code in which finance policies, spending limits, cost allocation rules and investment hypotheses are version-controlled. Files define budget envelopes per product, platform or team, and automated tests validate that proposed expenditure stays within budget.
Management effectiveness metrics: Measures similar to those of DevOps: lead time for management decisions, change failure rates for policies and mean time to recovery for organisational issues, drawn from management repositories and complemented by surveys.

Teaching plan

15 min	Teacher defines Management as Code, its principles, and how leadership responsibilities appear at each stage of the DevOps loop.
20 min	Work through three of the chapter's examples: the cloud migration decision as an Issue, the annual technology strategy as a Discussion, and the confidential handling of a vulnerability.
15 min	Teacher covers the five implementation steps, Budgeting as Code, competence management, team-of-teams leadership and the case study of a global software company.
30 min	Exercise in groups: design a transparent decision workflow and one management artefact as code.
10 min	Plenary on cultural implications: the temptation of private channels, and where confidentiality legitimately limits transparency.

Discussion

The chapter asks teams to resist resolving complex matters through private channels because it feels faster. What is the cost of that discipline, and when is it worth paying?
Where should deliberate confidentiality limit transparency in your organisation, and how would you make that boundary explicit?
What would be lost if culture or competence were codified badly, and how can the review process guard against it?

Exercise · 30 minutes

A transparent decision workflow and a management artefact

Design a transparent decision workflow for your own organisation following the chapter's five steps. Write an issue template with its five prompts: problem statement, business impact, technical context, stakeholder input and success criteria. Define a labelling taxonomy with four groups: strategic themes, affected systems, priority levels and workflow states. State how pull requests are linked to approved issues and how inactive Discussions are handled, using the chapter's 90-day flag as a starting point. Choose two metrics that will show the workflow's value. Then write one management artefact as structured data: either a budget envelope for a team with a limit and an approval rule, or a short competency definition with levels.

Deliverable: An issue template, a four-group label taxonomy, linking and review rules, two impact metrics, and one management artefact in structured form.

Self-test

Which of these is one of the three ways Management as Code differs from traditional management documentation?
1. The artefacts are approved once a year by the board
2. The artefacts are written only by engineers
3. The artefacts are executable and integrate with operational systems
4. The artefacts are kept confidential from delivery teams
In the chapter's implementation steps, after how long without activity does automation flag a Discussion for closure or renewal?
1. 14 days
2. 90 days
3. 30 days
4. One year
How does Management as Code keep leadership in the change management loop without reintroducing bottlenecks?
1. Codified criteria approve low-risk changes and route higher-risk items to leaders
2. Every change waits for a weekly leadership review meeting
3. Leaders approve all changes in advance for the coming quarter
4. Changes are approved afterwards by leaders on the basis of continuous delivery dashboards

Chapter 23 · 75 minutes

The Interplay Between Soft As Code Disciplines

The lesson shows how the soft as-code disciplines reinforce one another. It covers the shared DNA of structured representation, version control and automatability, Compliance as Code as the quality engine, Architecture as Code as the hub, Documentation as Code as the communication layer, Knowledge as Code and Culture as Code with their worked files, the synergies shown in two scenarios, four challenges, and five adoption strategies.

Learning objectives

Describe the shared DNA that unifies the soft as-code disciplines.
Explain the distinct roles of Compliance, Architecture and Documentation as Code and how each strengthens the others.
Draft a team norms file and a lessons-learned entry as version-controlled artefacts.
Identify the challenges of combining the disciplines and plan an incremental adoption.

Key concepts

Shared DNA: The three properties into which soft artefacts are converted: structured representation in machine-readable formats, version control with history and pull requests, and automatability, so that artefacts can feed tools that generate reports, verify compliance or trigger workflows.
Compliance as Code as quality engine: Codified controls that reinforce the other disciplines through rule reuse, continuous validation and transparency. When a rule changes, the update propagates to every system that uses it.
Architecture as Code as hub: The connection between technical implementations and the policy and documentation layers, giving traceability to compliance rules, real-time documentation generated from models, and automated quality gates before an architectural change is approved.
Culture as Code: Team agreements and working norms moved out of slide decks and corridor conversations into version-controlled files, such as a team norms file, where a pull request records who proposed a change, the discussion and when the new norm took effect.
Knowledge as Code: Lessons learned and patterns kept in structured, queryable registries instead of wikis that drift. Pipelines validate required fields and check that referenced decision records exist, and search surfaces relevant lessons.

Teaching plan

15 min	Teacher presents the shared DNA and the three roles: quality engine, hub and communication layer.
15 min	Walk through the two scenarios, a policy change and a new product launch, tracing what each discipline does and in which order.
10 min	Teacher explains Culture as Code and Knowledge as Code with the two worked files, then the four challenges and five adoption strategies.
30 min	Exercise in teams: write a team norms file and a lessons-learned entry, and review another team's through a simulated pull request.
5 min	Close on the future perspective: the more of the soft fabric is codified, the greater the demands on access control, privacy and accountability.

Discussion

The chapter describes pull requests on policy code as educational moments where lawyers, security experts and developers meet. What would each need in order to take part on equal terms?
Automation debt means codified rules do not capture every interpretation. Which of your rules should stay with human interpretation, and why?
What changes in a team when a norm can only be altered through a visible proposal and review?

Exercise · 30 minutes

A team norms file and a lessons-learned entry

Working as a team, write a team norms file in structured form for a real or representative team in your own organisation. Include working agreements, review expectations with a response time, how decisions are made, and two cultural principles each tied to a behavioural example. Then write one lessons-learned entry for a real event: an identifier, a title, the context, what happened, the lesson, the related decision record or system, and tags for search. State which fields a pipeline should require. Hand both files to another team as a simulated pull request; the reviewers propose one change to a norm and record their reasoning, and the authors accept or contest it in writing.

Deliverable: A structured team norms file, one lessons-learned entry with required fields marked, and the written review exchange on one proposed change.

Self-test

Which three elements make up the shared DNA of the soft as-code disciplines?
1. Policy engines, static site generators and dashboards
2. Lawyers, architects and documentation specialists
3. Regulations, standards and internal policies
4. Structured representation, version control and automatability
Which role does the chapter assign to Documentation as Code in the interplay?
1. The quality engine
2. The communication layer
3. The central hub
4. The automated quality gate
In Scenario 1, the compliance team updates a data retention rule in code. What happens next in the chapter's account?
1. The rule waits for the next quarterly architecture board
2. The documentation team rewrites the affected manuals by hand over the following weeks, one system at a time
3. The architectural models flag components lacking encryption and a documentation section is generated
4. The change is applied to production without notifying the teams

Chapter 20 · 60 minutes

AI Agent Team for Architecture as Code Initiatives

The lesson presents a team of AI agents that works as a digital delivery team under human direction. It covers the multi-agent operating model and its specialist roles, collaboration that updates living cases instead of following a rigid timetable, governance through sprint rituals, reporting and quality measures, integration through repository events and automation workflows, and the categories of decision that remain with human practitioners.

Learning objectives

Describe the multi-agent operating model and the contribution of each specialist role.
Explain how agents are activated by repository events and integrated with automation workflows.
Identify the four categories of decision that must remain with human practitioners.
Define governance and quality measures that make an agent team accountable and auditable.

Key concepts

Multi-agent operating model: The project owner defines priorities and acceptable outcomes; a Project Manager agent turns them into sprint goals and cases and steers information between specialists such as the Architect, Requirements Analyst, Designer, Developer, Quality Control, Editor and Graphic Designer agents.
Living cases: Shared artefacts that accumulate updates whenever two or more specialists exchange information. The focus lies on how communications revise artefacts and decisions, not on tracking activities against a rigid timetable.
Issue-driven agent activation: Agents started by repository events instead of conversation, for example a workflow that runs when an issue receives a certain label, produces a diagram and opens a pull request with a comment on the issue.
Human oversight guardrails: Decisions that stay with people: architectural commitments with long-term consequences, stakeholder communication, security and compliance decisions such as policy exceptions and risk acceptances, and resolution of conflicting recommendations. Agents draft; humans approve.
Agent team quality measures: Lead time from requirement to release within two sprints, automated test coverage of at least eighty-five per cent for critical components, documentation changes within twenty-four hours of a governance or design decision, and fewer than three blockers per sprint.

Teaching plan

15 min	Teacher presents the operating model and roles, and reads the chapter's note that multi-agent workflows remain an active area of research needing validation and cost monitoring.
10 min	Walk through the collaboration table: for each communication thread, which case is updated and what evidence is left.
10 min	Teacher explains integration through workflows and labels, least-privilege permissions for automation, and the four oversight categories.
20 min	Exercise: write an oversight and escalation policy for an agent team.
5 min	Close on the key insight: agents are most effective as structured participants in a governance framework that keeps humans informed and in control.

Discussion

The chapter treats sprint rituals, daily reporting and quality thresholds as what makes an agent team trustworthy and not as overhead. What would you be unable to audit without them?
Why does the chapter require named human approval, captured in the audit trail, for policy exceptions and risk acceptances?
Which routine activities in your own delivery work could be drafted or checked by an agent, and what validation step would you place after each?

Exercise · 20 minutes

An oversight and escalation policy for an agent team

Assume your own organisation introduces three AI agents into an architecture repository: one that drafts documentation updates, one that checks diagrams and one that proposes decision records. Write the oversight policy. For each agent state what it may draft, flag or execute and which repository event activates it. List the decisions it must escalate, using the chapter's four categories, and name the human role that approves each. Define how conflicting recommendations from two agents are presented to the project owner. Add four quality measures with thresholds, the validation step for output before merge, and how every agent-generated change is traced to a pull request and an accountable individual.

Deliverable: A one-page oversight policy with permitted actions per agent, an escalation table with named approver roles, four quality measures and a traceability rule.

Self-test

What does the chapter say about external communication such as progress reports to sponsors or responses to regulatory enquiries?
1. Agents publish it directly to save time
2. Agents draft it and humans approve it before publication
3. It is excluded from the repository altogether
4. It is approved by the Project Manager agent alone, in the sprint packet
What coverage do automated tests aim for on critical components in the agent team's quality measures?
1. At least fifty per cent
2. At least seventy per cent
3. At least one hundred per cent
4. At least eighty-five per cent
When two agents produce conflicting recommendations, what happens in the chapter's model?
1. The Project Manager agent presents both perspectives to the project owner, who resolves it
2. The Architect agent's recommendation always takes precedence, since it curates the system blueprint
3. The recommendation with the higher test coverage is merged
4. Both recommendations are discarded and the case is closed

Chapter 21 · 75 minutes

Digitalisation through Code-based Infrastructure

The lesson places Architecture as Code in the context of digital transformation in Europe. It covers the four dimensions of transformation, the regulatory drivers including the GDPR and the NIS2 Directive, cloud-first strategies, the provider ecosystem with EU-native providers and sovereign offerings of global providers, provider selection as policy, a compliant infrastructure template, self-service developer portals, and the limits of keyword-based compliance checks.

Learning objectives

Explain the four dimensions of digital transformation that must be addressed together.
Identify the regulatory drivers that shape cloud-first strategies for organisations in the EU.
Evaluate cloud provider offerings against data sovereignty requirements and write the result as a selection policy.
Assess the limitation of keyword-based compliance checks and name the appropriate alternative.

Key concepts

Transformation dimensions: Four dimensions to be addressed holistically: technical transformation, organisational change, cultural evolution and competence development. Technical transformation must be combined with organisational and cultural change to achieve lasting results.
Cloud-first strategy: A strategy in which organisations primarily choose cloud-based solutions for new initiatives. In the EU it must comply with data sovereignty regulations, which creates demand for Architecture as Code that handles sensitive data in line with the GDPR and sector rules.
EU-trusted provider policy: A codified provider selection policy that differentiates providers that are inherently sovereign from those acceptable only when their EU-only controls are in force. EU-headquartered platforms form the default where obligations prohibit other arrangements.
Self-service developer portal: A portal through which developers provision infrastructure from templates that carry compliance defaults from the start. The chapter cites Backstage, created at Spotify, with a software catalogue and software templates.
Keyword-based compliance check: A pipeline step that searches infrastructure code for words such as encryption. The chapter warns that this is not a meaningful GDPR compliance check and points to policy-as-code tooling as the alternative.

Teaching plan

15 min	Teacher presents the transformation challenges and the four dimensions, with the regulatory instruments the chapter names.
15 min	Map the provider ecosystem on a board: EU-native providers and the sovereign offerings of global providers, and what makes each qualify.
10 min	Teacher walks through the compliant template with its parameterised EU region and state locking, the developer portal, and the warning on keyword checks.
25 min	Exercise: write a provider selection policy for one class of workload.
10 min	Close on the key lesson: Architecture as Code is the technical foundation, but success needs organisational and cultural change.

Discussion

The chapter distinguishes providers that are inherently sovereign from those that become acceptable only when EU-only controls are in force. How would you verify, continuously, that those controls remain in force?
Why is a pipeline step that searches for the word encryption worse than no check at all in some respects?
Which of the four transformation dimensions receives the least attention in your organisation's digital strategy, and what does that cost?

Exercise · 25 minutes

A provider selection policy for one class of workload

Choose one class of workload in your own organisation that processes personal data. Write a provider selection policy for it in plain structured language that a policy engine could later enforce. State the regulatory obligations that apply, as your organisation has documented them. Define which providers and regions are permitted by default, which are permitted only when named EU-only controls are in force, and which are excluded. Specify the checks a pipeline must run on every change: region within the approved list, encryption, audit logging and state storage. Replace any keyword-style check with a rule that inspects the actual configuration value. State who may grant an exception, for how long, and where it is recorded.

Deliverable: A one-page provider selection policy with default, conditional and excluded options, four enforceable pipeline rules and an exception procedure.

Self-test

What does the chapter say about searching infrastructure code for encryption keywords in a compliance pipeline?
1. It is sufficient evidence for a supervisory authority
2. It is the recommended first step before any policy tooling
3. It is not a meaningful GDPR compliance check
4. It is required by the NIS2 Directive
How should policy catalogues treat cloud providers, according to the chapter?
1. Differentiate inherently sovereign providers from those acceptable only with EU-only controls
2. Treat all providers with an EU region as equivalent
3. Exclude every provider headquartered outside the EU, whatever sovereign controls it has in force
4. Leave provider choice to each product team's preference
Which four dimensions of digital transformation does the chapter say must be addressed holistically?
1. Strategy, budget, procurement and operations
2. Technical, organisational, cultural and competence
3. Cloud, data, security and artificial intelligence
4. Discovery, pilot, scale and optimisation

Module 6 · Part F · Experience & Best Practices

Part F consolidates experience. The module first separates two disciplines that are easily confused, Documentation as Code, which communicates an architecture, and Architecture as Code, which defines and enforces it, and shows how each feeds the other. It then gathers the lessons of practice into seven clusters, from code organisation to continuous improvement. Participants leave with a classification of their own artefacts and tools and a prioritised improvement backlog.

Lecture · 40 minutes

Explaining an architecture is not the same as enforcing it

Part F makes one distinction and draws one synthesis. The distinction: Documentation as Code communicates knowledge to people, while Architecture as Code defines structure and enforces constraints for people and machines. A diagram drawn as text is still a diagram; only a model can be queried, validated and used to drive automation. The synthesis: mature programmes layer their capabilities across seven practice clusters, and the most successful pair disciplined engineering routines with human-centred ways of working, so that automation never removes context or accountability.

8 min	Two disciplines, two purposes Documentation as Code answers how a system is configured, operated and why decisions were made; its audience is human. Architecture as Code answers what components exist, how they communicate and whether the running system matches the approved design. Success is measured differently: reduced onboarding time on one side, prevented drift and automated compliance on the other.
9 min	Modelling tools and diagram tools With CALM and Structurizr the model is the source of truth, and diagrams, documentation and compliance reports are derived from it. With Mermaid and PlantUML the diagram itself is the primary artefact, with limited metadata, no automated validation and manual synchronisation. The book itself uses Mermaid because its diagrams are documentation, not executable models.
7 min	How the two reinforce each other Architecture feeds documentation with generated diagrams, component catalogues and compliance statements. Documentation explains architecture through decision rationale, usage guides and conceptual overviews. Five integration practices keep both in one reviewed, version-controlled ecosystem.
9 min	Seven practice clusters Code organisation, secure foundations, performance management, governance, people enablement, collaborative ecosystems and continuous improvement. An orderly codebase is the first visible signal of a mature programme. Effective governance empowers delivery teams: approval thresholds follow blast radius, so low-risk experiments move quickly.
7 min	Resilience and learning Risk registers link infrastructure components to critical business services, and disaster simulations are rehearsed at least annually. Blameless post-incident reviews examine systemic contributors and track action items visibly. Improvement backlogs turn telemetry, regulatory change and retrospective findings into small, evaluated experiments.

What the audience takes away

Use documentation to explain and models to enforce; a text-based diagram alone cannot be validated against policy.
The two disciplines belong in the same repository and review process, with models generating the diagrams that documentation embeds.
Best practice is a layered set of capabilities in which technical excellence, people enablement and governance advance together.

Chapter 22 · 75 minutes

Documentation as Code vs Architecture as Code

The lesson clarifies the difference between Documentation as Code and Architecture as Code. It compares their purposes, audiences, artefacts, validation and success metrics, contrasts the modelling tools CALM and Structurizr with the diagram tools Mermaid and PlantUML, names four limitations of diagram tools for architectural enforcement, and shows how the two disciplines feed and explain each other through five integration practices.

Learning objectives

Distinguish Documentation as Code from Architecture as Code by purpose, audience, artefact type and success metric.
Explain why a modelling tool can serve as a source of truth where a diagram tool cannot.
Classify existing artefacts and tools as documentation or architecture and identify misuse.
Apply the five practices for integrating both disciplines in one repository.

Key concepts

Documentation as Code: A discipline that treats documentation as a first-class artefact in the codebase, with the primary goal of communicating how systems work, why decisions were made and how teams should interact with the technology. It targets human audiences.
Architecture as Code as structure and enforcement: The definition of a system's structure in a machine-readable format that can be validated, tested and automated, so that the implementation matches the intended design and constraints are enforced programmatically. It targets both humans and machines.
Model as the source of truth: The key advantage of modelling tools such as CALM and Structurizr: diagrams, documentation and compliance reports are all derived from the same underlying model, which ensures consistency and enables automated validation.
CALM: The Common Architecture Language Model, an open-source specification developed under FINOS and built on a JSON meta-schema. Its format is built around nodes, relationships, interfaces, controls, flows and metadata such as compliance tags.
Limitations of diagram tools: For Architecture as Code, diagram tools make the diagram itself the source of truth, capture limited metadata, allow no automated validation against policies and require manual synchronisation with the implementation.

Teaching plan

15 min	Teacher presents the two purposes with the questions each discipline answers, then the ten-row comparison table.
15 min	Side-by-side reading of a model definition and a text diagram of the same payment flow. Participants list what a tool could check in each.
10 min	Teacher explains how architecture feeds documentation and documentation explains architecture, and the five integration practices.
25 min	Exercise: classify the participant's own artefacts and tools and plan one integration.
10 min	Plenary: where diagrams are being treated as architecture, and what the consequence is.

Discussion

The book uses Mermaid for its own diagrams and explains why. When is an illustrative diagram the right choice, even in an organisation that practises Architecture as Code?
What can an architectural model never convey without accompanying documentation?
If your organisation measured documentation quality and architectural integrity as distinct metrics, which would look better today, and why?

Exercise · 25 minutes

Classify your artefacts: explained or enforced

List ten artefacts that describe the architecture of one system in your own organisation, such as diagrams, guides, decision records, models, modules and policies. For each one decide, using the chapter's comparative framework, whether it is Documentation as Code or Architecture as Code: who its audience is, whether a machine can validate it, and what its source of truth is. Mark every artefact that is used as if it enforced the architecture but is only a diagram or a narrative. Choose one of these and describe how it could be derived from a model instead. Finally write how the five integration practices would apply to this system, one sentence each.

Deliverable: A table of ten classified artefacts with audience, validation and source of truth, one proposal to derive an artefact from a model, and five integration statements.

Self-test

What is the first limitation of diagram tools for Architecture as Code that the chapter lists?
1. They cannot be stored in version control
2. The diagram is the source of truth, with no underlying model to query or validate
3. They cannot be reviewed through pull requests
4. They require a commercial licence for every contributor who edits or reviews a diagram
According to the comparative framework, what is the validation focus of Architecture as Code?
1. Link checking, spelling, grammar and consistency
2. Readability scores and reader satisfaction surveys
3. Page load time and search ranking of the documentation site
4. Compliance verification, policy enforcement and drift detection
Which three of CALM's core components does the chapter use to illustrate the approach?
1. Nodes, relationships and metadata
2. Context, containers and components
3. Actors, use cases and sequences
4. Catalogues, profiles and plans

Chapter 24 · 75 minutes

Best Practices and Lessons Learned

The lesson distils the lessons of practice into seven clusters: code organisation, secure foundations, performance management, governance, people enablement, collaborative ecosystems and continuous improvement. It covers repository, module and versioning practices, security and compliance patterns, global deployment and observability, governance that empowers teams, tooling and supplier strategy, enablement routines for the architecture workspace, risk and resilience, and learning from incidents.

Learning objectives

Describe the seven practice clusters and the maturity indicator of each.
Assess an organisation's practice against the clusters and identify the weakest.
Explain how governance can set approval thresholds by blast radius.
Construct an improvement backlog of small experiments with measures of success.

Key concepts

Seven practice clusters: Code organisation, secure foundations, performance management, governance, people enablement, collaborative ecosystems and continuous improvement, each with a focus area, key capabilities and a maturity indicator, layered in the sequence many organisations follow.
Layered repository strategy: Shared modules live in dedicated libraries with strict versioning, environment-specific overlays capture configuration differences without duplicating logic, and application repositories reference the shared components as dependencies.
Approval thresholds by blast radius: A governance practice in which boards define approval thresholds according to the potential impact of a change, so that low-risk experiments progress quickly while critical systems receive broader scrutiny.
Blameless post-incident review: A review that examines systemic contributors instead of individual mistakes. Action items target tooling upgrades, skill gaps or process refinements, and progress is tracked visibly so that learning becomes part of the culture.
Improvement backlog: A backlog that converts feedback signals, such as production telemetry, customer sentiment, regulatory changes and retrospective findings, into incremental experiments that are each evaluated against a stated hypothesis.

Teaching plan

15 min	Teacher presents the table of seven practice clusters with capabilities and maturity indicators.
15 min	Gallery walk: seven sheets, one per cluster. Participants add one practice their organisation does well and one it lacks under each.
10 min	Teacher deepens three areas: versioning and release management, tooling and supplier strategy with exit clauses, and risk management with rehearsed disaster simulations.
30 min	Exercise: a maturity self-assessment and an improvement backlog.
5 min	Close on the summary: technical excellence, empathetic leadership and responsible governance advancing together.

Discussion

The chapter says effective governance empowers delivery teams rather than restricting them. What does a governance board have to give up, and what does it gain, when approval follows blast radius?
Where a single provider is necessary, the chapter asks for exit clauses and data portability guarantees. How well do your current contracts and architecture support an exit?
Why does the chapter insist that automation must never remove context or accountability, and where have you seen that happen?

Exercise · 30 minutes

A maturity self-assessment and improvement backlog

Assess your own organisation against the seven practice clusters. For each cluster, compare what you observe with the chapter's maturity indicator and rate the cluster as absent, emerging or established, with one sentence of evidence. Choose the two weakest clusters. For each, write three improvement backlog items as experiments: the signal that motivates it (telemetry, an audit finding, a retrospective), the hypothesis, the smallest change that tests it, the measure of success and an owner. For one item, state the approval threshold it needs according to its blast radius. Finally define two leading and two lagging indicators for a balanced scorecard of the programme.

Deliverable: A seven-row assessment table with evidence, six backlog items written as experiments with hypothesis and measure, and four scorecard indicators.

Self-test

What does the chapter call the first visible signal of a mature Architecture as Code programme?
1. A dedicated architecture review board
2. A contract with more than one cloud provider
3. An orderly codebase
4. A FinOps dashboard
How often does the chapter say organisations rehearse disaster simulations to validate recovery time and recovery point objectives?
1. At least annually
2. After incidents
3. Once, when the platform is first built
4. Every working day in production
Which maturity indicator does the cluster table give for the governance cluster?
1. Strategic vendor partnerships and reduced lock-in
2. Empowered delivery teams, automated policy enforcement and fiscal control
3. Latency budgets met and performance balanced with sustainability
4. Multidisciplinary teams and career development

Module 7 · Part G · Future & Wrap-up

Part G looks ahead and closes the book. The module surveys the drivers that will shape the discipline, from AI-assisted automation and post-quantum cryptography to edge computing, sustainability and digital sovereignty, then catalogues the anti-patterns that derail programmes with their recovery measures and early-warning signals, and ends with the six-step adoption strategy and the open question of accountability for machine-authored artefacts. Participants leave with a future-readiness assessment, an anti-pattern diagnosis and an adoption roadmap.

Lecture · 40 minutes

What stays constant when everything else changes

Part G holds two views side by side. Looking forward, the discipline is shaped by intelligent automation, quantum-resistant cryptography, distributed infrastructure, sustainability and sovereignty, and the book's advice is to invest in adaptive capabilities instead of individual technologies. Looking back at how programmes fail, the same causes recur: buying a tool in place of changing an organisation, governing by exception, relying on a few experts. The lecture closes with the book's constants, declarative intent, repeatability, automated testing and continuous delivery, and with the question it leaves open: how human accountability is kept over artefacts that a language model proposed.

9 min	The drivers of change AI services ingest observability data and propose or execute configuration changes; in the EU this meets the risk-based framework of the AI Act, Regulation (EU) 2024/1689. Post-quantum standards exist, and hybrid patterns bridge the transition; algorithm agility belongs in infrastructure definitions. Sustainability moves from optional consideration to design requirement, with carbon-aware scheduling as a concrete pattern.
7 min	Adaptive capability over individual technologies Flexible architectures, modular codebases and automated testing form a foundation that can absorb new paradigms. Platform engineering offers golden paths and self-service with compliance built in. Sovereignty guardrails codify residency rules and approved providers alongside cost controls.
10 min	How programmes fail Six clusters of anti-patterns: strategy, governance, delivery, tooling, culture and sustainability, with blind spots that pass risk from one to the next. Each anti-pattern has a stated recovery, for example time-boxed exceptions stored as code in place of spreadsheets of waivers. Four leading indicators give early warning: contribution imbalance, exception backlog growth, pipeline failure clustering and shadow tooling. A three-step remediation playbook and four severity levels turn detection into response.
7 min	A six-step way in Foundational education, pilot projects, security integration, scaling and automation, readiness and risk management, future readiness. Pilots should demonstrate tangible value without jeopardising critical services. Centres of excellence or platform teams accelerate adoption with reusable modules and reference implementations.
7 min	The open question Version control captures what changed; it does not yet capture whether the reasoning was sound or who held responsibility. The book's challenge: find one AI-assisted decision without a traceable human rationale and write a decision record for it. Making the implicit explicit is the habit on which trustworthy programmes are built.

What the audience takes away

Prepare for the future by building adaptive capabilities, not by betting on individual technologies.
Anti-patterns emerge gradually and can be caught early by a small set of leading indicators and a blameless remediation routine.
Declarative intent, repeatability, automated testing and continuous delivery stay constant as tooling evolves, and human accountability must be kept explicit.

Chapter 25 · 75 minutes

Future Trends in Architecture as Code

The lesson surveys the trends that will shape Architecture as Code. It covers AI and machine learning in infrastructure within the frame of the EU AI Act, post-quantum cryptography with the three NIST standards and hybrid transition patterns, edge computing, environmental sustainability with carbon-aware scheduling, platform engineering, the evolution of FinOps and GitOps, digital sovereignty in Europe, and strategies for building adaptive capabilities.

Learning objectives

Describe the technology drivers the chapter identifies and their implications for architecture definitions.
Name the three post-quantum standards published by NIST and the purpose of each.
Explain carbon-aware scheduling and how it can be expressed in infrastructure provisioning decisions.
Assess an organisation's future readiness in terms of adaptive capabilities.

Key concepts

Predictive scaling: The use of historical datasets and machine learning models to anticipate capacity requirements and scale resources before demand spikes occur, one of the ways AI turns reactive infrastructure into proactive ecosystems.
Post-quantum cryptography standards: The first three NIST standards: ML-KEM (FIPS 203) for key encapsulation and key establishment, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205), a hash-based signature scheme that gives diversity against advances in lattice-based attacks.
Carbon-aware scheduling: Shifting compute-intensive workloads to time periods and regions with cleaner energy mixes, using real-time carbon intensity data from electricity grids to guide infrastructure provisioning decisions.
Digital sovereignty: Control over data residency, privacy and supply-chain risk. The chapter asks teams to codify residency rules and approved EU providers, and points to initiatives such as Gaia-X that provide federated infrastructure frameworks.
Adaptive capabilities: Flexible architectures, modular codebases and automated testing that create a foundation able to absorb new paradigms with minimal disruption. The chapter recommends investing in these instead of relying on individual technologies.

Teaching plan

15 min	Teacher presents the four emerging technology drivers: AI and machine learning, quantum computing, edge computing and sustainability.
15 min	Group work on one driver each: what would have to change in an architecture repository today to be ready for it. Short reports.
10 min	Teacher covers platform engineering, FinOps and GitOps evolution, sovereignty, and the two implementation strategies for future readiness.
25 min	Exercise: a future-readiness assessment with a hybrid cryptography and a carbon-aware element.
10 min	Plenary on balance: experimentation with governance, automation without neglecting ethics.

Discussion

The chapter says AI services may propose or execute configuration changes. Where would you draw the line between proposing and executing in your own estate, and who decides where it lies?
Why does the chapter recommend hybrid patterns that combine classical and post-quantum algorithms during the transition?
What would it take for carbon accounting to become an operational concern in your organisation and not an annual report?

Exercise · 25 minutes

A future-readiness assessment

Assess your own organisation's architecture practice against four drivers from the chapter: AI-assisted automation, post-quantum cryptography, sustainability and digital sovereignty. For each driver write what the organisation does today, what an architecture definition would need to express to be ready, and one adaptive capability (modularity, automated testing, observability) that would make the change cheap. For cryptography, list where algorithms are fixed in your definitions and how they could be made exchangeable. For sustainability, describe one workload that could be scheduled by carbon intensity and the data it would need. Rank the four drivers by urgency and give one reason for each rank.

Deliverable: A four-row readiness table with current state, required expression in code and enabling capability, plus a ranked list of the drivers with reasons.

Self-test

Which NIST standard does the chapter name as the primary algorithm for key encapsulation and key establishment?
1. ML-KEM, standardised as FIPS 203
2. ML-DSA, standardised as FIPS 204
3. SLH-DSA, standardised as FIPS 205
4. FN-DSA (Falcon), still being standardised
What does the chapter recommend investing in to prepare for the future?
1. The single most promising emerging technology
2. A complete rebuild of the platform every three years
3. Adaptive capabilities: flexible architectures, modular codebases and automated testing
4. Long-term exclusive contracts with one technology supplier to secure its product roadmap
What does carbon-aware scheduling do, as the chapter describes it?
1. It switches off all non-production workloads at night
2. It buys carbon credits for each deployment automatically
3. It moves every workload to the cheapest available region
4. It shifts compute-intensive workloads to times and regions with cleaner energy mixes

Chapter 26B · 75 minutes

Anti-Patterns in Architecture as Code Programmes

The lesson catalogues the anti-patterns that derail Architecture as Code programmes. It covers six clusters, strategic, governance and compliance, delivery lifecycle, tooling, cultural and people, and scaling and sustainability, each anti-pattern with its recovery. It then teaches detection through four leading indicators, feedback channels and a risk radar, and response through a three-step remediation playbook and a severity classification.

Learning objectives

Identify anti-patterns from the six clusters in a described programme.
Match each anti-pattern to the recovery the chapter recommends.
Use the four leading indicators to detect anti-patterns early.
Classify an anti-pattern by severity and plan a remediation with the three-step playbook.

Key concepts

Treating AaC as a tool purchase: A strategic anti-pattern in which budgets focus on licences and consultants while change management, governance design and capability building are neglected. Recovery: treat the practice as a product with a roadmap, a coaching budget and a guild that curates shared models.
Audit theatre: Staging elaborate compliance demonstrations just before regulatory reviews, with hand-crafted dashboards and manually executed scripts. Recovery: generate policy evidence automatically in pipelines so auditors can review the repository.
Fork-first module evolution: Teams copy shared modules instead of contributing improvements upstream, leaving dozens of subtly different variants that cannot be upgraded. Recovery: contribution agreements, automatic surfacing of module drift and mentoring through upstream pull requests.
Leading indicators of anti-patterns: Four early signals: repository contribution imbalance, exception backlog growth, pipeline failure clustering and shadow tooling proliferation.
Remediation playbook and severity: Three steps: diagnose the root cause without blame, run a corrective experiment with success metrics, share the learning and watch for regression. Severity is Critical, High, Medium or Low, each with a recommended response.

Teaching plan

15 min	Teacher walks through the six clusters, giving one anti-pattern and its recovery from each.
20 min	Card sort in groups: cards with symptoms on one side are matched to anti-pattern names and recoveries. Groups justify disputed matches.
10 min	Teacher explains leading indicators, feedback channels, the risk radar, the playbook and the severity table.
25 min	Exercise: diagnose a programme and write a remediation plan.
5 min	Close on the summary: equal attention to technology, governance, culture and sustainability.

Discussion

The chapter describes how a central team responds to bypassing with more rigid controls, which accelerates fragmentation. How can that loop be broken?
Why does the chapter treat hero culture as a risk to the programme and not as a sign of commitment by the people concerned?
Which of the four leading indicators could you measure in your repositories this week, and what would you expect to find?

Exercise · 25 minutes

Diagnose a programme and plan the remediation

Take an Architecture as Code initiative, or an automation programme, in your own organisation. Go through the six anti-pattern clusters and note every anti-pattern for which you can give a concrete observation; do not list any without evidence. For each of the four leading indicators, state what you can measure and what the measurement shows or would show. Select the two most serious anti-patterns and classify each by the chapter's severity table. For each, write a remediation following the three steps: how you will diagnose the root cause without blame, the corrective experiment with its success metric and safeguard, and how the learning will be shared and regression watched for.

Deliverable: An evidence-based list of observed anti-patterns, measurements for the four leading indicators, and two remediation plans with severity and success metrics.

Self-test

What recovery does the chapter give for policy drift through manual exceptions?
1. Move the exception list from spreadsheets to a shared wiki page
2. Store time-boxed exceptions as code and evaluate them with the same policy engine
3. Forbid all exceptions and escalate every request to the board
4. Reconcile the exception spreadsheets and email threads by hand before each regulatory audit
A small minority of contributors performs the majority of merges. Which leading indicator is this, and what does it suggest?
1. Pipeline failure clustering, suggesting automation fatigue
2. Exception backlog growth, suggesting governance drift
3. Shadow tooling proliferation, suggesting trust gaps
4. Repository contribution imbalance, suggesting gatekeeping or insufficient coaching
According to the severity table, what is the recommended response to a Critical anti-pattern?
1. Escalate to leadership, pause scaling and address it within the sprint
2. Add it to the backlog and address it within the quarter
3. Monitor it and document it in the risk register
4. Prioritise it in the next planning cycle and assign an owner

Chapter 27 · 60 minutes

Conclusion

The lesson draws the book together. It consolidates the Architecture as Code mindset as an interplay of technical craft and organisational intent, reviews how each capability builds on the previous layer, places the practice in the European regulatory context, presents the six-step adoption strategy, and ends with the unsolved challenge of governing AI-generated architecture decisions and the book's direct challenge to practitioners.

Learning objectives

Summarise the Architecture as Code mindset as the alignment of technical craft and organisational intent.
Sequence an adoption using the six steps of the chapter's strategy.
Explain why the governance of AI-generated architecture decisions remains unsolved.
Write a retrospective decision record for an AI-assisted decision that lacks a traceable human rationale.

Key concepts

Technical and organisational alignment: The chapter's position that cloud platforms, automation tooling and security principles form a single strategic capability, which must be matched by organisational investment in skills, culture and operating models so that new workflows can flourish.
Six-step adoption strategy: Foundational education, pilot projects on a contained low-risk service, security integration, scaling and automation, readiness and risk management before expanding to new domains, and future readiness.
Data residency as a first-class requirement: Treating data residency as a requirement from the earliest blueprints, which keeps infrastructure definitions aligned with EU data boundary commitments, sector-specific controls such as DORA for financial services, and horizontal frameworks such as the Data Governance Act and the Data Act.
Governance of AI-generated architecture decisions: The challenge the chapter calls unsolved: how to audit, attribute and enforce human accountability over machine-authored artefacts. Version control captures what changed, not whether the reasoning was sound or who held responsibility.
The constants: Declarative intent, repeatability, automated testing and continuous delivery, which the chapter says remain constant even as tooling evolves.

Teaching plan

10 min	Teacher recaps the progression of the book: from declarative blueprints through platform, security and governance to organisation and future.
10 min	Walk through the six-step adoption strategy and link each step to work participants produced in earlier modules.
10 min	Discussion of the closing reflection: what version control does and does not capture about a change proposed by a language model.
25 min	Exercise: the book's direct challenge, a retrospective decision record for an AI-assisted decision.
5 min	Participants each state one practice they will start next week. Close of the course content.

Discussion

The chapter says version control cannot yet show how to roll back a conceptual mistake as opposed to a configuration error. What would a record need to contain to make that possible?
Which step of the six-step strategy has your organisation skipped or done out of order, and what was the consequence?
Of the four constants the chapter names, which is weakest in your current practice, and what is the smallest change that would strengthen it?

Exercise · 25 minutes

A retrospective decision record for an AI-assisted decision

Take up the chapter's direct challenge. Identify one decision in your own architecture estate where an AI system proposed or drafted the pattern, configuration or control, and where no traceable human rationale exists. Write an Architecture Decision Record for it retrospectively: status, context (including what the AI system proposed and on what input), the decision as it stands, the consequences, and the named person who now holds accountability for it. State what evidence shows the decision is still appropriate and when it will be reviewed. Add a short note on what your team would record at the time of the decision in future, and with whom in your community of practice you will share the approach.

Deliverable: One retrospective ADR with a named accountable person and review date, plus a half-page note on recording practice for future AI-assisted decisions.

Self-test

Which challenge does the chapter describe as remaining genuinely unsolved?
1. The choice between mono-repo and multi-repo topologies
2. The measurement of cloud costs across several providers
3. The governance of AI-generated architecture decisions
4. The rendering of diagrams from textual models
What is the first step of the chapter's step-by-step adoption strategy?
1. Scaling towards container orchestration and platform capabilities
2. Foundational education in principles and version control
3. Security integration into every delivery workflow
4. Tracking emerging trends and sustainability expectations
What does the fifth step of the adoption strategy ask organisations to do before expanding to new domains?
1. Validate readiness with the prerequisites framework and consult the anti-patterns
2. Replace the pilot team with an external centre of excellence that curates reusable modules
3. Complete the migration of every legacy system
4. Obtain a conformity assessment for all automation tooling

Answers to the self-tests

Chapter 1	1B · 2D · 3A (1) The chapter names microservice complexity as the primary driver: each additional service adds APIs, contracts and deployment topologies that outpace what static diagrams or isolated configuration repositories can keep synchronised. (2) The definition contrasts live, executable specifications that stay synchronised with the running estate against design artefacts that linger as aspirations. (3) The chapter states that adoptability, extensibility and productivity are the three design criteria, and gives each a subsection of its own.
Chapter 26A	1C · 2A · 3D (1) The scoring guidance places 40 to 59 points in the band of partial readiness, where critical gaps are addressed before scaling. 60 to 75 means ready, below 40 means foundation work. (2) Automation maturity was high in the case. The gaps were knowledge artefacts in static slide decks, psychological safety that varied across regions, and funding tied to annual projects. (3) Tool-first enthusiasm is defined as buying modelling platforms without addressing the cultural foundations, which produces shelfware.
Chapter 2	1B · 2C · 3D (1) The chapter notes that protected branch rules bind administrators only when the rule's option not to allow bypassing the settings is enabled, since administrators are otherwise exempt by default. (2) Most non-functional requirements are quantitative, so they translate into executable tests with objective pass or fail results, while functional requirements need stakeholder validation of business intent. (3) The drift table lists emergency patches, urgent fixes applied under pressure without following standard processes, whose impact is bypassed guardrails and undocumented changes. The other options are countermeasures, not causes.
Chapter 3	1A · 2C · 3B (1) The table gives codified guardrails, architectural policies and structural models as the primary artefact of Architecture as Code; environment templates, resource modules and orchestration logic belong to Infrastructure as Code. (2) The chapter argues that architectural definitions are long-lived assets that should reflect reality continuously, not periodically, so the canonical model should never diverge far from the development state. (3) The mono-repo makes cross-cutting changes atomic and configures shared tooling once; its principal drawback is scale, as clone times, CI run durations and merge-conflict frequency grow with the repository.
Chapter 4	1D · 2B · 3A (1) Numbering is permanent: even a deprecated or replaced ADR retains its number, and a new ADR is created to supersede it so the historical context is preserved. (2) The chapter cites the Thoughtworks Technology Radar technique, which recommends storing decision records in source control rather than a wiki so that they remain in sync with the code itself. (3) The negative consequences listed are the learning curve, complexity in state file management, cost of commercial features and the licence change. Multi-cloud support, a declarative syntax and a large community are listed as positives.
Chapter 5	1C · 2A · 3D (1) The chapter attributes data protection by design and by default to Article 25 and translates it into automated scanning, data-residency validation and audit-trail generation in the pipeline. (2) For production, release gates require explicit architect approval plus a policy-as-code attestation uploaded by the pipeline before the traffic switch executes. (3) Policy breach density is the number of failing policy checks divided by total runs in each environment. The other options describe the drift diff count, the rollback recovery time and the stability index.
Chapter 6	1B · 2D · 3A (1) The System Context level shows how the system fits into its environment, highlighting users and neighbouring systems, for both technical and non-technical stakeholders. (2) Layout changes made in the diagram editor are saved to the JSON file next to the DSL. The DSL holds the model and view definitions and the JSON the manual layout, so both are committed. (3) The matrix recommends Mermaid for quick diagrams in a README because of native GitHub support and simple syntax, and Structurizr for large-scale system architecture and Architecture as Code practice.
Chapter 7	1B · 2C · 3A (1) The chapter's minimal Gatekeeper example is a constraint that prohibits privileged containers, shown together with an Argo CD Application manifest that reconciles desired state. (2) Because Git is the source of truth and tools such as Argo CD and Flux reconcile clusters to it, rollbacks become a matter of reverting commits, with the audit trail preserved. (3) Crossplane, the Operator Framework and similar projects expose cloud resources as custom resource definitions, so databases, queues or networking can be provisioned through the Kubernetes API.
Chapter 8	1D · 2B · 3A (1) A saga is a sequence of local transactions, each triggering the next through an event or message; if any step fails, compensating transactions reverse the completed steps. (2) The chapter says pipelines should verify that each service consumes the authorised modules and that deviations are reviewed through architecture decision records. (3) Coupling telemetry derives dependency graphs and flags hotspots where a service has many synchronous consumers or repeatedly changes its schema.
Chapter 9	1B · 2D · 3A (1) Zero Trust Architecture is guided by never trust, always verify, requiring explicit validation of every user, device and network transaction regardless of location or prior authentication. (2) Repudiation is denying actions without a proper audit trail; the listed concerns are missing version control history, inadequate logging of infrastructure changes and untracked deployments. (3) State files capture live inventories, secrets and the policy decisions enforced across environments, so the baseline is a remote backend, locking during writes and restricted access.
Chapter 9B	1C · 2A · 3D (1) The chapter's advanced GDPR compliance example shows how Article 32 of the GDPR can be translated into automated checks with Open Policy Agent. (2) The monitoring rules include manual state downloads or unlock operations executed outside approved pipeline identities, which may indicate credential abuse. (3) The chapter states that the integration allows infrastructure-level responses: compromised components can be isolated or redeployed from known-good definitions and network policies adjusted to contain lateral movement.
Chapter 9C	1C · 2A · 3B (1) The example policy allows deployments only when every high or critical risk is either mitigated by automated controls or accompanied by a time-bound exception with expiry and approval chain. (2) Playbooks should subscribe to signals, assess risk ratings by referencing the risk-as-code repository, act by triggering infrastructure changes, and document activities in immutable logs and tickets. (3) Threat handling begins by ingesting intelligence in STIX and TAXII, the OASIS standards for describing and exchanging cyber threat intelligence.
Chapter 10	1D · 2B · 3A (1) Profiles tailor catalogues to organisation-specific needs and help harmonise overlapping regulations, as in the financial institution example that overlays GDPR Article 32 on imported controls. (2) Scripted automation in Python, Bash and PowerShell improved speed but brought duplication, drift, brittle scripts and difficult enterprise sharing. (3) The roadmap starts with a policy inventory: catalogue existing manual controls, identify overlaps and prioritise high-risk scenarios. Pilot automation follows, in a non-production pipeline.
Chapter 11	1C · 2B · 3D (1) The metrics table sets time to policy adoption at no more than 5 business days. The 48-hour target belongs to remediation lead time. (2) Review and approval uses pull requests with templates, with policy-as-code validations, required reviewers and signed commits as automated controls, giving formal approval gates. (3) The chapter advises starting with low-risk governance components so the organisation can gather feedback and fine-tune the approach before scaling to critical controls.
Chapter 12	1A · 2C · 3B (1) SEC-ID-001 is titled Enforce MFA for human identities. Its policy module and evidence pipeline execute once and satisfy several attestations, with IAM-01 as the internal catalogue entry. (2) The fifth stage, governance reinforcement, produces updated policies, remediation plans and training, and the loop closes as governance informs the next regulatory intelligence cycle. (3) The section is headed as speculative and says the topics are exploratory, to be treated as forward-looking guidance rather than current-state requirements.
Chapter 15A	1C · 2D · 3B (1) The characteristics are deterministic capture, traceability, reusability and version control. Evidence is generated from automated checks, not manual screenshots, and kept alongside policies and blueprints. (2) A SLSA provenance attestation records the build platform, the external parameters that defined the build, the resolved dependencies and the output digests, signed by the build platform's identity. (3) At indexing, the manifest is registered in an evidence catalogue so that auditors or tools can later query by control identifier or framework. Capture and expiry are separate stages.
Chapter 13	1B · 2D · 3A (1) The chapter notes that the two act at different points: Open Policy Agent evaluates preventively in the pipeline before deployment, while AWS Config Rules are detective by default. (2) Unit tests validate resource configurations, variable validations, output consistency and module interface contracts without deploying infrastructure. Load, failover and end-to-end checks belong to higher layers. (3) Security scanning and policy testing offer high coverage with moderate complexity, so the chapter suggests starting there and adding end-to-end tests where the risk justifies their cost.
Chapter 14	1C · 2A · 3D (1) The Pilot stage establishes the landing zone and delivers the first reusable module, led by the platform squad and a product team. The other options are Discovery, Scale and Optimise. (2) Rollback readiness asks whether there is a tested rollback script or inverse plan that can run without manual edits, and whether feature flags or traffic controls are aligned with the release. (3) For version compatibility the mitigation is staged rollouts, compatibility matrices and automated integration tests, with version pinning as best practice. The first two options answer state management and dependency coordination.
Chapter 15B	1B · 2C · 3A (1) Baseline before committing: the chapter advises analysing at least 30 to 90 days of usage data to identify stable, predictable workloads suitable for reservation. (2) Combine with rightsizing: committing to the wrong instance size locks in waste, so recommendations should be acted on before a multi-year commitment is made. (3) ResourceQuotas set hard limits per namespace, preventing over-allocation and enforcing budget constraints. LimitRanges define defaults and maxima for individual containers.
Chapter 16	1D · 2A · 3B (1) Lift-and-improve selectively re-architects critical components while keeping most unchanged, and the table lists it as best suited for phased modernisation, risk-balanced approaches and the majority of enterprise migrations. (2) The import is a reviewed change set followed by drift detection, so that the template is proven to describe reality before any further update touches the resources. (3) Pilot projects with non-critical systems enable team learning and process refinement before critical systems migration commences.
Chapter 17	1B · 2D · 3A (1) Product-aligned teams, the fourth stage, are autonomous within guardrails, supported by self-service platforms and full automation. Tickets and shared backlogs describe the first two stages. (2) Pilots prove technical feasibility while creating reference stories that persuade sceptical stakeholders; the chapter recommends low-risk, high-visibility use cases. (3) The framework emphasises leading indicators that teams can influence directly, and balances technical, business and cultural dimensions instead of focusing narrowly on infrastructure metrics.
Chapter 18	1C · 2A · 3D (1) The four levels are Foundation (basic operations), Practitioner (infrastructure automation), Advanced (architecture design) and Expert (platform leadership). (2) Platform teams act as internal service providers and own the common toolchains, guardrails and reusable modules that let application teams move quickly without sacrificing governance. (3) Balanced scorecards combine operational indicators drawn from the DORA software delivery metrics with knowledge-sharing and cross-team collaboration contributions.
Chapter 19	1C · 2B · 3A (1) The three differences are that the artefacts are executable, that management inputs follow the same change management discipline as software features, and that telemetry instruments every directive. (2) Step four, scheduled Discussion reviews, has automation flag Discussions with no activity for 90 days, prompting closure or renewal, alongside monthly leadership reviews. (3) Change requests reference management policies stored as code, enabling automated approval for low-risk changes while routing higher-risk items to the appropriate leaders, with every decision logged.
Chapter 23	1D · 2B · 3C (1) The chapter names structured representation, version control and automatability as the common DNA into which soft artefacts are converted. (2) Documentation as Code is the communication layer, providing narratives around rules and architecture, self-service and feedback loops. Compliance as Code is the quality engine and Architecture as Code the hub. (3) After the rule changes, the architectural models flag components lacking encryption, Documentation as Code generates a new section about the requirement, and dashboards notify teams.
Chapter 20	1B · 2D · 3A (1) External communication passes through human review before publication. The chapter summarises the rule as agents draft, humans approve. (2) The quality measures set at least eighty-five per cent coverage of critical components, with lead time within two sprints and documentation changes within twenty-four hours of a decision. (3) The Project Manager surfaces the conflict to the project owner with both perspectives clearly articulated, and the human owner resolves it.
Chapter 21	1C · 2A · 3B (1) The pipeline example carries an explicit warning that searching for encryption keywords is not a meaningful GDPR compliance check, and the learning objectives point to policy-as-code tooling instead. (2) Policy catalogues should differentiate between providers that are inherently sovereign and those that become acceptable only when their EU-only controls are in force. (3) The dimensions are technical transformation, organisational change, cultural evolution and competence development, to be balanced with one another.
Chapter 22	1B · 2D · 3A (1) With diagram tools the diagram is the primary artefact; there is no underlying model that can be queried, validated or used to drive automation. The diagrams are still version-controllable and reviewable. (2) The framework gives compliance verification, policy enforcement and drift detection for Architecture as Code, and link checking, spelling, grammar and consistency for Documentation as Code. (3) CALM is built around nodes, relationships, interfaces, controls, flows and metadata. The chapter illustrates it with three: nodes (services, databases, networks, people), relationships (connections, data flows, dependencies) and metadata (compliance tags, operational data, custom attributes).
Chapter 24	1C · 2A · 3B (1) Establishing an orderly codebase is described as the first visible signal of maturity: clear structure shortens feedback loops and accelerates onboarding. (2) Organisations rehearse disaster simulations at least annually, validating recovery time objectives and recovery point objectives under realistic conditions. (3) For governance the indicator is empowered delivery teams, automated policy enforcement and fiscal control. The other options belong to collaborative ecosystems, performance management and people enablement.
Chapter 25	1A · 2C · 3D (1) ML-KEM (FIPS 203) is the primary algorithm for key encapsulation and key establishment. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are signature algorithms. (2) Preparing for the future requires investment in adaptive capabilities rather than reliance on individual technologies, so that new paradigms can be absorbed with minimal disruption. (3) Carbon-aware scheduling shifts compute-intensive workloads to time periods and regions with cleaner energy mixes, using real-time carbon intensity data.
Chapter 26B	1B · 2D · 3A (1) Exceptions are stored as time-boxed code and evaluated with the same policy engine as the rules they relax, so they surface automatically in pipelines until the owning team resolves them. (2) Repository contribution imbalance, a small minority performing the majority of merges, suggests gatekeeping or insufficient coaching. (3) A Critical anti-pattern is actively blocking delivery or causing security incidents; the response is to escalate to leadership, pause scaling and address it within the sprint.
Chapter 27	1C · 2B · 3A (1) The closing reflection names the governance of AI-generated architecture decisions as unsolved: the profession must work out how to audit, attribute and enforce human accountability over machine-authored artefacts. (2) The strategy begins with foundational education: a common understanding of the principles and disciplined version control practices, followed by pilot projects. (3) Step five, readiness and risk management, validates organisational readiness using the framework of Chapter 26A and consults Chapter 26B to anticipate and mitigate common pitfalls.

Final assignment

An Architecture as Code blueprint for one system in your organisation. Choose one real system in your own organisation and produce the blueprint for governing its architecture as code. The blueprint brings together artefacts from every module: the readiness of the organisation, the repository and branching design, decision records, a C4 model, a validating pipeline with a promotion ladder, at least one control carried from policy rule through governance workflow and Control Mapping Matrix to an evidence manifest, a test strategy, cost governance, a team charter and an anti-pattern diagnosis. Everything is kept in a version-controlled repository and reviewed through pull requests by a fellow participant. The blueprint must be specific enough that a pilot could start from it, and honest about what the organisation cannot yet do.

Assessment criteria

Fidelity: terms, artefacts and methods are used as the book defines them, and every claim about the organisation is supported by evidence
Traceability: decisions, models, policies and evidence reference one another, so that a reviewer can follow one change from rationale to proof
Enforceability: rules are written so that a machine could check them, and it is stated what blocks a merge or a promotion
Realism: the pilot is contained and low-risk, gaps are named, and human accountability is explicit for consequential decisions
Review quality: the participant's pull requests show substantive review given and received