Fundamental Principles of Architecture as Code · Architecture as Code: the course

All courses / Architecture as Code / Module 1 / Chapter 2

Learning objectives

After the lesson the participant can:

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.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Causes of drift and their impact

Match each cause of architectural drift to the impact the chapter's table gives for it.

Interactive exercise 2 · Scenario

Drift that turned out to be intended

Read the situation and choose what the chapter's reasoning leads to. Each choice gives feedback.

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?

Written exercise

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.

Your work

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

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?
Show the answer
B. Enabling the option that disallows bypassing the settings
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.
How does the chapter characterise the predominant way non-functional requirements are checked as code?
Show the answer
C. Automated testing with objective, quantitative thresholds
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.
Which of the following is listed in the chapter as a cause of architectural drift?
Show the answer
D. Emergency patches applied without the standard process
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.