130da6298f
Decks 1-8: every abbreviation (DORA, ADR, ACID, SLO, CI/CD, LLM, ATAM, AHP, CBAM, MADR, TCO, FTE, regulatory acronyms, ...) is now expanded or glossed where it first appears; "TTM" table labels written out as time-to-market; SL pattern code no longer used before its definition (deck 3); "A1" assumption vs deliverable disambiguated where they collide (deck 3); the two meanings of DORA (DevOps metrics vs EU Digital Operational Resilience Act) made explicit in deck 8. Deck 1: new section "Monolith and Microservices: A First Look" with six slides (layered monolith, modular monolith, cost/benefit; microservices topology, organisational problem, cost/benefit) using the Part II topology diagrams, placed before the four production cases. All decks rebuilt: zero errors, zero overfull vboxes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
975 lines
70 KiB
TeX
975 lines
70 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 8 slides, typeset with the official FHGR beamer theme
|
|
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
|
|
% Slide content is unchanged; only the presentation layer is the FHGR template.
|
|
% ============================================================================
|
|
\documentclass[aspectratio=169]{beamer}
|
|
|
|
\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}
|
|
|
|
% ============================================
|
|
% PACKAGES
|
|
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
|
|
% listings, hyperref, environ and xparse -- only the extras are needed here.
|
|
% ============================================
|
|
\usepackage[british]{babel}
|
|
\usepackage{booktabs}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{tcolorbox}
|
|
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}
|
|
|
|
% ============================================
|
|
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
|
|
% The names used throughout the slides are kept, so no slide text changes;
|
|
% they now resolve to the FHGR brand colours defined by the theme.
|
|
% ============================================
|
|
\colorlet{bankblue}{blue} % FHGR blue (4B92A4)
|
|
\colorlet{bankgreen}{green} % FHGR green (817E65)
|
|
\colorlet{bankred}{red} % FHGR red (C60219)
|
|
\colorlet{codegray}{gray} % FHGR gray (595959)
|
|
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
|
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
|
|
|
% Attribution labels in English (theme default is German)
|
|
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
|
|
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}
|
|
|
|
% ============================================
|
|
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
|
|
% ============================================
|
|
\newtcolorbox{keypoint}{
|
|
colback=bankblue!7!white,
|
|
colframe=bankblue,
|
|
title=Key Concept,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{examplebox}[1][]{
|
|
colback=bankgreen!10!white,
|
|
colframe=bankgreen,
|
|
title={Example: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{definitionbox}[1][]{
|
|
colback=linen!40!white,
|
|
colframe=camel!85!black,
|
|
title={Definition: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{thinkbox}{
|
|
colback=lightGray!35!white,
|
|
colframe=darkGray,
|
|
title=Discussion,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{hinweisbox}{
|
|
colback=bankred!5!white,
|
|
colframe=bankred,
|
|
title=Important Note,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{ailinse}[1][]{
|
|
colback=aiviolet!7!white,
|
|
colframe=aiviolet,
|
|
title={AI Lens: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{projektbox}{
|
|
colback=bankblue!4!white,
|
|
colframe=bankblue!70!black,
|
|
title=Project Link: Portfolio Intelligence Platform,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
% ============================================
|
|
% TITLE METADATA
|
|
% ============================================
|
|
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
|
|
\subtitle{Lecture 8: Requirements Profiles I -- Application Classes C1--C5\\[0.4ex]{\small Script: Part III, Sections 18--23}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\shortname{AISE502}
|
|
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
|
|
|
\begin{document}
|
|
|
|
% ============================================
|
|
% TITLE SLIDE
|
|
% ============================================
|
|
\FHGRTitlePage
|
|
|
|
% ============================================
|
|
% AGENDA
|
|
% ============================================
|
|
\begin{frame}{Agenda}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes
|
|
\item \textbf{C1} -- Core banking / transaction systems: the double impossibility
|
|
\item \textbf{C2} -- Social media / content platforms: 50:1 and the fan-out
|
|
\item \textbf{C3} -- Back-office / workflow: the modal, unglamorous case
|
|
\item \textbf{C4} -- ERP (enterprise resource planning) / enterprise core: integration \emph{is} the product
|
|
\item \textbf{C5} -- E-commerce: quality attributes with price tags
|
|
\item Five classes side by side -- five verdicts as previews for Part IV
|
|
\item This week's exercise: \textbf{the walking skeleton} (milestone M3)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{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
|
|
\item \textbf{Lecture 6 opened Part III with C10}: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal MM $+$ PF $+$ EDA) -- and the C1/C2 mirror pair in one frame: \emph{weights, not dimensions, define a class}
|
|
\item \textbf{Lecture 7 (Part IV)}: three cases, three stages; $\mathrm{fit}(a,p)$ formally -- ordinal, non-compensatory; the $7 \times 10$ grid read (MM primary or secondary in seven of ten); the measurement contract -- fitness functions and the four DORA (DevOps Research and Assessment) metrics; A2 dossier and design-review gate passed: \emph{implementation is free}
|
|
\item \textbf{Method recall (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 gates; constraints knock out; every High is a veto trigger with the cap rule of the three-stage procedure
|
|
\item \textbf{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 closing verdict is a preview that Part IV recomputes
|
|
\item \textbf{Project}: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% APPLICATION CLASSES AS REQUIREMENTS PROFILES
|
|
% ============================================
|
|
\section{Application Classes as Requirements Profiles}
|
|
|
|
\begin{frame}{Part III: the demand side, in the same vocabulary}
|
|
\footnotesize\emph{\textcolor{bankblue}{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.}}
|
|
|
|
\vspace{0.02cm}
|
|
\footnotesize ``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}.
|
|
|
|
\vspace{0.02cm}
|
|
\begin{definitionbox}[Application class]
|
|
\footnotesize 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}, and a \emph{regulatory frame} acting as hard constraints. Formally, $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}\}$.
|
|
\end{definitionbox}
|
|
|
|
\vspace{-0.05cm}
|
|
\begin{center}
|
|
\begin{tikzpicture}[
|
|
rstep/.style={rectangle, draw, rounded corners=4pt, align=center, font=\scriptsize\sffamily, line width=0.8pt, fill=bankblue!20, draw=bankblue, minimum height=0.5cm, minimum width=2.7cm},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[rstep] (q) at (0,0) {leading question};
|
|
\node[rstep] (c) at (3.3,0) {the challenges it brings};
|
|
\node[rstep] (p) at (6.6,0) {the requirements profile};
|
|
\node[rstep] (r) at (9.9,0) {what real systems chose\\-- and why};
|
|
\draw[arr] (q) -- (c); \draw[arr] (c) -- (p); \draw[arr] (p) -- (r);
|
|
\end{tikzpicture}
|
|
\end{center}
|
|
\vspace{-0.28cm}
|
|
\footnotesize Ten sections, one rhythm -- Part II turned around: challenges first, weights after, structures last; every closing recommendation is a \emph{preview} that Part IV recomputes.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Method recall: where the weights come from (Lectures 2--3)}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textcolor{codegray}{(Lecture 2)} A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are \emph{elicited}, not guessed (QAW -- Quality Attribute Workshop; the utility tree of ATAM, the Architecture Tradeoff Analysis Method), each leaf rated (business importance, achievement difficulty) on \{H, M, L\}
|
|
\item \textcolor{codegray}{(Lecture 2)} \textbf{The (H,\,H) leaves of a class's characteristic utility tree \emph{are} the High weights of $R(a)$}
|
|
\item \textbf{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
|
|
\item \textcolor{codegray}{(Lecture 3)} \textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps it at $\circ$, unless a documented mitigation with production evidence exists; \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
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize There is no weighted sum: profiles are ordinal, the aggregation non-compensatory. \textbf{An H weight is a veto trigger, not a coefficient.} Ten excellent Medium ratings cannot buy back one violated High.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Workload shape and hard constraints}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item \textcolor{codegray}{(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 -- \emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}
|
|
\item \textcolor{codegray}{(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
|
|
\item The regulatory inventory of this catalogue: BCBS~239 (Basel risk-data rules), FINMA Circular 2023/1, DORA (here the EU Digital Operational Resilience Act, not the DevOps metrics), PCI~DSS v4.0 (card payments), the EU AI Act -- plus organisational facts (team size, skills, platforms, budget)
|
|
\item Regulation is a first-class requirement that \textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, AI logging obligations
|
|
\end{itemize}
|
|
|
|
\begin{keypoint}
|
|
\footnotesize 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: C1 booking core, C3 workflows, C6 risk runs, C7 reporting, C10 advisory) -- so the fit matrix is read \textbf{per subsystem, never per company logo}.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{A map of the ten classes}
|
|
\begin{center}
|
|
\resizebox{!}{4.55cm}{%
|
|
\begin{tikzpicture}[
|
|
x=1cm, y=1cm,
|
|
classnode/.style={rectangle, draw, rounded corners=3pt, minimum width=2.6cm, minimum height=0.72cm, align=center, font=\small\sffamily, line width=0.6pt},
|
|
inter/.style={classnode, fill=bankblue!15, draw=bankblue},
|
|
stream/.style={classnode, fill=bankgreen!15, draw=bankgreen},
|
|
batchn/.style={classnode, fill=gray!15, draw=gray!60!black},
|
|
hybridn/.style={classnode, fill=bankblue!70!black!15, draw=bankblue!70!black, font=\small\sffamily\bfseries},
|
|
today/.style={line width=1.6pt},
|
|
bandlabel/.style={font=\small\sffamily\bfseries, anchor=west, align=left, text=gray!50!black},
|
|
axislabel/.style={font=\small\sffamily, text=gray!50!black}
|
|
]
|
|
% --- workload-shape bands ---
|
|
\fill[gray!6] (0,3.75) rectangle (16.4,6.1);
|
|
\fill[gray!12] (0,2.55) rectangle (16.4,3.75);
|
|
\fill[gray!6] (0,1.35) rectangle (16.4,2.55);
|
|
\fill[gray!12] (0,0.15) rectangle (16.4,1.35);
|
|
\node[bandlabel] at (0.15,5.85) {interactive request/response};
|
|
\node[bandlabel] at (0.15,3.5) {continuous stream};
|
|
\node[bandlabel] at (0.15,2.3) {scheduled batch};
|
|
\node[bandlabel] at (0.15,0.75) {hybrid:\\interactive + batch/async};
|
|
% --- consistency axis ---
|
|
\draw[-{Stealth[length=2.5mm]}, thick, gray!60!black] (0,0) -- (16.4,0);
|
|
\foreach \x in {2.0,6.9,11.3,15.0} \draw[gray!60!black, thick] (\x,0) -- (\x,0.12);
|
|
\node[axislabel, anchor=north] at (2.0,-0.08) {strict ACID};
|
|
\node[axislabel, anchor=north] at (6.9,-0.08) {hybrid (split by subsystem)};
|
|
\node[axislabel, anchor=north] at (11.3,-0.08) {causal / per-key / by contract};
|
|
\node[axislabel, anchor=north] at (15.0,-0.08) {eventual};
|
|
\node[axislabel, anchor=north] at (8.2,-0.62) {consistency semantics required by the class core (guarantee weakens $\rightarrow$)};
|
|
% --- interactive band ---
|
|
\node[inter, today] at (2.0,5.15) {C1 core banking\\ \scriptsize ACID ledger};
|
|
\node[inter, today] at (2.0,4.2) {C4 ERP\\ \scriptsize + batch runs};
|
|
\node[inter, today] at (4.7,5.15) {C3 back-office};
|
|
\node[inter, today] at (6.9,4.2) {C5 e-commerce\\ \scriptsize checkout ACID, catalogue eventual};
|
|
\node[inter] at (11.3,5.15) {C9 collab/messaging\\ \scriptsize connection-stateful, causal per channel};
|
|
\node[inter, today] at (14.7,4.2) {C2 social/content\\ \scriptsize stale feed acceptable};
|
|
% --- stream band ---
|
|
\node[stream] at (13.0,3.15) {C8 IoT streaming\\ \scriptsize event time, exactly-once state};
|
|
% --- batch band ---
|
|
\node[batchn] at (8.9,1.95) {C6 simulation/batch\\ \scriptsize reproducible (seeds)};
|
|
\node[batchn] at (12.4,1.95) {C7 DSS/BI\\ \scriptsize fresh by refresh contract};
|
|
% --- hybrid band ---
|
|
\node[hybridn] at (6.9,0.75) {C10 AI-native advisory\\ \scriptsize index eventual, audit path ACID};
|
|
\end{tikzpicture}}%
|
|
\end{center}
|
|
|
|
\vspace{-0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item 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
|
|
\item Today's five (thick frames) all sit in the interactive band -- read them along the axis: C1/C4 strict ACID (atomic, all-or-nothing transactions), C3 ACID-leaning, C5 split by subsystem, C2 eventual
|
|
\item Map labels: ERP $=$ enterprise resource planning; DSS/BI $=$ decision support / business intelligence; IoT $=$ Internet of Things
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion: classification is a hypothesis -- test it on three systems}
|
|
\begin{hinweisbox}
|
|
\footnotesize 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.
|
|
\end{hinweisbox}
|
|
|
|
\vspace{0.25cm}
|
|
\begin{thinkbox}
|
|
\footnotesize Take three software systems you have used this week -- your e-banking app, a messaging tool, a streaming service.
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Which application classes do they instantiate?
|
|
\item Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement?
|
|
\item Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn?
|
|
\end{itemize}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C1 -- CORE BANKING
|
|
% ============================================
|
|
\section{C1 -- Core Banking}
|
|
|
|
\begin{frame}{Part III in the class rhythm: C1 -- Core banking / transaction systems}
|
|
\emph{\textcolor{bankblue}{A payment is booked twice, or not at all: which of the two can a bank survive?}}
|
|
|
|
\vspace{0.1cm}
|
|
\small Neither -- and that double impossibility is the class in one sentence.
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item 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
|
|
\item 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
|
|
\item 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
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{The sums at stake} (D4, D6)
|
|
\item \textbf{A speed spread of six orders of magnitude} within one class (D3, D2, D5)
|
|
\item \textbf{Time} -- lifetimes measured in decades (D7)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- the challenges in numbers}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item \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 first. 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
|
|
\item \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
|
|
\item SIC5 (fifth-generation Swiss Interbank Clearing) instant-payment infrastructure: dimensioned for peaks in the order of 2{,}000 payments/s (clustered in-memory replicated state machine). VisaNet: \emph{capacity} above 65{,}000 transaction messages/s, average load orders of magnitude below -- capacity dimensioning vs.\ normal load: D2 is \emph{planned, not elastic}
|
|
\item Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability a loss event on national infrastructure, with regulator-defined disruption tolerances -- D5
|
|
\item \textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\,\% of US banking systems COBOL-based -- ossification is the documented failure mode: 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
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- the binding scenarios and the knock-outs}
|
|
\footnotesize
|
|
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.
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{S1 (instant payment finality).} A customer submits an instant payment 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. \textcolor{codegray}{(D3, D4, D5.)}
|
|
\item \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.
|
|
\item \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. \textcolor{codegray}{(D6, D9.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$K(\text{C1})$ -- \textbf{the densest constraint set in the catalogue:} BCBS~239 (risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1~January 2024: ICT -- information and communication technology -- risk, protection of \emph{critical data}, business continuity with disruption tolerances); DORA, the Digital Operational Resilience Act (EU 2022/2554, applicable 17~January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR (data protection) throughout.
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- requirements profile (column C1)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}cp{7.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
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 \& time-to-market & 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 \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive ($+$ batch edges)} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{BCBS 239; FINMA 2023/1; DORA; ACID core; 10+ yr retention} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize \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.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- what real systems chose, and why}
|
|
\footnotesize
|
|
Two documented production systems show this profile does \emph{not} determine a single pattern:
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item \textbf{LMAX} (retail trading): six million orders/s on a \emph{single} JVM (Java virtual machine) thread -- in-memory, event-sourced, deterministic sequential core. Serialisable \emph{by construction} (the strongest answer to the D4 veto); journal replay answers D6 and D9; surrenders D2 -- weighted only Medium
|
|
\item \textbf{Monzo} (UK digital bank): ca.\ 2{,}800 Go microservices, viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, the MS column's strength; the $--$ on simplicity and cost paid deliberately; the saga risk on D4 mitigated by homogeneity and central tooling
|
|
\item \textbf{Apache Fineract} (week 4), read from the demand side: a modular monolith behind a REST facade (a web API) -- 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''
|
|
\end{itemize}
|
|
|
|
\begin{keypoint}
|
|
\footnotesize $R(a)$ defines the feasible set; constraints decide within it. C1's vetoes (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.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- AI lens and the verdict}
|
|
\begin{ailinse}[Fraud scoring at the edge of the ledger (Axis B)]
|
|
\footnotesize 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 (large language model) 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.}
|
|
\end{ailinse}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize 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.
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize \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.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C2 -- SOCIAL MEDIA / CONTENT PLATFORMS
|
|
% ============================================
|
|
\section{C2 -- Social Media / Content Platforms}
|
|
|
|
\begin{frame}{C2 -- Social media / content platforms}
|
|
\emph{\textcolor{bankblue}{Three hundred thousand people refresh their feed every second while six thousand post: what structure serves the ratio?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Consumer platforms whose product is a continuously updated content feed: social networks, media-sharing platforms, content communities -- the apps that fill the tram ride
|
|
\item 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
|
|
\item Consistency is explicitly negotiable -- eventual consistency is a design choice, not a defect -- while read scalability, availability and feed latency carry the binding scenarios
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{The 50:1 ratio and the fan-out amplification} (D1, D2)
|
|
\item \textbf{The pace of the product} (D7, D9, D11)
|
|
\item \textbf{Spiky, viral load} (D5, D3)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- the challenges: the ratio, the pace, the spikes}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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
|
|
\item 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
|
|
\item The textbook decision \emph{write work versus read work as a function of the read/write ratio} -- and why D2 stays Medium: the amplification is absorbed by a dedicated fan-out subsystem, not by the write path
|
|
\item \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 hundreds of feature teams exist, D11
|
|
\item \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
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- binding scenarios and a light $K$}
|
|
\footnotesize
|
|
The (H,\,H) leaves of the C2 utility tree -- A4 in action, each with its response measure:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \textbf{p99 (99th-percentile) server-side latency below 200\,ms} -- the regime precomputed timelines and edge caches exist to meet. \textcolor{codegray}{(D1, D3.)}
|
|
\item \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.
|
|
\item \textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \textbf{SLO (service level objective) attainment maintained and the blast radius of any single component failure below a declared bound}. \textcolor{codegray}{(The D5 scenario.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$K(\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (DSA: content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data).
|
|
|
|
\vspace{0.05cm}
|
|
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.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- requirements profile (column C2)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}cp{7.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
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 \& time-to-market & 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 (machine-learning) components off the p99 path \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive read-heavy} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{DSA; GDPR} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- what real systems chose, and why}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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
|
|
\item 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}
|
|
\item 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)
|
|
\item 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
|
|
\item \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 (application programming interface), 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}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- AI lens and the verdict}
|
|
\begin{ailinse}[Feed ranking and moderation as runtime AI (Axis B)]
|
|
\footnotesize 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 and served from precomputed feature stores at millisecond latency, so S1's p99 budget survives; moderation classifiers sit on the asynchronous ingestion path. 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.}
|
|
\end{ailinse}
|
|
|
|
\vspace{0cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textcolor{codegray}{(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.
|
|
\end{keypoint}
|
|
|
|
\vspace{0cm}
|
|
\footnotesize \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.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C3 -- BACK-OFFICE / WORKFLOW
|
|
% ============================================
|
|
\section{C3 -- Back-Office / Workflow}
|
|
|
|
\begin{frame}{C3 -- Back-office / workflow applications}
|
|
\emph{\textcolor{bankblue}{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?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Internal administration systems: case management, approval workflows, HR and procurement processes, departmental record-keeping -- the vacation request, the invoice approval, the onboarding checklist
|
|
\item 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
|
|
\item Users are employees, dozens to thousands; hours of downtime usually tolerable; load low and planable
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{The organisation keeps changing under the software} (D7)
|
|
\item \textbf{The budget} (D8, D10)
|
|
\item \textbf{Correctness with witnesses} (D4, D6)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- the challenges: reorganisation, budget, witnesses}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \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
|
|
\item \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
|
|
\item \textbf{Workload.} Almost no pressure: CRUD-dominated (create/read/update/delete forms over data), 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
|
|
\item \textbf{Witnesses.} Internal control systems demand enforced dual control and a complete audit trail per case -- D4 (transactional case state) and D6
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- binding scenarios and the knock-outs}
|
|
\footnotesize
|
|
The (H,\,H) leaves of the C3 utility tree -- A4 in action:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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. \textcolor{codegray}{(The D7 scenario.)}
|
|
\item \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. \textcolor{codegray}{(D4, D6.)}
|
|
\item \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. \textcolor{codegray}{(D3, weighted Medium.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$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.
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- requirements profile (column C3)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}cp{7.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
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 (internal control system) 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 \& time-to-market & \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 \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{Retention law (Swiss Code of Obligations, Art.\ 958\emph{f}); internal controls; GDPR} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize \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.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- what real systems chose, and why}
|
|
\footnotesize
|
|
The modal industrial answer: a three-tier or modular-monolith application over one relational database -- the capability tables explain why in two steps.
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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
|
|
\item \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
|
|
\item \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
|
|
\item 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
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- why this class punishes distribution}
|
|
\footnotesize \textcolor{codegray}{(recall, Lecture 3)} The mini-match against $R(\text{back-office})$, which you computed: MS hits \textbf{two unmitigated $--$ vetoes at once} (D8, D10); verdicts L $+$, MM $++$, MS $--$. Today: the evidence behind those weights.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{examplebox}[Why this class punishes distribution]
|
|
\footnotesize 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.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{keypoint}
|
|
\footnotesize 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.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- AI lens and the verdict}
|
|
\begin{ailinse}[Document extraction and workflow triage (Axis B)]
|
|
\footnotesize 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.
|
|
\end{ailinse}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \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.
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize \textbf{Project link:} this is the discipline your deterministic services inherit (Lecture 6, inheritance diagram: ``the deterministic services are C3 -- ACID, boring on purpose'').
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C4 -- ERP / ENTERPRISE CORE
|
|
% ============================================
|
|
\section{C4 -- ERP / Enterprise Core}
|
|
|
|
\begin{frame}{C4 -- ERP / enterprise core systems}
|
|
\emph{\textcolor{bankblue}{A sales order must update stock and ledger in the same breath -- for thirty years: what does ``integrated'' actually demand?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Integrated enterprise systems: order management, inventory, finance, HR and production planning sharing \textbf{one} data model
|
|
\item 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
|
|
\item Cross-module ACID transactions over a shared schema -- exactly what distribution makes structurally expensive
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{Cross-module atomicity} (D4, D6)
|
|
\item \textbf{Time, in its most extreme form in the catalogue} (D7)
|
|
\item \textbf{Rhythm rather than volume} (D3, D5; D1/D2 Low)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- the challenges: atomicity, thirty years, the batch window}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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
|
|
\item \textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC (ERP Central Component) 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
|
|
\item 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
|
|
\item \textbf{Rhythm, not volume.} Mixed workload: an OLTP (online transaction processing) core with deterministic batch peaks (month-end and year-end close, MRP -- material requirements planning -- 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
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- binding scenarios and the knock-outs}
|
|
\footnotesize
|
|
The (H,\,H) leaves of the C4 utility tree -- A4 in action:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \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}. \textcolor{codegray}{(The D4 veto scenario.)}
|
|
\item \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.
|
|
\item \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. \textcolor{codegray}{(The D7 scenario.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$K(\text{C4})$: financial-reporting law (Swiss Code of Obligations, the German Commercial Code HGB, the International Financial Reporting Standards IFRS); audit-proof archiving duties (GoBD in Germany, GeB\"uV in Switzerland); GDPR for the HR module; SOX (Sarbanes--Oxley) control requirements for US-listed groups.
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- requirements profile (column C4)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}cp{7.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
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 \& time-to-market & 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 \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive ($+$ batch runs)} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{GoBD/GeB\"uV; SOX; IFRS audit chains} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize \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.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- what real systems chose, and why}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM (object-relational mapping) data model, extended by inheritance. \textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs
|
|
\item Both: strict module boundaries, one deployment, one database, shared transactions -- \emph{the modular monolith in its purest industrial form}
|
|
\item 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}
|
|
\item 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}; community attempts to cut such systems into microservices have remained marginal -- the near-absence of viable microservice ERPs after a decade of microservices enthusiasm is itself empirical evidence
|
|
\item Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI -- electronic data interchange -- banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- key concept, verdict and Discussion: what exactly ossified?}
|
|
\begin{keypoint}
|
|
\footnotesize 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).
|
|
\end{keypoint}
|
|
|
|
\vspace{0.02cm}
|
|
\footnotesize \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.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{thinkbox}
|
|
\footnotesize SAP's maintenance extension to 2027/2030 means thousands of enterprises run an ERP generation older than most of this course's students.
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Is that an architecture failure, an architecture success, or both?
|
|
\item 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?
|
|
\end{itemize}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C5 -- E-COMMERCE
|
|
% ============================================
|
|
\section{C5 -- E-Commerce}
|
|
|
|
\begin{frame}{C5 -- E-commerce platforms}
|
|
\emph{\textcolor{bankblue}{A hundred milliseconds of delay costs one per cent of sales, and Black Friday brings fifty times the load: what survives both at once?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Online retail platforms: catalogue, search, cart, checkout, payment, fulfilment
|
|
\item Defining property: downtime and slowness convert \emph{directly} into revenue loss
|
|
\item 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
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{A price tag on latency and availability} (D3, D5, D1)
|
|
\item \textbf{The most extreme seasonality of all classes} (D2, D9)
|
|
\item \textbf{The split personality of the data} (D4 Medium)
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- the challenges: price tags, Black Friday, two kinds of truth}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{The price tag} \textcolor{codegray}{(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
|
|
\item The read side is equally commercial: browse-to-buy ratios often exceed \textbf{100:1}, so the catalogue is a read product -- D1
|
|
\item \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
|
|
\item \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
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- binding scenarios and the PCI knock-out}
|
|
\footnotesize
|
|
The (H,\,H) leaves of the C5 utility tree -- A4 in action:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\times$ normal load; browsing and checkout continue with \textbf{p95 (95th-percentile) checkout latency within budget and zero uncompensated oversells at 10$\times$ baseline in the pre-peak load test}. \textcolor{codegray}{(D2, D5, D9.)}
|
|
\item \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. \textcolor{codegray}{(D1/D3.)}
|
|
\item \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. \textcolor{codegray}{(The D6 scenario.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$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 (multi-factor authentication) for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2, the EU Payment Services Directive (payment initiation, strong customer authentication -- SCA); GDPR for customer data.
|
|
|
|
\vspace{0.05cm}
|
|
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}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- requirements profile (column C5: seven Highs)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}cp{7.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
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 \& time-to-market & 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 \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive, seasonal} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{PCI DSS v4.0 scope minimisation; PSD2/SCA} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- what real systems chose, and why}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \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
|
|
\item \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
|
|
\item 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
|
|
\item 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}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- hybrid consistency as a designed boundary}
|
|
\begin{examplebox}[Hybrid consistency as a designed boundary]
|
|
\footnotesize The C5 consistency split is not an accident but a boundary to be \emph{designed and documented}: catalogue reads may be minutes stale; 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 in peak-load tests at 10$\times$ baseline}. Where the boundary runs (is the cart eventual?) is an ATAM tradeoff point: an ADR, not folklore.
|
|
\end{examplebox}
|
|
|
|
\vspace{0cm}
|
|
\begin{keypoint}
|
|
\footnotesize C5 is the class where quality attributes carry price tags: latency and availability convert to revenue at documented rates, seasonality defines elasticity, and the consistency profile is hybrid \emph{by definition} -- the one class where ``ACID or eventual?'' is answered \textbf{``both, along a designed boundary''}.
|
|
\end{keypoint}
|
|
|
|
\vspace{0cm}
|
|
\footnotesize \textbf{Verdict (preview):} primary -- a modular monolith with the hybrid consistency profile designed inside it, event-driven edges (MM at $++$); secondary -- microservices at organisational scale, MS/EDA/SL earning their $+$ at the edges. Part IV recomputes.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% FIVE CLASSES SIDE BY SIDE
|
|
% ============================================
|
|
\section{Five Classes Side by Side}
|
|
|
|
\begin{frame}{Five classes side by side -- assembled from today's five tables}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.76\textwidth}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\setlength{\tabcolsep}{3.5pt}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.3cm}ccccc@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{C1} & \textbf{C2} & \textbf{C3} & \textbf{C4} & \textbf{C5} \\
|
|
\midrule
|
|
D1 Read scalability & M & \textbf{H} & L & L & \textbf{H} \\
|
|
D2 Write scal.\ \& elasticity & M & M & L & L & \textbf{H} \\
|
|
D3 Latency & M & \textbf{H} & M & M & \textbf{H} \\
|
|
D4 Consistency \& integrity & \textbf{H} & L & \textbf{H} & \textbf{H} & M \\
|
|
D5 Availability \& isolation & \textbf{H} & \textbf{H} & L & M & \textbf{H} \\
|
|
D6 Security \& auditability & \textbf{H} & M & \textbf{H} & \textbf{H} & \textbf{H} \\
|
|
D7 Evolvability & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} \\
|
|
D8 Simplicity \& time-to-market & L & M & \textbf{H} & M & M \\
|
|
D9 Testability \& deployability & \textbf{H} & \textbf{H} & M & M & \textbf{H} \\
|
|
D10 Operating cost & L & M & \textbf{H} & M & M \\
|
|
D11 Team scaling & M & \textbf{H} & L & M & M \\
|
|
D12 AI integrability & M & M & L & L & M \\
|
|
\midrule
|
|
Shape (all interactive) & $+$ batch edges & read-heavy & \textcolor{codegray}{\textemdash} & $+$ batch runs & seasonal \\
|
|
Verdict (preview) & MM$+$HX & EDA$+$MS & MM & MM & MM \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{column}
|
|
\begin{column}{0.22\textwidth}
|
|
\vspace{0.3cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item all five interactive
|
|
\item \textbf{D7 High in all five}
|
|
\item D4 runs H/L/H/H/M -- the consistency axis of the map
|
|
\item D8/D10 High only in C3
|
|
\end{itemize}
|
|
|
|
\vspace{0.3cm}
|
|
\scriptsize \emph{Assembled from today's five tables; the ten-column version and its footnotes: Lecture 9.}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: the walking skeleton}
|
|
\begin{projektbox}
|
|
\footnotesize \textbf{Implementation phase begins:} the exercise slot becomes a one-hour standup/coaching session; implementation happens mainly in self-study time.
|
|
|
|
\vspace{0.1cm}
|
|
\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.
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Build the skeleton first thing in the implementation phase -- a thin end-to-end slice de-risks everything that follows
|
|
\item Keep the deterministic core free of LLM calls -- \textbf{this is the line that is graded} (today's C1 rule: agents propose, deterministic services decide and book)
|
|
\item 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
|
|
\end{itemize}
|
|
\textbf{Checked in week 9: walking skeleton runs end-to-end.}
|
|
\end{projektbox}
|
|
|
|
\vspace{0.1cm}
|
|
\small Your deterministic services inherit today's C3 verdict: ACID, boring on purpose.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item An application class is an \textbf{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
|
|
\item The map: shape $\times$ consistency semantics -- today's five are all interactive; C1/C4 strict ACID, C3 ACID-leaning, C5 split, C2 eventual
|
|
\item \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
|
|
\item \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
|
|
\item \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
|
|
\item \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
|
|
\item \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
|
|
\item Every verdict is a \textbf{preview}: Part IV recomputes it through the three-stage procedure
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 9 -- Part III: classes C6--C9 and ``Stepping back: ten profiles side by side''}}
|
|
\begin{itemize}\footnotesize\setlength\itemsep{1pt}
|
|
\item C6 scientific simulation / batch compute -- reproducibility as consistency semantics
|
|
\item C7 DSS/BI -- freshness by refresh contract
|
|
\item C8 IoT streaming -- event time, exactly-once state
|
|
\item C9 collaboration/messaging -- connection-stateful, causal per channel
|
|
\item the consolidated requirements table with its seventeen footnotes, and five cross-class observations (\S29, \S29.1)
|
|
\item C6 and C7 inside your C10 project (projektboxes \S24.3, \S25.3)
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part III, Sections 18--23
|
|
\item ahead: Part III, Sections 24--27 and 29
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item coaching; finish the walking skeleton
|
|
\item \textbf{milestone M3: walking skeleton runs end-to-end (checked in week 9)}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% END
|
|
% ============================================
|
|
\FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex]
|
|
{\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex]
|
|
Fachhochschule Graub\"unden, Chur\\[2.4ex]
|
|
{\small AISE502 -- AI in Software Engineering II}}}}]
|
|
|
|
\end{document}
|