1111 lines
100 KiB
JSON
1111 lines
100 KiB
JSON
{
|
|
"lecture": 8,
|
|
"week": 8,
|
|
"lessons": 3,
|
|
"title": "Lecture 8: Requirements Profiles I -- Application Classes C1--C5",
|
|
"script_reference": "Script: Part III, Sections 18--23",
|
|
"agenda": [
|
|
"Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes",
|
|
"\\textbf{C1} -- Core banking / transaction systems: the double impossibility",
|
|
"\\textbf{C2} -- Social media / content platforms: 50:1 and the fan-out",
|
|
"\\textbf{C3} -- Back-office / workflow: the modal, unglamorous case",
|
|
"\\textbf{C4} -- ERP / enterprise core: integration \\emph{is} the product",
|
|
"\\textbf{C5} -- E-commerce: quality attributes with price tags",
|
|
"Five classes side by side -- five verdicts as previews for Part IV",
|
|
"This week's exercise: \\textbf{the walking skeleton} (M3)"
|
|
],
|
|
"recap": [
|
|
"Lecture 6 closed Part II: the consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis",
|
|
"Lecture 6 also opened Part III with \\textbf{C10}, the class of your project: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal modular monolith + PF + EDA) -- and the C1/C2 mirror pair in one frame: \\emph{weights, not dimensions, define a class}",
|
|
"Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \\times 10$ matrix; the measurement contract introduced -- A2 architecture dossier and the design-review gate: implementation is free",
|
|
"Method recall from Lectures 2--3: $R(a) = (w_1 \\ldots w_{12};\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves of the utility tree, shape as a gate, constraints as knock-outs; every High is a veto trigger with the cap rule of the three-stage procedure",
|
|
"Today: back to the demand side, properly -- Part III in its class rhythm for C1--C5: \\emph{challenges $\\to$ binding scenarios $\\to$ profile $\\to$ what real systems chose}; every closing verdict is a preview that Part IV recomputes",
|
|
"Project: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9; numbering as in the taskboxes of the exercise sheet)"
|
|
],
|
|
"frames": [
|
|
{
|
|
"no": 1,
|
|
"deck_section": "Title",
|
|
"title": "AISE502: AI in Software Engineering II -- Lecture 8: Requirements Profiles I -- Application Classes C1--C5",
|
|
"kind": "content",
|
|
"script_ref": "Title slide; Script: Part III, Sections 18--23",
|
|
"content": [
|
|
"\\FHGRTitlePage with subtitle 'Lecture 8: Requirements Profiles I -- Application Classes C1--C5' and script line 'Script: Part III, Sections 18--23'"
|
|
],
|
|
"elements": [
|
|
"\\FHGRTitlePage (theme)"
|
|
],
|
|
"minutes": 0,
|
|
"notes": "Same metadata block as deck 6; only \\subtitle changes."
|
|
},
|
|
{
|
|
"no": 2,
|
|
"deck_section": "Agenda",
|
|
"title": "Agenda",
|
|
"kind": "agenda",
|
|
"script_ref": "Deck skeleton (decks 1-6)",
|
|
"content": [
|
|
"1. Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes",
|
|
"2. C1 -- Core banking / transaction systems",
|
|
"3. C2 -- Social media / content platforms",
|
|
"4. C3 -- Back-office / workflow applications",
|
|
"5. C4 -- ERP / enterprise core systems",
|
|
"6. C5 -- E-commerce platforms",
|
|
"7. Five classes side by side -- five verdicts as previews for Part IV",
|
|
"8. This week's exercise: the walking skeleton (M3)"
|
|
],
|
|
"elements": [
|
|
"enumerate, \\small, itemsep 1pt (deck-6 style)"
|
|
],
|
|
"minutes": 1,
|
|
"notes": "Point out the rhythm once: every class = intro -> challenges -> scenarios and K -> profile -> real systems -> lens/key concept. The rhythm strip itself sits on frame 4."
|
|
},
|
|
{
|
|
"no": 3,
|
|
"deck_section": "Recap",
|
|
"title": "Recap: where we are",
|
|
"kind": "recap",
|
|
"script_ref": "Deck 6 summary and 'Next week' frame (AISE502_Vorlesung_6_Folien.tex 660-698); semester plan rows 6-8; deck 2 frames 691-780 (R(a) method); deck 3 line 389 (veto caps); project_exercise.tex 355-363 (two phases) and taskbox M3 (416-422)",
|
|
"content": [
|
|
"Lecture 6 closed Part II: consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis",
|
|
"Lecture 6 opened Part III with C10: Highs on D6/D7/D9/D10/D12, binding scenarios, verdict hexagonal MM + PF + EDA -- and the C1/C2 mirror pair in one frame: \\emph{weights, not dimensions, define a class}",
|
|
"Lecture 7 (Part IV): three cases, three stages; the procedure in general; reading the $7 \\times 10$ matrix; the measurement contract introduced -- A2 dossier and design-review gate passed: implementation is free",
|
|
"Method recall (Lectures 2--3): $R(a) = (w_1 \\ldots w_{12};\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; shape gates; constraints knock out; every High is a veto trigger with the cap rule",
|
|
"Today: the demand side in its full class rhythm for C1--C5 -- \\emph{challenges $\\to$ binding scenarios $\\to$ profile $\\to$ what real systems chose}; each verdict a preview that Part IV recomputes",
|
|
"Project: design phase over -- the implementation phase opens with M3, the walking skeleton (weeks 8--9)"
|
|
],
|
|
"elements": [
|
|
"bullet list, \\footnotesize"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "No deck 7 file exists yet; the Lecture-7 bullet is taken from the semester plan row 7 and the deck-6 'Next week' frame -- adjust wording once deck 7 is typeset."
|
|
},
|
|
{
|
|
"no": 4,
|
|
"deck_section": "Application Classes as Requirements Profiles",
|
|
"title": "Part III: the demand side, in the same vocabulary",
|
|
"kind": "definition",
|
|
"script_ref": "§18 opening (part3_application_classes.tex 12-27) and §18.4 rhythm sentence (line 112)",
|
|
"content": [
|
|
"\\emph{Part II priced the supply side: seven patterns, each a capability profile $C(p)$ over the twelve dimensions. Part III characterises the demand side -- and A2 and A3 require it in the \\textbf{same} vocabulary at the \\textbf{same} resolution.}",
|
|
"'We are building a banking system' carries almost no architectural information; 'an instant payment must reach confirmed finality in under ten seconds end-to-end, with zero transaction loss, under a regulator-enforced audit obligation' carries almost all of it -- the unit that packages such statements is the \\textbf{application class}",
|
|
"[body of the definitionbox] Definition (application class): a recurring bundle of architecturally significant requirements (ASRs) -- a set of dominant quality attribute scenarios with \\emph{typical response measures}, a characteristic \\emph{workload shape} with its quantitative signature, and a \\emph{regulatory frame} acting as hard constraints",
|
|
"[body of the definitionbox, display math] $R(a) = \\bigl(w_1(a), \\ldots, w_{12}(a);\\; S(a);\\; K(a)\\bigr)$ with $w_i(a) \\in \\{\\text{H}, \\text{M}, \\text{L}\\}$, $S(a)$ the dominant workload shape, $K(a)$ the set of hard constraints",
|
|
"[one-line rhythm strip] Ten sections, one rhythm -- Part II turned around: \\textbf{leading question} $\\to$ \\textbf{the challenges it brings} $\\to$ \\textbf{the requirements profile} $\\to$ \\textbf{what real systems chose, and why}; challenges first, weights after, structures last -- every closing recommendation is a \\emph{preview} that Part IV recomputes"
|
|
],
|
|
"elements": [
|
|
"definitionbox[Application class] from lines 18-25 -- bullets 3-4 are its body, the formula in display math inside the box",
|
|
"one-line horizontal tikz strip of four rounded boxes (question -> challenges -> profile -> real systems) from §18.4 line 112, replacing the former 'How to read the class sections' frame"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The frame carries only: the leading italic sentence in bankblue, the two 'banking' quotations, the definition box (\\footnotesize) and the one-line rhythm strip -- nothing else. Bridge spoken from line 27: 'two pieces of method recall before the catalogue, because every class section uses them' -> frames 5-6."
|
|
},
|
|
{
|
|
"no": 5,
|
|
"deck_section": "Application Classes as Requirements Profiles",
|
|
"title": "Method recall: where the weights come from (Lectures 2--3)",
|
|
"kind": "content",
|
|
"script_ref": "§18.1 (part3_application_classes.tex 29-41); recall of deck 2 frame 'From leaves to weights' (692-702) and deck 3 definitionbox fit(a,p) stage 2 (389)",
|
|
"content": [
|
|
"(Lecture 2) A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are elicited, not guessed (QAW, ATAM utility tree), each leaf rated (business importance, achievement difficulty) on \\{H, M, L\\}",
|
|
"(Lecture 2) \\textbf{The (H,\\,H) leaves of a class's characteristic utility tree \\emph{are} the High weights of $R(a)$}",
|
|
"New in Part III: a weight is a \\textbf{compressed empirical claim} -- 'systems of this class recurrently produce (H,\\,H) scenario leaves on this dimension' -- and each class section makes it \\textbf{auditable}: documented challenges (incidents, production numbers, statutory obligations) $\\to$ two to three \\emph{binding scenarios} with response measures, populating the (H,\\,H) region",
|
|
"(Lecture 3) \\textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps at $\\circ$, unless a documented mitigation with production evidence; \\textbf{M} -- measured, conflicts noted not vetoed, clustered Medium conflicts downgrade one step; \\textbf{L} -- does not discriminate for this class; optimising it is waste",
|
|
"Important Note: there is no weighted sum -- profiles are ordinal, aggregation non-compensatory. \\textbf{An H weight is a veto trigger, not a coefficient.} Ten excellent Mediums cannot buy back one violated High"
|
|
],
|
|
"elements": [
|
|
"hinweisbox from lines 39-41 (condensed; the ledger simile is dropped here -- it returns on frames 10-11)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "§18.1 is labelled 'method recall' by the script itself (line 27). Bullets 1, 2 and 4 are tagged as recall and kept to one line each; the genuinely new payload is bullet 3 (lines 33-35) and the box. Body \\footnotesize."
|
|
},
|
|
{
|
|
"no": 6,
|
|
"deck_section": "Application Classes as Requirements Profiles",
|
|
"title": "Workload shape and hard constraints",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§18.2 (part3_application_classes.tex 43-52); recall of deck 2 frame 'The last two components: shape and constraints' (735-752)",
|
|
"content": [
|
|
"(recall, Lecture 2) $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \\emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core; every shape has a quantitative signature reported with production numbers -- \\emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}",
|
|
"(recall, Lecture 2) $K(a)$ -- \\textbf{knock-out filters, not weights}: a violating pattern or deployment form is excluded before any scoring and can never be averaged away",
|
|
"The regulatory inventory of this catalogue: BCBS 239, FINMA Circular 2023/1, DORA, PCI DSS v4.0, the EU AI Act -- plus organisational facts (team size and skills, mandated platforms, budget)",
|
|
"Regulation is a first-class architectural requirement that \\textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components",
|
|
"Key Concept: an application class is an ASR bundle, not an industry label -- weights from the (H,\\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \\emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting and increasingly a C10 advisory layer -- so the fit matrix is read \\textbf{per subsystem, never per company logo}: your project's inheritance diagram (Lecture 6: C10 inherits C6/C7/C3) is exactly that reading"
|
|
],
|
|
"elements": [
|
|
"keypoint from lines 50-52 (condensed; last clause recalls the deck-6 inheritance diagram)"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Bullets 1-2 are marked recall; new for this lecture are the regulatory inventory, 'regulation translates into structure' (lines 46-48) and the keypoint. The bank-with-five-classes sentence recalls the inheritance diagram of deck 6 (frame 'C10 -- your project as an inheritance diagram'), it does not prepare it."
|
|
},
|
|
{
|
|
"no": 7,
|
|
"deck_section": "Application Classes as Requirements Profiles",
|
|
"title": "A map of the ten classes",
|
|
"kind": "diagram",
|
|
"script_ref": "§18.3 (part3_application_classes.tex 54-108)",
|
|
"content": [
|
|
"C1 and C2 at opposite ends of the consistency axis within the same band -- the didactic \\textbf{mirror pair}; C10 the only class whose \\emph{shape} is constitutively hybrid",
|
|
"Today's five all sit in the interactive band -- read them along the axis: C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual"
|
|
],
|
|
"elements": [
|
|
"tikz fig:classmap, lines 58-108 -- redraw at \\resizebox{0.85\\textwidth} with rounded rectangles; colours inter=bankblue, stream=bankgreen, batch=gray, hybrid=bankblue!70!black (script's projteal is not defined in the deck preamble -- define or alias it); highlight today's five nodes with a thicker frame; two \\footnotesize lines beneath the figure"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Only the two bullets go on the slide; the rest is spoken from these notes: (i) two variables discriminate more than any others -- dominant workload shape (bands) and consistency semantics the core requires (axis); (ii) the axis is ordinal, not metric: strict ACID -> hybrid split by subsystem -> causal / per-key / by contract -> eventual; (iii) interactive band: C1 ACID ledger, C4 + batch runs, C3, C5 checkout ACID / catalogue eventual, C9 connection-stateful causal per channel, C2 stale feed acceptable; (iv) stream band C8 (event time, exactly-once state); batch band C6 (reproducible, seeds) and C7 (fresh by refresh contract); hybrid band C10 (index eventual, audit path ACID); (v) C6 reproducibility and C7 freshness by refresh contract are a third family of semantics, neither ACID nor eventual -- Lecture 9. On the map C3 sits between the ACID tick and the hybrid tick without a sub-label, hence 'ACID-leaning'; the C4 keypoint (frame 33) makes the ACID claim explicit. Verify with pdftoppm that the axis labels do not collide."
|
|
},
|
|
{
|
|
"no": 8,
|
|
"deck_section": "Application Classes as Requirements Profiles",
|
|
"title": "Discussion: classification is a hypothesis -- test it on three systems",
|
|
"kind": "discussion",
|
|
"script_ref": "§18.4 hinweisbox and thinkbox (part3_application_classes.tex 113-119)",
|
|
"content": [
|
|
"Important Note: classifying a concrete system as an instance of a class is step (i) of the decision procedure -- a \\emph{hypothesis about the system's ASR bundle}, to be inherited and then corrected against elicited scenarios, never a verdict. Real systems blend classes; \\textbf{the blend, not the label}, is what the utility tree must capture",
|
|
"Take three software systems you have used this week -- your e-banking app, a messaging tool, a streaming service",
|
|
"Which application classes do they instantiate?",
|
|
"Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement?",
|
|
"Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn?"
|
|
],
|
|
"elements": [
|
|
"hinweisbox from lines 113-115 (condensed) as the lead-in at the top of the frame",
|
|
"thinkbox from lines 117-119 with the three questions"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "3 minutes of pair talk; collect two answers, place them on the map of frame 7 (go back one frame) -- and point out where an answer is a blend rather than a label."
|
|
},
|
|
{
|
|
"no": 9,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "Part III in the class rhythm: C1 -- Core banking / transaction systems",
|
|
"kind": "content",
|
|
"script_ref": "§19 opening (part3_application_classes.tex 125-128)",
|
|
"content": [
|
|
"\\emph{A payment is booked twice, or not at all: which of the two can a bank survive?} Neither -- and that double impossibility is the class in one sentence",
|
|
"Systems of record for accounts, payments and positions: the booking core of a bank, a payment-clearing platform, an exchange's matching and settlement layer -- the machinery behind your e-banking balance, the card authorisation at the till, the salary on the 25th",
|
|
"Defining property: a lost or double-posted booking event is an \\textbf{existential} defect -- it creates or destroys money -- whereas unavailability is expensive but reversible",
|
|
"Double-entry bookkeeping demands atomic, serialisable transactions over the ledger: classical ACID territory. Auditability is a regulator-enforced obligation: every state change journaled and reconstructable -- which is why event-sourced journals and ledger data models fit naturally",
|
|
"Three challenges define the class: (1) \\textbf{the sums at stake} (D4, D6); (2) \\textbf{a speed spread of six orders of magnitude} within one class (D3, D2, D5); (3) \\textbf{time} -- lifetimes measured in decades (D7)"
|
|
],
|
|
"elements": [
|
|
"italic leading question in bankblue (deck 4-6 style); numbered challenge list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Reference the deck-6 mirror-pair frame in one spoken sentence ('you saw the headline; now the derivation'). Do not repeat its bullets."
|
|
},
|
|
{
|
|
"no": 10,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "C1 -- the challenges in numbers",
|
|
"kind": "content",
|
|
"script_ref": "§19.1 (part3_application_classes.tex 130-136)",
|
|
"content": [
|
|
"\\textbf{Sums.} Swiss Interbank Clearing settles on average roughly CHF 226 billion per day, peaks above CHF 386 billion -- a double-posted or lost booking is a balance-sheet event: D4 and D6 before any other consideration. Every payment is a write surrounded by reads (cover checks, sanctions screening, fraud scoring): \\emph{write-critical} -- but the \\emph{concurrency} of writes against shared accounts, not their raw rate, stresses D4",
|
|
"\\textbf{Speed spread.} Batch clearing hours; instant payments under 10 s; card authorisation 1--2 s; exchange trading microseconds -- latency means something different in each regime, hence D3 \\textbf{Medium with a footnote}, not High",
|
|
"SIC5 instant-payment infrastructure: dimensioned for peaks in the order of 2,000 payments/s, clustered in-memory replicated-state-machine design. VisaNet: \\emph{capacity} above 65,000 transaction messages/s while average load lies orders of magnitude below -- capacity dimensioning vs.\\ normal load, the reason D2 is \\emph{planned, not elastic}",
|
|
"Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability is a loss event on national infrastructure with regulator-defined disruption tolerances -- D5",
|
|
"\\textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\\,\\% of US banking systems COBOL-based -- ossification is the documented failure mode, which makes D7 a High \\emph{requirement} precisely because it is so often unmet. Change rate bimodal: booking core rarely, periphery (channels, onboarding, products) constantly. Data structured, records small, retention extreme -- ten years and more"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets, bold challenge labels; numbers in text; target 13-14 lines"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The SWIFT/ISO 20022 evidence is spoken from here, not typeset: 'SWIFT carried over one million ISO 20022 messages per day by the end of 2024, with the MT/MX coexistence phase ending in November 2025 -- a multi-year, industry-wide coordinated interface migration, again a D7 stress' (script line 134, written before the cut-over; by the lecture date the phase has ended). The former SIC5/VisaNet bullet is split into its two claims (capacity vs. load; load pattern and D5) to keep every bullet at three lines or fewer."
|
|
},
|
|
{
|
|
"no": 11,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "C1 -- the binding scenarios and the knock-outs",
|
|
"kind": "content",
|
|
"script_ref": "§19.1 scenarios and K (part3_application_classes.tex 138-146)",
|
|
"content": [
|
|
"Three scenarios compress these challenges into the (H,\\,H) region of the C1 utility tree -- \\textbf{Assumption A4 in action}; every High in the next table traces to one of them",
|
|
"\\textbf{S1 (instant payment finality).} A customer submits an instant payment (stimulus) in normal operation to the payment core; it clears, settles and posts with confirmed finality \\textbf{in under 10 seconds end-to-end, with zero transaction loss} -- the SIC5 operating regime. D3, D4, D5",
|
|
"\\textbf{S2 (ledger integrity under concurrency).} Concurrent postings against the same account at peak load leave the double-entry invariant intact: \\textbf{zero invariant violations, verified by a daily reconciliation job with zero unexplained discrepancies}. The D4 veto scenario -- and, through the reconciliation job, D9",
|
|
"\\textbf{S3 (audit-trail reconstruction).} An auditor requests the complete causal history of one transaction chosen at random, up to ten years back; the full trail is reproduced \\textbf{within one working day, from immutable records} -- BCBS 239's aggregation and reporting principles read operationally. D6, D9",
|
|
"$K(\\text{C1})$ -- the densest constraint set in the catalogue: BCBS 239 (demonstrable risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1 January 2024: ICT risk, protection of \\emph{critical data}, business continuity with disruption tolerances); DORA (EU 2022/2554, applicable 17 January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR throughout",
|
|
"\\textbf{Knock-out reading:} any structure that cannot guarantee an ACID booking core, an immutable and complete audit journal, and ten-plus-year retention is eliminated \\emph{before} any fit scoring -- however well it scales"
|
|
],
|
|
"elements": [
|
|
"one-line lead sentence (line 138); three scenario bullets in deck-6 'binding scenarios' style with (D\\_i) tag in codegray; K paragraph as bold-led text"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Same layout as deck 6 'C10 -- the binding scenarios'. Response measures in bold. The lead line closes the chain from frame 5 (challenges -> (H,H) leaves -> High weights); it is repeated as a short tag on frames 17, 23, 30 and 36. Here the ledger simile of the §18.1 box is spoken ('no feature velocity buys back a double-posted booking'). If overfull, shorten the parentheticals of the K bullet, not the scenarios."
|
|
},
|
|
{
|
|
"no": 12,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "C1 -- requirements profile (column C1)",
|
|
"kind": "table",
|
|
"script_ref": "§19.2 tab:req-c1 (part3_application_classes.tex 148-178)",
|
|
"content": [
|
|
"D1 Read scalability -- M -- reads surround every posting; volumes modest",
|
|
"D2 Write scal.\\ \\& elasticity -- M -- constant load, deterministic peaks; capacity planned, not elastic",
|
|
"D3 Latency -- M -- spread of orders of magnitude: microseconds to hours",
|
|
"D4 Consistency \\& integrity -- \\textbf{H} -- a lost or double-posted booking creates or destroys money",
|
|
"D5 Availability \\& isolation -- \\textbf{H} -- payment rails are national infrastructure; outages are loss events",
|
|
"D6 Security \\& auditability -- \\textbf{H} -- the immutable audit journal is a statutory obligation",
|
|
"D7 Evolvability -- \\textbf{H} -- decades-long lifetimes; ossification is the failure mode",
|
|
"D8 Simplicity \\& TTM -- L -- time-to-market traded for integrity without hesitation",
|
|
"D9 Testability \\& deployability -- \\textbf{H} -- reconciliation and trail reconstruction verifiable by construction",
|
|
"D10 Operating cost -- L -- run cost traded for integrity as willingly as D8",
|
|
"D11 Team scaling -- M -- binds only at neobank organisational scale -- the Monzo condition",
|
|
"D12 AI integrability -- M -- fraud scoring at the edge; the booking path stays deterministic",
|
|
"Shape $S(a)$: interactive (+ batch edges). Constraints $K(a)$: BCBS 239; FINMA 2023/1; DORA; ACID core; 10+ yr retention"
|
|
],
|
|
"elements": [
|
|
"12-row requirements-profile table (scriptsize, arraystretch 0.8, p{3.0cm}cp{7.7cm}, \\vspace{-0.35cm}) from tab:req-c1 lines 152-178, plus Shape and Constraints rows; Highs bold; every 'Why' cell at most ~65 characters, one line, no parentheticals, no inline footnotes"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Five Highs: D4/D5/D6/D7/D9. Weights, Shape and Constraints cell-identical with the script; 'Why' cells are one-line condensations of lines 162-173 (row label 'D5 Availability \\& isolation' follows the deck-6 convention, script says 'fault isolation'). Spoken from the notes, not typeset: note 3 (batch clearing hours, instant payments <10 s, card authorisation 1-2 s, trading microseconds); D1's read list (cover checks, sanctions, fraud scoring) was on frame 10; D6's statute list is on frame 11. Point at the two Lows: this class pays with D8 and D10."
|
|
},
|
|
{
|
|
"no": 13,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "C1 -- what real systems chose, and why",
|
|
"kind": "case",
|
|
"script_ref": "§19.3 text and keypoint (part3_application_classes.tex 180-184, 190-192); deck 4 line 534 (Fineract study)",
|
|
"content": [
|
|
"Two documented production systems show this profile does \\emph{not} determine a single pattern",
|
|
"\\textbf{LMAX} (retail trading): six million orders/s on a \\emph{single} JVM thread -- in-memory, event-sourced, deterministic sequential core with lock-free ring buffers. Serialisable \\emph{by construction} (the strongest answer to the D4 veto); deterministic replay of the journal answers D6 and D9 at once; surrenders elastic write scaling (D2) -- weighted only Medium",
|
|
"\\textbf{Monzo} (UK digital bank): ca.\\ 2,800 Go microservices (ca.\\ 1,600 in 2020), viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, where the MS column excels; the $--$ on simplicity and cost paid deliberately; the D4 risk of sagas in the money path mitigated by homogeneity and central tooling",
|
|
"\\textbf{Apache Fineract} -- the 34-module single deployable you inspected in week 4, now read from the demand side: a modular monolith behind a REST facade -- one ACID quantum serves the D4 veto; domain modules absorb the peripheral change rate (D7); the weak cell, $-$ on D5 (one process as blast radius), mitigated by hot-standby replication. A standing counter-example to 'banking at scale implies microservices'",
|
|
"Key Concept: $R(a)$ alone does not force one pattern; it defines the feasible set, and constraints decide within it. C1's veto dimensions -- D4, D5, D6, D7, D9 -- eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do \\emph{not} rank the survivors. The LMAX/Monzo pair is evidence \\textbf{for} the theory, not against it"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets; system names bold",
|
|
"keypoint from lines 190-192 (condensed) as the closing box"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The examplebox 'LMAX versus Monzo' (lines 186-188) was shown in Lecture 3 (deck 3 407-408) and in the deck-6 mirror-pair frame -- one spoken sentence only: 'same profile, opposite structures -- LMAX's binding scenario microsecond-scale deterministic ordering, Monzo's binding constraint scaling hundreds of engineers safely; A2 resolved twice, in opposite directions, within one feasible set'. Fineract: students read its code in week 4 (34 fineract-* Gradle modules, custom/ extension directory) -- ask them where the hot-standby mitigation sits. Density: four bullets plus box at \\footnotesize; the 'both banking-grade with opposite structures' sentence is spoken, not typeset."
|
|
},
|
|
{
|
|
"no": 14,
|
|
"deck_section": "C1 -- Core Banking",
|
|
"title": "C1 -- AI lens and the verdict",
|
|
"kind": "ailens",
|
|
"script_ref": "§19.3 ailinse and closing sentence (part3_application_classes.tex 194-198)",
|
|
"content": [
|
|
"AI Lens (Fraud scoring at the edge of the ledger, Axis B): AI enters C1 at the periphery, never in the booking path -- fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \\emph{before} a posting is committed; increasingly LLM-based components for case triage and customer communication",
|
|
"D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \\textbf{The rule 'agents propose, deterministic services decide and book' originates in this class}",
|
|
"Where the winning structures' weak cells bite, practice \\emph{places} patterns rather than replacing them: the immutable event journal -- EDA's natural artefact -- serves as the regulatory audit trail at the core's edges; end-of-day clearing, statements and risk runs are genuine PF batch runs beside the interactive core",
|
|
"\\textbf{Verdict (preview):} primary -- a hexagonal modular monolith for the booking core (MM and HX at $++$); secondary -- EDA at the edges, PF for the batch runs; microservices only when organisation size forces D11 to High, the Monzo condition. Part IV computes this through the three-stage procedure"
|
|
],
|
|
"elements": [
|
|
"ailinse[Fraud scoring at the edge of the ledger (Axis B)] from lines 194-196 (condensed)",
|
|
"verdict as bold-led closing paragraph (deck-6 style)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Link to the project hint 'keep the deterministic core free of LLM calls -- this is the line that is graded'."
|
|
},
|
|
{
|
|
"no": 15,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- Social media / content platforms",
|
|
"kind": "content",
|
|
"script_ref": "§20 opening (part3_application_classes.tex 203-206)",
|
|
"content": [
|
|
"\\emph{Three hundred thousand people refresh their feed every second while six thousand post: what structure serves the ratio?}",
|
|
"Consumer platforms whose product is a continuously updated content feed: social networks, media-sharing platforms, content communities -- the apps that fill the tram ride",
|
|
"Defining property: the exact inversion of C1 -- a feed that is a few seconds \\emph{stale} is acceptable; a feed that does not \\emph{load} is not",
|
|
"Consistency is explicitly negotiable -- eventual consistency is a design choice, not a defect -- while read scalability, availability and feed latency carry the binding scenarios",
|
|
"Three challenges: (1) \\textbf{the 50:1 ratio and the fan-out amplification} (D1, D2); (2) \\textbf{the pace of the product} (D7, D9, D11); (3) \\textbf{spiky, viral load} (D5, D3)"
|
|
],
|
|
"elements": [
|
|
"italic leading question in bankblue; numbered challenge list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Light frame; the numbers come on the next one."
|
|
},
|
|
{
|
|
"no": 16,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- the challenges: the ratio, the pace, the spikes",
|
|
"kind": "content",
|
|
"script_ref": "§20.1 (part3_application_classes.tex 208-212)",
|
|
"content": [
|
|
"\\textbf{The ratio.} Twitter's documented 2013 figures, still the canonical calibration: roughly 300,000 timeline reads/s against roughly 6,000 tweet writes/s -- about \\textbf{50:1}. A read path that carries the product at that ratio is a demand on D1 before anything else",
|
|
"Raw write rate modest; the \\textbf{fan-out amplification} is not: one write by an account with millions of followers implies millions of logical deliveries. The naive materialisation ('\\texttt{SELECT} over all follows at read time') was tried and abandoned; the documented solution: fan-out-on-write into in-memory timeline caches (bounded to some 800 entries per home timeline), hybridised with fan-out-on-read for extreme-follower accounts",
|
|
"The textbook decision \\emph{write work versus read work as a function of the read/write ratio} -- and the reason D2 stays Medium: the amplification is absorbed by a dedicated fan-out subsystem, not by the write path proper",
|
|
"\\textbf{The pace.} Feature change rate among the highest in industry: permanent A/B experiments, daily deployments -- Instagram: roughly 100 deployments per day on a Django codebase of several million lines. A joint demand on D7, D9 and -- once the organisation grows into hundreds of feature teams -- D11",
|
|
"\\textbf{The spikes.} Spiky and viral load (breaking news, events), traffic multiplying within minutes: stresses D5 and keeps D3 binding at global peak. Data volume very large, predominantly unstructured (text, images, video); platform long-lived, individual features short-lived"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets, bold challenge labels"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Dense; itemsep 1pt. The 800-entry cache bound and the 50:1 ratio are the numbers to write on the board. Bullet 3 is the text of note 1 of the consolidated table (6 k writes/s vs 300 k reads/s) -- say so here, so the table frame needs no inline footnote."
|
|
},
|
|
{
|
|
"no": 17,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- binding scenarios and a light $K$",
|
|
"kind": "content",
|
|
"script_ref": "§20.1 scenarios and K (part3_application_classes.tex 214-222)",
|
|
"content": [
|
|
"The (H,\\,H) leaves of the C2 utility tree -- A4 in action, each with its response measure:",
|
|
"\\textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \\textbf{p99 server-side latency below 200 ms} -- the regime precomputed timelines and edge caches exist to meet. D1, D3",
|
|
"\\textbf{S2 (fan-out delivery).} A user posts in normal operation; the post becomes visible to followers \\textbf{within 5 seconds for the vast majority of accounts} -- Twitter's stated target, missed by design for extreme-follower accounts and compensated by hybrid fan-out. D2's amplification reading -- and a \\emph{licence} on D4: seconds of staleness are within contract",
|
|
"\\textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \\textbf{SLO attainment maintained and the blast radius of any single component failure below a declared bound}. The D5 scenario",
|
|
"$K(\\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data)",
|
|
"Neither forces a consistency model -- which is precisely why this class can trade consistency away: the mirror image of C1, where regulation forbids exactly that trade. $K$ knocks out little; \\textbf{the discrimination work is done by the weights, not the constraints}"
|
|
],
|
|
"elements": [
|
|
"short (H,H)/A4 tag line; scenario bullets in deck-6 style"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Contrast with frame 11: densest K versus lightest K."
|
|
},
|
|
{
|
|
"no": 18,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- requirements profile (column C2)",
|
|
"kind": "table",
|
|
"script_ref": "§20.2 tab:req-c2 (part3_application_classes.tex 224-254)",
|
|
"content": [
|
|
"D1 Read scalability -- \\textbf{H} -- ca.\\ 50:1 read/write ratio -- the read path carries the product",
|
|
"D2 Write scal.\\ \\& elasticity -- M -- raw writes ca.\\ 6 k/s; fan-out absorbed by a subsystem",
|
|
"D3 Latency -- \\textbf{H} -- p99 below 200 ms at global peak or the product feels broken",
|
|
"D4 Consistency \\& integrity -- L -- a feed seconds stale is invisible; eventual by design",
|
|
"D5 Availability \\& isolation -- \\textbf{H} -- an unavailable feed is the defect; spikes arrive within minutes",
|
|
"D6 Security \\& auditability -- M -- DSA and GDPR duties matter but do not shape the topology",
|
|
"D7 Evolvability -- \\textbf{H} -- permanent A/B experiments; features live weeks, platform decades",
|
|
"D8 Simplicity \\& TTM -- M -- simplicity welcome but outbid by feature velocity at scale",
|
|
"D9 Testability \\& deployability -- \\textbf{H} -- ca.\\ 100 deployments per day need cheap, safe releases",
|
|
"D10 Operating cost -- M -- fleet cost matters but never vetoes the read path",
|
|
"D11 Team scaling -- \\textbf{H} -- hundreds of feature teams must deploy independently",
|
|
"D12 AI integrability -- M -- ranking and moderation are ML components off the p99 path",
|
|
"Shape $S(a)$: interactive read-heavy. Constraints $K(a)$: DSA; GDPR"
|
|
],
|
|
"elements": [
|
|
"12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c2 lines 228-254, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells (~65 characters max)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Six Highs, one Low on D4 -- point at the D1/D4 inversion relative to frame 12 (the mirror seen in deck 6, now derived). Note 1 was said on frame 16; D11's 'the documented growth bottleneck' is spoken."
|
|
},
|
|
{
|
|
"no": 19,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- what real systems chose, and why",
|
|
"kind": "case",
|
|
"script_ref": "§20.3 (part3_application_classes.tex 256-260)",
|
|
"content": [
|
|
"\\textbf{Instagram} -- the documented monolith-at-scale case: to this day a Django monolith at its core, several million lines of Python, thousands of endpoints, roughly 100 deployments per day, scaled horizontally across tens of thousands of identical servers over sharded PostgreSQL and Cassandra",
|
|
"It exploits exactly the cell the L and MM columns share: stateless replication of the application tier scales \\emph{reads} far -- so D1 High is servable from a monolith. \\textbf{A monolith is a potential organisational problem, not a read-scaling problem}",
|
|
"A2 bites on D11: one release train throttles hundreds of teams -- why \\textbf{Twitter/X} migrated from a Rails monolith to JVM services as organisation and load grew, and why its fan-out is an \\emph{event flow} at heart: fan-out-on-write is publish/subscribe, the EDA column's home turf ($++$ on D1, D2 and D7's attach-new-consumers reading)",
|
|
"The MS column serves the same three Highs -- independent scaling of feed, media and graph services (D1), independent team deployments (D9, D11) -- at the documented price of $--$ on D8 and D10, accepted at this scale",
|
|
"\\textbf{Mastodon} (open-source reference): Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, Node.js streaming API, federated via ActivityPub. The entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source: \\emph{Mastodon is the secondary recommendation running in public}"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets; system names bold"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Connect to deck 1 (Stack Overflow: read scaling from one quantum) in one spoken sentence -- not on the slide. 'The scaling limits of the Rails monolith are documented rather than hidden' is spoken."
|
|
},
|
|
{
|
|
"no": 20,
|
|
"deck_section": "C2 -- Social Media / Content Platforms",
|
|
"title": "C2 -- AI lens and the verdict",
|
|
"kind": "ailens",
|
|
"script_ref": "§20.3 keypoint, ailinse, closing sentence (part3_application_classes.tex 262-270)",
|
|
"content": [
|
|
"AI Lens (Feed ranking and moderation as runtime AI, Axis B): in C2, AI is the product's economic engine -- feed ranking, recommendation and content moderation are ML components \\emph{in the serving path}",
|
|
"They inherit the class's own discipline: ranking models trained in offline pipelines (a C6/C7-shaped subsystem) and served from precomputed feature stores at millisecond latency, so S1's p99 budget survives; moderation classifiers sit on the asynchronous ingestion path, where seconds of latency are invisible",
|
|
"General Axis-B rule (Part V): \\textbf{the latency class of the AI component, not its accuracy, decides where in the topology it may live}",
|
|
"Key Concept (recall, Lecture 6): C1 and C2 are mirror images across the consistency/availability trade -- same twelve dimensions, inverted weights on D1 and D4; \\emph{weights, not dimensions, define a class} -- now derived from both sides",
|
|
"\\textbf{Verdict (preview):} primary -- an EDA + microservices hybrid at organisational scale (MS and EDA at $++$); secondary -- a modular monolith until that scale is \\emph{measured}, not assumed. The deciding measurement: deployments per developer per day as teams multiply. Part IV recomputes"
|
|
],
|
|
"elements": [
|
|
"ailinse[Feed ranking and moderation as runtime AI (Axis B)] from lines 266-268 (condensed)",
|
|
"keypoint from lines 262-264 as a one-sentence keypoint box (recall-tagged; the full box was deck 6's mirror-pair frame)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The closing frame keeps the established two-box form (AI Lens + Key Concept) as in frames 14 and 27; the keypoint is a single sentence tagged as recall, so it does not repeat deck 6's full box."
|
|
},
|
|
{
|
|
"no": 21,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- Back-office / workflow applications",
|
|
"kind": "content",
|
|
"script_ref": "§21 opening (part3_application_classes.tex 275-277)",
|
|
"content": [
|
|
"\\emph{The organisation reorganises again, and by next sprint the approval workflow must follow: which structure absorbs its fortieth process change as cheaply as its first?}",
|
|
"Internal administration systems: case management, approval workflows, HR and procurement processes, departmental record-keeping -- the vacation request, the invoice approval, the onboarding checklist",
|
|
"The \\textbf{modal, unglamorous case} of industrial software -- systematically under-represented in engineering blogs precisely because nothing about it is spectacular, which is itself the didactic point",
|
|
"Users are employees, dozens to thousands; hours of downtime usually tolerable; load low and planable",
|
|
"Three challenges: (1) \\textbf{the organisation keeps changing under the software} (D7); (2) \\textbf{the budget} (D8, D10); (3) \\textbf{correctness with witnesses} (D4, D6)"
|
|
],
|
|
"elements": [
|
|
"italic leading question in bankblue; numbered challenge list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Light intro frame in the same rhythm as C1/C2/C4/C5; the numbers follow on the next frame."
|
|
},
|
|
{
|
|
"no": 22,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- the challenges: reorganisation, budget, witnesses",
|
|
"kind": "content",
|
|
"script_ref": "§21.1 (part3_application_classes.tex 279-286)",
|
|
"content": [
|
|
"\\textbf{Reorganisation.} The dominant challenge is not technical: the \\emph{organisation} keeps changing under the software. Maintenance and enhancement consume roughly 40--80\\,\\% (typically about 60\\,\\%) of life-cycle cost, mostly for adapting to reorganisations and process changes rather than repair -- the single strongest demand, on D7. Lifetimes 10--20 years and routinely beyond plan: the fortieth process change is not rhetorical",
|
|
"\\textbf{Budget.} Small internal teams against internal cost centres; every franc spent on platform machinery is a franc unavailable for the next reorganisation -- a standing demand on D8 and D10, and a standing veto against premium structures",
|
|
"\\textbf{Workload.} Almost no pressure: CRUD-dominated, moderately read-heavy (80/20 rule of thumb), office-hours load, gigabytes to a few terabytes of structured data -- D1, D2, D5 do not bind; a single relational ACID database almost always suffices; integration demand, however, is high",
|
|
"\\textbf{Witnesses.} Internal control systems demand enforced dual control and a complete audit trail per case -- D4 (transactional case state) and D6"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets, bold challenge labels"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The budget paragraph and the workload paragraph are separate bullets. Spoken from the notes: the integration list (identity/LDAP, ERP, document management, e-mail) and 'often with document attachments'."
|
|
},
|
|
{
|
|
"no": 23,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- binding scenarios and the knock-outs",
|
|
"kind": "content",
|
|
"script_ref": "§21.1 scenarios and K (part3_application_classes.tex 288-294)",
|
|
"content": [
|
|
"The (H,\\,H) leaves of the C3 utility tree -- A4 in action:",
|
|
"\\textbf{S1 (process change dispersion).} The organisation changes an approval process; the change is implemented and released \\textbf{touching no more than the process definition and one module, within one sprint} -- change dispersion is the operative evolvability metric. The D7 scenario",
|
|
"\\textbf{S2 (four-eyes integrity).} A clerk approves a case that requires dual control; the system enforces the second approval and journals both: \\textbf{zero bypasses and a complete, sequential audit trail per case} -- the internal-control-system obligation read as a scenario. D4, D6",
|
|
"\\textbf{S3 (interactive adequacy).} A caseworker submits a form during office hours; the system responds \\textbf{within 1--2 seconds} -- internal users tolerate more latency than customers, but not unboundedly more. D3, weighted Medium",
|
|
"$K(\\text{C3})$: GDPR for employee data; statutory retention duties (Switzerland: Art.\\ 958\\emph{f} Code of Obligations -- business records retained for ten years); internal control systems with enforced dual control; for public administration additionally administrative law and accessibility requirements",
|
|
"\\textbf{Knock-out reading:} a structure that cannot produce a sequential, tamper-evident audit trail per case, or cannot guarantee retention, is excluded -- constraints that favour simple, journaled, transactional designs"
|
|
],
|
|
"elements": [
|
|
"short (H,H)/A4 tag line; scenario bullets in deck-6 style"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Point out that S1's response measure is a change-dispersion count -- the metric introduced with D7 in deck 2."
|
|
},
|
|
{
|
|
"no": 24,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- requirements profile (column C3)",
|
|
"kind": "table",
|
|
"script_ref": "§21.2 tab:req-c3 (part3_application_classes.tex 296-326)",
|
|
"content": [
|
|
"D1 Read scalability -- L -- dozens to thousands of internal users at office-hours load",
|
|
"D2 Write scal.\\ \\& elasticity -- L -- two requests per second at the July peak -- nothing to elasticise",
|
|
"D3 Latency -- M -- 1--2 s form turnaround suffices, but not unboundedly more",
|
|
"D4 Consistency \\& integrity -- \\textbf{H} -- case state transactional; one skipped approval is an ICS finding",
|
|
"D5 Availability \\& isolation -- L -- hours of downtime are tolerable; the work waits",
|
|
"D6 Security \\& auditability -- \\textbf{H} -- four-eyes enforcement and a tamper-evident trail per case",
|
|
"D7 Evolvability -- \\textbf{H} -- ca.\\ 60\\,\\% of life-cycle cost is evolution, driven by reorganisations",
|
|
"D8 Simplicity \\& TTM -- \\textbf{H} -- small teams, internal budgets: simplest adequate structure wins",
|
|
"D9 Testability \\& deployability -- M -- releases weekly, not hourly; regression scope modest",
|
|
"D10 Operating cost -- \\textbf{H} -- the budget belongs to the next reorganisation, not platform staff",
|
|
"D11 Team scaling -- L -- one team, often part-time",
|
|
"D12 AI integrability -- L -- document extraction decorates the intake edge; core untouched",
|
|
"Shape $S(a)$: interactive. Constraints $K(a)$: retention law, e.g.\\ OR 958\\emph{f}; internal control systems; GDPR"
|
|
],
|
|
"elements": [
|
|
"12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c3 lines 300-326, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The only class among today's five with D8 = H and D10 = H -- mark those two rows; they carry the argument of frame 26. Scenario tags (S1-S3) are spoken."
|
|
},
|
|
{
|
|
"no": 25,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- what real systems chose, and why",
|
|
"kind": "case",
|
|
"script_ref": "§21.3 (part3_application_classes.tex 328-332)",
|
|
"content": [
|
|
"The modal industrial answer: a three-tier or modular-monolith application over one relational database -- the capability tables explain why in two steps",
|
|
"\\textbf{Step 1, column L:} serves D8 and D10 at $++$ -- one artefact, one pipeline, near-zero platform staff -- and its ACID cell serves the D4 veto; its weakness is exactly where this class hurts most, the $-$ on D7 $\\to$ layering fits only small, stable scope",
|
|
"\\textbf{Step 2, column MM:} the same run cost with domain boundaries that absorb the reorganisation-driven change rate -- D7 rises to $+$ while D4 and D10 keep their ratings, at the price of one step on D8 (boundary governance is a permanent line item): the Pareto choice when process change is frequent",
|
|
"\\textbf{Camunda} -- the class's other big lever, \\emph{externalising the thing that changes most}: Camunda 7 embeds the process engine as a Java library with relational persistence (monolith-friendly); Camunda 8 rebuilt the engine (Zeebe) as a partitioned, replicated, horizontally scalable distributed system. Process models in BPMN 2.0: when a reorganisation arrives, \\textbf{the process definition changes, not the codebase} -- S1 met by design",
|
|
"Open-source references for the forms-over-data core: \\textbf{Flowable}; the \\textbf{Frappe} framework underlying ERPNext -- metadata-driven DocTypes generate schema, forms and REST APIs"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets; no mini table"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Spoken, not typeset: 'Camunda's product evolution is a miniature architecture lecture; the 7-to-8 migration documents precisely what distribution buys and what it costs'. The L-vs-MM cells are already in words in steps 1 and 2 -- no mini table."
|
|
},
|
|
{
|
|
"no": 26,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- why this class punishes distribution",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§21.3 examplebox and keypoint (part3_application_classes.tex 334-340); recall of deck 3 mini-match variant (AISE502_Vorlesung_3_Folien.tex 462-467)",
|
|
"content": [
|
|
"Recall, Lecture 3 -- the mini-match variant against $R(\\text{back-office})$: you computed this. MS hits \\textbf{two unmitigated $--$ vetoes at once} (D8 and D10); verdicts L $+$, MM $++$, MS $--$. Today: the evidence behind those weights",
|
|
"Example: a vacation-approval workflow serving 800 employees, peaking at perhaps \\textbf{two requests per second} on the first workday of July. Every quality attribute microservices buy -- independent scaling, independent deployment by many teams, fault isolation across quanta -- is priced in platform staffing and operational complexity that this workload cannot amortise; the Segment case (Part I) showed a small team crushed by exactly this premium. C3 is the clearest instance of the rule that \\textbf{D8 = H and D10 = H jointly veto premium-priced structures}: the class needs its budget for the next reorganisation, not for a service mesh",
|
|
"Key Concept: C3 is the industry's modal case, and its profile rewards the simplest structure that meets the audit constraints -- evolution dominates the cost function, so D7 = H; nobody pays for scale that office-hours load never generates, so D8 = H and D10 = H. \\emph{Unglamorous is not a defect of this class -- it is its optimum}"
|
|
],
|
|
"elements": [
|
|
"one \\footnotesize recall line above the boxes",
|
|
"examplebox[Why this class punishes distribution] from lines 334-336 (condensed)",
|
|
"keypoint from lines 338-340"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Recall line plus two boxes; nothing else. The strongest continuity link of the day: the students derived the L/MM/MS verdicts for this class in week 3 without the evidence."
|
|
},
|
|
{
|
|
"no": 27,
|
|
"deck_section": "C3 -- Back-Office / Workflow",
|
|
"title": "C3 -- AI lens and the verdict",
|
|
"kind": "ailens",
|
|
"script_ref": "§21.3 ailinse and closing sentence (part3_application_classes.tex 342-346)",
|
|
"content": [
|
|
"AI Lens (Document extraction and workflow triage, Axis B): the AI foothold in C3 is \\emph{unstructured input} -- incoming invoices, applications and correspondence parsed by LLM-based extraction components that propose structured case data",
|
|
"The class's constraints shape the integration: extraction runs \\textbf{asynchronously before the workflow starts} (latency-tolerant); its output is \\textbf{validated against the domain schema} before any case is created (the ontology-guard tactic of Part V); the four-eyes obligation of S2 extends to AI proposals -- a human confirms, the system journals both the proposal and the confirmation",
|
|
"D12 = L because none of this touches the class's core; it decorates the intake edge",
|
|
"\\textbf{Verdict (preview):} primary -- a modular monolith with externalised process logic, a Camunda-class workflow engine behind a port (MM at $++$); secondary -- layered 3-tier for small, stable scope (L at $+$). Part IV recomputes",
|
|
"Project link: this is the discipline your deterministic services inherit (deck 6 inheritance diagram: 'the deterministic services are C3 -- ACID, boring on purpose')"
|
|
],
|
|
"elements": [
|
|
"ailinse[Document extraction and workflow triage (Axis B)] from lines 342-344 (condensed)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "The ontology-guard sentence maps directly onto the project's 'ontology guard active on all insights' (M5)."
|
|
},
|
|
{
|
|
"no": 28,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- ERP / enterprise core systems",
|
|
"kind": "content",
|
|
"script_ref": "§22 opening (part3_application_classes.tex 351-354)",
|
|
"content": [
|
|
"\\emph{A sales order must update stock and ledger in the same breath -- for thirty years: what does 'integrated' actually demand?}",
|
|
"Integrated enterprise systems: order management, inventory, finance, HR and production planning sharing \\textbf{one} data model",
|
|
"Defining property: the product's value \\emph{is} the integration -- an order posting updates stock and ledger in one transaction, and every module sees every other module's data consistently",
|
|
"Cross-module ACID transactions over a shared schema -- exactly what distribution makes structurally expensive",
|
|
"Three challenges: (1) \\textbf{cross-module atomicity} (D4, D6); (2) \\textbf{time, in its most extreme form in the catalogue} (D7); (3) \\textbf{rhythm rather than volume} (D3, D5; D1/D2 Low)"
|
|
],
|
|
"elements": [
|
|
"italic leading question in bankblue; numbered challenge list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Light frame."
|
|
},
|
|
{
|
|
"no": 29,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- the challenges: atomicity, thirty years, the batch window",
|
|
"kind": "content",
|
|
"script_ref": "§22.1 (part3_application_classes.tex 356-362)",
|
|
"content": [
|
|
"\\textbf{Cross-module atomicity.} An order confirmation must commit order, stock reservation and ledger posting together, with zero half-completed postings, ever -- the hardest possible demand on D4, coupled directly to D6: financial-reporting law demands an unbroken, tamper-evident chain from source document to ledger entry. Eventual consistency \\emph{between ledger and inventory} is not merely inconvenient -- it contradicts the audit obligation itself",
|
|
"\\textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC generation to end-2027 (optionally 2030) because customers could not complete their migrations. ERP life cycles of 20--30 years are the normal case; replacement projects run for years",
|
|
"Under that horizon \\emph{customising pressure is permanent} -- every enterprise adapts the system to itself -- so the central requirement is a disciplined extension mechanism (modules and add-ons rather than core modification): D7, with the operative sub-requirement that \\textbf{extensions survive releases}. Change-rate signature inverse to load: core processes stable, customisations churn",
|
|
"\\textbf{Rhythm, not volume.} Mixed workload: an OLTP core with deterministic batch peaks (month-end and year-end close, MRP runs, payroll); interactive latency of 1--2 s suffices (D3 Medium); the batch window is a hard boundary; load is almost never the problem -- D1 and D2 Low; planned maintenance windows are an accepted norm, which caps D5 at Medium. Data medium to large, highly structured, very long retention"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets, bold challenge labels"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Four long bullets -- \\footnotesize, itemsep 1pt."
|
|
},
|
|
{
|
|
"no": 30,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- binding scenarios and the knock-outs",
|
|
"kind": "content",
|
|
"script_ref": "§22.1 scenarios and K (part3_application_classes.tex 364-370)",
|
|
"content": [
|
|
"The (H,\\,H) leaves of the C4 utility tree -- A4 in action:",
|
|
"\\textbf{S1 (cross-module posting).} A sales order is confirmed in normal operation; order, stock reservation and ledger posting commit atomically with \\textbf{zero half-completed postings, ever}. The D4 veto scenario",
|
|
"\\textbf{S2 (period-end close).} Month-end closing starts at the period boundary; MRP, depreciation and reporting runs complete \\textbf{within the overnight batch window, with a reconciled trial balance at 06:00}. The batch edge of the workload shape -- and D6's reconciliation reading",
|
|
"\\textbf{S3 (customising survival).} A new release of the core is installed in a system carrying years of customer-specific extensions; the extensions continue to function with \\textbf{zero core modifications required and all extension contracts verified before rollout} -- the survival condition of 20--30-year life cycles. The D7 scenario",
|
|
"$K(\\text{C4})$: financial-reporting law (Swiss CO, HGB, IFRS); audit-proof archiving duties (GoBD in Germany, GeB\\\"uV in Switzerland); GDPR for the HR module; SOX control requirements for US-listed groups",
|
|
"\\textbf{Knock-out reading:} auditability of posting chains is an obligation, not an option -- a candidate that cannot demonstrate an unbroken, tamper-evident chain from source document to ledger entry is knocked out before scoring"
|
|
],
|
|
"elements": [
|
|
"short (H,H)/A4 tag line; scenario bullets in deck-6 style"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Compare S2 with the PF frame of deck 6 ('the 02:00 run missed its window')."
|
|
},
|
|
{
|
|
"no": 31,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- requirements profile (column C4)",
|
|
"kind": "table",
|
|
"script_ref": "§22.2 tab:req-c4 (part3_application_classes.tex 372-402)",
|
|
"content": [
|
|
"D1 Read scalability -- L -- hundreds to thousands of internal users; load rarely binds",
|
|
"D2 Write scal.\\ \\& elasticity -- L -- batch peaks deterministic and planned into the window",
|
|
"D3 Latency -- M -- 1--2 s interactive turnaround; the batch window is the boundary",
|
|
"D4 Consistency \\& integrity -- \\textbf{H} -- cross-module ACID postings order $\\to$ stock $\\to$ ledger \\emph{are} the product",
|
|
"D5 Availability \\& isolation -- M -- planned maintenance windows are an accepted ERP norm",
|
|
"D6 Security \\& auditability -- \\textbf{H} -- unbroken, tamper-evident chain from source document to ledger",
|
|
"D7 Evolvability -- \\textbf{H} -- 20--30-year lifetimes; extensions must survive releases",
|
|
"D8 Simplicity \\& TTM -- M -- nobody expects an ERP overnight, but complexity still costs",
|
|
"D9 Testability \\& deployability -- M -- release trains; extension contracts verified before rollout",
|
|
"D10 Operating cost -- M -- material, but never the deciding dimension",
|
|
"D11 Team scaling -- M -- several module teams coordinate inside one release",
|
|
"D12 AI integrability -- L -- AI assists at the edges; the posting core is untouched",
|
|
"Shape $S(a)$: interactive (+ batch runs). Constraints $K(a)$: GoBD/GeB\\\"uV; SOX; IFRS audit chains"
|
|
],
|
|
"elements": [
|
|
"12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c4 lines 376-402, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Three Highs only (D4/D6/D7) -- the narrowest High set of the five; say so: a narrow High set with the hardest single High. D6's statute list (GoBD/GeBüV, SOX) sits in the Constraints row; scenario tags spoken."
|
|
},
|
|
{
|
|
"no": 32,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- what real systems chose, and why",
|
|
"kind": "case",
|
|
"script_ref": "§22.3 (part3_application_classes.tex 406-408)",
|
|
"content": [
|
|
"\\textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM data model, extended by inheritance. \\textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs",
|
|
"Both: strict module boundaries, one deployment, one database, shared transactions -- \\emph{the modular monolith in its purest industrial form}",
|
|
"Read against the MM column: one ACID quantum answers the D4 veto; domain modules and a disciplined extension mechanism answer D7 -- exactly S3; the $-$ on D5 is absorbed because the class weights D5 only Medium: \\textbf{a rare case where a pattern's weak cell meets a class that does not care}",
|
|
"A2 starkest in the opposite direction: decomposing an ERP into independently deployable services turns cross-module atomicity into distributed sagas -- MS's $--$ on D4 meets the class's hardest High: \\textbf{the structurally strongest anti-fit in the whole grid}; a decade of microservices enthusiasm produced no viable ERP counter-example",
|
|
"Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI, banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets; system names bold; no verdict paragraph (moved to frame 33)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Five bullets at \\footnotesize, each three lines or fewer. 'Community attempts at microservice ERPs have remained marginal; their near-absence after a decade ... is itself empirical evidence' is compressed to the last clause of bullet 4."
|
|
},
|
|
{
|
|
"no": 33,
|
|
"deck_section": "C4 -- ERP / Enterprise Core",
|
|
"title": "C4 -- key concept, verdict and Discussion: what exactly ossified?",
|
|
"kind": "discussion",
|
|
"script_ref": "§22.3 keypoint, thinkbox and closing sentence (part3_application_classes.tex 410-418)",
|
|
"content": [
|
|
"Key Concept: C4 sharpens the difference between C3 and itself -- both are ACID, interactive, evolution-dominated classes, but C4's value proposition is \\emph{integration across modules}, which binds the class to a \\textbf{single transactional quantum}. Where C3 could plausibly be several small systems, C4 by definition cannot: decomposing it converts its core feature (cross-module atomic postings) into its hardest problem (distributed sagas)",
|
|
"\\textbf{Verdict (preview):} primary -- a modular monolith (MM at $++$), the strongest pattern--class alignment in the matrix; secondary -- hexagonal discipline within it for the extension ecosystem. Part IV recomputes",
|
|
"Discussion: SAP's maintenance extension to 2027/2030 means thousands of enterprises run an ERP generation older than most of this course's students",
|
|
"Is that an architecture failure, an architecture success, or both?",
|
|
"Formulate your answer as a statement about D7 (evolvability): what precisely ossified -- the pattern, the customisations, or the organisation's ability to re-derive its own requirements profile?"
|
|
],
|
|
"elements": [
|
|
"keypoint from lines 410-412",
|
|
"verdict as one bold-led line between the boxes (from line 418)",
|
|
"thinkbox from lines 414-416"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Two boxes and one verdict line; 3 minutes of discussion; steer to 'the customisations and the organisation, not the pattern'. Natural break before C5 -- about 95 minutes in (cumulative 97 min at the end of this frame)."
|
|
},
|
|
{
|
|
"no": 34,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- E-commerce platforms",
|
|
"kind": "content",
|
|
"script_ref": "§23 opening (part3_application_classes.tex 423-426)",
|
|
"content": [
|
|
"\\emph{A hundred milliseconds of delay costs one per cent of sales, and Black Friday brings fifty times the load: what survives both at once?}",
|
|
"Online retail platforms: catalogue, search, cart, checkout, payment, fulfilment",
|
|
"Defining property: downtime and slowness convert \\emph{directly} into revenue loss",
|
|
"Equally defining: the only class in the catalogue whose consistency profile is \\textbf{hybrid by definition} -- catalogue and recommendations may be stale, inventory is negotiable (oversell compensation), checkout and payment are strictly ACID",
|
|
"Three challenges: (1) \\textbf{a price tag on latency and availability} (D3, D5, D1); (2) \\textbf{the most extreme seasonality of all classes} (D2, D9); (3) \\textbf{the split personality of the data} (D4 Medium)"
|
|
],
|
|
"elements": [
|
|
"italic leading question in bankblue; numbered challenge list"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Light frame."
|
|
},
|
|
{
|
|
"no": 35,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- the challenges: price tags, Black Friday, two kinds of truth",
|
|
"kind": "content",
|
|
"script_ref": "§23.1 (part3_application_classes.tex 428-432); numbers first shown in deck 2 (211, 227)",
|
|
"content": [
|
|
"\\textbf{The price tag} (Lecture 2 numbers, now read as response measures): Amazon's internal experiment attributing roughly $-1\\,\\%$ of sales to $+100$ ms of latency; Akamai's 2017 retail study measuring up to $-7\\,\\%$ conversion per 100 ms of delay. Latency and availability are \\emph{revenue variables} -- direct demands on D3 and D5, with documented conversion rates as the response measures",
|
|
"The read side is equally commercial: browse-to-buy ratios often exceed \\textbf{100:1}, so the catalogue is a read product -- D1",
|
|
"\\textbf{Seasonality.} Black Friday/Cyber Monday: load factors of \\textbf{10--50$\\times$} over normal operation; Shopify reported peaks of roughly 280 million requests per minute for BFCM 2024. Peaks of that shape must be \\emph{absorbed, not survived} -- the D2 demand, rehearsed in advance: peak readiness is load-tested at 10$\\times$ baseline before the season, which is simultaneously a demand on D9",
|
|
"\\textbf{Two kinds of truth.} The checkout must never lie, the catalogue may -- the hybrid consistency encoded as D4 Medium. Data heterogeneous (semi-structured catalogue, structured orders, media blobs); business change rate high (promotions, checkout experiments -- D7); integration surface very wide (payment service providers, logistics, tax, search, recommendations). The platform lives 10+ years; frontends are short-lived"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets, bold challenge labels"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "The headline numbers ($-1\\,\\%$/100 ms, $-7\\,\\%$/100 ms, 280 M req/min) were on deck 2 -- the tag on bullet 1 says so; what is new is their reading as response measures and dimension demands. Note 6 of the consolidated table (catalogue eventual, checkout ACID) is said here, so the table frame needs no inline footnote."
|
|
},
|
|
{
|
|
"no": 36,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- binding scenarios and the PCI knock-out",
|
|
"kind": "content",
|
|
"script_ref": "§23.1 scenarios and K (part3_application_classes.tex 434-440)",
|
|
"content": [
|
|
"The (H,\\,H) leaves of the C5 utility tree -- A4 in action:",
|
|
"\\textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\\times$ normal load; browsing and checkout continue with \\textbf{p95 checkout latency within budget and zero uncompensated oversells at 10$\\times$ baseline in the pre-peak load test}. D2, D5, D9",
|
|
"\\textbf{S2 (page latency).} A customer opens a product page in normal operation; it renders \\textbf{in under 1--2 s, with API calls under 100--300 ms} -- the budgets behind the revenue calibrations. D1/D3",
|
|
"\\textbf{S3 (payment-scope containment).} A security assessor audits the cardholder-data environment; the audit scope is demonstrably \\textbf{confined to the tokenised payment subsystem, with third-party scripts on checkout pages inventoried and controlled} -- PCI DSS v4.0 read as a scenario. D6",
|
|
"$K(\\text{C5})$: PCI DSS v4.0 governs cardholder data -- v3.2.1 retired 31 March 2024; future-dated requirements mandatory since 31 March 2025, including MFA for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2 (payment initiation, strong customer authentication); GDPR for customer data",
|
|
"Direct architectural implication: \\textbf{payment-scope minimisation} through tokenisation and outsourcing -- the audit scope is a function of the structure, so the structure is chosen to shrink it: \\emph{regulation acting on D6 as a structural force}"
|
|
],
|
|
"elements": [
|
|
"short (H,H)/A4 tag line; scenario bullets in deck-6 style"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Contrast with C1: there regulation forbids a consistency trade; here it reshapes the topology (scope zoning) -- both examples of frame 6's 'regulation translates into structure'."
|
|
},
|
|
{
|
|
"no": 37,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- requirements profile (column C5: seven Highs)",
|
|
"kind": "table",
|
|
"script_ref": "§23.2 tab:req-c5 (part3_application_classes.tex 442-472)",
|
|
"content": [
|
|
"D1 Read scalability -- \\textbf{H} -- browse-to-buy beyond 100:1 -- the catalogue is a read product",
|
|
"D2 Write scal.\\ \\& elasticity -- \\textbf{H} -- 10--50$\\times$ seasonal peaks must be absorbed, not survived",
|
|
"D3 Latency -- \\textbf{H} -- $+100$ ms $\\approx -1\\,\\%$ sales: latency carries a price tag",
|
|
"D4 Consistency \\& integrity -- M -- hybrid by definition: catalogue eventual, checkout ACID",
|
|
"D5 Availability \\& isolation -- \\textbf{H} -- downtime converts to revenue loss at documented rates",
|
|
"D6 Security \\& auditability -- \\textbf{H} -- PCI DSS v4.0 makes payment-scope minimisation structural",
|
|
"D7 Evolvability -- \\textbf{H} -- promotions, checkout experiments, provider churn arrive weekly",
|
|
"D8 Simplicity \\& TTM -- M -- speed to market matters, but not at the checkout's expense",
|
|
"D9 Testability \\& deployability -- \\textbf{H} -- load tests at 10$\\times$ baseline gate the season",
|
|
"D10 Operating cost -- M -- fleet cost matters; the revenue stakes dominate it",
|
|
"D11 Team scaling -- M -- organisation-size dependent: Shopify versus Amazon",
|
|
"D12 AI integrability -- M -- recommendations and search ranking serve off precomputed stores",
|
|
"Shape $S(a)$: interactive, seasonal. Constraints $K(a)$: PCI DSS v4.0 scope minimisation; PSD2/SCA"
|
|
],
|
|
"elements": [
|
|
"12-row requirements-profile table (scriptsize, arraystretch 0.8) from tab:req-c5 lines 446-472, plus Shape and Constraints rows; Highs bold; one-line 'Why' cells"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Seven Highs -- more than any other class (script). No Low at all: say it -- the class pays on every dimension and has the least room to not pay. Notes 6 and 17 are spoken (note 6 was said on frame 35; note 17 -- team size, not traffic -- comes on frame 38)."
|
|
},
|
|
{
|
|
"no": 38,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- what real systems chose, and why",
|
|
"kind": "case",
|
|
"script_ref": "§23.3 (part3_application_classes.tex 476-478); recall of deck 4 examplebox 'Shopify -- the canonical modular monolith' (431-432)",
|
|
"content": [
|
|
"\\textbf{Shopify} -- the Lecture-4 case, now from the demand side: pod sharding lifts the MM column's weak D2 cell to carry 280-million-requests-per-minute peaks, while the single transactional quantum preserves checkout ACID against the D4 boundary -- a documented mitigation of exactly the two cells where pattern and profile rub. Stated rationale: developer productivity plus transactional consistency",
|
|
"\\textbf{Amazon} -- the founding pioneer of service orientation with two-pizza team ownership: the same class, the opposite structure, driven by organisational scale. MS's $++$ on D11 becomes decisive only when team count makes D11 bind: \\textbf{team size, not traffic, is the deciding variable} -- A2 resolved by an organisational constraint, as in C1",
|
|
"Open source: \\textbf{Saleor} (Python/Django, GraphQL-first API-centric monolith), \\textbf{Medusa} (Node.js, modular commerce modules behind a REST API) -- the 'headless/composable' trend is a \\emph{layering} cut, not a microservice cut",
|
|
"Event-shaped edges -- order flows, inventory updates, search indexing, recommendation training -- served by EDA and PF beside the core; flash-sale spikes are the textbook serverless elasticity case: those three columns earn a $+$ in this row \\textbf{without ever owning the checkout}"
|
|
],
|
|
"elements": [
|
|
"\\footnotesize bullets; system names bold; no verdict paragraph (moved to frame 39)"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Shopify's structure (Rails core, ca. 2.8 M lines restructured since 2017 into components with enforced boundaries, Packwerk, pod sharding) was deck 4's examplebox -- one spoken sentence. Amazon's bullet is the text of note 17 of the consolidated table. Shopify returns in Lecture 10 as an evolution-path case -- announce it in one sentence."
|
|
},
|
|
{
|
|
"no": 39,
|
|
"deck_section": "C5 -- E-Commerce",
|
|
"title": "C5 -- hybrid consistency as a designed boundary",
|
|
"kind": "keyconcept",
|
|
"script_ref": "§23.3 examplebox, keypoint and closing sentence (part3_application_classes.tex 480-488)",
|
|
"content": [
|
|
"Example: the C5 consistency split is not an accident to be tolerated but a boundary to be \\emph{designed and documented} -- catalogue reads may be minutes stale (cache-friendly, eventually consistent); inventory may oversell within a compensable bound; the checkout/payment path is ACID with idempotent order creation. The measurable contract: \\textbf{p95 checkout latency within budget and zero \\emph{uncompensated} oversells during peak-load tests at 10$\\times$ baseline}. Where exactly the boundary runs -- is the cart eventual or transactional? -- is a genuine ATAM tradeoff point and belongs in an ADR, not in folklore",
|
|
"Key Concept: C5 is the class where quality attributes carry price tags -- latency and availability convert to revenue at documented rates, seasonality defines elasticity (10--50$\\times$ peaks), and the consistency profile is hybrid \\emph{by definition}: the one class where 'ACID or eventual?' is answered \\textbf{'both, along a designed boundary'}. Team size, not traffic, decides between the Shopify and the Amazon structure",
|
|
"\\textbf{Verdict (preview):} primary -- a modular monolith with the hybrid consistency profile designed inside it and event-driven edges (MM at $++$); secondary -- microservices at organisational scale, MS/EDA/SL earning their $+$ at the edges. Part IV recomputes"
|
|
],
|
|
"elements": [
|
|
"examplebox[Hybrid consistency as a designed boundary] from lines 480-482 (condensed)",
|
|
"keypoint from lines 484-486",
|
|
"verdict as bold-led closing line (line 488), matching how frames 14/20/27 close a class"
|
|
],
|
|
"minutes": 4,
|
|
"notes": "Link to C10 (deck 6): the project's D4 is also a designed split (index eventual, audit path ACID) -- the same discipline, one ADR."
|
|
},
|
|
{
|
|
"no": 40,
|
|
"deck_section": "Five Classes Side by Side",
|
|
"title": "Five classes side by side -- assembled from today's five tables",
|
|
"kind": "table",
|
|
"script_ref": "Assembled from tab:req-c1..c5 (part3_application_classes.tex 152-178, 228-254, 300-326, 376-402, 446-472: the Weight and Shape rows already shown on frames 12, 18, 24, 31, 37); verdict codes from the closing sentences lines 198, 270, 346, 418, 488. Nothing from the consolidated table of Lecture 9",
|
|
"content": [
|
|
"Compact table, rows D1--D12, columns C1 | C2 | C3 | C4 | C5 -- the Weight columns of today's five profile tables placed side by side: D1 M/H/L/L/H; D2 M/M/L/L/H; D3 M/H/M/M/H; D4 H/L/H/H/M; D5 H/H/L/M/H; D6 H/M/H/H/H; D7 H/H/H/H/H; D8 L/M/H/M/M; D9 H/H/M/M/H; D10 L/M/H/M/M; D11 M/H/L/M/M; D12 M/M/L/L/M",
|
|
"Shape row (label 'Shape $S(a)$ -- all interactive'), condensed from the five Shape rows: + batch edges | read-heavy | -- | + batch runs | seasonal",
|
|
"Verdict row (primary, pattern codes from the five closing sentences): MM+HX | EDA+MS | MM | MM | MM",
|
|
"One line under the table: all five interactive; \\textbf{D7 High in all five}; D4 runs H/L/H/H/M -- the consistency axis of the map (frame 7); D8/D10 High only in C3",
|
|
"Label line (\\scriptsize, last line of the frame): \\emph{assembled from today's five tables; the ten-column version and its footnotes: Lecture 9}"
|
|
],
|
|
"elements": [
|
|
"scriptsize table p{2.6cm} + 5 centred columns, Highs bold; weight cells copied from the Weight columns of frames 12/18/24/31/37 (tab:req-c1..c5, cell-identical); shape cells at most two words, condensed from the per-class Shape rows; verdict row as pattern codes only; scriptsize label line below the table"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "A summary assembled from the five profile frames, not a preview of the consolidated table: nothing on this frame is taken from §29 -- the ten-column table, its row-reading rules and its seventeen footnotes are Lecture 9's. Spoken, not typeset: 'within the feasible set the organisation decides -- the Monzo condition (C1), deployments per developer per day (C2), team size not traffic (C5)'; 'Lecture 9 sets the other five columns beside these and adds the footnotes'. Droppable if the deck runs long; summary bullets 3-7 carry the five verdicts."
|
|
},
|
|
{
|
|
"no": 41,
|
|
"deck_section": "Closing",
|
|
"title": "This week's exercise: the walking skeleton",
|
|
"kind": "exercise",
|
|
"script_ref": "project_exercise.tex 355-363 (two phases), week-table rows 8-9 (376-377), taskbox M3 (416-422) and hintbox (451-464); milestone numbering M1-M6 from the taskboxes 391-448; semester plan row 8",
|
|
"content": [
|
|
"Project Link box: \\textbf{implementation phase begins} -- the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time",
|
|
"\\textbf{M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase:} an end-to-end thin slice running: \\texttt{MarketDataService} delivers prices; a \\emph{minimal} \\texttt{ResearchAgent} produces one validated \\texttt{Insight}; a stable API and a placeholder UI that calls it",
|
|
"Build the skeleton first thing -- a thin end-to-end slice de-risks everything that follows",
|
|
"Keep the deterministic core free of LLM calls -- this is the line that is graded (the C1 rule of today: agents propose, deterministic services decide and book)",
|
|
"Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record decisions as ADRs as you go",
|
|
"Checked in week 9: \\textbf{walking skeleton runs end-to-end}"
|
|
],
|
|
"elements": [
|
|
"projektbox with the M3 taskbox content (project_exercise.tex 416-422) and the hintbox lines 453-462"
|
|
],
|
|
"minutes": 3,
|
|
"notes": "Same layout as deck 6 'This week's exercise'. Tie the C3 verdict to the deterministic services (ACID, boring on purpose). Milestone label M3 follows the taskboxes of project_exercise.tex (M1 requirements and ontology, weeks 1-3; M2 architecture decision and solution design, weeks 4-7; M3 walking skeleton, weeks 8-9; M4 deterministic core and resilience, weeks 10-11; M5 multi-agent orchestration, evaluation and hardening, weeks 12-13; M6 presentation, week 14) -- the same numbering decks 9-13 use. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still labels the walking skeleton M2 and the later milestones M3/M4/M5; that table is stale, not the deck -- do not follow it."
|
|
},
|
|
{
|
|
"no": 42,
|
|
"deck_section": "Closing",
|
|
"title": "Summary",
|
|
"kind": "summary",
|
|
"script_ref": "§18-§23 keypoints",
|
|
"content": [
|
|
"1. An application class is an ASR bundle, not an industry label: $R(a) = (w;\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem",
|
|
"2. The map: shape $\\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual",
|
|
"3. \\textbf{C1}: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch",
|
|
"4. \\textbf{C2}: 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; verdict EDA+MS at \\emph{measured} organisational scale, MM until then",
|
|
"5. \\textbf{C3}: the modal case -- ca.\\ 60\\,\\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port",
|
|
"6. \\textbf{C4}: integration \\emph{is} the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid",
|
|
"7. \\textbf{C5}: quality attributes with price tags, 10--50$\\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\\ Amazon -- team size, not traffic, decides",
|
|
"8. Every verdict is a preview: Part IV recomputes it through the three-stage procedure"
|
|
],
|
|
"elements": [
|
|
"enumerate, \\footnotesize, itemsep 2pt"
|
|
],
|
|
"minutes": 2,
|
|
"notes": "Eight points -- at the upper limit; keep each to one line and a half."
|
|
},
|
|
{
|
|
"no": 43,
|
|
"deck_section": "Closing",
|
|
"title": "Next week",
|
|
"kind": "nextweek",
|
|
"script_ref": "Semester plan row 9; task brief 'Next lecture'; §29.1 opening sentence (part3_application_classes.tex 917-920); projektboxes §24.3 (558-560) and §25.3 (632-634)",
|
|
"content": [
|
|
"Left column -- Lecture 9, Part III: classes C6--C9 and 'Stepping back: ten profiles side by side'",
|
|
"C6 simulation/batch (reproducibility); C7 DSS/BI (freshness by refresh contract); C8 IoT streaming; C9 collaboration/messaging",
|
|
"The consolidated requirements table with its seventeen footnotes (§29)",
|
|
"Reading the catalogue as a whole: five cross-class observations (§29.1)",
|
|
"C6 and C7 inside your C10 project (projektboxes §24.3, §25.3)",
|
|
"Right column -- Reading: this week Part III, Sections 18--23; ahead Part III, Sections 24--27 and 29",
|
|
"Right column -- Exercise / deliverable: coaching; finish the walking skeleton -- \\textbf{milestone M3: runs end-to-end (week 9)}"
|
|
],
|
|
"elements": [
|
|
"two columns 0.55/0.42 as in deck 6; left column as a \\footnotesize bullet list (six lines)"
|
|
],
|
|
"minutes": 1,
|
|
"notes": "Verbatim in substance from the task brief. The two added bullets announce what deck 9 teaches beyond C6-C9 and the table: §29.1's five cross-class observations (script line 920: 'Five cross-class observations fall out of the catalogue and prepare the matching in Part IV') and the two projektboxes -- the ingestion and eval pipelines are C6-shaped subsystems (reproducibility as the operative meaning of testability, line 560), the analytics and report subsystem is C7-shaped with the refresh contract 'analysis as of last completed ingestion' (line 634). Say both in one sentence each; the substance is Lecture 9's."
|
|
},
|
|
{
|
|
"no": 44,
|
|
"deck_section": "Closing",
|
|
"title": "Closing slide",
|
|
"kind": "content",
|
|
"script_ref": "\\FHGRClosingPage (deck 6 lines 703-706)",
|
|
"content": [
|
|
"Thank you! -- Dr.\\ Florian Herzog -- Fachhochschule Graub\\\"unden, Chur -- AISE502 -- AI in Software Engineering II"
|
|
],
|
|
"elements": [
|
|
"\\FHGRClosingPage with \\parbox wrapper and \\color{white} (trap 1 and 2 of the theme memo)"
|
|
],
|
|
"minutes": 0,
|
|
"notes": "Copy verbatim from deck 6."
|
|
}
|
|
],
|
|
"exercise_frame": {
|
|
"title": "This week's exercise: the walking skeleton",
|
|
"content": [
|
|
"Implementation phase begins: the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time",
|
|
"M3 -- Walking Skeleton (weeks 8--9), the first milestone of the implementation phase: an end-to-end thin slice running -- \\texttt{MarketDataService} delivers prices; a minimal \\texttt{ResearchAgent} produces one validated \\texttt{Insight}; a stable API and a placeholder UI that calls it",
|
|
"Build the skeleton first thing in the implementation phase -- a thin end-to-end slice de-risks everything that follows",
|
|
"Keep the deterministic core free of LLM calls -- this is the line that is graded (today's C1 rule: agents propose, deterministic services decide and book)",
|
|
"Use a snapshot of market/news data so demo and grading are reproducible; commit after each milestone; record architectural decisions as ADRs as you go",
|
|
"Checked in week 9: walking skeleton runs end-to-end"
|
|
]
|
|
},
|
|
"summary": [
|
|
"An application class is an ASR bundle, not an industry label: $R(a) = (w;\\, S(a);\\, K(a))$ -- weights from the (H,\\,H) leaves; H a veto trigger, not a coefficient; $S(a)$ gates; $K(a)$ knocks out before scoring; one organisation runs several classes, so the matrix is read per subsystem",
|
|
"The map: shape $\\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual",
|
|
"C1: D4/D5/D6/D7/D9 High, the densest $K$; LMAX vs.\\ Monzo -- $R(a)$ defines the feasible set, constraints decide within it; verdict MM+HX core, EDA edges, PF batch",
|
|
"C2: 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; verdict EDA+MS at measured organisational scale, MM until then",
|
|
"C3: the modal case -- ca.\\ 60\\,\\% of life-cycle cost is evolution; D8 = H and D10 = H jointly veto premium structures; verdict MM with a workflow engine behind a port",
|
|
"C4: integration is the product -- cross-module ACID binds the class to one quantum; MM the strongest alignment, MS's $--$ on D4 the strongest anti-fit in the grid",
|
|
"C5: quality attributes with price tags, 10--50$\\times$ peaks, consistency hybrid by definition, PCI scope minimisation as structure; Shopify vs.\\ Amazon -- team size, not traffic, decides",
|
|
"Every verdict is a preview: Part IV recomputes it through the three-stage procedure"
|
|
],
|
|
"next_week": {
|
|
"lecture_line": "Lecture 9 -- Part III: classes C6--C9 and 'Stepping back: ten profiles side by side'",
|
|
"topics": [
|
|
"C6 scientific simulation / batch compute -- reproducibility as consistency semantics",
|
|
"C7 DSS/BI -- freshness by refresh contract",
|
|
"C8 IoT streaming -- event time, exactly-once state",
|
|
"C9 collaboration/messaging -- connection-stateful, causal per channel",
|
|
"Stepping back: the consolidated requirements table with its seventeen footnotes (§29)",
|
|
"Reading the catalogue as a whole: five cross-class observations (§29.1)",
|
|
"C6 and C7 inside your C10 project (projektboxes §24.3, §25.3)"
|
|
],
|
|
"reading": [
|
|
"this week: Part III, Sections 18--23",
|
|
"ahead: Part III, Sections 24--27 and 29"
|
|
],
|
|
"exercise": [
|
|
"coaching; finish the walking skeleton",
|
|
"milestone M3: walking skeleton runs end-to-end (checked in week 9)"
|
|
]
|
|
},
|
|
"script_boxes_used": [
|
|
{
|
|
"box": "definitionbox[Application class]",
|
|
"location": "§18, part3_application_classes.tex 18-25",
|
|
"used_in_frame": "4 Part III: the demand side, in the same vocabulary"
|
|
},
|
|
{
|
|
"box": "hinweisbox (H is a veto trigger, not a coefficient)",
|
|
"location": "§18.1, lines 39-41",
|
|
"used_in_frame": "5 Method recall: where the weights come from (Lectures 2--3)"
|
|
},
|
|
{
|
|
"box": "keypoint (class = ASR bundle; one organisation operates several classes)",
|
|
"location": "§18.2, lines 50-52",
|
|
"used_in_frame": "6 Workload shape and hard constraints"
|
|
},
|
|
{
|
|
"box": "figure fig:classmap (tikz)",
|
|
"location": "§18.3, lines 58-108",
|
|
"used_in_frame": "7 A map of the ten classes"
|
|
},
|
|
{
|
|
"box": "hinweisbox (classification is a hypothesis, never a verdict)",
|
|
"location": "§18.4, lines 113-115",
|
|
"used_in_frame": "8 Discussion: classification is a hypothesis -- test it on three systems (lead-in)"
|
|
},
|
|
{
|
|
"box": "thinkbox (three systems you used this week)",
|
|
"location": "§18.4, lines 117-119",
|
|
"used_in_frame": "8 Discussion: classification is a hypothesis -- test it on three systems"
|
|
},
|
|
{
|
|
"box": "table tab:req-c1",
|
|
"location": "§19.2, lines 152-178",
|
|
"used_in_frame": "12 C1 -- requirements profile (Weight column re-used on frame 40's assembled table)"
|
|
},
|
|
{
|
|
"box": "keypoint (R(a) defines the feasible set, constraints decide)",
|
|
"location": "§19.3, lines 190-192",
|
|
"used_in_frame": "13 C1 -- what real systems chose, and why (closing box)"
|
|
},
|
|
{
|
|
"box": "ailinse[Fraud scoring at the edge of the ledger (Axis B)]",
|
|
"location": "§19.3, lines 194-196",
|
|
"used_in_frame": "14 C1 -- AI lens and the verdict"
|
|
},
|
|
{
|
|
"box": "table tab:req-c2",
|
|
"location": "§20.2, lines 228-254",
|
|
"used_in_frame": "18 C2 -- requirements profile (Weight column re-used on frame 40's assembled table)"
|
|
},
|
|
{
|
|
"box": "keypoint (C1 and C2 are mirror images)",
|
|
"location": "§20.3, lines 262-264",
|
|
"used_in_frame": "20 C2 -- AI lens and the verdict (one-sentence keypoint box, recall-tagged; full box already in deck 6)"
|
|
},
|
|
{
|
|
"box": "ailinse[Feed ranking and moderation as runtime AI (Axis B)]",
|
|
"location": "§20.3, lines 266-268",
|
|
"used_in_frame": "20 C2 -- AI lens and the verdict"
|
|
},
|
|
{
|
|
"box": "table tab:req-c3",
|
|
"location": "§21.2, lines 300-326",
|
|
"used_in_frame": "24 C3 -- requirements profile (Weight column re-used on frame 40's assembled table)"
|
|
},
|
|
{
|
|
"box": "examplebox[Why this class punishes distribution]",
|
|
"location": "§21.3, lines 334-336",
|
|
"used_in_frame": "26 C3 -- why this class punishes distribution"
|
|
},
|
|
{
|
|
"box": "keypoint (C3 is the modal case; unglamorous is its optimum)",
|
|
"location": "§21.3, lines 338-340",
|
|
"used_in_frame": "26 C3 -- why this class punishes distribution"
|
|
},
|
|
{
|
|
"box": "ailinse[Document extraction and workflow triage (Axis B)]",
|
|
"location": "§21.3, lines 342-344",
|
|
"used_in_frame": "27 C3 -- AI lens and the verdict"
|
|
},
|
|
{
|
|
"box": "table tab:req-c4",
|
|
"location": "§22.2, lines 376-402",
|
|
"used_in_frame": "31 C4 -- requirements profile (Weight column re-used on frame 40's assembled table)"
|
|
},
|
|
{
|
|
"box": "keypoint (C4 vs C3: integration binds to one quantum)",
|
|
"location": "§22.3, lines 410-412",
|
|
"used_in_frame": "33 C4 -- key concept, verdict and Discussion"
|
|
},
|
|
{
|
|
"box": "thinkbox (SAP maintenance extension: what ossified?)",
|
|
"location": "§22.3, lines 414-416",
|
|
"used_in_frame": "33 C4 -- key concept, verdict and Discussion"
|
|
},
|
|
{
|
|
"box": "table tab:req-c5",
|
|
"location": "§23.2, lines 446-472",
|
|
"used_in_frame": "37 C5 -- requirements profile (Weight column re-used on frame 40's assembled table)"
|
|
},
|
|
{
|
|
"box": "examplebox[Hybrid consistency as a designed boundary]",
|
|
"location": "§23.3, lines 480-482",
|
|
"used_in_frame": "39 C5 -- hybrid consistency as a designed boundary"
|
|
},
|
|
{
|
|
"box": "keypoint (C5: quality attributes carry price tags)",
|
|
"location": "§23.3, lines 484-486",
|
|
"used_in_frame": "39 C5 -- hybrid consistency as a designed boundary"
|
|
}
|
|
],
|
|
"script_boxes_dropped": [
|
|
{
|
|
"box": "examplebox[LMAX versus Monzo: one profile -- two structures]",
|
|
"location": "§19.3, lines 186-188",
|
|
"reason": "already shown as a box in deck 3 (407-408) and as the deck-6 mirror-pair bullet; reduced to one spoken sentence in the notes of frame 13 -- its lesson is carried by the keypoint 190-192 on that frame"
|
|
},
|
|
{
|
|
"box": "keypoint (an H is a veto trigger backed by a scenario; footnotes carry class-specific semantics)",
|
|
"location": "§29, lines 860-862",
|
|
"reason": "§29 is taught in Lecture 9 together with the full ten-column table and its seventeen footnotes; frame 40 is assembled from the five per-class tables of §19-§23 and takes nothing from §29"
|
|
},
|
|
{
|
|
"box": "tab:requirements footnotes 1, 3, 6, 17",
|
|
"location": "§29, lines 897-912",
|
|
"reason": "referenced by number in the per-class tables (tab:req-c1 D3, tab:req-c2 D2, tab:req-c5 D4/D11) but not inlined in the deck's table cells (one-line rule); their substance also appears in the §19-§23 body text and is spoken there (note 1: frame 16; note 3: frame 10/12 notes; note 6: frame 35; note 17: frame 38)"
|
|
},
|
|
{
|
|
"box": "tab:requirements footnotes 2, 4, 5, 7-16",
|
|
"location": "§29, lines 897-912",
|
|
"reason": "belong to C6-C10 (Lecture 9; C10 covered in deck 6)"
|
|
},
|
|
{
|
|
"box": "§18.4 'How to read the class sections' as a frame of its own",
|
|
"location": "lines 110-112",
|
|
"reason": "six lines of script; folded into the one-line rhythm strip on frame 4 -- the hinweisbox 113-115 moved to frame 8 as the discussion lead-in"
|
|
},
|
|
{
|
|
"box": "Part III \\part opening paragraph references to Tables tab:cap-l..tab:cap-sl and tab:capability",
|
|
"location": "lines 14-16, 112",
|
|
"reason": "cross-references only; the capability columns were shown in deck 6 and are quoted per class in the 'what real systems chose' frames"
|
|
}
|
|
],
|
|
"open_issues": [
|
|
"No deck 7 file exists yet: the recap's Lecture-7 bullet is taken from the semester plan row 7 and deck 6's 'Next week' frame; re-align its wording once AISE502_Vorlesung_7_Folien.tex is typeset.",
|
|
"Frame 40 is a summary table assembled from the five per-class tables of frames 12/18/24/31/37 (Weight cells cell-identical with tab:req-c1..c5), with a two-word shape row condensed from the per-class Shape rows and pattern-code verdicts from the five closing sentences; it is labelled 'assembled from today's five tables; the ten-column version and its footnotes: Lecture 9' and cites no §29 material, so §29 (table, row readings, footnotes, §29.1 observations) stays single-taught in deck 9. Drop the frame if the deck runs long -- summary bullets 3-7 carry the five verdicts.",
|
|
"Milestone numbering: this deck (frames 3, 27 notes, 41, 43) uses the taskbox numbering of project_exercise.tex 391-448 -- M3 walking skeleton (weeks 8-9), M4 deterministic core + resilience (10-11), M5 multi-agent/eval/hardening (12-13), M6 presentation (14) -- as decks 9-13 do. The semester plan's 'Notwendige Anpassungen' table (Semesterplan_AISE502_HS26.md lines 35-46) still uses the older labels (M2 walking skeleton, M3 resilience + deterministic core, M4 multi-agent, M5 operate/harden), although its row 14 already says M6 and the exercise sheet has implemented the new phase logic (week table 369-387, taskboxes 401-448). Fix belongs in the semester plan, not in the deck: delete the 'Notwendige Anpassungen' section (its changes are applied) or rewrite its table with the sheet's numbering, and add the M-labels (M3, M4, M5) to the 'Meilenstein / Abgabe' column of rows 9, 11 and 13.",
|
|
"The five profile tables (frames 12, 18, 24, 31, 37) now use one-line 'Why' cells (~65 characters, no parentheticals, no inline footnotes); weights, Shape and Constraints cells are cell-identical with the script, the 'Why' texts are condensations -- verify each frame visually with pdftoppm after the first build, and check the C4 D4 cell (contains two $\\to$ arrows) for wrapping.",
|
|
"Row label 'D5 Availability \\& isolation' follows the deck-6 convention (deck 6 lines 210, 335, 568); the script writes 'D5 Availability \\& fault isolation'. Kept for consistency within the slide series; restore 'fault isolation' if the convention is not intended.",
|
|
"Footnotes 1, 3, 6, 17 of the consolidated table are no longer typeset anywhere; their content is spoken on frames 10, 16, 35 and 38 (and in the table-frame notes). If the lecturer wants them visible, the only place with room is the challenge frames, not the tables.",
|
|
"Part III has no 'build it and study it' boxes and no licence/runnability status for its open-source references (Fineract, Mastodon, Camunda/Flowable/Frappe, Odoo/ERPNext, Saleor/Medusa); the deck must not add such status -- keep the references as the script states them (Fineract's week-4 study status is quoted from deck 4, not invented).",
|
|
"The script provides only one figure for §18-23 (fig:classmap). Its node style 'projteal' is not defined in the deck preamble -- alias it (e.g. bankblue!70!black) or define it before redrawing. All other frames are text and tables.",
|
|
"Density to verify after the first build: frames 10 (C1 numbers, target 13-14 lines), 11 (C1 scenarios with lead line and the K bullet), 16 (C2 challenges), 19 (C2 real systems), 22 (C3 challenges), 25 (C3 real systems), 29 (C4 challenges), 32 (C4 real systems) and 38 (C5 real systems) -- all at \\footnotesize with three-line bullets; move parentheticals into speaker notes rather than adding frames.",
|
|
"MT/MX coexistence: the script (line 134) writes prospectively 'ending in November 2025'; the deck speaks the SWIFT evidence from the notes of frame 10 with the script's wording and a remark that the phase has since ended.",
|
|
"Script wording 'this class carries more Highs than any other' (C5) -- the count is seven of twelve (C2 has six, C1 five); frame 37 states 'seven Highs' rather than 'more than any other' to stay accurate before C6-C10 are seen.",
|
|
"Minutes: content frames 4-40 sum to 115 (intro block 14, C1 20, C2 19, C3 21, C4 19, C5 20, side-by-side 2); agenda 1 + recap 3 + exercise 3 + summary 2 + next week 1 = 10 framing minutes; total 125 for three lessons, 44 frames including title and closing. Cumulative count at the end of frame 33 (C4 discussion, the natural break) is 97 minutes.",
|
|
"Frame 43 'Next week' now carries six left-column lines (C6-C9, consolidated table, §29.1 observations, C6/C7 projektboxes) at \\footnotesize in the 0.55 column -- verify with pdftoppm that the two columns still fit without an overfull box; the frame stays at 1 minute."
|
|
],
|
|
"total_frames": 44
|
|
}
|