752 lines
68 KiB
JSON
752 lines
68 KiB
JSON
{
|
|
"lecture": 7,
|
|
"week": 7,
|
|
"lessons": 2,
|
|
"title": "Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix",
|
|
"script_reference": "Script: Part IV, Sections 30--32, 34; Section 37 (introduction)",
|
|
"agenda": [
|
|
"Recap: the match, seen once at small scale -- and run by you last week",
|
|
"Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm)",
|
|
"The procedure in general -- and what a weighted sum would have destroyed",
|
|
"The matching matrix: cell semantics and the $7 \\times 10$ grid",
|
|
"Reading the matrix as a whole: columns, rows, five support points",
|
|
"The measurement contract, introduced: fitness functions and the DORA metrics",
|
|
"This week's exercise: the design-review gate and Deliverable A2"
|
|
],
|
|
"recap": [
|
|
"Centre line (deck 3): demand $\\to$ supply $\\to$ match $\\to$ record $\\to$ test",
|
|
"Done (weeks 1--6): Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (weights, not dimensions, define a class)",
|
|
"Last week's exercise: you ran the three stages on your own platform (knock-out $\\to$ veto $\\to$ ordinal reading) and began the ADR",
|
|
"Today: three cases from Part IV, one per stage; the general statement and the seventy-cell grid; the measurement contract, introduced",
|
|
"hinweisbox: A2 (architecture dossier: ADR $+$ C4 $+$ measurement contract) is due this week; the design-review gate closes the design phase; production code starts only after the gate"
|
|
],
|
|
"frames": [
|
|
{
|
|
"no": 1,
|
|
"deck_section": "Title",
|
|
"title": "AISE502: AI in Software Engineering II -- Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix",
|
|
"kind": "content",
|
|
"script_ref": "title slide; subtitle line: Script: Part IV, Sections 30--32, 34; Section 37 (introduction)",
|
|
"content": [
|
|
"\\FHGRTitlePage with \\subtitle{Lecture 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix\\\\[0.4ex]{\\small Script: Part IV, Sections 30--32, 34; Section 37 (introduction)}}",
|
|
"author Dr.\\ Florian Herzog; \\fullname Fachhochschule Graub\\\"unden, Chur -- Autumn Semester 2026"
|
|
],
|
|
"elements": [
|
|
"FHGR title page (theme), identical to decks 1--6"
|
|
],
|
|
"minutes": 0,
|
|
"notes": "Same preamble and box definitions as deck 6 (copy verbatim). Title format: one colon, then an en-dash, as decks 1--6."
|
|
},
|
|
{
|
|
"no": 2,
|
|
"deck_section": "Agenda",
|
|
"title": "Agenda",
|
|
"kind": "agenda",
|
|
"script_ref": "deck skeleton (decks 1--6)",
|
|
"content": [
|
|
"1. Recap: the match, seen once at small scale -- and run by you last week",
|
|
"2. Three matches, three stages: C6 (gate), C1 (veto), C2 (holistic reading and its alarm)",
|
|
"3. The procedure in general -- and what a weighted sum would have destroyed",
|
|
"4. The matching matrix: cell semantics and the $7 \\times 10$ grid",
|
|
"5. Reading the matrix as a whole: columns, rows, five support points",
|
|
"6. The measurement contract, introduced: fitness functions and the DORA metrics",
|
|
"7. This week's exercise: the design-review gate and Deliverable A2"
|
|
],
|
|
"elements": [
|
|
"enumerate, \\small, itemsep 1pt (as deck 6)"
|
|
],
|
|
"minutes": 1,
|
|
"notes": "Seven items; each now under ~85 characters so none wraps at \\small."
|
|
},
|
|
{
|
|
"no": 3,
|
|
"deck_section": "Recap",
|
|
"title": "Recap: where we are",
|
|
"kind": "recap",
|
|
"script_ref": "deck 3 recap frame (shape template) and its centre line; deck 6 Summary and Next-week frames; semester plan week 7",
|
|
"content": [
|
|
"Centre line (as deck 3): demand $\\to$ supply $\\to$ \\textbf{match} $\\to$ record $\\to$ \\textbf{test}",
|
|
"\\textbf{Done (weeks 1--6)}: Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (\\emph{weights, not dimensions, define a class})",
|
|
"\\textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\\to$ veto $\\to$ ordinal reading) and began the ADR",
|
|
"\\textbf{Today}: three cases from Part IV, one per stage $\\cdot$ the general statement and the seventy-cell grid $\\cdot$ the measurement contract, introduced",
|
|
"hinweisbox: \\textbf{A2 is due this week} -- architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate"
|
|
],
|
|
"elements": [
|
|
"centred chain line (deck-3 style)",
|
|
"hinweisbox (A2 due), as deck 3 recap did for A1"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Deck-3 shape: one centred line, one 'Done' sentence, one exercise line, three short 'Today' items, the hinweisbox. \\footnotesize. Do not re-run the mini-match. Emphasise 'you will recognise every step' (deck 6 exercise frame promised it)."
|
|
},
|
|
{
|
|
"no": 4,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Part IV opens: three matches, three stages",
|
|
"kind": "content",
|
|
"script_ref": "Part IV opening + §30 intro (part4_fit.tex 1-11); operands formula from §31.1 (part4_fit.tex 80-82)",
|
|
"content": [
|
|
"\\emph{What does the three-stage procedure actually do when it runs?} -- usually far less than students expect: \\textbf{most of the work happens before anything is scored}",
|
|
"Every Part III class ends with a verdict and a promise -- a one-sentence primary and secondary recommendation, and the assurance that Part IV computes it through the three-stage procedure. You have seen one (C10) and the C1/C2 sketch; Part IV computes those verdicts, and you meet the other rows in weeks 8--9",
|
|
"You own both operands: {\\scriptsize $R(a) = (w_1(a),\\dots,w_{12}(a);\\, S(a);\\, K(a))$, $w_i \\in \\{\\text{H},\\text{M},\\text{L}\\}$ -- from A1 and Part III; $C(p) = (c_1(p),\\dots,c_{12}(p);\\, S(p))$, $c_i \\in \\{++,+,\\circ,-,--\\}$ -- the seven columns of Part II}. You have watched $\\mathrm{fit}(a,p)$ run once at small scale (C10 mini-match); not yet seen: the machine at full load",
|
|
"Cases first, generalisation after (as Parts II and III worked) -- three matches computed end to end, each exposing one stage: \\textbf{C6} -- knock-out screening and shape gate (Stage 1) $\\cdot$ \\textbf{C1} -- veto rule with documented mitigations (Stage 2) $\\cdot$ \\textbf{C2} -- holistic ordinal reading with its built-in sensitivity alarm (Stage 3). Each lands on exactly the verdict its Part III section states",
|
|
"Roadmap strip (tikz, one line of boxes): \\textbf{today} §30 cases $\\cdot$ §31 procedure $\\cdot$ §32 matrix $\\cdot$ §34 reading $\\cdot$ §37 contract (introduced) $\\mid$ \\textcolor{gray}{Lecture 10: §33 rationales $\\cdot$ §35 hybrids and evolution paths $\\cdot$ §36 eight-step decision procedure} $\\mid$ \\textcolor{gray}{Lecture 11: §37 in depth $\\cdot$ §38 organisational complement $\\cdot$ §39 limits}"
|
|
],
|
|
"elements": [
|
|
"small tikz roadmap strip of Part IV sections derived from the part opening (line 4): 30, 31, 32, 34, 37-intro highlighted 'today'; 33, 35, 36 greyed 'Lecture 10'; 37-depth, 38, 39 greyed 'Lecture 11'"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Leading question in italics, bankblue (deck 4--6 style). Five items maximum incl. the strip; body \\footnotesize. The operands formula is here (scriptsize) so frame 13 can stay at the deck-3 box length. The Part-III sections C1--C9 are weeks 8--9: do not say 'recall'."
|
|
},
|
|
{
|
|
"no": 5,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 1 -- C6 against all seven: the shape gate",
|
|
"kind": "table",
|
|
"script_ref": "§30.1 (part4_fit.tex 15-16) + Table tab:case-c6 (part4_fit.tex 24-42)",
|
|
"content": [
|
|
"\\emph{The nightly risk run must finish by 06:00, reproduce to the bit, and cost as little as possible: which of the seven patterns can even apply for the job?}",
|
|
"The C6 profile (Part III, Lecture 9 -- given here as the operand): High on \\textbf{D2} (makespan reading), \\textbf{D9} (reproducibility reading), \\textbf{D10}; dominant workload shape \\textbf{scheduled batch}; deterministic seeds as a hard constraint",
|
|
"Before comparing a single rating: hold $S(\\text{C6})$ against the native-shape row $S(p)$ of the capability table (deck 6) -- the table carries the gate and its harm clause",
|
|
"Table columns: Pattern | Native shape $S(p)$ | Stage-1 outcome | Verdict",
|
|
"L | interactive | gate caps at $\\circ$; harm clause -- no answer to makespan or checkpointing, $--$ against High D2 | $--$",
|
|
"MM | interactive | gate caps at $\\circ$: orchestration codebase around monolithic kernels | $\\circ$",
|
|
"HX | (host's) | gate caps at $\\circ$: ports touch no binding dimension | $\\circ$",
|
|
"MS | interactive | gate caps; harm clause -- communication cost multiplied against High D10 | $--$",
|
|
"EDA | stream / async | gate caps at $\\circ$: job-status glue beside scheduler and DAG | $\\circ$",
|
|
"PF | scheduled batch | \\textbf{gate passed} -- proceeds to Stages 2--3; no veto on $\\{$D2, D9, D10$\\}$ | $++$",
|
|
"SL | event-trig., short-lived | gate caps at $\\circ$: burst fan-out for communication-light sections only | $\\circ$",
|
|
"Caption line (\\scriptsize): the workload-shape gate against $S(\\text{C6}) = $ scheduled batch; only PF proceeds to Stages 2--3; the verdict column is identical to the C6 row of the matching matrix"
|
|
],
|
|
"elements": [
|
|
"7-row scriptsize booktabs table from tab:case-c6 (lines 24-42), columns @{}lp{2.6cm}p{6.6cm}c@{}, arraystretch 0.9; 'event-trig., short-lived' abbreviated as in the script",
|
|
"the examplebox 'Computing the C6 row: one gate, six casualties' (lines 17-22), Stage-1 half, is carried by the table rows, not repeated as bullets"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Merged frame (former 5 and 6): three bullets above the table, nothing below except the caption line. The two harm-clause verdicts ($--$ for L and MS without any scoring) are the surprise -- say it while pointing at the rows; MS's harm clause is 'the Prime Video lesson at HPC scale' (line 20, deck 6). \\footnotesize bullets, scriptsize table."
|
|
},
|
|
{
|
|
"no": 6,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 1 -- one survivor, and the didactic point",
|
|
"kind": "case",
|
|
"script_ref": "§30.1 (part4_fit.tex 19-22, 44)",
|
|
"content": [
|
|
"\\textbf{Stages 2 and 3 -- one survivor.} Only PF reaches the veto stage, and no veto fires: against the High set $\\{$D2, D9, D10$\\}$ it rates $+$, $+$, $++$ (PF column, deck 6) -- throughput from data-parallel frameworks, reproducibility by construction, utilisation-driven cost",
|
|
"Its $--$ on D3 sits on a Low weight and is \\emph{inert}; the holistic reading ranks a field of one",
|
|
"\\textbf{Result: $\\mathrm{fit}(\\text{C6},\\text{PF}) = ++$, every other pattern at $\\circ$ or below} -- the C6 row of the matrix, computed almost entirely at Stage 1",
|
|
"The didactic point generalises: \\textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed",
|
|
"The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\\text{C1})$ eliminates any structure that cannot guarantee an ACID booking core, an immutable audit journal, and ten-plus-year retention -- \\emph{before} scoring, however well it scales",
|
|
"The verdict the class's Part III section states (Lecture 9): pipes-and-filters on HPC/batch infrastructure as primary, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\\circ$ cells) stated, not hidden"
|
|
],
|
|
"elements": [
|
|
"examplebox 'Computing the C6 row' (lines 17-22), second half ('Stages 2 and 3 -- one survivor')"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "\\footnotesize; 6 bullets. Link back to deck 6's PF profile column (D2 $+$, D9 $+$, D10 $++$, D3 $--$) without re-showing it."
|
|
},
|
|
{
|
|
"no": 7,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 2 -- C1: the gate passes both, the veto rule decides",
|
|
"kind": "case",
|
|
"script_ref": "§30.2 (part4_fit.tex 46-52: intro, Stage 1, Stage 2 for MS)",
|
|
"content": [
|
|
"\\emph{Two candidates pass the gate, both natively interactive -- and one of them cannot commit a transaction across its own internal boundaries: how does the procedure decide core banking?}",
|
|
"Recall from the deck-6 mirror pair: C1 High on \\textbf{D4, D5, D6, D7, D9}; $K(\\text{C1})$ includes an ACID booking core and BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: the modular monolith against microservices -- the MM and MS columns side by side",
|
|
"\\textbf{Stage 1.} Both natively interactive $\\to$ the gate passes both; no hard constraint in $K(\\text{C1})$ eliminates either -- \\emph{a constraint names an obligation, not a pattern}; both can in principle be operated under FINMA-grade audit obligations",
|
|
"\\textbf{Stage 2 for MS.} $c_4(\\text{MS}) = --$: no ACID transactions across service boundaries; sagas trade atomicity for choreography complexity. D4 is High in C1 $\\to$ \\textbf{the veto fires and caps the cell at $-$}",
|
|
"The fact is \\emph{structural}: no mitigation \\emph{restores} ACID across service boundaries -- sagas buy coordination with compensating actions, not atomicity -- so a mitigation can only show that living without the property is \\emph{survivable}",
|
|
"Monzo (deck 5): roughly 2{,}800 microservices in production banking -- under \\textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation); a condition most organisations do not meet, the premium paid in platform staffing with no gain for typical team sizes",
|
|
"Cap lifted \\textbf{only to $\\circ$}, the condition recorded in the cell rationale; MS's $--$ on D8 and D10 sit on Low weights -- no further veto fires",
|
|
"\\textbf{Result: $\\mathrm{fit}(\\text{C1},\\text{MS}) = \\circ$}"
|
|
],
|
|
"elements": [
|
|
"examplebox 'Computing the cells C1/MS and C1/MM step by step' (lines 50-57), Stage-1 paragraph and 'Stage 2 -- veto rule for MS' paragraph"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Merged frame (former 8 and 9). \\footnotesize, 8 bullets -- the density limit; keep bullets 3, 7 and 8 to one line. Students met the Monzo homogeneity condition in deck 5; here it is priced. Stress on bullet 3: a constraint names an obligation, not a pattern."
|
|
},
|
|
{
|
|
"no": 8,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 2 -- stage 2 for MM, and the stage-3 reading",
|
|
"kind": "case",
|
|
"script_ref": "§30.2 (part4_fit.tex 54-57)",
|
|
"content": [
|
|
"\\textbf{Stage 2 -- veto rule for MM.} $c_4(\\text{MM}) = ++$ (cross-module ACID transactions) -- no veto",
|
|
"But $c_5(\\text{MM}) = -$ on High-weight D5 $\\to$ caps the cell at $\\circ$ -- \\emph{unless a documented mitigation exists}",
|
|
"It does: \\textbf{hot-standby replication of whole monolith instances} -- the classical banking high-availability tactic, in production at Fineract-class core-banking systems. The cap is lifted.",
|
|
"\\textbf{Stage 3 -- holistic reading.} MM now stands at $++$ on D4, $+$ on D6, $+$ on D7, $+$ on D9 -- support on every High-weight dimension of the class, with the one structural weakness mitigated",
|
|
"\\textbf{Result: $\\mathrm{fit}(\\text{C1},\\text{MM}) = ++$}",
|
|
"The ranking MM $\\succ$ MS for the C1 core is \\textbf{stable under plausible weight variation}: it would flip only if D11 (team scaling) rose to High \\emph{and} the Monzo homogeneity condition held -- exactly what the C1 cell rationale (Section 33, Lecture 10) records as the escalation condition"
|
|
],
|
|
"elements": [
|
|
"examplebox (lines 50-57), 'Stage 2 -- veto rule for MM' and 'Stage 3' paragraphs"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "\\footnotesize. Do not add MS's ratings on D5--D9 here: the passage states only MS's D4/D8/D10 cells; the comparison lives in the next frame as two kinds of mitigation."
|
|
},
|
|
{
|
|
"no": 9,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 2 -- two kinds of mitigation, and the C1 verdict",
|
|
"kind": "case",
|
|
"script_ref": "§30.2 (part4_fit.tex 59)",
|
|
"content": [
|
|
"Two columns. Left: \\textbf{operational weakness} -- MM's one-process blast radius (D5): \\emph{repaired outright} by a standard tactic -- hot standby, pod replication",
|
|
"Right: \\textbf{structural weakness} -- atomicity surrendered at the boundary (MS, D4): can only be \\emph{made survivable}, under a condition most organisations do not meet",
|
|
"The division of labour generalises: the veto rule does the heavy lifting, and the \\textbf{``documented mitigation'' clause is where engineering knowledge -- not arithmetic -- enters the computation}",
|
|
"The rest of the row follows the same mechanics (Section 33, Lecture 10); in particular \\textbf{HX -- a delta discipline, not a competitor -- joins MM at $++$} by isolating the long-lived booking core from volatile channels and providers",
|
|
"The verdict the class's Part III section states (Lecture 8): a \\textbf{hexagonal modular monolith for the booking core} (MM and HX at $++$), EDA at the edges and PF for the batch runs as secondary, and microservices only when organisation size forces D11 to High -- the Monzo condition -- exactly the C1 row of the matrix"
|
|
],
|
|
"elements": [
|
|
"two-column comparison (operational vs structural mitigation), deck-6 mirror-pair layout",
|
|
"verdict as a one-line bold statement below the columns"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The asymmetry is the lesson of the case; give it the visual centre. \\footnotesize."
|
|
},
|
|
{
|
|
"no": 10,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 3 -- C2: when scoring cannot separate the survivors",
|
|
"kind": "case",
|
|
"script_ref": "§30.3 (part4_fit.tex 61-66)",
|
|
"content": [
|
|
"\\emph{Two finalists carry $++$ where it matters and neither dominates: what does the procedure return when scoring cannot separate the survivors?}",
|
|
"C2 (from the deck-6 mirror pair): the \\textbf{widest High set in the catalogue} -- D1, D3, D5, D7, D9, D11 -- and a constraint set that knocks out almost nothing; the discrimination work is done by the \\emph{weights}, not the constraints",
|
|
"\\textbf{Stage 1} requires one honest observation about shape: the class core has \\textbf{two constitutive paths} -- the interactive read path that serves the feed, and the asynchronous fan-out path that delivers posts (the five-second delivery scenario, given here from the C2 profile of Part III, is binding for the class)",
|
|
"Neither MS (natively interactive) nor EDA (natively stream/async) is shape-foreign to the path it would carry $\\to$ the gate passes both",
|
|
"\\textbf{Stage 2} fires one veto against each, and documented practice lifts both: MS's $-$ on High-weighted D3 (mitigation: edge caching, precomputed timelines); EDA's $-$ on High-weighted D9 (mitigation: schema/contract tests, progressive delivery)",
|
|
"Both reach Stage 3 intact"
|
|
],
|
|
"elements": [
|
|
"none (bullets); the 'per constitutive path' reading of the gate returns in the formal statement (frame 13) as the one clause not shown in deck 3"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "\\footnotesize. The C2 profile (tab:req-c2) is Lecture 8 material: the High set is recalled from the deck-6 mirror pair, the delivery scenario is given, not recalled. Flag that the per-path reading of the gate is the one element not in deck 3's definition."
|
|
},
|
|
{
|
|
"no": 11,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 3 -- stage 3: the comparison refuses to close",
|
|
"kind": "table",
|
|
"script_ref": "§30.3 (part4_fit.tex 68)",
|
|
"content": [
|
|
"Table across the C2 High set -- columns High dimension | MS | EDA:",
|
|
"D1 read scalability | $++$ | $++$",
|
|
"D3 latency \\& predictability | (mitigated) | $+$",
|
|
"D5 availability \\& isolation | $++$ | $++$",
|
|
"D7 evolvability | $++$ | $++$",
|
|
"D9 testability \\& deployability | $+$ | (mitigated)",
|
|
"D11 team scaling | $++$ | $+$",
|
|
"\\textbf{Neither dominates}: MS leads where \\emph{teams} multiply (D9, D11 -- independent deployments), EDA where \\emph{consumers} multiply (D3 on the asynchronous path; D7 in its attach-new-consumers reading)",
|
|
"The \\textbf{mandatory sensitivity analysis flips the ordering under entirely plausible variation}: weight D11 the way a several-hundred-team organisation must, and MS wins; frame the feed as what it technically is -- an eventually consistent, precomputed product of an event flow -- and EDA wins",
|
|
"By Stage 3's own rule, that instability is \\textbf{not noise}: it marks a genuine tradeoff point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over"
|
|
],
|
|
"elements": [
|
|
"6-row scriptsize table (High dimension | MS | EDA) built from the two rating sequences in line 68 (MS: $++$, (mitigated), $++$, $++$, $+$, $++$; EDA: $++$, $+$, $++$, $++$, (mitigated), $+$), in High-set order D1, D3, D5, D7, D9, D11"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Table on top (compact, 3 columns), three bullets below in \\footnotesize. The dimension names are the standard D-labels of the reference card; the passage gives only the numbers."
|
|
},
|
|
{
|
|
"no": 12,
|
|
"deck_section": "Three Matches, Three Stages",
|
|
"title": "Case 3 -- the record refuses the either/or",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§30.3 (part4_fit.tex 70) + keypoint (72-74)",
|
|
"content": [
|
|
"Twitter's timeline architecture is \\textbf{both patterns at once}: fan-out-on-write \\emph{is} publish/subscribe -- an event flow whose product, the precomputed timeline, is served by independently scaled services",
|
|
"The honest reading of the instability is not ``the procedure failed to pick a winner'' but ``\\textbf{the class genuinely needs both patterns, placed}'' -- the bridge to hybrids (Section 35, Lecture 10), where hybrids turn out to be the normal case, not the exception",
|
|
"The verdict the class's Part III section states (Lecture 8): an \\textbf{EDA $+$ microservices hybrid at organisational scale} (MS and EDA at $++$), a modular monolith as secondary until that scale is \\emph{measured}, not assumed -- Mastodon runs the full fan-out mechanics in a Rails monolith -- exactly the C2 row",
|
|
"keypoint: Three cases, three stages, one division of labour -- the knock-out screening and shape gate kill most candidates before any scoring (C6: the cheapest test runs first); the veto rule disciplines the High set and prices every mitigation as documented engineering rather than optimism (C1); the holistic ordinal reading ranks the survivors while flagging its own instability as a finding, not an error (C2). Every one of the seventy cells was produced by exactly this division of labour."
|
|
],
|
|
"elements": [
|
|
"keypoint box, condensed from lines 72-74"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Three bullets + keypoint: fits at \\footnotesize. Closes the section. C2 is Lecture 8 (Part III, Sections 18--23 cover C1--C5)."
|
|
},
|
|
{
|
|
"no": 13,
|
|
"deck_section": "The Procedure in General",
|
|
"title": "The formal statement -- the deck-3 box, plus one clause",
|
|
"kind": "definition",
|
|
"script_ref": "§31.1 (part4_fit.tex 76-93); recap of deck 3 frame 'The three-stage fit procedure'",
|
|
"content": [
|
|
"\\emph{What rule were the three matches following?} -- stated briefly, because every element has already done visible work: $\\mathrm{fit}(a,p)$ is the ordinal aggregate of the dimension-wise comparison of $R(a)$ and $C(p)$ (operands: opening frame), on the same five-step scale, computed under a deliberately \\textbf{non-compensatory, three-stage procedure}",
|
|
"definitionbox Architecture--application fit (the box you saw in deck 3, now with worked faces):",
|
|
"1. \\textbf{Knock-out screening and workload-shape gate} -- $K(a)$ eliminates before any scoring; $S(p) \\neq S(a)$ caps the cell at $\\circ$ (subsystem role; $+$ only for a \\emph{constitutive} subsystem of a shape-hybrid class; $-$/$--$ where it would harm the binding scenarios). \\textbf{Not shown in deck 3: the gate is read per constitutive path} -- a pattern is not shape-foreign to a class one of whose binding scenarios constitutes a path of the pattern's native shape (Case 3: C2's fan-out delivery scenario)",
|
|
"2. \\textbf{Veto rule on High-weight dimensions} -- $c_i(p) = --$ on a High dimension caps at $-$; $c_i(p) = -$ caps at $\\circ$ -- unless a documented mitigation exists (a tactic or hybrid composition with production evidence): the cell says so, the cap is lifted",
|
|
"3. \\textbf{Holistic ordinal reading with mandatory sensitivity analysis} -- survivors ranked by support of the High set; clustered Medium conflicts downgrade one step; a \\emph{ranking with exclusions}, never ``12\\,\\% better''; a flip under plausible weight variation marks a tradeoff point (ATAM) and is escalated to scenario-based analysis"
|
|
],
|
|
"elements": [
|
|
"definitionbox 'Architecture--application fit' (lines 86-93), condensed to three items of deck-3 length; the per-constitutive-path clause (line 89, last sentence) set in bold and labelled 'not shown in deck 3' -- a deck-level highlight, the script presents it as part of the definition"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Recap frame in substance: the box is deck 3's; do not re-teach it -- point at the three worked faces (C6, C1, C2) and dwell only on the bold per-path clause. Operands formula lives on frame 4, so this frame stays at deck-3 box length (\\footnotesize). If it still overflows, split '(1/2) stage 1' / '(2/2) stages 2--3'."
|
|
},
|
|
{
|
|
"no": 14,
|
|
"deck_section": "The Procedure in General",
|
|
"title": "Three stages, decreasing hardness -- each with a worked face",
|
|
"kind": "table",
|
|
"script_ref": "§31.1 (part4_fit.tex 103)",
|
|
"content": [
|
|
"The three stages are ordered by \\textbf{decreasing hardness}, and each now has a worked face:",
|
|
"Table columns: Stage | What it encodes | Worked face",
|
|
"1 Knock-out and shape gate | facts no merit elsewhere can compensate -- a violated BCBS 239 obligation, an interactive pattern asked to carry a scheduled-batch core | Case 1 (C6): this stage running the show, emptying six of the row's seven cells on shape alone",
|
|
"2 Veto rule | \\textbf{Assumption A4}: the High weights come from the $(H,H)$ leaves of a utility tree (deck 2), so a structural failure on such a dimension fails precisely the scenarios that define the class -- unless engineering practice has produced a documented way around it | Case 2 (C1): both halves of the rule -- a mitigation that \\emph{repairs} (MM's hot standby) and one that merely makes \\emph{survivable under condition} (MS's Monzo condition)",
|
|
"3 Holistic ordinal reading | deliberately the softest: produces an ordering, and carries a built-in alarm for its own instability | Case 3 (C2): the alarm fired and returned a hybrid rather than a false winner"
|
|
],
|
|
"elements": [
|
|
"3-row footnotesize table Stage | What it encodes | Worked face (p{2.6cm} p{5.6cm} p{5.0cm}), from line 103"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "One table, one intro line -- the actually new content of §31.1. The A4 link (High = (H,H) leaves) connects to deck 2's utility-tree frame; spend the extra minute there."
|
|
},
|
|
{
|
|
"no": 15,
|
|
"deck_section": "The Procedure in General",
|
|
"title": "Why the fit is not a weighted sum",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§31.2 (part4_fit.tex 105-109)",
|
|
"content": [
|
|
"Deck 3 (Part I): $V(p) = \\sum_i w_i \\cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all three violated by ordinal profiles (A2); AHP inherits rank reversal",
|
|
"\\textbf{What the three cases add -- a demonstration of what the formula would have destroyed:}",
|
|
"C6: it would have averaged the shape gate away under good scores elsewhere $\\cdot$ C1: it would have let MS's missing cross-service ACID be compensated by team scaling $\\cdot$ C2: it would have manufactured a decimal-point winner exactly where the honest output is a flagged tradeoff point",
|
|
"Kept from multi-criteria decision analysis: the \\emph{explication discipline} (criteria, weights, assumptions forced into the open); dropped: its arithmetic pretensions -- the matrix is an \\textbf{explication and communication instrument}, not a computation that determines decisions; behind every contested cell stands \\textbf{ATAM}, and, where money decides, \\textbf{CBAM} (utility-response curves, return on investment)",
|
|
"keypoint: the fit computation is non-compensatory by design -- constraints knock out before anything is scored, structural failures on High-weight dimensions veto unless a documented mitigation exists, and only then does a holistic ordinal ranking follow, with mandatory sensitivity analysis. A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most."
|
|
],
|
|
"elements": [
|
|
"keypoint box (lines 107-109), condensed",
|
|
"the three C-lines as a compact three-item list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "One recap line only (deck 3's 'Why the obvious alternative fails' / 'pseudo-precision' frames); the three-case demonstration is the new content. \\footnotesize: four bullets + keypoint."
|
|
},
|
|
{
|
|
"no": 16,
|
|
"deck_section": "The Matching Matrix",
|
|
"title": "Cell semantics: what one cell of the grid actually claims",
|
|
"kind": "definition",
|
|
"script_ref": "§32.1 (part4_fit.tex 118-130)",
|
|
"content": [
|
|
"\\emph{What does one cell of a seventy-cell grid actually claim?} A matrix cell answers one precisely delimited question -- and misreading that question is the \\textbf{most common student error} with this instrument",
|
|
"definitionbox Cell semantics of the matching matrix: a cell $\\mathrm{fit}(a,p)$ states the fit of pattern $p$ \\emph{as the dominant structure of the core} of application class $a$ -- the pattern that owns the class's binding quality attribute scenarios. It does \\emph{not} state whether $p$ is useful anywhere in a system of class $a$: hybrid roles at the edges (an event journal beside an ACID core, a batch pipeline beside an interactive product) are stated in the cell rationale, not in the cell value",
|
|
"\\textbf{Consequence 1: a $-$ cell is not a prohibition.} EDA rates $-$ as the dominant structure of a banking core, yet the same rationale names the immutable event journal as the natural regulatory audit trail at that core's edges",
|
|
"\\textbf{Consequence 2: the hexagonal column needs a special reading.} HX is a delta pattern of dependency organisation, not a distribution style; it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''"
|
|
],
|
|
"elements": [
|
|
"definitionbox 'Cell semantics of the matching matrix' (lines 121-123)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Definition box + two consequences; \\footnotesize. Ask students to keep the definition in mind before the grid appears."
|
|
},
|
|
{
|
|
"no": 17,
|
|
"deck_section": "The Matching Matrix",
|
|
"title": "The $7 \\times 10$ matching matrix",
|
|
"kind": "table",
|
|
"script_ref": "§32.2, Table tab:fitmatrix (part4_fit.tex 132-160)",
|
|
"content": [
|
|
"Header: Application class | L | MM | HX$^{\\dagger}$ | MS | EDA | PF | SL",
|
|
"C1 Core banking / transactions | $\\circ$ | \\boldmath$++$ | \\boldmath$++$ | $\\circ$ | $-$ | $\\circ$ | $-$",
|
|
"C2 Social media / content platform | $\\circ$ | $+$ | $\\circ$ | \\boldmath$++$ | \\boldmath$++$ | $\\circ$ | $\\circ$",
|
|
"C3 Back-office / workflow | $+$ | \\boldmath$++$ | $+$ | $--$ | $-$ | $\\circ$ | $\\circ$",
|
|
"C4 ERP / enterprise core system | $\\circ$ | \\boldmath$++$ | $+$ | $--$ | $-$ | $\\circ$ | $--$",
|
|
"C5 E-commerce platform | $-$ | \\boldmath$++$ | $+$ | $+$ | $+$ | $\\circ$ | $+$",
|
|
"C6 Simulation / batch compute | $--$ | $\\circ$ | $\\circ$ | $--$ | $\\circ$ | \\boldmath$++$ | $\\circ$",
|
|
"C7 Decision support / BI analytics | $+$ | $+$ | $\\circ$ | $-$ | $\\circ$ | \\boldmath$++$ | $+$",
|
|
"C8 Real-time / IoT streaming | $--$ | $-$ | $\\circ$ | $+$ | \\boldmath$++$ | $+$ | $-$",
|
|
"C9 Collaboration / messaging | $\\circ$ | $+$ | $\\circ$ | $+$ | \\boldmath$++$ | $-$ | $--$",
|
|
"C10 AI-native analysis / advisory | $-$ | \\boldmath$++$ | \\boldmath$++$ | $\\circ$ | $+$ | $+$ | $\\circ$",
|
|
"Footnote line (\\scriptsize): ratings $++$ (excellent fit) to $--$ (structural misfit); bold $=$ cells underlying the primary recommendation of each class; $^{\\dagger}$HX is a delta pattern -- composes with a host (typically MM), cells read ``as the internal discipline of the class's core''; abbreviations L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS"
|
|
],
|
|
"elements": [
|
|
"10-row scriptsize booktabs table from tab:fitmatrix (lines 138-152), columns @{}p{4.2cm}ccccccc@{}, arraystretch 0.85 -- upright (the script's sidewaystable becomes a normal slide table, same format as deck 6's consolidated capability table)",
|
|
"one-line scriptsize footnote condensed from the minipage (lines 156-158), without the never-negative sentence (frame 20 carries it)"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "The central slide of the deck: nothing else on it. Optionally shade rows C1, C2, C6 lightly (colortbl, bankblue!8) to mark 'the rows you computed'. Give students a silent minute with the grid before talking."
|
|
},
|
|
{
|
|
"no": 18,
|
|
"deck_section": "The Matching Matrix",
|
|
"title": "Reading the grid: the rows you computed",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§32.2 (part4_fit.tex 134, 156) + keypoint (162-164)",
|
|
"content": [
|
|
"The matrix is the three cases of Section 30, \\textbf{done seventy times}",
|
|
"Rows C6, C1, C2: the rows you have just computed; the remaining seven were produced by exactly the same three stages -- knock-out and shape gate, then the H-dimension veto with documented mitigations, then the holistic ordinal reading",
|
|
"Every cell is traceable to $R(a) \\times C(p)$ through the per-class rationales (Section 33 -- Lecture 10)",
|
|
"$^{\\dagger}$HX: a delta pattern -- it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''",
|
|
"keypoint: read a matrix cell as the answer to one question only -- \\emph{how well does this pattern serve as the dominant structure of this class's core?} The edges of the same system routinely use patterns whose cell reads $\\circ$ or $-$; the hybrid roles are stated in the rationales, and Section 35 (Lecture 10) shows that hybrids are the normal case, not the exception"
|
|
],
|
|
"elements": [
|
|
"keypoint box (lines 162-164)"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Short frame after the grid; \\footnotesize like every other content frame. The never-negative claim is deferred to frame 20, where the excerpt table makes it checkable. Point back to the C10 row: identical to the deck-3 mini-match verdicts (L $-$, MM $++$, MS $\\circ$) -- now with HX $++$, EDA $+$, PF $+$, SL $\\circ$ added."
|
|
},
|
|
{
|
|
"no": 19,
|
|
"deck_section": "Reading the Matrix as a Whole",
|
|
"title": "Column patterns (1/2): the unfashionable default",
|
|
"kind": "content",
|
|
"script_ref": "§34.1 (part4_fit.tex 461-469)",
|
|
"content": [
|
|
"\\emph{What does the grid say as a whole that no single cell can?} The matrix rewards a second reading -- not cell by cell but by columns, rows, and boundaries",
|
|
"Column-wise, the \\textbf{modular monolith is primary or secondary in seven of ten classes} -- not because it is fashionable (it is conspicuously unfashionable) but because most requirements profiles weight consistency, evolvability, cost, and time-to-market higher than independent scaling, and \\textbf{MM is the only pattern rated $+$ or better on all four} of those dimensions (capability table, deck 6)",
|
|
"The matrix-level restatement of Fowler's \\textbf{MonolithFirst}: do not start with microservices even if you expect to need them -- stable service boundaries cannot be cut before the domain is understood, and refactoring \\emph{between} services is far costlier than \\emph{within} a monolith",
|
|
"\\textbf{Microservices earn their premium in exactly two situations}, both visible in the grid: where High-weight read scalability, fault isolation, and team scaling coincide (C2, and conditionally C5 and C8) -- and nowhere else",
|
|
"The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO \\textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \\textbf{pay the premium and collect nothing}"
|
|
],
|
|
"elements": [
|
|
"none -- bullets only; the MM and MS columns appear in the excerpt table of frame 20"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "\\footnotesize, 5 bullets, no side table (the optional column excerpt has been removed; frame 20's five-column excerpt covers the visual check)."
|
|
},
|
|
{
|
|
"no": 20,
|
|
"deck_section": "Reading the Matrix as a Whole",
|
|
"title": "Column patterns (2/2): workload-shaped columns, HX never negative",
|
|
"kind": "content",
|
|
"script_ref": "§34.1 (part4_fit.tex 471-473) + footnote minipage (157); excerpt values from tab:fitmatrix (138-147)",
|
|
"content": [
|
|
"\\textbf{PF and EDA are workload-shaped columns.} Their $++$ cells sit precisely where the class's dominant workload shape matches the pattern's native shape -- scheduled batch for PF (C6, C7), continuous stream or fan-out for EDA (C8, C9, and the C2 fan-out)",
|
|
"The shape gate caps them at $\\circ$ -- or, by the harm clause, below -- everywhere the class core is interactive",
|
|
"The clearest demonstration that the gate of Stage 1 does real work: \\textbf{no amount of merit on other dimensions lets a batch pipeline carry an interactive core}",
|
|
"\\textbf{The HX column is never negative} -- not a free lunch but a property of orthogonality: as a delta pattern, hexagonal architecture composes with the host rather than competing with it, and its cost ($c_8 = -$) surfaces only as capped cells where the change rate is low (C6, C7)",
|
|
"Column excerpt table (Class | MM | MS | HX | EDA | PF): C1 $++$ $\\circ$ $++$ $-$ $\\circ$; C2 $+$ $++$ $\\circ$ $++$ $\\circ$; C3 $++$ $--$ $+$ $-$ $\\circ$; C4 $++$ $--$ $+$ $-$ $\\circ$; C5 $++$ $+$ $+$ $+$ $\\circ$; C6 $\\circ$ $--$ $\\circ$ $\\circ$ $++$; C7 $+$ $-$ $\\circ$ $\\circ$ $++$; C8 $-$ $+$ $\\circ$ $++$ $+$; C9 $+$ $+$ $\\circ$ $++$ $-$; C10 $++$ $\\circ$ $++$ $+$ $+$"
|
|
],
|
|
"elements": [
|
|
"10-row scriptsize five-column excerpt (MM, MS, HX, EDA, PF) of tab:fitmatrix (lines 138-147) on the right, bullets on the left (columns 0.58/0.38); MM/MS columns serve frame 19's claims (seven of ten; the two $--$ cells C3, C4), HX/EDA/PF serve this frame's"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The excerpt makes the claims visually checkable: $++$ only on shape matches; no negative HX cell; the MS $--$ cells at C3/C4. Speaker note on bullet 2: the $-$ cells of EDA (C1, C3, C4) and PF (C9) are harm-clause results of the same gate (definition item 1, line 89) -- the script's sentence at line 471 says only 'caps at $\\circ$'."
|
|
},
|
|
{
|
|
"no": 21,
|
|
"deck_section": "Reading the Matrix as a Whole",
|
|
"title": "Row patterns and the five empirical support points",
|
|
"kind": "table",
|
|
"script_ref": "§34.2 (part4_fit.tex 475-479)",
|
|
"content": [
|
|
"Row-wise: \\textbf{no class is served above $\\circ$ by every pattern, and no pattern serves every class above $\\circ$} -- Assumption A2 made visible in a single glance at the grid",
|
|
"If a dominant pattern existed, its column would be uniformly positive, and this part of the module would be one page long",
|
|
"Cell-wise: the five case-study systems of the module each sit \\textbf{exactly on a cell boundary} -- the empirical support points at which fit and misfit have been \\emph{measured in money}",
|
|
"Table columns: System | Cell it sits on | What was measured",
|
|
"Prime Video (deck 6) | the split serverless cost cell | over 90\\,\\% infrastructure cost reduction after consolidating a data-intensive flow into one process",
|
|
"Segment | the MS evolvability cell, read against a wrongly cut boundary | services per configuration instance, not per domain seam",
|
|
"Shopify | the MM write-scalability mitigation | pod-sharded replication",
|
|
"Uber (DOMA) | the MS team-scaling cell | the point where service count itself became the problem",
|
|
"Stack Overflow | the layered read-scalability deviation | cache-friendly read dominance served by roughly nine web servers"
|
|
],
|
|
"elements": [
|
|
"5-row scriptsize table System | Cell | What was measured (p{2.4cm} p{4.6cm} p{6.2cm}) from line 479"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Three bullets above the table at \\footnotesize; the table carries only what the passage states (no further figures). All five systems were case studies in decks 3--6; the deck marker is set on Prime Video, the one this deck reuses again in frame 23."
|
|
},
|
|
{
|
|
"no": 22,
|
|
"deck_section": "Reading the Matrix as a Whole",
|
|
"title": "Discussion: the C5 row under two variations",
|
|
"kind": "discussion",
|
|
"script_ref": "§34.2 thinkbox (part4_fit.tex 485-487) + keypoint (481-483); C5 row from tab:fitmatrix (142)",
|
|
"content": [
|
|
"The C5 row for reference: L $-$ | MM $++$ | HX $+$ | MS $+$ | EDA $+$ | PF $\\circ$ | SL $+$",
|
|
"thinkbox: Take the C5 row (e-commerce) and increase the organisation from 3 teams to 30 while holding traffic constant. Which cells change, through which dimension, and at which stage of the three-stage procedure?",
|
|
"thinkbox: Now hold the organisation at 3 teams and multiply traffic by 50.",
|
|
"thinkbox: Why does the second variation move the row so much less than the first -- and what does that say about the popular claim that ``we need microservices to scale''?",
|
|
"keypoint (closing line, after the discussion): the modular monolith dominates the matrix as default \\emph{not despite but because of} its unfashionableness: most requirements profiles weight consistency, evolvability, cost, and time-to-market above independent scaling. Microservices earn their documented premium only where read scalability, fault isolation, and team scaling are simultaneously High -- and the premium is paid in platform staffing either way"
|
|
],
|
|
"elements": [
|
|
"one-line C5 row excerpt from tab:fitmatrix (line 142)",
|
|
"thinkbox 'Discussion' with the three questions (lines 485-487)",
|
|
"keypoint (lines 481-483), condensed, placed below the thinkbox as the closing line"
|
|
],
|
|
"minutes": 6,
|
|
"notes": "Budgeted at 6 minutes: run Stage 2/3 on the C5 row twice with the room. Expected direction -- inferred from §34.1 (lines 465-467) and §34.2 (line 479), NOT stated in the script: the first variation moves D11 to High and re-runs Stage 2/3 in MS's favour (the C2 condition); the second moves D1/D2 but MM's mitigations (Shopify-style replication) hold. Keep this in the speaker notes only; the keypoint is revealed last."
|
|
},
|
|
{
|
|
"no": 23,
|
|
"deck_section": "The Measurement Contract, Introduced",
|
|
"title": "How a decision made this year stays honest in year five",
|
|
"kind": "content",
|
|
"script_ref": "§37 opening (part4_fit.tex 654-659); deck 3 framework frame (measurement contract as fifth element)",
|
|
"content": [
|
|
"\\emph{How does a decision made this year stay honest in year five?} One case motivates the apparatus",
|
|
"What actually triggered the Prime Video re-architecture (deck 6) was \\textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay -- and that measurement, not an opinion, first forced and then vindicated the redesign",
|
|
"The cost dashboard was a \\textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified''",
|
|
"Empirical anchor for building such checks systematically: DORA's finding that \\textbf{loosely coupled architectures and teams are the strongest predictor of continuous delivery} -- coupling, this theory's leading dimension, is a \\emph{measurable} property",
|
|
"The seventh step of the eight-step decision procedure (Section 36, Lecture 10) generalises the observation into a concept -- where this course differs from a classical architecture lecture: the chosen fit is codified as a \\textbf{measurement contract} -- the set of executable invariants under which the architecture is allowed to keep evolving. \\textcolor{bankblue}{\\textbf{``The architecture may change freely as long as the contract stays green''}}",
|
|
"Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD, the four-layer cascade, Boehm vs.\\ Menzies) in Lecture 11"
|
|
],
|
|
"elements": [
|
|
"none; the contract motto set as a highlighted one-liner (\\textcolor{bankblue})"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Bridge to A2: this is the third artefact of the dossier. The 'Lecture 11' pointer lives here (removed from the DORA frame)."
|
|
},
|
|
{
|
|
"no": 24,
|
|
"deck_section": "The Measurement Contract, Introduced",
|
|
"title": "Fitness functions -- the definition",
|
|
"kind": "definition",
|
|
"script_ref": "§37.1 definitionbox (part4_fit.tex 663-665)",
|
|
"content": [
|
|
"definitionbox Architectural fitness function: ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into executable, objective checks and move architecture governance from review meetings into the CI/CD pipeline",
|
|
"Classified along two primary dimensions -- mini-table (two rows):",
|
|
"\\textbf{Scope} | \\emph{atomic}: one characteristic in isolation (e.g.\\ a dependency rule as a unit test) | \\emph{holistic}: combined characteristics in interplay (e.g.\\ security and data freshness under load)",
|
|
"\\textbf{Cadence} | \\emph{triggered}: event-based, on every build or deployment | \\emph{continual}: running permanently in operation (e.g.\\ chaos experiments) | \\emph{temporal}: time-scheduled (e.g.\\ dependency-freshness time bombs)"
|
|
],
|
|
"elements": [
|
|
"definitionbox 'Architectural fitness function' (lines 663-665), quote + one sentence",
|
|
"two-row footnotesize mini-table Scope (atomic | holistic) / Cadence (triggered | continual | temporal) with the script's own examples -- not a 2x3 cross-table, because the script gives no example for four of the six cross cells"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Split from the former frame 26 (definition + families were overfull). Introduction only: the taxonomy in CI/CD is Lecture 11."
|
|
},
|
|
{
|
|
"no": 25,
|
|
"deck_section": "The Measurement Contract, Introduced",
|
|
"title": "Three instrument families",
|
|
"kind": "table",
|
|
"script_ref": "§37.1 enumerate (part4_fit.tex 667-673)",
|
|
"content": [
|
|
"Three worked instrument families recur throughout the module -- table columns: Family | Instruments | Scope / cadence | What it makes testable",
|
|
"1 Dependency checks as CI gates (decks 3--4) | ArchUnit (analogues: NetArchTest, dependency-cruiser, import-linter): ``the domain layer imports no framework'', ``no cycles between modules'' as unit tests that fail the build; Spring Modulith for declared module boundaries | atomic, triggered | what makes the MM ratings of the capability table \\emph{enforceable} rather than aspirational -- without automated boundary verification, boundary erosion is the documented failure mode of the pattern",
|
|
"2 Performance and cost budgets as pipeline gates | latency thresholds, bundle sizes, Lighthouse scores declared in a budget file | (pipeline gate) | \\textbf{Axis B transfer is direct: token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units}",
|
|
"3 Chaos experiments | Netflix's Chaos Monkey terminates production instances to test resilience assumptions permanently; formalised as the principles of chaos engineering | holistic, continual | verifies the \\textbf{D5 cells}: a claimed blast radius is a hypothesis until an instance has actually been killed under load"
|
|
],
|
|
"elements": [
|
|
"3-row scriptsize table Family | Instruments | Scope / cadence | What it makes testable, columns p{2.2cm} p{5.0cm} p{1.8cm} p{4.4cm}, from the enumerate in lines 669-673; the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label because the script classifies only families 1 and 3"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Table alone on the frame. The Axis-B sentence (line 671) is the deck's only AI-lens material -- set in bold, no separate ailinse frame (see open_issues); map it onto item 3 of the A2 measurement contract on the exercise frame. Family 1 was deck 4's ArchUnit/Spring Modulith CI gate and deck 3's ADR-011 confirmation block: say 'the first fitness function most teams ever write' verbally, not on the slide."
|
|
},
|
|
{
|
|
"no": 26,
|
|
"deck_section": "The Measurement Contract, Introduced",
|
|
"title": "DORA metrics: the delivery layer -- and the coupling finding",
|
|
"kind": "content",
|
|
"script_ref": "§37.2 (part4_fit.tex 675-680)",
|
|
"content": [
|
|
"The four DORA metrics measure whether the delivery-relevant promises of a structure are being kept: \\textbf{deployment frequency} and \\textbf{lead time for changes} (tempo); \\textbf{change failure rate} and \\textbf{failed-deployment recovery time} (stability)",
|
|
"Central empirical finding: elite performers lead on \\emph{all four} -- \\textbf{tempo and stability are not a trade-off}",
|
|
"The strongest single result in the field supports coupling as the leading dimension of this entire theory: ``loosely coupled architectures and teams are the strongest predictor of continuous delivery'' -- in the 2017 analysis, testability and deployability contributed more to continuous delivery than test and deployment automation itself",
|
|
"High performance is possible with all kinds of systems -- including mainframes -- provided systems and teams are loosely coupled: the label ``microservices'' is \\emph{neither necessary nor sufficient}",
|
|
"Second follow-on finding (deck 5, depth in Lecture 11): as team count grows, deployments per developer per day \\emph{rise} for high performers and \\emph{fall} for low performers",
|
|
"hinweisbox: DORA's evidence is survey-based and analysed with structural equation models -- prediction, not experimental causal proof. The theory treats it as the best available large-$n$ evidence, to be triangulated against case studies and your own measurements -- not as settled law"
|
|
],
|
|
"elements": [
|
|
"hinweisbox with the honesty caveat (line 680)"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "\\footnotesize; five one-to-two-line bullets + hinweisbox. The 'neither necessary nor sufficient' line closes the loop to frame 19 (MS premium) and deck 6's Conway bullet. No separate 'Depth' line -- frame 23 carries the Lecture-11 pointer."
|
|
},
|
|
{
|
|
"no": 27,
|
|
"deck_section": "Closing",
|
|
"title": "This week's exercise: the design-review gate and Deliverable A2",
|
|
"kind": "exercise",
|
|
"script_ref": "project_exercise.tex M2 taskbox (lines 401-414) and phase description (line 361); semester plan week 7 row",
|
|
"content": [
|
|
"projektbox: \\textbf{The design phase closes this week.} Finalise the solution design:",
|
|
"1. \\textbf{Service cut and contracts} -- bounded contexts $\\to$ service decomposition and the contracts between the deterministic core, the edges, and the AI subsystem",
|
|
"2. \\textbf{Walking-skeleton plan} -- the thin end-to-end slice you will build first in Sprint 1",
|
|
"3. \\textbf{Measurement contract} -- in today's vocabulary: a \\emph{token budget} (family 2: cost budget as a pipeline gate), an \\emph{eval threshold} (pass rate on the golden set before rollout), and \\emph{module-boundary checks} (family 1: dependency rules as CI gates, ArchUnit / import-linter style)",
|
|
"4. \\textbf{Design-Review Gate} -- defend the ADR: which vetoes fired, which mitigations are \\emph{documented}, what the sensitivity check showed",
|
|
"\\textbf{Deliverable A2 (end of week 7): architecture dossier} -- ADR $+$ C4 diagram $+$ measurement contract. Production code starts only after the gate (exploratory spikes are allowed)",
|
|
"Below the box (\\small): From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (walking skeleton) begins"
|
|
],
|
|
"elements": [
|
|
"projektbox with enumerate (deck-6 exercise-frame format); the outlook line sits outside the box as \\small text, as deck 6 did"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Map each measurement-contract item to one of the instrument families from frame 25 so the lecture content lands directly in the deliverable. 'and the AI subsystem' in item 1 is consistent with the deck-6 projektbox but is not in the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts')."
|
|
},
|
|
{
|
|
"no": 28,
|
|
"deck_section": "Closing",
|
|
"title": "Summary",
|
|
"kind": "summary",
|
|
"script_ref": "deck summary (frames 4-26)",
|
|
"content": [
|
|
"1. \\textbf{Three cases, three stages}: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid",
|
|
"2. \\textbf{Two kinds of mitigation}: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo)",
|
|
"3. \\textbf{The formal statement}: $\\mathrm{fit}(a,p)$ -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts",
|
|
"4. \\textbf{Cell semantics}: a cell rates the pattern as the dominant structure of the core only; $-$ is not a prohibition; HX reads as the internal discipline of the core",
|
|
"5. \\textbf{The grid}: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2)",
|
|
"6. \\textbf{Five support points}: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money",
|
|
"7. \\textbf{Measurement contract}: fitness functions (scope $\\times$ cadence; dependency checks, budgets, chaos) and the four DORA metrics; \\emph{the architecture may change freely as long as the contract stays green}"
|
|
],
|
|
"elements": [
|
|
"numbered list (7 points, each at most two lines), \\footnotesize, no keypoint"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Keypoint dropped (its two claims are points 4 and 7). Deck-6 summary shape: seven points of 1--2 lines."
|
|
},
|
|
{
|
|
"no": 29,
|
|
"deck_section": "Closing",
|
|
"title": "Next week",
|
|
"kind": "nextweek",
|
|
"script_ref": "semester plan week 8 row; project_exercise.tex M3 (lines 416-420); task brief 'Next lecture'",
|
|
"content": [
|
|
"Left column -- \\textbf{Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5}: challenges $\\to$ profiles $\\to$ what real systems chose; the rows C1--C5 of today's matrix, derived from the demand side",
|
|
"Right column -- \\textbf{Reading}: this week: Part IV, Sections 30--32, 34; Section 37 (introduction); ahead: Part III, Sections 18--23",
|
|
"Right column -- \\textbf{Exercise / deliverable}: \\textbf{A2 $+$ design-review gate: this week}; from week 8: Sprint 1 -- walking skeleton (\\texttt{MarketDataService} $+$ minimal \\texttt{ResearchAgent} $+$ stable API); exercise slot becomes a one-lesson standup/coaching"
|
|
],
|
|
"elements": [
|
|
"two-column layout 0.55/0.42 as decks 3--6"
|
|
],
|
|
"minutes": 1,
|
|
"notes": "Verbatim in substance from the task brief."
|
|
},
|
|
{
|
|
"no": 30,
|
|
"deck_section": "Closing",
|
|
"title": "Closing slide",
|
|
"kind": "content",
|
|
"script_ref": "deck skeleton",
|
|
"content": [
|
|
"\\FHGRClosingPage with 'Thank you!' / Dr.\\ Florian Herzog / Fachhochschule Graub\\\"unden, Chur / AISE502 -- AI in Software Engineering II (wrapped in \\parbox, white text -- theme traps 1 and 2)"
|
|
],
|
|
"elements": [
|
|
"FHGR closing page"
|
|
],
|
|
"minutes": 0,
|
|
"notes": "Copy from deck 6 verbatim."
|
|
}
|
|
],
|
|
"exercise_frame": {
|
|
"title": "This week's exercise: the design-review gate and Deliverable A2",
|
|
"content": [
|
|
"projektbox: the design phase closes this week -- finalise the solution design",
|
|
"1. Service cut and contracts: bounded contexts $\\to$ service decomposition and contracts between the deterministic core, the edges, and the AI subsystem",
|
|
"2. Walking-skeleton plan: the thin end-to-end slice built first in Sprint 1",
|
|
"3. Measurement contract in today's vocabulary: token budget (family 2: cost budget as pipeline gate), eval threshold (pass rate on the golden set before rollout), module-boundary checks (family 1: dependency rules as CI gates, ArchUnit / import-linter style)",
|
|
"4. Design-Review Gate: defend the ADR -- which vetoes fired, which mitigations are documented, what the sensitivity check showed",
|
|
"Deliverable A2 (end of week 7): architecture dossier -- ADR $+$ C4 $+$ measurement contract; production code starts only after the gate (exploratory spikes allowed)",
|
|
"Below the box (\\small): from week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session, the lecture grows to three lessons; Sprint 1 walking skeleton begins"
|
|
]
|
|
},
|
|
"summary": [
|
|
"Three cases, three stages: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid",
|
|
"Two kinds of mitigation: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo)",
|
|
"The formal statement: fit(a,p) -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts",
|
|
"Cell semantics: a cell rates the pattern as the dominant structure of the core only; a $-$ is not a prohibition; HX reads as the internal discipline of the core",
|
|
"The grid: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2)",
|
|
"Five support points: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money",
|
|
"Measurement contract: fitness functions (scope x cadence; dependency checks, budgets, chaos) and the four DORA metrics; the architecture may change freely as long as the contract stays green"
|
|
],
|
|
"next_week": {
|
|
"lecture_line": "Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5: challenges -> profiles -> what real systems chose",
|
|
"topics": [
|
|
"application classes C1--C5: challenges -> requirements profiles -> what real systems chose",
|
|
"the rows C1--C5 of today's matrix, derived from the demand side"
|
|
],
|
|
"reading": [
|
|
"this week: Part IV, Sections 30--32, 34; Section 37 (introduction)",
|
|
"ahead: Part III, Sections 18--23"
|
|
],
|
|
"exercise": [
|
|
"A2 (architecture dossier: ADR + C4 + measurement contract) + design-review gate: due end of this week",
|
|
"week 8: Sprint 1 -- walking skeleton (MarketDataService + minimal ResearchAgent + stable API)",
|
|
"from week 8 the exercise slot is a one-lesson (one-hour) standup/coaching; the lecture grows to three lessons"
|
|
]
|
|
},
|
|
"script_boxes_used": [
|
|
{
|
|
"box": "examplebox 'Computing the C6 row: one gate, six casualties'",
|
|
"location": "§30.1, part4_fit.tex 17-22",
|
|
"used_in_frame": "5 (Stage-1 half, carried by the table rows), 6 (Stages 2-3 half)"
|
|
},
|
|
{
|
|
"box": "Table tab:case-c6 'Case 1 -- the C6 row decided at Stage 1'",
|
|
"location": "§30.1, part4_fit.tex 24-42",
|
|
"used_in_frame": "5"
|
|
},
|
|
{
|
|
"box": "examplebox 'Computing the cells C1/MS and C1/MM step by step'",
|
|
"location": "§30.2, part4_fit.tex 50-57",
|
|
"used_in_frame": "7 (Stage 1 + Stage 2 MS), 8 (Stage 2 MM + Stage 3)"
|
|
},
|
|
{
|
|
"box": "keypoint 'Three cases, three stages, one division of labour'",
|
|
"location": "§30.3, part4_fit.tex 72-74",
|
|
"used_in_frame": "12"
|
|
},
|
|
{
|
|
"box": "definitionbox 'Architecture--application fit'",
|
|
"location": "§31.1, part4_fit.tex 86-93",
|
|
"used_in_frame": "13 (condensed to deck-3 length; per-path clause highlighted)"
|
|
},
|
|
{
|
|
"box": "keypoint 'The fit computation is non-compensatory by design'",
|
|
"location": "§31.2, part4_fit.tex 107-109",
|
|
"used_in_frame": "15"
|
|
},
|
|
{
|
|
"box": "definitionbox 'Cell semantics of the matching matrix'",
|
|
"location": "§32.1, part4_fit.tex 121-123",
|
|
"used_in_frame": "16"
|
|
},
|
|
{
|
|
"box": "sidewaystable tab:fitmatrix 'The matching matrix' incl. dagger footnote minipage",
|
|
"location": "§32.2, part4_fit.tex 132-160",
|
|
"used_in_frame": "17 (full grid), 18 (dagger one-liner), 20 (five-column excerpt + never-negative sentence), 22 (C5 row)"
|
|
},
|
|
{
|
|
"box": "keypoint 'Read a matrix cell as the answer to one question only'",
|
|
"location": "§32.2, part4_fit.tex 162-164",
|
|
"used_in_frame": "18"
|
|
},
|
|
{
|
|
"box": "keypoint 'The modular monolith dominates the matrix as default'",
|
|
"location": "§34.2, part4_fit.tex 481-483",
|
|
"used_in_frame": "22 (closing line after the discussion)"
|
|
},
|
|
{
|
|
"box": "thinkbox 'C5 row: 3 to 30 teams / traffic x50'",
|
|
"location": "§34.2, part4_fit.tex 485-487",
|
|
"used_in_frame": "22"
|
|
},
|
|
{
|
|
"box": "definitionbox 'Architectural fitness function'",
|
|
"location": "§37.1, part4_fit.tex 663-665",
|
|
"used_in_frame": "24"
|
|
},
|
|
{
|
|
"box": "enumerate 'Three worked instrument families' (dependency checks, budgets, chaos)",
|
|
"location": "§37.1, part4_fit.tex 669-673",
|
|
"used_in_frame": "25 (as 3-row table)"
|
|
}
|
|
],
|
|
"script_boxes_dropped": [],
|
|
"open_issues": [
|
|
"No ailinse box exists in the assigned passages (§30-32, §34, §37 intro), so the deck has no dedicated 'AI Lens' frame -- unlike decks 3-6. The only Axis-B material is the §37.1 sentence 'token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units' (line 671); it is set in bold in frame 25 and mapped onto item 3 of the A2 measurement contract in frame 27. An AI-lens frame would need a script addition (recorded for the script maintainer), not a deck-side invention.",
|
|
"§37 now spans four frames (23 intro, 24 definition, 25 instrument families, 26 DORA; 10 minutes) against the brief's '2-3 frames': the high-severity density finding on the former combined definition/families frame forced the split. Content was thinned to an introduction (tool analogues trimmed, no Depth line on the DORA frame, the deployments-per-developer finding reduced to a deck-5 pointer); the taxonomy in CI/CD, the four-layer cascade and Boehm vs Menzies remain Lecture 11.",
|
|
"Frame 25: the family-2 scope/cadence cell reads '(pipeline gate)' without a scope label -- the script (line 671) classifies only family 1 ('atomic, triggered', line 670) and family 3 ('continual holistic', line 672).",
|
|
"§37 opening refers to 'Step (vii)' of the eight-step decision procedure (§36, Lecture 10). Frame 23 names it as 'the seventh step of the eight-step decision procedure (Section 36, Lecture 10)' without explaining the other steps.",
|
|
"The C6 profile (frame 5) and the C2 five-second delivery scenario S2 (frame 10) are Part III material (Lectures 9 and 8); both are presented as 'given here', not 'recalled'. The C1 and C2 High sets are recalled from the deck-6 mirror pair. The 'verdict the class's Part III section states' lines (frames 6, 9, 12) refer to sections students have not read yet.",
|
|
"Case 2 (frame 8) states the escalation condition 'recorded in the cell rationale of Section 33' -- the rationale itself is Lecture 10 material; the deck only names the condition (D11 High and the Monzo homogeneity condition).",
|
|
"Frame 11's table labels the High-set dimensions by their standard names (D1 read scalability, D3 latency, ...); the passage (line 68) gives the two rating sequences by position only, in the order D1, D3, D5, D7, D9, D11.",
|
|
"Frame 8 deliberately omits MS's ratings on D5/D6/D7/D9 for C1 -- the passage states only c4(MS) = --, and -- on D8/D10 (Low); the complete MS column is available from tab:capability (deck 6) but is not in the assigned text.",
|
|
"Frame 20, bullet 2: the script's sentence (line 471) says the shape gate 'caps them at o everywhere the class core is interactive', while its own table shows EDA at - for C1, C3, C4 and PF at - for C9 (harm-clause results of the same gate). The slide rewords to 'caps them at o -- or, by the harm clause, below --'; the tension in the script itself is recorded for the script maintainer.",
|
|
"Frame 22 speaker notes carry an 'expected direction' for the thinkbox (D11 -> High re-runs Stage 2/3 in MS's favour; traffic x50 moves D1/D2 but MM's mitigations hold). It is inferred from §34.1/§34.2, not stated in the script; it must not migrate onto the slide.",
|
|
"Frame 13 labels the per-constitutive-path clause 'not shown in deck 3' -- a deck-level highlight; the script (line 89) presents it as part of the definition, not as new.",
|
|
"Frame 27 item 1 adds 'and the AI subsystem' to the M2 taskbox wording ('Bounded contexts -> service decomposition and contracts', lines 408-410); consistent with the deck-6 projektbox, not in the taskbox. 'One-lesson (one-hour)' matches both the semester plan's 3+1 and the exercise sheet's 'one-hour standup/coaching session' (line 361).",
|
|
"tab:fitmatrix is a sidewaystable in the script; on the slide it is an upright scriptsize table (p{4.2cm} class column + 7 centred columns), the same format deck 6 used for the consolidated capability table -- verify visually after the build.",
|
|
"Deck 6's 'Next week' frame announced reading 'Part IV, sections 1--3' while the title-slide line here is 'Part IV, Sections 30--32, 34; Section 37 (introduction)' -- section numbering follows the script's global numbering; the deck uses the title-slide line.",
|
|
"Minutes: content frames 4-26 sum to 70; with agenda (1), recap (3), exercise (3), summary (2), next week (1) the deck plans 80 of 90 minutes -- 10 minutes slack for the silent matrix minute and a discussion that overruns. If time is short, frame 20's excerpt table can be skipped verbally (the bullets carry the claims).",
|
|
"Residual density risks (all fallbacks recorded in the notes): frame 7 has 8 bullets (merged Stage 1 + Stage 2 for MS) -- keep bullets 3, 7, 8 to one line; frame 13 may still need a '(1/2)/(2/2)' split if the deck-3 box length is exceeded."
|
|
],
|
|
"total_frames": 30
|
|
}
|