Week 1: Architecture as a Decision Problem

🎯 Learning objectives

• I can explain, using the four production systems, why no structure dominates and why each failure was a mismatch.
• I know Maxim 1: patterns are neither good nor bad; only the fit is.
• I can explain architecture as hard-to-reverse structural decisions and distinguish it from design and implementation by cost of change.
• I can name the five elements of the framework: R(a), C(p), fit(a,p), ADR, measurement contract.
• I can explain the two AI axes: Axis A (tool in the process), Axis B (runtime component).
• I know the six assumptions A1–A6 and which framework element each one justifies.
• I can derive Maxim 2 – match, document, measure – from assumptions A1, A2, A3 and A5.
• I can explain why the twelve dimensions D1–D12 are recurring, measurable engineering questions in five groups.

🧑‍🏫 Theory

Lecture 1: Architecture as a Decision Problem · 2 lessons lecture + 2 lessons exercise
This lecture introduces the module and frames architecture selection as a decidable matching problem: four production systems, two facts, a five-element framework, six assumptions A1–A6, two maxims.

• Four production systems (Stack Overflow, Monzo, Segment, Prime Video) show two facts: structures differ radically for similar problems, and no structure dominates; the failures were mismatches, not bad patterns.
• Maxim 1: patterns are neither good nor bad; only the fit between a requirements profile and a capability profile is. The decision problem: choose among non-dominated alternatives, expensive to reverse.
• Architecture = the hard-to-reverse structural decisions that determine quality behaviour; design and implementation are cheaper to reverse. ISO/IEC/IEEE 42010:2022 obliges recording decisions with rationale. Two refusals: no fashion, no taste.
• Five framework elements: requirements profile R(a) (demand), capability profile C(p) (supply), the ordinal, non-compensatory fit(a,p), the ADR and the measurement contract; both profiles span the same twelve dimensions.
• AI enters twice: Axis A, a tool in the development process (changing how we decide); Axis B, a runtime component bringing non-determinism, latency and per-call cost (changing what we decide).
• Load-bearing assumptions: A1 architecture = hard-to-reverse decisions (justifies the ADR); A2 everything is a trade-off, dominance does not occur (matching problem); A3 quality attributes, not functionality, drive architecture (twelve dimensions).
• A4 requirements = measurable scenarios (demand-side method); A5 a decision is a hypothesis, continuously tested (measurement contract); A6 AI extends the space, not the method (D12 plus eval harness).
• Maxim 2: architecture selection is matching (A2, A3); the match must be documented and continuously measured (A1, A5). The red line: demand → supply → match → record → test.
• Three observations: engineering questions recur, ask how well rather than what, and each has a number; the twelve dimensions D1–D12 are these questions – grouped in five groups, named, measurable.

📎 Materials: Slide set of Lecture 1 (added below by the lecturer) · Script: Part I – Sections 1 (The Decision Problem) and 2 (The Coordinate System: Twelve Profile Dimensions). Section 2: introduced this week, completed in week 2.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part I – Sections 1 (The Decision Problem) and 2 (The Coordinate System: Twelve Profile Dimensions). Section 2: introduced this week, completed in week 2.

🧩 Exercise session: Project kickoff: form teams, set up repository and tooling including agentic coding tools, build domain understanding, sketch a first ontology and collect raw stakeholder wishes.

🛠️ Project work this week · Milestone M1 – Requirements and Ontology (weeks 1–3)

• Form your team and set up the project: repository, environment and agentic coding tools.
• Build domain understanding of the investment domain and sketch a first domain model and ontology.
• Collect raw stakeholder wishes – unfiltered, unweighted; next week they become scenarios, in week 3 your requirements profile (Deliverable A1).
• Study the exercise sheet: the AI-augmented portfolio intelligence platform – prices and news in, deterministic services, an LLM Insight component, a multi-agent advisor, API-first.

No deliverable is due this week.

Week 2: The Twelve Dimensions – and How Requirements Become Measurable

🎯 Learning objectives

• I can name the twelve profile dimensions D1–D12, their five groups and the recurring question behind each.
• I can give a response measure and a measurement instrument for each dimension – no instrument, no dimension.
• I know the three admission conditions for a dimension and the ISO/IEC 25010:2023 changes relevant to AI systems.
• I can distinguish quality attribute requirements from functional requirements and explain why only the former drive structure.
• I can explain what an architecturally significant requirement (ASR) is and why it must be elicited in a QAW.
• I can construct a six-part quality attribute scenario with a numeric response measure, also for an AI component.
• I can derive the twelve weights from a utility tree: (H,H) leaves under an attribute give High.
• I can assemble R(a) from weights, workload shape S(a) and hard constraints K(a), treating constraints as knock-out filters.

🧑‍🏫 Theory

Lecture 2: The Twelve Dimensions – and How Requirements Become Measurable · 2 lessons lecture + 2 lessons exercise
This lecture completes the twelve profile dimensions D1–D12, each with its measurement instrument, then builds the demand side R(a): scenarios, QAW, utility tree, workload shape and hard constraints.

• Twelve dimensions: load and speed (D1–D3), correctness and trust (D4–D6), change and delivery (D7–D9), economics and organisation (D10–D11), AI integrability (D12); each admitted only with standard anchoring, discrimination and instrumentation.
• No instrument, no dimension: D1–D6 measure throughput at k× replication, sustained ingest rate, p50/p95/p99 latency, invariant violations (target 0 for ledgers), SLO attainment and blast radius, audit-trail reconstruction time.
• D7–D11 measure change dispersion and boundary violations, time from empty repository to first release, deployment frequency and change failure rate, cost per request, deployments per developer per day.
• D12 needs a queue, a port and a measurement point, instrumented by the eval harness; ISO/IEC 25010:2023 (Safety, Flexibility, Security with resistance) supplies the names without private extensions (assumption A6).
• ASRs are vague and implicit: a Quality Attribute Workshop (QAW) elicits them; the six-part scenario with a response measure makes them testable and needs no extension for AI components (assumption A6).
• The utility tree (ATAM) rates each leaf H/M/L on business importance and achievement difficulty; (H,H) leaves under an attribute make that dimension High – a veto claim in the match.
• R(a) = (w1, …, w12; S(a); K(a)) – weights, measured workload shape, constraints as knock-out filters, never weights; for the advisory platform C10: High on D6, D7, D9, D10, D12.
• Maxim 6. An architecture decision without a response measure is an opinion; with a response measure and a fitness function it is a testable hypothesis.

📎 Materials: Slide set of Lecture 2 (added below by the lecturer) · Script: Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.

Also before the lecture:

• Bring the raw stakeholder wishes collected at the kickoff – unfiltered and unweighted; this week they become scenarios.
• Have the kickoff outputs in place: team, repository and tooling (including agentic coding tools), domain understanding, first ontology sketch.

🧩 Exercise session: Requirements workshop I: in stakeholder roles the team runs a compressed QAW, refines the top scenarios into the six-part form with numeric response measures and begins the utility tree.

🛠️ Project work this week · Milestone M1 – Requirements and Ontology (weeks 1–3)

• Run a compressed QAW in stakeholder roles (retail customer, compliance officer, operations engineer, product owner): brainstorm, consolidate and prioritise scenarios from your raw stakeholder wishes.
• Refine the top candidates into six-part scenarios, each with a numeric response measure: at least eight scenarios, at least three for the AI components (answer correctness, token cost per request, provider migration).
• Assemble a first utility tree and identify the (H,H) leaves – they become the weights of your requirements profile R(platform) in week 3 (Deliverable A1).
• Keep the domain model and ontology of the investment domain moving – both belong to the M1 requirements dossier.

No deliverable is due this week.

Week 3: The Supply Side, the Match, and the Decision Record

🎯 Learning objectives

• I know the seven candidate patterns L, MM, HX, MS, EDA, PF, SL and their signature strength and cost.
• I can distinguish an architectural pattern from an architectural tactic and explain why the framework keeps them apart.
• I can derive a capability rating c_i(p) from tactics, published star ratings and documented production systems.
• I can explain, via tactics, why EDA rates ++ on D7 and MS rates −− on D4.
• I can run the three-stage, non-compensatory fit procedure: knock-outs and shape gate, vetoes, ordinal reading with sensitivity analysis.
• I can defend the C10 mini-match verdict against L, MM and MS and explain why the MS veto relaxes.
• I can explain why a weighted sum over ordinal ratings fails its three preconditions and produces pseudo-precision.
• I can record an architecture decision as a MADR (drivers, options, consequences) and attach a measurement contract.

🧑‍🏫 Theory

Lecture 3: The Supply Side, the Match, and the Decision Record · 2 lessons lecture + 2 lessons exercise
Lecture 3 completes Part I: the supply side C(p) from tactics, the three-stage non-compensatory match run live on C10, and the decision record (ADR/MADR) with its measurement contract.

• Seven candidates form the set P (L, MM, HX, MS, EDA, PF, SL), each with a signature strength and cost; HX composes with the other six rather than competing.
• Patterns are macro-structures that bundle tactics (elementary design decisions on one quality attribute); the chain topology → tactics → responses makes every ++ and −− explainable by construction.
• An ordinal rating c_i(p) is derived from tactics analysis, then published star ratings (deviations footnoted), then documented production systems; C(p) = (c_1(p), …, c_12(p); S(p)) adds the native workload shape.
• The three-stage match fit(a,p) is non-compensatory: knock-outs and the workload-shape gate; vetoes on High dimensions, liftable only by documented mitigations; ordinal reading with sensitivity analysis – a ranking with exclusions.
• Mini-match R(C10) against L, MM, MS: L fails two unmitigated vetoes (−), the MS cost veto relaxes under mitigation (○), the hexagonal modular monolith wins (++) – the project architecture.
• A weighted sum fails three preconditions (cardinal scales, preferential independence, weights as trade-off rates) and yields pseudo-precision; the 7 × 10 matrix is an explication instrument, not a computation.
• An ADR records one decision (title, status, context, decision, consequences): co-located in the repository, brief, immutable. MADR adds decision drivers and considered options – one matrix row in narrative form.
• Every ADR ends with a measurement contract: fitness functions and thresholds as CI gates, automated tests and telemetry alarms, DORA metrics in operation; a breach leads to a superseding ADR.

📎 Materials: Slide set of Lecture 3 (added below by the lecturer) · Script: Part I – Sections 4 (Constructing the Supply Side: The Capability Profile C(p)), 5 (The Match: fit(a,p)) and 6 (Recording and Testing the Decision).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part I – Sections 4 (Constructing the Supply Side: The Capability Profile C(p)), 5 (The Match: fit(a,p)) and 6 (Recording and Testing the Decision).

Also before the lecture:

• Bring the results of requirements workshop I (QAW scenarios and utility tree) – A1 is due at the end of week 3.
• Have R(C10) from Lecture 2 at hand: the worked mini-match runs the advisory platform against three candidates.

🧩 Exercise session: Requirements workshop II: teams finalise R(platform) – weights, workload shape and knock-out constraints – fix the ontology as a contract, and complete the A1 requirements dossier (scenarios, utility tree, R(a)).

🛠️ Project work this week · Milestone M1 – Requirements and Ontology (weeks 1–3)

• Finalise R(platform) – weights, workload shape and hard constraints (the knock-outs of stage 1).
• Finalise the domain model and fix the ontology of the investment domain as a contract.
• Check the scenario set: at least eight quality attribute scenarios with response measures, at least three for the AI components (answer correctness, token cost per request, provider migration), plus the utility tree.
• Confirm that the project and tooling setup (repository, environment, agentic dev tools) is complete.
• Deliver A1 (end of week 3): the requirements dossier – scenarios, utility tree and R(platform) with weights, workload shape and hard constraints.

Week 4: Patterns I – Layered, Modular Monolith, Hexagonal

🎯 Learning objectives

• I can derive a capability profile C(p) from a pattern's problem and topology, with a structural reason per cell.
• I know the vocabulary of the three patterns: architecture quantum, technical versus domain partitioning, bounded context, ports and adapters.
• I can explain why L rates ++ on D4, D8, D10 yet pays on every axis of change and scale.
• I can read the MM column against L and show what domain partitioning buys at constant quantum count.
• I can explain why boundary conformance in a modular monolith must be a CI subject, not a diagram convention.
• I know the hexagonal dependency rule: adapters depend on ports, the core depends on nothing outside itself.
• I can explain why an HX port is the anti-corruption layer that makes an LLM component swappable and mockable.
• I can judge which of L, MM or MM+HX carries a requirements profile, using the selection signals.

🧑‍🏫 Theory

Lecture 4: Patterns I – Layered, Modular Monolith, Hexagonal · 2 lessons lecture + 2 lessons exercise
This lecture opens Part II and derives the capability profiles of L, MM and HX inductively – problem, topology, twelve dimensions, engineering consequences, and open-source systems to build and study.

• L partitions a system into horizontal technical layers with a downward dependency rule; the whole system is exactly one architecture quantum – one unit of deployment, scaling and failure.
• L buys the lowest entry cost in the catalogue (++ on D4, D8, D10) and pays on every axis of change and scale – a specific trade, not a defect.
• MM keeps one deployable but partitions its interior by domain: each module owns one bounded context and its data and communicates only through published module APIs or in-process events.
• Against L at constant quantum count, MM's domain cut lifts D7 and D9 from − to + while D4 and D10 stay ++; the price is permanent boundary governance.
• Boundary conformance is a CI subject (ArchUnit, Spring Modulith, Packwerk), not a matter of good intentions; the default: domain partitioning now, distribution only when a measured requirement demands it.
• HX organises dependencies: the core defines technology-neutral ports, adapters plug in, all source-code dependencies point inwards; not a distribution style but a delta profile that composes with the other six.
• HX's delta: ++ on D7 (technology migrations become localised adapter tasks), D9 (hermetic domain tests) and D12 (an imposed anti-corruption layer for LLM components), bought with − on D8.
• L → MM isolates the partitioning axis and HX composes on top: the hexagonal modular monolith won last week's C10 mini-match and is the project's architecture.

📎 Materials: Slide set of Lecture 4 (added below by the lecturer) · Script: Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).

Also before the lecture:

• Bring the finalised R(platform) from Deliverable A1 (weights, workload shape, knock-out constraints) – this week's exercise shortlists L, MM and MM+HX against it.

🧩 Exercise session: Architecture study I (2 lessons): the teams inspect Apache Fineract and cosmicpython/code for boundaries and ports, shortlist L, MM or MM+HX for the platform core against R(platform) from A1, and draft the C4 context and container diagrams.

🛠️ Project work this week · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)

• Inspect Apache Fineract (34 fineract-* Gradle modules composed into one deployable, plus a custom/ extension directory) and cosmicpython/code (domain/, service_layer/, adapters/, entrypoints/) – find the boundaries, find the ports.
• Apply the two-minute habit first: check licence and maintenance status (last commit, open issues) – one of this week's study objects carries a no-derivatives licence, and finding it yourself is part of the exercise.
• Shortlist candidates for the platform core – which of L, MM or MM+HX carries your requirements profile R(platform) from A1? – and begin evaluating candidate architectures for the deterministic core and the edges.
• Draw the C4 context and container diagrams of your platform draft; the C4-style diagram is part of the architecture dossier (Deliverable A2, end of week 7).
• Do not start production code before the design-review gate at the end of week 7; exploratory spikes are allowed.

No deliverable is due this week.

Week 5: Patterns II – Microservices and Event-Driven Architecture

🎯 Learning objectives

• I can derive the MS and EDA capability profiles from their tactics and quantum boundaries, cell by cell.
• I can explain why compensation in a saga is not rollback and why D4 = −− is structural for MS.
• I can judge when MS is legitimately forced (D11 measurably binding) and when to avoid it.
• I know the distributed monolith and its measures: lockstep release ratio, cross-service change dispersion, synchronised version bumps.
• I can distinguish the broker and mediator topologies of EDA and name what each gives and takes.
• I can explain EDA's threefold decoupling and why D4, D8 and D9 are the same coin's other side.
• I can explain why EDA is rated ++ on D12: queues absorb what LLMs are worst at.
• I know the seven resilience primitives for distributed edges and the measure attached to each.

🧑‍🏫 Theory

Lecture 5: Patterns II – Microservices and Event-Driven Architecture · 2 lessons lecture + 2 lessons exercise
This lecture derives the capability profiles of the two distributed patterns, MS and EDA, from their tactics and quantum boundaries, and introduces the resilience primitives for distributed edges.

• MS and EDA form the catalogue's distributed half: MS distributes by domain, EDA decouples in time; both multiply quanta and pay D8 = −− before the first feature ships.
• MS – services around business capabilities, one quantum each, database per service – is the only pattern rated ++ on D11: adopt for measured organisational scale, never for traffic alone.
• The bill is structural: D4 = −− because cross-service consistency needs sagas, and compensation is not rollback; D8 and D10 = −− because the premium is platform staffing.
• The distributed monolith is the most common failure outcome, measurable as lockstep release ratio; Monzo and Segment show viability depends on where boundaries run (Maxim 4) and central platform investment.
• EDA connects asynchronously decoupled producers and consumers through a messaging substrate; they share event schemas, never knowledge of each other. Broker topology maximises scaling, mediator topology gives workflow visibility.
• EDA's decoupling is threefold (topology, time, organisation); eventual consistency moves correctness into the design, keeping D4 and D8 at −− and D9 at −; no broker removes the trade.
• EDA is rated ++ on D12: queues absorb LLM latency, rate limits and outages, and the event log doubles as audit journal; EDA takes the project's edges, MM+HX core unchanged.
• The seven resilience primitives – timeout, retry with backoff, circuit breaker, bulkhead, fallback, dead-letter queue, idempotent consumer – are constitutive tactics, each becoming a fitness function in the measurement contract.

📎 Materials: Slide set of Lecture 5 (added below by the lecturer) · Script: Part II – Sections 11 (MS – Microservices) and 12 (EDA – Event-Driven Architecture).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part II – Sections 11 (MS – Microservices) and 12 (EDA – Event-Driven Architecture).

🧩 Exercise session: Architecture study II (2 lessons): teams design the edges of their platform – the ingestion queue and resilience against external-API failure – sketch the service contracts and run the matrix pre-filter of the candidate patterns against their A1 requirements profile.

🛠️ Project work this week · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)

• Design the edges of your platform: the ingestion queue for analysis requests, and resilience against external-API failure – timeouts, retries with backoff, circuit breaker, fallback and DLQ on every external call.
• Sketch the service contracts: which events exist, which schemas, who produces and who consumes.
• Run the matrix pre-filter: hold your A1 requirements profile R(platform) against all candidate patterns seen so far and record which survive stage 1 (shape gate) and stage 2 (vetoes) – next week's full three-stage match builds on it.
• Study this week's reference systems: Google's Online Boutique (twelve polyglot services, gRPC contracts) and Home Assistant's homeassistant/core.py (Event, EventBus, async_fire) – read exactly that one file.
• Record the edge design and contracts in the M2 architecture dossier (bounded contexts → service decomposition and contracts); production code starts only after the design-review gate – exploratory spikes are allowed.

No deliverable is due this week.

Week 6: Pipelines, Serverless, the View Across – and Your Class (C10)

🎯 Learning objectives

• I can derive C(PF) and C(SL) from their tactics and explain their defining cells (PF's D3, SL's split D10).
• I know the architecture quantum – the joint unit of deployment, scaling and failure – and each pattern's quantum count.
• I can explain the capability table through Maxims 3 and 4: quantum count and partitioning axis.
• I can read the consolidated capability table ordinally – rankings and exclusions, never weighted sums.
• I can explain why agent orchestration is a composition pattern, not an eighth style, and defend “workflows before agents”.
• I can construct the C10 requirements profile: its five High dimensions, three binding scenarios, shape and constraints.
• I can explain why weights, not dimensions, define a class, using the C1/C2 mirror pair.
• I can run the three-stage match for the project platform and record the decision as an ADR draft.

🧑‍🏫 Theory

Lecture 6: Pipelines, Serverless, the View Across – and Your Class (C10) · 2 lessons lecture + 2 lessons exercise
Lecture 6 closes the pattern catalogue with PF and SL, reads all seven columns side by side (Maxims 3 and 4), and opens Part III with C10, your project's class.

• PF: D3 = −− is its definition – makespan and reproducibility, a third consistency semantics (“as of last run”); most deterministically testable pattern, natural home of ingestion, training and evals.
• SL – event-triggered, short-lived, stateless functions; pay per execution, own no capacity. Load shape dominates the profile: D10 = ++/−− inverts (Prime Video) and does not average to ○ (neutral).
• Architecture quantum: independently deployable unit. Maxim 3: one quantum → cheap, simple, consistent, rigid; many → expensive, complex, eventually consistent, elastic. Maxim 4: domain-oriented partitioning, not deployment-unit count, predicts evolvability.
• The consolidated table: no column dominates – a matching problem exists (assumption A2); ordinal reading, never weighted sums; every cell is a default hypothesis, two documented to invert with context.
• Agent orchestration is a composition pattern reusing the catalogue's topologies, not an eighth style; workflows before agents – multi-agent beat single-agent by 90.2 % at 15× the tokens.
• C10 – AI-native advisory platforms, the project's class: Highs D6/D7/D9/D10/D12 (accountability, churn, evals, cost per request, containment); binding scenarios S1–S3; shape hybrid interactive + batch/async; K(a): EU AI Act, GDPR.
• C10 stress-tests the method: inherits C6/C7/C3, adds token budget and eval harness; verdict: hexagonal modular monolith with LLM gateway, PF for ingestion and evals, EDA for job and audit spine.
• C1 and C2 are mirror images across the consistency/availability trade – inverted weights on D1 and D4, verdicts MM+HX core versus EDA+MS hybrid. Weights, not dimensions, define a class.

📎 Materials: Slide set of Lecture 6 (added below by the lecturer) · Script: Part II – Sections 13 (PF – Pipes-and-Filters / Batch Pipeline), 14 (SL – Serverless / FaaS), 15 (Stepping Back: What Seven Patterns Generalise To), 16 (Reading the Catalogue as a Whole) and 17 (Outlook: Agent Orchestration as an Emergent Composition Pattern); Part III – Section 28 (C10 – AI-Native Advisory Platforms). Sections 19–20: preview of the C1/C2 mirror pair only; read in full in week 8.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part II – Sections 13 (PF – Pipes-and-Filters / Batch Pipeline), 14 (SL – Serverless / FaaS), 15 (Stepping Back: What Seven Patterns Generalise To), 16 (Reading the Catalogue as a Whole) and 17 (Outlook: Agent Orchestration as an Emergent Composition Pattern); Part III – Section 28 (C10 – AI-Native Advisory Platforms). Sections 19–20: preview of the C1/C2 mirror pair only; read in full in week 8.

Also before the lecture:

• Bring last week's matrix pre-filter: which candidate patterns survived stage 1 (shape gate) and stage 2 (vetoes) against your A1 requirements profile – the full match builds on it.
• Bring your edge design and service-contract sketch from week 5 (ingestion queue, resilience measures on external calls, events and schemas).

🧩 Exercise session: The match: each team runs the full three-stage procedure against its A1 requirements profile – knock-out with the shape gate, veto with documented mitigations, ordinal reading with sensitivity check – takes the decision and begins the ADR.

🛠️ Project work this week · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)

• Run the full three-stage match for your platform against your A1 requirements profile R(platform), starting from last week's pre-filter.
• Stage 1, knock-out: apply the hard constraints K(a) and the workload-shape gate (S(a) versus S(p)) – which candidates cannot carry the core?
• Stage 2, veto: hold every High weight against the capability columns – which vetoes fire, and which have documented mitigations?
• Stage 3, ordinal reading: rank the survivors on the High set and run the sensitivity check; then take the decision and begin the ADR (MADR: drivers, options, consequences, confirmation).
• Keep Deliverable A2 in view: architecture dossier + design-review gate at the end of week 7; production code starts only after the gate (exploratory spikes are allowed).

No deliverable is due this week.

Week 7: The Fit, Formally – Three Cases, the Procedure, the Matrix

🎯 Learning objectives

• I can explain why fit(a,p) is non-compensatory and what a weighted sum would have destroyed in C6, C1 and C2.
• I can derive the C6 row from the workload-shape gate: six of seven cells emptied before any rating is scored.
• I can distinguish an operational weakness (repaired by a tactic) from a structural one (made survivable under condition).
• I can judge a flipped ordering under plausible weight variation as a finding (trade-off point), not an error.
• I know that a matrix cell rates a pattern only as the dominant structure of a class's core.
• I can read the matrix by columns and rows: MM as default, MS premium, workload-shaped PF/EDA, HX never negative.
• I know the definition of an architectural fitness function, its scope and cadence classes, and the four DORA metrics.
• I can defend an ADR at the design-review gate: vetoes fired, mitigations documented, what the sensitivity check showed.

🧑‍🏫 Theory

Lecture 7: The Fit, Formally – Three Cases, the Procedure, the Matrix · 2 lessons lecture + 2 lessons exercise
This lecture runs the three-stage match end to end on C6, C1 and C2, states the procedure formally, reads the 7 × 10 matching matrix and introduces the measurement contract.

• C6: the workload-shape gate alone empties six of seven cells before any scoring; only PF proceeds to Stages 2–3 and reaches ++ – run the cheapest test first.
• C1: MS's structural −− on D4 (no cross-service ACID) fires the veto, lifted only to ○ under the Monzo condition; MM's operational D5 weakness is repaired by hot standby (++).
• C2: MS and EDA survive to Stage 3; the sensitivity analysis flips the ordering under plausible variation – a trade-off point, not an error: the class needs both patterns, placed.
• fit(a,p) is non-compensatory: knock-out and shape gate (read per constitutive path), veto on High-weight dimensions unless a documented mitigation exists, holistic ordinal reading with sensitivity analysis – no weighted sum.
• Cell semantics: fit(a,p) rates p only as the dominant structure of the core of a; a − cell is not a prohibition; HX cells read as the core's internal discipline.
• Column-wise: MM is primary or secondary in seven of ten classes (MonolithFirst); MS earns its premium only where read scalability, fault isolation and team scaling coincide (C2; conditionally C5, C8).
• PF and EDA are workload-shaped, HX is never negative, no row or column is uniformly positive (assumption A2); Prime Video, Segment, Shopify, Uber and Stack Overflow sit on cell boundaries.
• Measurement contract: fitness functions (dependency checks, budgets, chaos experiments) and the four DORA metrics as executable invariants – the architecture may change freely as long as the contract stays green.

📎 Materials: Slide set of Lecture 7 (added below by the lecturer) · Script: Part IV – Sections 30 (Three Matches, Three Stages), 31 (The Procedure in General), 32 (The Matching Matrix), 34 (Reading the Matrix as a Whole) and 37 (The Measurement Contract). Section 37: introduction only.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part IV – Sections 30 (Three Matches, Three Stages), 31 (The Procedure in General), 32 (The Matching Matrix), 34 (Reading the Matrix as a Whole) and 37 (The Measurement Contract). Section 37: introduction only.

Also before the lecture:

• Bring last week's exercise results: the three-stage match on your own platform (knock-out → veto → ordinal reading), the decision, and the ADR you began.
• Prepare for the design-review gate: A2 (ADR + C4 + measurement contract) is due at the end of this week.

🧩 Exercise session: The two-lesson exercise slot finalises the solution design (service cut and contracts, walking-skeleton plan, measurement contract) and holds the design-review gate at which each team defends its ADR – the last two-lesson slot before it becomes a one-lesson standup/coaching session from week 8.

🛠️ Project work this week · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)

• Finalise the service cut and contracts: bounded contexts → service decomposition and the contracts between the deterministic core, the edges and the AI subsystem; record the decision as an ADR with rationale and a C4-style diagram.
• Write the walking-skeleton plan: the thin end-to-end slice you will build first in Sprint 1 (M3: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, stable API, placeholder UI).
• Set the numbers in the measurement contract: a token-cost budget per request at p95 (family 2, cost budget as a pipeline gate), an eval threshold of pass rate ≥ 95 % on a versioned golden set before rollout, p95 latency ≤ 20 s for the advisory scenario, and zero module-boundary violations (family 1, dependency rules as CI gates, ArchUnit / import-linter style).
• Pass the design-review gate: defend the ADR – which vetoes fired, which mitigations are documented, what the sensitivity check showed.
• Submit Deliverable A2 (end of week 7): the architecture dossier – ADR + C4 diagram + measurement contract. Production code starts only after the gate (exploratory spikes are allowed); from week 8 the exercise slot becomes a one-lesson standup/coaching session and Sprint 1 (M3, walking skeleton) begins.

Week 8: Requirements Profiles I – Application Classes C1–C5

🎯 Learning objectives

• I can define an application class as an ASR bundle and write it as R(a) = (w; S(a); K(a)).
• I can derive a class's High weights from documented challenges and binding scenarios, each H a veto trigger.
• I can place C1–C5 on the map of ten classes by workload shape and consistency semantics.
• I know the binding scenarios, High weights, shape S(a) and constraints K(a) of classes C1 to C5.
• I can explain, with LMAX and Monzo, why R(a) defines a feasible set rather than one pattern.
• I can explain why C2 scales reads from a monolith yet moves to EDA+MS at measured organisational scale.
• I can explain why D8 = H and D10 = H jointly veto premium-priced structures in C3.
• I can explain why cross-module ACID binds C4 to one transactional quantum and makes MS the strongest anti-fit.
• I can explain C5's hybrid consistency as a designed boundary that belongs in an ADR.
• I can judge where an AI component may live in a topology by its latency class, not its accuracy.

🧑‍🏫 Theory

Lecture 8: Requirements Profiles I – Application Classes C1–C5 · 3 lessons lecture + 1 lesson standup/coaching
Part III turns to the demand side: the requirements profiles of application classes C1–C5, derived from documented challenges and binding scenarios – every closing verdict a preview for Part IV.

• An application class is an ASR bundle, not an industry label: R(a) = (w; S(a); K(a)) – weights from the (H,H) leaves, S(a) gates the core, K(a) knocks out before scoring.
• A weight is a compressed empirical claim, made auditable per class: documented challenges → binding scenarios with response measures → High weights; an H is a veto trigger, not a coefficient.
• Regulation translates directly into structure (immutable journals, scope zoning); one organisation runs several classes, so the matrix is read per subsystem; classifying a system is a hypothesis, never a verdict.
• The map of ten classes: workload shape × consistency semantics; C1–C5 all interactive – C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual; C1 and C2 form the mirror pair.
• C1 core banking: D4/D5/D6/D7/D9 High, densest K(a); LMAX vs. Monzo – R(a) defines the feasible set, constraints decide within it; AI at the edge: agents propose, deterministic services decide and book.
• C2 social media: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day – a monolith is an organisational problem, not a read-scaling problem.
• C3 back-office, the modal case: ca. 60 % of life-cycle cost is evolution (D7 = H); D8 = H and D10 = H jointly veto premium-priced structures; verdict MM, workflow engine behind a port.
• C4 ERP: integration is the product – cross-module ACID postings bind the class to one transactional quantum; MM the strongest alignment in the matrix, MS's −− on D4 the strongest anti-fit.
• C5 e-commerce: quality attributes with price tags, 10–50× peaks, hybrid consistency as a designed boundary, PCI DSS v4.0 scope minimisation as structure; Shopify vs. Amazon – team size, not traffic, decides.
• Side by side: D7 High in all five, D8/D10 High only in C3; verdict previews C1 MM+HX, C2 EDA+MS at measured organisational scale, C3/C4/C5 MM – Part IV recomputes every verdict.

📎 Materials: Slide set of Lecture 8 (added below by the lecturer) · Script: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).

Also before the lecture:

• Sprint 1 / M3 starts this week: bring the walking-skeleton plan from your A2 dossier (MarketDataService + minimal ResearchAgent + stable API).
• Make sure Deliverable A2 and the design-review gate are complete – production code starts only after the gate (exploratory spikes are allowed).
• Have the 7 × 10 matching matrix from Lecture 7 at hand: this week derives its rows C1–C5 from the demand side.

🧩 Exercise session: The exercise slot becomes a one-lesson standup/coaching session as the implementation phase begins with Sprint 1 of the walking skeleton (M3); implementation happens mainly in self-study time.

🛠️ Project work this week · Milestone M3 – Walking Skeleton (weeks 8–9)

• Start the walking skeleton (Sprint 1, M3) first thing in the implementation phase: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, plus a stable API and a placeholder UI that calls it.
• Keep the deterministic core free of LLM calls – agents propose, deterministic services decide and book; this is the line that is graded. Your deterministic services inherit the C3 verdict: ACID, boring on purpose.
• Use a snapshot of market/news data so that demo and grading are reproducible.
• Commit after each milestone and record architectural decisions as ADRs as you go.
• Work towards the week-9 check: the walking skeleton runs end-to-end (M3).

No deliverable is due this week.

Week 9: Classes C6–C9 – and Ten Profiles Side by Side

🎯 Learning objectives

• I can explain why C6 replaces the interactive vocabulary with makespan, batch-window adherence and cost per simulation.
• I can distinguish the third consistency semantics – reproducibility and refresh contracts – from ACID and eventual consistency.
• I know that C7 is an integration product over C1–C5 whose ADR to write is the freshness contract.
• I can explain why C8's hard requirement is declared correctness semantics under failure, not throughput.
• I can judge, per stream and per scenario, when at-least-once plus idempotence is legitimate instead of exactly-once.
• I can explain why C9's binding load is connection fan-out and push, with concurrent-connection count as tiebreaker.
• I can explain each H of C6–C9 as a veto trigger backed by a scenario with a response measure.
• I can read the consolidated requirements table by columns and by rows, including its seventeen footnotes.
• I can name the five cross-class observations, including that D11 High, not scale, forces microservices.
• I can explain why the freshness contract appears twice in the course project's measurement contract.

🧑‍🏫 Theory

Lecture 9: Classes C6–C9 – and Ten Profiles Side by Side · 3 lessons lecture + 1 lesson standup/coaching
This lecture completes the demand side: classes C6–C9 in the same rhythm, then the consolidated requirements table with its seventeen footnotes and five cross-class observations.

• C6 replaces the interactive vocabulary: makespan, batch-window adherence and cost per simulation are the response measures; correctness means bit-level reproducibility from versioned inputs and seeds (Highs D2, D9, D10).
• C6 and C7 define a third consistency semantics beside ACID and eventual: reproducibility (“as of this run”) and freshness by refresh contract (“as of yesterday 24:00”), contracts with response measures.
• C7 is an integration product over C1–C5 (Highs D1, D10); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8 economics.
• The course project inherits C6 (ingestion and eval pipelines) and C7 (analytics); its freshness contract appears twice: as a pipeline fitness function and as a grounding rule for generated answers.
• C8 must keep pace with the world indefinitely (Highs D2, D3, D5); the hard requirement is declared correctness semantics under failure; at-least-once plus idempotence is decided per stream, per scenario.
• AI lens: C7 docks text-to-SQL onto the governed semantic layer, not onto raw tables; C8 rules out per-event LLM calls; models score events in the stream as checkpointed operators.
• C9's binding load is connection fan-out and push (Highs D3, D5); same domain, four structures: scale and business model move the weights at the edges; concurrent-connection count is the tiebreaker.
• In the consolidated requirements table an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics.
• Five observations: read/write ratio and consistency semantics discriminate most; D11 High, not scale, forces microservices; rollbacks cut dataflows along technical seams; regulation lives in K(a); C10 inherits before it innovates.
• The ten profiles are derivable, not arbitrary: weights trace to binding scenarios, constraints to statutes or contracts, workload shapes to production numbers – the other operand, R(a), is ready.

📎 Materials: Slide set of Lecture 9 (added below by the lecturer) · Script: Part III – Sections 24 (C6 – Scientific Simulation / Batch Compute), 25 (C7 – Decision Support / BI Analytics), 26 (C8 – Real-Time / IoT Streaming), 27 (C9 – Collaboration / Messaging) and 29 (Stepping Back: Ten Profiles Side by Side).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part III – Sections 24 (C6 – Scientific Simulation / Batch Compute), 25 (C7 – Decision Support / BI Analytics), 26 (C8 – Real-Time / IoT Streaming), 27 (C9 – Collaboration / Messaging) and 29 (Stepping Back: Ten Profiles Side by Side).

Also before the lecture:

• Have the walking skeleton ready for the milestone check M3 in the coaching session: it must run end-to-end.

🧩 Exercise session: Coaching session (1 lesson): the teams finish the walking skeleton and the milestone check M3 takes place – the end-to-end thin slice must run.

🛠️ Project work this week · Milestone M3 – Walking Skeleton (weeks 8–9)

• Finish the walking skeleton: the end-to-end thin slice runs – MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, delivered through the stable API; a placeholder UI calls it.
• Keep the deterministic core free of LLM calls – this is the line that is graded.
• Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.
• Commit after the milestone and record your decisions as ADRs as you go.
• Apply today's lecture: your ingestion and eval pipelines are C6, your analytics are C7 – the skeleton should already show where an Insight's freshness stamp comes from.

Week 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure

🎯 Learning objectives

• I can explain why hybrids are the normal case and what the unit of fit evaluation is.
• I can explain why fit decays over time (Lehman's laws, assumption A5) and name the three migration strategies.
• I can read the evolution-path diagram: MM is both sanctioned start state and consolidation target.
• I know Maxim 5: buy options on tomorrow's profile via modules and ports, not speculative distribution.
• I can name the eight steps of the decision procedure with the artefact and measurement of each.
• I can distinguish a sensitivity point from a trade-off point and explain what a weight-variation flip means.
• I know Maxim 6: without a response measure a decision is an opinion; with a fitness function, a testable hypothesis.
• I can judge my A2 against the reference run ADR-007: options, vetoes, fitness functions, evolution path.
• I can read a row rationale of the matrix: gate, veto, documented mitigation, primary recommendation, central trade-off.
• I can defend the C10 verdict: a designed hybrid with the determinism boundary – agents propose, deterministic services decide and book.

🧑‍🏫 Theory

Lecture 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure · 3 lessons lecture + 1 lesson standup/coaching
This lecture treats fit as a function of time (hybrids, evolution paths), then runs the eight-step decision procedure through ADR-007 and reads the ten matrix rows cell by cell.

• Eight of the ten primary recommendations of Section 33 are compositions; the unit of fit evaluation is the subsystem with its own architecture quantum, recorded in a C4 container diagram.
• Fit is a function of time (Lehman's laws, assumption A5): every recommendation carries a migration strategy – MonolithFirst, Strangler Fig in both directions, sacrificial architecture; MM is start state and consolidation target.
• Maxim 5: choose the pattern for the profile verifiable today and buy options on tomorrow's via module boundaries, ports and a strangler-ready seam – not via speculative distribution.
• AI Lens: for a C10 system's AI layer, sacrificial architecture is the rational default – replaceable behind a port, eval harness as acceptance gate; the deterministic core is designed to last.
• The matrix only pre-filters: eight steps – ASRs, scenarios with numbers, utility tree whose (H,H) leaves are the weights of R(a), matrix shortlist, ATAM-light, ADR, measurement contract, measure in operation.
• Sensitivity point: one decision, large effect on one attribute; trade-off point: opposing effects on several attributes. A weight variation that flips the recommendation calls for stakeholder negotiation, not a formula.
• Steps (vii)–(viii) are the genuinely new obligations. Maxim 6: a decision without a response measure is an opinion; with response measure and fitness function it is a testable hypothesis.
• ADR-007 (reference run, class C10) narrates one matrix row: decision drivers are the utility-tree weights, considered options the matrix shortlist (auditable), the final section the measurement contract (falsifiable).
• In the ten row rationales every cell is traceable to R(a) against C(p) – gate, veto, documented mitigation – plus primary recommendation and central trade-off; the recurring resolution: consistent core, asynchronous edges.
• C10's verdict is a designed hybrid – hexagonal modular monolith core, pipelines, orchestrated agents, EDA spine secondary – governed by the determinism boundary: LLM agents propose, deterministic services decide and book.

📎 Materials: Slide set of Lecture 10 (added below by the lecturer) · Script: Part IV – Sections 35 (Hybrids and Evolution Paths), 36 (The Decision Procedure) and 33 (Cell Rationales: The Ten Rows in Detail).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part IV – Sections 35 (Hybrids and Evolution Paths), 36 (The Decision Procedure) and 33 (Cell Rationales: The Ten Rows in Detail).

Also before the lecture:

• Have your A2 dossier (ADR, C4 container diagram, measurement contract) at hand – the lecture holds it against the reference run ADR-007.
• Make sure the walking skeleton runs end-to-end (M3 check, week 9) before M4 starts this week.

🧩 Exercise session: The exercise slot is one lesson of standup/coaching for milestone M4: implementing the deterministic Performance, Risk and Optimization services with exact tests against the reference vectors.

🛠️ Project work this week · Milestone M4 – Deterministic Core and Resilience (weeks 10–11)

• Implement the Performance, Risk and Optimization services and test them fully against the reference vectors – exact tests, not approximate ones.
• Pin the deterministic services with tests before you trust any agent output.
• Keep the deterministic core free of LLM calls – this is the line that is graded (ADR-007's determinism boundary: agents propose, deterministic services decide and book).
• Commit after the milestone and record architectural decisions as ADRs as you go – a revised decision is a new, superseding ADR.
• Plan the second half of M4: resilience patterns on all external calls and verified graceful degradation follow next week (M4 check end of week 11).

No deliverable is due this week.

Week 11: The Fit III – Measurement Contract, Conway's Law, and the Limits of the Theory

🎯 Learning objectives

• I can explain why step (vii) codifies the chosen fit as a measurement contract of executable invariants.
• I can define an architectural fitness function, classify it by scope and cadence, and name the three instrument families.
• I know the four DORA metrics, the coupling finding, and why the evidence is prediction rather than causal proof.
• I can name the four layers of the cascade with their falsification questions and read the C10 reference contract.
• I can explain, using Boehm and Menzies, why the cost-of-change curve is flat within but steep across architecture boundaries.
• I can explain why fitness functions are the operating licence for agents and name the two Axis-B fitness-function types.
• I know which five measurement-contract items my project submission must ship, wired into CI.
• I can apply Conway's law as the third fit dimension: check D11 last but veto on it first.
• I know the four Team Topologies team types, the three interaction modes, and the inverse Conway manoeuvre.
• I can name the six limits of the theory, what compensates each, and state Maxim 9.

🧑‍🏫 Theory

Lecture 11: The Fit III – The Measurement Contract, Conway's Law, and the Limits of the Theory · 3 lessons lecture + 1 lesson standup/coaching
Part IV closes with the measurement contract in depth (fitness functions, DORA, C10 reference contract, cost of change), Conway's law as third fit dimension, and six limits of the theory.

• Step (vii) codifies the chosen fit as a measurement contract of executable invariants: “the architecture may change freely as long as the contract stays green”.
• Fitness functions – objective integrity assessments – are classified by scope (atomic, holistic) and cadence (triggered, continual, temporal); three families: dependency checks as CI gates, performance and cost budgets, chaos experiments.
• The four DORA metrics – tempo: deployment frequency, lead time for changes; stability: change failure rate, failed-deployment recovery time – are not a trade-off: elite performers lead on all four.
• Loosely coupled architectures and teams are the strongest predictor of continuous delivery; the label “microservices” is neither necessary nor sufficient – survey-based prediction, not causal proof.
• The four-layer cascade – design time, delivery, operation, evolution – asks whether the structure is intact, delivering, keeping its runtime promises, ageing; the C10 reference contract instantiates it in eight rows.
• Boehm's cost-of-change escalation (up to one hundred times) is flattened for changes within an architecture (Menzies, 171 projects) but steep for changes of it – the contract, not the diagram, protects the investment.
• Fitness functions are the operating licence for agents (Axis A); Axis B adds two new fitness-function types with old mechanics: eval-harness pass rate (triggered) and token-cost budget per request (continual).
• The fit is three-way – pattern, application class, team structure; check D11 last but veto on it first; Team Topologies and the inverse Conway manoeuvre make Conway's law a design instrument.
• Six limits – ordinal scales, context-dependence, hybrids as the normal case, heterogeneous evidence, the hidden organisation, AI-era volatility – make the matrix a hypothesis, not an authority.
• Maxim 9: the matrix is the argument's skeleton, ATAM is its court of appeal, the ADR is its record, and the fitness function is its parole condition.

📎 Materials: Slide set of Lecture 11 (added below by the lecturer) · Script: Part IV – Sections 37 (The Measurement Contract), 38 (The Third Fit Dimension: Conway's Law and Team Topologies) and 39 (Limits of the Theory – Applied to Itself).

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part IV – Sections 37 (The Measurement Contract), 38 (The Third Fit Dimension: Conway's Law and Team Topologies) and 39 (Limits of the Theory – Applied to Itself).

Also before the lecture:

• Arrive with the deterministic core (Performance, Risk, Optimization services) tested against the reference vectors – week 11 completes M4 with resilience and graceful degradation.
• Have your project's measurement contract from the A2 dossier at hand – the lecture shows the C10 reference contract and what your submission must ship.

🧩 Exercise session: One lesson of standup/coaching: the teams complete the resilience patterns on all external calls and verify graceful degradation, closing milestone M4 at the end of the week.

🛠️ Project work this week · Milestone M4 – Deterministic Core and Resilience (weeks 10–11)

• Add resilience patterns to all external calls: timeout, retry, circuit breaker, fallback.
• Verify graceful degradation – the resilience row of the reference contract (kill one instance or broker under load; the SLO holds) is the fitness function that verifies it.
• Finish testing the Performance, Risk, and Optimization services fully against the reference vectors – milestone M4 closes at the end of week 11 with the deterministic core fully tested and resilient.
• Keep the deterministic core free of LLM calls – this is the line that is graded.
• Prepare for the project review: the submission must ship its measurement contract wired into CI – module-boundary check with zero violations (Python: import-linter; Java: ArchUnit or Spring Modulith), including the determinism-boundary rule; an eval harness with a versioned golden set and pass rate ≥ 95 %; a token-cost budget per request as a pipeline gate; a p95 latency budget ≤ 20 s for the advisory scenario; and the ADR (MADR form) whose final section is the contract. Be ready to demonstrate one contract violation being caught by CI.

Week 12: The AI Dimension I – Axis A Evidence, Axis B Foundations

🎯 Learning objectives

• I can explain assumption A6 – two axes, one method – and distinguish Axis A (tool) from Axis B (component).
• I can reconcile the Copilot RCT (+55.8 %) and the METR RCT (−19 %) with the five moderator variables.
• I know the system-level record – DORA's amplifier finding, GitClear's duplication and churn trend – and the METR perception gap.
• I can explain the verification bottleneck and derive Maxim 7 from it: AI raises the value of architecture.
• I can explain how ADRs, agent instruction files and fitness functions become the control interface and operating licence for agents.
• I know that patterns are examinable and products expire, that MCP is ports-and-adapters, and who answers for merged code.
• I can name the five failures of the synchronously wired sentiment call and their dimensions D3, D10, D12, D7, D6.
• I can distinguish the three AI component types and explain why adding AI is a per-component matching problem.
• I can explain why CACE demands containment and justify each element of the reference architecture (port, gateway, queue, guard).
• I can define the eval harness, name its four evaluation strategies, and place its thresholds in the measurement contract.

🧑‍🏫 Theory

Lecture 12: The AI Dimension I – Axis A Evidence, Axis B Foundations · 3 lessons lecture + 1 lesson standup/coaching
Part V opens as Assumption A6 falls due: the Axis A evidence and its resolution, then the Axis B foundations from the wrongly wired sentiment call to the eval harness.

• Assumption A6 falls due: Axis A (AI as tool) changes how systems are built, Axis B (AI as component) what they contain – two independent axes, one method, nothing new.
• Copilot RCT: +55.8 % on a greenfield task; METR RCT: experts 19 % slower in their own mature codebases, estimating +20 % – the perception gap is the didactic core.
• Neither study is wrong – five moderators reconcile the record; at system level DORA finds AI an amplifier (instability persists); GitClear: duplication 4×, refactoring signature collapsed; adoption up, trust down.
• The verification bottleneck: code generation became cheap; specification, verification and architecture became the binding constraints – AI lowers the cost of producing code, not of taking responsibility for it.
• Maxim 7: AI raises the change rate by an order of magnitude and therefore raises, not lowers, the value of architecture; D7 and D9 gain weight in every requirements profile.
• ADRs and agent instruction files are the control interface, fitness functions the operating licence for agents; whoever merges code answers for it; patterns are examinable, products expire; MCP is ports-and-adapters.
• Wired synchronously, the news-sentiment call fails on latency (D3), cost (D10), non-determinism (D12), drift (D7) and injection (D6) – properties of the wiring, not bugs in the model.
• Three component types (LLM, ML, optimisation) differ where the twelve dimensions measure: adding AI is a per-component matching problem; CACE (changing anything changes everything) means decomposing around the component.
• Reference architecture (ADR-011 made structural): typed port → gateway (routing, semantic cache, stability patterns, cost telemetry) → queue → ontology guard; LLM agents propose, deterministic services decide and book.
• Eval harness (versioned cases, scoring logic, statistical thresholds, executed in CI) replaces exact assertion by statistical acceptance: golden-set regression, LLM-as-judge, domain axioms, online evaluation; thresholds belong in the measurement contract.

📎 Materials: Slide set of Lecture 12 (added below by the lecturer) · Script: Part V – Sections 40 (Two Axes, One Method), 41 (Axis A: AI as a Tool Shifts the Economics of the SDLC) and 42 (Axis B: AI as a Runtime Component). Section 42: subsections 42.1–42.5 only.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part V – Sections 40 (Two Axes, One Method), 41 (Axis A: AI as a Tool Shifts the Economics of the SDLC) and 42 (Axis B: AI as a Runtime Component). Section 42: subsections 42.1–42.5 only.

Also before the lecture:

• Come to the coaching slot ready to start M5: the AdvisorAgent with 2–3 sub-agents behind the gateway (mandatory) and the ontology guard active on all insights.

🧩 Exercise session: One-lesson standup/coaching slot on milestone M5: teams wire the AdvisorAgent and its 2–3 sub-agents into the lecture's reference architecture – typed port → gateway → queue → ontology guard – with every LLM call through the gateway and the ontology guard active on all insights.

🛠️ Project work this week · Milestone M5 – Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12–13)

• Wire the AdvisorAgent to orchestrate 2–3 sub-agents through contracts – every LLM call through the gateway port (ADR-011), no provider SDK import in domain code; this is the mandatory part of the week.
• Activate the ontology guard on all insights: entity resolution against the deterministic store (valid ticker, sector, event type), domain axioms, citation check – reject unresolvable references rather than passing them on.
• Keep the deterministic core free of LLM calls – LLM agents propose, deterministic services decide and book; this is the line that is graded.
• Apply the Axis A discipline: keep AGENTS.md / CLAUDE.md as current as code, let agents draft ADRs that a named team member signs, and merge agent-generated changes only through the CI gate (module-boundary fitness functions, test suite, eval harness for anything touching prompts or the gateway).
• Put a one-page AI policy in the project handbook (permitted tools, provenance labelling, review rules); week 13 turns the eval harness into a CI gate for the M5 check.

No deliverable is due this week.

Week 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis

🎯 Learning objectives

• I can pair each risk of the OWASP Top 10 for LLM Applications with its architectural counter-measure.
• I can explain why prompt injection cannot be solved inside the model and why the architecture is the trust boundary.
• I know the EU AI Act's four risk classes and why its obligations enter R(a) as hard constraints K(a).
• I can derive each pattern's D12 rating from the queue, port and measurement point it provides or lacks.
• I can name the five cell shifts AI causes in the matrix and the quality-attribute mechanism behind each.
• I can distinguish a workflow from an agent and explain why autonomy is a dial, not a binary.
• I can map the six workflow topologies onto their classical analogues from Part II.
• I can choose a topology from the task signature and justify it with a token budget and eval threshold.
• I can explain, from the profile sketch and the economics of autonomy, why agent orchestration remains an edge pattern.
• I can state Maxim 8 and explain why Axis A and Axis B are one discipline at two binding sites.

🧑‍🏫 Theory

Lecture 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis · 3 lessons lecture + 1 lesson standup/coaching
The last lecture of new material: Axis B completed (threats, regulation), the shifted matrix, agent orchestration as the eighth pattern, synthesis with Maxim 8, and exam orientation.

• The OWASP LLM Top 10 pairs risks with architectural counter-measures; prompt injection is not solvable in the model (same channel), so the architecture, not the model, is the trust boundary.
• EU AI Act obligations (C10 can be high-risk) are quality attributes with legal force; they enter R(a) as hard constraints K(a), never weights: compliance is the same architecture, documented.
• The matrix is shifted, not rewritten: patterns providing the queue, port and measurement point (D12) gain (EDA, PF; HX most); synchronous chains lose (MS); SL is conditional; cost becomes load-bearing.
• The three-level MLOps ladder says how much of D9 and D12 a team can cash in; A6, restated as a falsifiable claim: AI stretches the dimensions, the method is unchanged.
• Agent orchestration is a composition pattern, not a new style; agent = loop + tools + state; workflows follow predefined code paths, agents steer their own process and tool use.
• The six topologies map onto Part II: chain (PF), routing (routing layer/mediator), parallelisation (broker-style fan-out), orchestrator–workers (mediator EDA), evaluator–optimizer (feedback control loop), multi-agent (broker topology); strengths and weaknesses transfer.
• The task-signature table selects the simplest matching topology first; the default rule: workflows before agents, every escalation an ADR with token budget and eval threshold (Maxim 6 applies unchanged).
• Autonomy is a CBAM (cost–benefit) decision (90.2 % better at ~15× the tokens); with −− on D3/D4/D9/D10 in its profile sketch, agent orchestration remains an edge pattern behind a deterministic core.
• Maxim 8: the theory absorbs AI (same assumptions, same procedure, same contract); the two axes are one discipline at two binding sites: cheap, fallible generation contained behind expensive, explicit verification.
• Exam orientation (open book, 60 minutes; focus: architecture reasoning): the map is Maxim 8's one sentence, the four tables, Part V's additions and the spine A1–A6 with the Maxims.

📎 Materials: Slide set of Lecture 13 (added below by the lecturer) · Script: Part V – Sections 42 (Axis B: AI as a Runtime Component), 43 (How AI Shifts the Matrix), 44 (Agent Orchestration: The Emergent Eighth Pattern) and 45 (Synthesis: One Theory, Five Parts). Section 42: subsections 42.6–42.7 only.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: Part V – Sections 42 (Axis B: AI as a Runtime Component), 43 (How AI Shifts the Matrix), 44 (Agent Orchestration: The Emergent Eighth Pattern) and 45 (Synthesis: One Theory, Five Parts). Section 42: subsections 42.6–42.7 only.

Also before the lecture:

• Bring the current state of your M5 work to the coaching session: eval harness as CI gate, cost/latency observability, hardening and any distinction work.

🧩 Exercise session: One lesson of standup and coaching on the closing M5 work: eval harness as a CI gate, token-cost and latency observability, threat model and hardening, caching and batching, optional distinction work; M5 is checked at the end of the week.

🛠️ Project work this week · Milestone M5 – Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12–13)

• Wire the evaluation harness into CI as a gate; report accuracy and failure modes.
• Add observability of token cost and latency per request – cost per request and per feature on a dashboard, enforced as a CI budget; then scale and optimise with caching and batching.
• Write the threat model including prompt injection via news, using the OWASP table as your checklist and the same-channel rule, and apply basic hardening: no LLM output reaches the booking path without the ontology guard, no agent tool performs an irreversible action.
• Record the ADR that justifies your orchestration topology against the task-signature table, with its token budget and eval threshold as the measurement contract.
• Take on optional distinction work (Kür) – autonomous planning, self-repair, model routing, CI/CD, tracing – justifying every topology escalation against the task-signature table and pricing it per the default rule; keep the deterministic core free of LLM calls – this is the line that is graded.

Week 14: Synthesis, Presentations, and Architecture Defence

🎯 Learning objectives

• I can read the script backwards as one argument, from assumptions A1–A6 to the ADR with a measurement contract.
• I can distinguish the two temptations, denial and exceptionalism, from the position the script defends: absorption.
• I can explain Maxim 8: why AI, on either axis, changes no step from scenarios to ADR.
• I can explain why Axis A and Axis B reach the same conclusion: one discipline at two binding sites.
• I know the examination facts: 50 %, 60 minutes, open book (script and notes on paper), closed internet.
• I can defend my team's architectural trade-offs on A2's artefacts – ADR, C4 diagram, measurement contract.

🧑‍🏫 Theory

Lecture 14: Synthesis, Presentations, and Architecture Defence · 1 lesson synthesis + 3 lessons presentations and defence
One lesson of synthesis and exam hints with no new material, then three lessons of final presentations, architecture defence and peer reviews (Deliverable A3, milestone M6).

• Two temptations – denial, falsified by adoption data alone (90 % of practitioners by 2025), and exceptionalism, rejected on the evidence – bracket the position defended since Part I: absorption.
• Read backwards, the script is one argument: Part I sets A1–A4 and the twelve dimensions, Parts II–III build capability and requirements profiles, Part IV matches them into an ADR (assumption A5).
• Part V's stress test held (assumption A6). Maxim 8: the theory absorbs AI – tenth class, twelfth dimension, shifted cells, one emergent composition pattern – same assumptions, same procedure, same contract.
• Axis A (cheap generation, verification bottleneck) and Axis B (cheap model output, validation bottleneck) are one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification.
• The written examination: 50 % of the grade, end of semester, 60 minutes, open book (script and own notes on paper), closed internet; focus architecture reasoning – profiles, matching, trade-offs.
• The open-book map: Maxim 8's sentence and four tables – twelve dimensions, consolidated capability table, requirements table, 7 × 10 fit matrix – plus the spine A1–A6 and the Maxims.

📎 Materials: Slide set of Lecture 14 (added below by the lecturer) · Script: No new script sections – the reading for the examination is the whole script, Parts I–V.

🧑‍💻 Self-study and assignments

📖 Reading before the lecture: No new script sections – the reading for the examination is the whole script, Parts I–V.

Also before the lecture:

• Prepare the final presentation with architecture defence (Deliverable A3): present the system and defend your architectural trade-offs.
• Prepare the reflection on where AI helped and where it hurt – in building (A) and in the system (B).
• Bring your questions on the script and the examination for the Q&A in the synthesis lesson.

🧩 Exercise session: Three lessons of final presentations, architecture defence and peer reviews (Deliverable A3, milestone M6): each team presents its system, defends its trade-offs and reflects on where AI helped and hurt; slot length per team, presentation order and the peer-review form are to be announced.

🛠️ Project work this week · Milestone M6 – Presentation and Architecture Defence (week 14)

• Present the system the mandatory part requires – architecture derived from the ontology with ADRs and a C4-style diagram, fully tested deterministic services, an orchestrated advisor with 2–3 sub-agents, ontology guard and resilience, evaluation harness and observability – as a reproducible demo on a data snapshot, keeping the deterministic core free of LLM calls.
• Defend your architectural trade-offs on A2's artefacts – the ADR, the C4 diagram, the measurement contract; the assessment emphasises architecture and trade-offs, robustness, quality, AI integration and operation.
• Reflect on where AI helped and where it hurt – in building (Axis A: generation cheap, verification the bottleneck) and in the system (Axis B: model output cheap, validation the bottleneck) – and test whether one discipline at two binding sites held in your project.
• Peer-review the other teams' presentations and defences – form, criteria and reviewer assignment to be announced; listen for which High weight of R(a) carried their decision and which veto they had to mitigate.
• Be prepared to show one measurement-contract violation being caught by CI (Lecture 11).

📘 Lecture script

📘 The lecture script: A Theory of Architecture–Application Fit

The lecture notes AISE502: AI in Software Engineering II – Lecture Notes, Core Part: A Theory of Architecture–Application Fit (Dr. Florian Herzog, FH Graubünden, Autumn Semester 2026; five parts, 45 sections, about 212 pages) are the backbone of this module. They develop one coherent theory: software architecture is the set of significant, hard-to-reverse decisions, driven by measurable quality attributes, made by systematically matching an application's requirements profile against the capability profiles of architectural patterns, and validated empirically over the whole software lifecycle.

• Part I – Architecture as a Decision Problem (Sections 1–7): the decision problem, the twelve profile dimensions as the shared coordinate system, the requirements profile R(a), the capability profile C(p), the three-stage match fit(a,p), Architecture Decision Records and the measurement of a decision.
• Part II – Capability Profiles: The Seven Architectural Patterns (Sections 8–17): layered, modular monolith, hexagonal, microservices, event-driven, pipes-and-filters and serverless – each developed from the real problem that produced it, with its tactics, capability profile and engineering consequences (“build it and study it”); stepping back; outlook on agent orchestration.
• Part III – Requirements Profiles: The Ten Application Classes (Sections 18–29): from core banking (C1) to AI-native advisory platforms (C10) – challenges, weighted requirements profiles, hard constraints, and what real systems chose.
• Part IV – The Fit: Matching, Decision Procedure, and Measurement (Sections 30–39): three worked matches, the procedure in general, the 7 × 10 matching matrix and its cell rationales, hybrids and evolution paths, the decision procedure, the measurement contract (fitness functions, DORA metrics), Conway's law and team topologies, and the limits of the theory.
• Part V – The AI Dimension: Tool and Component (Sections 40–45): AI as a tool in the lifecycle (Axis A) and AI as a non-deterministic runtime component (Axis B), how AI shifts the matrix, agent orchestration as the emergent eighth pattern, and the synthesis of the theory.

How the script is used. Every weekly section names the sections to read before the lecture (reading plan below). The project's design deliverables A1 and A2 use its methods – quality attribute scenarios, utility tree, R(a), the three-stage match, ADR, measurement contract. And it is the open-book material of the written examination: script and own notes on paper, closed internet; the reading for the examination is the whole script, Parts I–V.

📄 Download: AISE502_Vorlesung_Skript.pdf – [link]

Reading plan: which sections belong to which week

Section 7 (Summary: The Red Line) closes Part I and is not assigned to a particular week; Section 28 (C10) is read in week 6 because it is the class of the course project.

🛠️ Project exercise

🛠️ Project exercise: AI-Augmented Portfolio Intelligence Platform

Over the whole semester, in teams, you design, build and operate a modular, AI-augmented analysis platform for stock portfolios. The platform ingests market prices (structured) and company news (unstructured), turns news into validated insights with an AI component, computes risk, performance and optimisation figures in deterministic services, and exposes everything API-first through an orchestrated multi-agent advisor – with a thin dashboard for demonstration only. It is a Software Engineering II project: its centre of gravity is architecture – how you structure a system so that it meets its quality attributes and stays maintainable while one part of it (the news understanding) is non-deterministic, fallible and costly. Whether the services ship as one modular monolith or as several deployables is your architecture decision (week 6), which you defend in week 14.

AI appears in two roles: as a tool you build the system with (Axis A) and as a component inside the system (Axis B). Everything the lecture teaches – profiles, matching, ADRs, measurement – you apply to this system. The project counts 50 % of the module grade.

📎 Documents

• Exercise sheet – project_exercise.pdf (16 pages): the normative description – overview and goals, functional requirements, reference architecture, AI integration rules, mandatory vs. distinction, semester plan and milestones, assessment, UI sketches. Read it in full. [link]
• Project slides – AISE502_Projekt_Folien.pdf: the kickoff presentation of the project. The slides are the map, the sheet is the territory. [link]
• UI sketches – low-fidelity sketches of the user journey and the six screens (HTML and PNG; also Section 8 of the sheet). [link]

Two phases, six milestones

Weeks 1–7 – design phase: the two-lesson exercise slot produces the requirements, studies candidate architectures against the patterns taught in the lecture, and decides and documents your architecture. Weeks 8–13 – implementation phase: the exercise slot becomes a one-lesson standup/coaching session; implementation happens mainly in self-study time. Week 14: presentations, architecture defence and peer reviews. The project work for each week is listed in the weekly sections; the exercise sheet remains the normative source.

Deliverables and assessment

• A1 – requirements dossier (end of week 3): scenarios, utility tree, R(platform).
• A2 – architecture dossier (end of week 7): ADR, C4 views, measurement contract – followed by the design-review gate. Production code starts only after the gate (exploratory spikes are allowed).
• A3 – final presentation with architecture defence (week 14), plus peer reviews.

Evaluation of the project emphasises: architecture & trade-offs (decomposition, contracts, deterministic/non-deterministic separation, ADRs), robustness (resilience, guards, graceful degradation), quality (tests for the deterministic services, eval harness for AI), AI integration (anti-corruption layering, ontology guarding), operation (observability of cost and latency), and the distinction criteria for top marks (sheet, Section 5). The other 50 % of the module grade is the written examination (60 minutes, open book, closed internet).

Hints from the sheet

• Build the walking skeleton first thing in the implementation phase – a thin end-to-end slice de-risks everything that follows.
• Use the design phase fully: a decided architecture with contracts and a measurement contract makes the implementation weeks sufficient; an undecided one does not.
• Pin the deterministic services with tests before you trust any agent output; keep the deterministic core free of LLM calls – this is the line that is graded.
• Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.
• Commit after each milestone; record architectural decisions as ADRs as you go.