737 lines
48 KiB
TeX
737 lines
48 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 7 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 7: The Fit, Formally -- Three Cases, the Procedure, the Matrix\\[0.4ex]{\small Script: Part IV, Sections 30--32, 34; Section 37 (introduction)}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\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 Recap: the match, seen once at small scale -- and run by you last week
|
|
\item Three matches, three stages: \textbf{C6} (gate), \textbf{C1} (veto), \textbf{C2} (holistic reading and its alarm)
|
|
\item The procedure in general -- and what a weighted sum would have destroyed
|
|
\item The matching matrix: cell semantics and the $7 \times 10$ grid
|
|
\item Reading the matrix as a whole: columns, rows, five support points
|
|
\item The measurement contract, introduced: fitness functions and the DORA metrics
|
|
\item This week's exercise: \textbf{the design-review gate and Deliverable A2}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\begin{center}
|
|
\small demand $\;\to\;$ supply $\;\to\;$ \textbf{match} $\;\to\;$ record $\;\to\;$ \textbf{test}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Done} (weeks 1--6): Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (\emph{weights, not dimensions, define a class}).
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\to$ veto $\to$ ordinal reading) and began the ADR -- today you will recognise every step.
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Today}:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item three cases from Part IV, \textbf{one per stage}
|
|
\item the general statement and the \textbf{seventy-cell grid}
|
|
\item the \textbf{measurement contract}, introduced
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize \textbf{A2 is due this week} -- the architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THREE MATCHES, THREE STAGES
|
|
% ============================================
|
|
\section{Three Matches, Three Stages}
|
|
|
|
\begin{frame}{Part IV opens: three matches, three stages}
|
|
\emph{\textcolor{bankblue}{What does the three-stage procedure actually do when it runs?}} -- usually far less than students expect: \textbf{most of the work happens before anything is scored}.
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Every Part III class ends with a \textbf{verdict and a promise} -- a one-sentence primary and secondary recommendation, and the assurance that Part IV computes it through the three-stage procedure. You have seen one (C10) and the C1/C2 sketch; the other rows follow in weeks 8--9
|
|
\item You own both operands: {\scriptsize $R(a) = (w_1(a),\dots,w_{12}(a);\, S(a);\, K(a))$, $w_i \in \{\text{H},\text{M},\text{L}\}$ -- from A1 and Part III; $C(p) = (c_1(p),\dots,c_{12}(p);\, S(p))$, $c_i \in \{++,+,\circ,-,--\}$ -- the seven columns of Part II.} You have watched $\mathrm{fit}(a,p)$ run once at small scale (the C10 mini-match); not yet seen: \textbf{the machine at full load}
|
|
\item Cases first, generalisation after (as Parts II and III worked) -- three matches computed end to end, each exposing one stage: \textbf{C6} -- knock-out screening and shape gate (Stage 1) $\cdot$ \textbf{C1} -- veto rule with documented mitigations (Stage 2) $\cdot$ \textbf{C2} -- holistic ordinal reading with its built-in sensitivity alarm (Stage 3). Each lands on exactly the verdict its Part III section states
|
|
\end{itemize}
|
|
|
|
\vspace{-0.05cm}
|
|
\begin{center}
|
|
\resizebox{\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
box/.style={rectangle, draw, rounded corners=3pt, align=center, font=\small\sffamily, minimum height=0.5cm, inner sep=3pt},
|
|
today/.style={box, fill=bankblue!20, draw=bankblue},
|
|
later/.style={box, fill=gray!15, draw=gray!60!black, text=gray!60!black},
|
|
lab/.style={font=\small\sffamily\bfseries, anchor=east, minimum width=1.9cm, align=right},
|
|
node distance=0.2cm
|
|
]
|
|
\node[lab, text=bankblue] (l1) at (0,0) {Today:};
|
|
\node[today, right=0.2cm of l1] (a) {\S30 three cases};
|
|
\node[today, right=of a] (b) {\S31 the procedure};
|
|
\node[today, right=of b] (c) {\S32 the matrix};
|
|
\node[today, right=of c] (d) {\S34 reading the matrix};
|
|
\node[today, right=of d] (e) {\S37 the contract (introduction)};
|
|
\node[lab, text=gray!60!black] (l2) at (0,-0.68) {Lecture 10:};
|
|
\node[later, right=0.2cm of l2] (f) {\S33 rationales};
|
|
\node[later, right=of f] (g) {\S35 hybrids and evolution paths};
|
|
\node[later, right=of g] (h) {\S36 eight-step decision procedure};
|
|
\node[lab, text=gray!60!black] (l3) at (0,-1.36) {Lecture 11:};
|
|
\node[later, right=0.2cm of l3] (i) {\S37 the contract in depth};
|
|
\node[later, right=of i] (j) {\S38 organisational complement};
|
|
\node[later, right=of j] (k) {\S39 limits};
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 1 -- C6 against all seven: the shape gate}
|
|
\emph{\textcolor{bankblue}{The nightly risk run must finish by 06:00, reproduce to the bit, and cost as little as possible: which of the seven patterns can even apply for the job?}}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item The C6 profile (given here as the operand; Part III, Lecture 9): High on \textbf{D2} (makespan reading), \textbf{D9} (reproducibility reading), \textbf{D10}; shape \textbf{scheduled batch}; deterministic seeds as a hard constraint
|
|
\item Before comparing a single rating, hold $S(\text{C6}) = $ scheduled batch against the native-shape row $S(p)$ of the capability table (deck 6): \textbf{only PF proceeds to Stages 2--3}; the table carries the gate and its harm clause, and its verdict column is identical to the C6 row of the matching matrix
|
|
\end{itemize}
|
|
|
|
\vspace{-0.05cm}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}lp{2.6cm}p{7.6cm}c@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Native shape $S(p)$} & \textbf{Stage-1 outcome} & \textbf{Verdict} \\
|
|
\midrule
|
|
L & interactive & gate caps at $\circ$; harm clause -- no answer to makespan or checkpointing, $--$ against High D2 & $--$ \\
|
|
MM & interactive & gate caps at $\circ$: orchestration codebase around monolithic kernels & $\circ$ \\
|
|
HX & (host's) & gate caps at $\circ$: ports touch no binding dimension & $\circ$ \\
|
|
MS & interactive & gate caps; harm clause -- communication cost multiplied against High D10 & $--$ \\
|
|
EDA & stream / async & gate caps at $\circ$: job-status glue beside scheduler and DAG & $\circ$ \\
|
|
PF & scheduled batch & \textbf{gate passed} -- proceeds to Stages 2--3; no veto on $\{$D2, D9, D10$\}$ & $++$ \\
|
|
SL & event-trig., short-lived & gate caps at $\circ$: burst fan-out for communication-light sections only & $\circ$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 1 -- one survivor, and the didactic point}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Stages 2 and 3 -- one survivor.} Only PF reaches the veto stage, and no veto fires: against the High set $\{$D2, D9, D10$\}$ it rates $+$, $+$, $++$ (PF column, deck 6) -- throughput from data-parallel frameworks, reproducibility by construction, utilisation-driven cost
|
|
\item Its $--$ on D3 sits on a Low weight and is \emph{inert}; the holistic reading ranks a field of one
|
|
\item \textbf{Result: $\mathrm{fit}(\text{C6},\text{PF}) = {++}$, every other pattern at $\circ$ or below} -- the C6 row of the matrix, computed almost entirely at Stage 1
|
|
\item The didactic point generalises: \textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed
|
|
\item The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\text{C1})$ eliminates any structure that cannot guarantee an ACID booking core, an immutable audit journal, and ten-plus-year retention -- \emph{before} scoring, however well it scales
|
|
\item The verdict the class's Part III section states (Lecture 9): \textbf{pipes-and-filters on HPC/batch infrastructure as primary}, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\circ$ cells) stated, not hidden
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 2 -- C1: the gate passes both, the veto rule decides}
|
|
\emph{\textcolor{bankblue}{Two candidates pass the gate, both natively interactive -- and one of them cannot commit a transaction across its own internal boundaries: how does the procedure decide core banking?}}
|
|
|
|
\vspace{-0.05cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item From the deck-6 mirror pair: C1 High on \textbf{D4, D5, D6, D7, D9}; $K(\text{C1})$: ACID booking core, BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: \textbf{MM against MS} -- the two columns side by side
|
|
\item \textbf{Stage 1.} Both natively interactive $\to$ the gate passes both; no hard constraint in $K(\text{C1})$ eliminates either -- \emph{a constraint names an obligation, not a pattern}; both can in principle be operated under FINMA-grade audit obligations
|
|
\item \textbf{Stage 2 for MS.} $c_4(\text{MS}) = {--}$: no ACID transactions across service boundaries; sagas trade atomicity for choreography complexity. D4 is High in C1 $\to$ \textbf{the veto fires and caps the cell at $-$}
|
|
\item The fact is \emph{structural}: a mitigation can only show that living without the property is \emph{survivable} -- yes, but conditional: Monzo (deck 5), roughly 2{,}800 microservices in production banking, under \textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation)
|
|
\item Cap lifted \textbf{only to $\circ$}, the condition recorded in the cell rationale; MS's $--$ on D8 and D10 sit on Low weights -- no further veto fires. \textbf{Result: $\mathrm{fit}(\text{C1},\text{MS}) = \circ$}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 2 -- stage 2 for MM, and the stage-3 reading}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Stage 2 -- veto rule for MM.} $c_4(\text{MM}) = {++}$ (cross-module ACID transactions) -- no veto
|
|
\item But $c_5(\text{MM}) = {-}$ on High-weight D5 $\to$ caps the cell at $\circ$ -- \emph{unless a documented mitigation exists}
|
|
\item It does: \textbf{hot-standby replication of whole monolith instances} -- the classical banking high-availability tactic, in production at Fineract-class core-banking systems. The cap is lifted.
|
|
\item \textbf{Stage 3 -- holistic reading.} MM now stands at $++$ on D4, $+$ on D6, $+$ on D7, $+$ on D9 -- support on every High-weight dimension of the class, with the one structural weakness mitigated
|
|
\item \textbf{Result: $\mathrm{fit}(\text{C1},\text{MM}) = {++}$}
|
|
\item The ranking MM $\succ$ MS for the C1 core is \textbf{stable under plausible weight variation}: it would flip only if D11 (team scaling) rose to High \emph{and} the Monzo homogeneity condition held -- exactly what the C1 cell rationale (Section 33, Lecture 10) records as the escalation condition
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 2 -- two kinds of mitigation, and the C1 verdict}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.40\textwidth}
|
|
\textcolor{bankblue}{\textbf{Operational weakness}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item MM's one-process blast radius (D5)
|
|
\item \emph{repaired outright} by a standard tactic -- hot standby, pod replication
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.56\textwidth}
|
|
\textcolor{bankblue}{\textbf{Structural weakness}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item atomicity surrendered at the boundary (MS, D4): no mitigation \emph{restores} ACID across service boundaries -- sagas buy coordination with compensating actions, not atomicity
|
|
\item can only be \emph{made survivable}, under a condition most organisations do not meet (Monzo, deck 5) -- the premium paid in platform staffing with no gain for typical team sizes
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item The division of labour generalises: the veto rule does the heavy lifting, and the \textbf{``documented mitigation'' clause is where engineering knowledge -- not arithmetic -- enters the computation}
|
|
\item The rest of the row follows the same mechanics (Section 33, Lecture 10); in particular \textbf{HX -- a delta discipline, not a competitor -- joins MM at $++$} by isolating the long-lived booking core from volatile channels and providers
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\textbf{The verdict the class's Part III section states (Lecture 8): a hexagonal modular monolith for the booking core} (MM and HX at $++$), EDA at the edges and PF for the batch runs as secondary, and microservices only when organisation size forces D11 to High -- the Monzo condition -- exactly the C1 row of the matrix.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 3 -- C2: when scoring cannot separate the survivors}
|
|
\emph{\textcolor{bankblue}{Two finalists carry $++$ where it matters and neither dominates: what does the procedure return when scoring cannot separate the survivors?}}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item C2 (from the deck-6 mirror pair): the \textbf{widest High set in the catalogue} -- D1, D3, D5, D7, D9, D11 -- and a constraint set that knocks out almost nothing; the discrimination work is done by the \emph{weights}, not the constraints
|
|
\item \textbf{Stage 1} requires one honest observation about shape: the class core has \textbf{two constitutive paths} -- the interactive read path that serves the feed, and the asynchronous fan-out path that delivers posts (the five-second delivery scenario, given here from the C2 profile of Part III, is binding for the class)
|
|
\item Neither MS (natively interactive) nor EDA (natively stream/async) is shape-foreign to the path it would carry $\to$ \textbf{the gate passes both}
|
|
\item \textbf{Stage 2} fires one veto against each, and documented practice lifts both: MS's $-$ on High-weighted D3 (mitigation: edge caching, precomputed timelines); EDA's $-$ on High-weighted D9 (mitigation: schema/contract tests, progressive delivery)
|
|
\item Both reach Stage 3 intact
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 3 -- stage 3: the comparison refuses to close}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{4.2cm}cc@{}}
|
|
\toprule
|
|
\textbf{High dimension (C2)} & \textbf{MS} & \textbf{EDA} \\
|
|
\midrule
|
|
D1 Read scalability & $++$ & $++$ \\
|
|
D3 Latency \& predictability & (mitigated) & $+$ \\
|
|
D5 Availability \& isolation & $++$ & $++$ \\
|
|
D7 Evolvability & $++$ & $++$ \\
|
|
D9 Testability \& deployability & $+$ & (mitigated) \\
|
|
D11 Team scaling & $++$ & $+$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Neither dominates}: MS leads where \emph{teams} multiply (D9, D11 -- independent deployments), EDA where \emph{consumers} multiply (D3 on the asynchronous path; D7 in its attach-new-consumers reading)
|
|
\item The \textbf{mandatory sensitivity analysis flips the ordering under entirely plausible variation}: weight D11 the way a several-hundred-team organisation must, and MS wins; frame the feed as what it technically is -- an eventually consistent, precomputed product of an event flow -- and EDA wins
|
|
\item By Stage 3's own rule, that instability is \textbf{not noise}: it marks a genuine trade-off point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Case 3 -- the record refuses the either/or}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Twitter's timeline architecture is \textbf{both patterns at once}: fan-out-on-write \emph{is} publish/subscribe -- an event flow whose product, the precomputed timeline, is served by independently scaled services
|
|
\item The honest reading of the instability is not ``the procedure failed to pick a winner'' but ``\textbf{the class genuinely needs both patterns, placed}'' -- the bridge to hybrids (Section 35, Lecture 10), where hybrids turn out to be the normal case, not the exception
|
|
\item The verdict the class's Part III section states (Lecture 8): an \textbf{EDA $+$ microservices hybrid at organisational scale} (MS and EDA at $++$), a modular monolith as secondary until that scale is \emph{measured}, not assumed -- Mastodon runs the full fan-out mechanics in a Rails monolith -- exactly the C2 row
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Three cases, three stages, one division of labour.} The knock-out screening and shape gate kill most candidates before any scoring (C6: the cheapest test runs first); the veto rule disciplines the High set and prices every mitigation as documented engineering rather than optimism (C1); the holistic ordinal reading ranks the survivors while flagging its own instability as a finding, not an error (C2). \emph{Every one of the seventy cells was produced by exactly this division of labour.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE PROCEDURE IN GENERAL
|
|
% ============================================
|
|
\section{The Procedure in General}
|
|
|
|
\begin{frame}{The formal statement -- the deck-3 box, plus one clause}
|
|
\footnotesize
|
|
\emph{\textcolor{bankblue}{What rule were the three matches following?}} Stated briefly -- every element has already done visible work: $\mathrm{fit}(a,p)$ is the ordinal aggregate of the dimension-wise comparison of $R(a)$ and $C(p)$, same five-step scale, \textbf{non-compensatory, three stages}.
|
|
|
|
\vspace{-0.1cm}
|
|
\begin{definitionbox}[Architecture--application fit $\mathrm{fit}(a,p)$]
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{0pt}
|
|
\item \textbf{Knock-out screening and workload-shape gate.} $K(a)$ eliminates before any scoring; $S(p) \neq S(a)$ caps at $\circ$ (subsystem role), $+$ only for a \emph{constitutive} subsystem of a shape-hybrid class, $-$/$--$ where it would harm the binding scenarios. \textbf{Not shown in deck 3 -- the gate is read per constitutive path}: a pattern is not shape-foreign to a class one of whose binding scenarios constitutes a path of its native shape (Case 3: C2's fan-out delivery scenario).
|
|
\item \textbf{Veto rule on High-weight dimensions.} $c_i(p) = {--}$ on a High dimension caps at $-$; $c_i(p) = {-}$ caps at $\circ$ -- unless a documented mitigation exists (a tactic or hybrid composition with production evidence): the cell says so, the cap is lifted.
|
|
\item \textbf{Holistic ordinal reading with mandatory sensitivity analysis.} Survivors ranked by support of the High set; clustered Medium conflicts \emph{can} downgrade one step; a \emph{ranking with exclusions}, never ``12\,\% better''; a flip under plausible weight variation marks a trade-off point (ATAM) $\to$ scenario-based analysis.
|
|
\end{enumerate}
|
|
\end{definitionbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Three stages, decreasing hardness -- each with a worked face}
|
|
\footnotesize
|
|
The three stages are ordered by \textbf{decreasing hardness}, and each now has a worked face:
|
|
|
|
\vspace{0.1cm}
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.6cm}p{5.6cm}p{4.9cm}@{}}
|
|
\toprule
|
|
\textbf{Stage} & \textbf{What it encodes} & \textbf{Worked face} \\
|
|
\midrule
|
|
1 Knock-out and shape gate & facts no merit elsewhere can compensate -- a violated BCBS 239 obligation, an interactive pattern asked to carry a scheduled-batch core & Case 1 (C6): this stage running the show, emptying six of the row's seven cells on shape alone \\[0.2cm]
|
|
2 Veto rule & \textbf{Assumption A4}: the High weights come from the $(H,H)$ leaves of a utility tree (deck 2), so a structural failure on such a dimension fails precisely the scenarios that define the class -- unless engineering practice has produced a documented way around it & Case 2 (C1): both halves of the rule -- a mitigation that \emph{repairs} (MM's hot standby) and one that merely makes \emph{survivable under condition} (MS's Monzo condition) \\[0.2cm]
|
|
3 Holistic ordinal reading & deliberately the softest: produces an ordering, and carries a built-in alarm for its own instability & Case 3 (C2): the alarm fired and returned a hybrid rather than a false winner \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Why the fit is not a weighted sum}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Deck 3 (Part I): $V(p) = \sum_i w_i \cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all three violated by ordinal profiles (A2); AHP inherits rank reversal
|
|
\item \textbf{What the three cases add -- a demonstration of what the formula would have destroyed:} \textbf{C6} -- it would have averaged the shape gate away under good scores elsewhere $\cdot$ \textbf{C1} -- it would have let MS's missing cross-service ACID be compensated by team scaling $\cdot$ \textbf{C2} -- it would have manufactured a decimal-point winner exactly where the honest output is a flagged trade-off point
|
|
\item Kept from multi-criteria decision analysis: the \emph{explication discipline} (criteria, weights, assumptions forced into the open); dropped: its arithmetic pretensions -- the matrix is an \textbf{explication and communication instrument}, not a computation that determines decisions; behind every contested cell stands \textbf{ATAM}, and, where money decides, \textbf{CBAM} (utility-response curves, return on investment)
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize The fit computation is \textbf{non-compensatory by design}: constraints knock out before anything is scored, structural failures on High-weight dimensions veto unless a documented mitigation exists, and only then does a holistic ordinal ranking follow -- with mandatory sensitivity analysis. \emph{A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE MATCHING MATRIX
|
|
% ============================================
|
|
\section{The Matching Matrix}
|
|
|
|
\begin{frame}{Cell semantics: what one cell of the grid actually claims}
|
|
\footnotesize
|
|
\emph{\textcolor{bankblue}{What does one cell of a seventy-cell grid actually claim?}} A matrix cell answers one precisely delimited question -- and misreading that question is the \textbf{most common student error} with this instrument.
|
|
|
|
\vspace{0.1cm}
|
|
\begin{definitionbox}[Cell semantics of the matching matrix]
|
|
\footnotesize A cell $\mathrm{fit}(a,p)$ states the fit of pattern $p$ \emph{as the dominant structure of the core} of application class $a$ -- the pattern that owns the class's binding quality attribute scenarios. It does \emph{not} state whether $p$ is useful anywhere in a system of class $a$: hybrid roles at the edges (an event journal beside an ACID core, a batch pipeline beside an interactive product) are stated in the cell rationale, not in the cell value.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Consequence 1: a $-$ cell is not a prohibition.} EDA rates $-$ as the dominant structure of a banking core, yet the same rationale names the immutable event journal as the natural regulatory audit trail at that core's edges
|
|
\item \textbf{Consequence 2: the hexagonal column needs a special reading.} HX is a delta pattern of dependency organisation, not a distribution style; it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The $7 \times 10$ matching matrix}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{4.2cm}ccccccc@{}}
|
|
\toprule
|
|
\textbf{Application class} & \textbf{L} & \textbf{MM} & \textbf{HX}$^{\dagger}$ & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
|
|
\midrule
|
|
\rowcolor{bankblue!8} C1 Core banking / transactions & $\circ$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $-$ & $\circ$ & $-$ \\
|
|
\rowcolor{bankblue!8} C2 Social media / content platform & $\circ$ & $+$ & $\circ$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $\circ$ \\
|
|
C3 Back-office / workflow & $+$ & {\boldmath$++$} & $+$ & $--$ & $-$ & $\circ$ & $\circ$ \\
|
|
C4 ERP / enterprise core system & $\circ$ & {\boldmath$++$} & $+$ & $--$ & $-$ & $\circ$ & $--$ \\
|
|
C5 E-commerce platform & $-$ & {\boldmath$++$} & $+$ & $+$ & $+$ & $\circ$ & $+$ \\
|
|
\rowcolor{bankblue!8} C6 Simulation / batch compute & $--$ & $\circ$ & $\circ$ & $--$ & $\circ$ & {\boldmath$++$} & $\circ$ \\
|
|
C7 Decision support / BI analytics & $+$ & $+$ & $\circ$ & $-$ & $\circ$ & {\boldmath$++$} & $+$ \\
|
|
C8 Real-time / IoT streaming & $--$ & $-$ & $\circ$ & $+$ & {\boldmath$++$} & $+$ & $-$ \\
|
|
C9 Collaboration / messaging & $\circ$ & $+$ & $\circ$ & $+$ & {\boldmath$++$} & $-$ & $--$ \\
|
|
C10 AI-native analysis / advisory & $-$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $+$ & $+$ & $\circ$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
Ratings $++$ (excellent fit) to $--$ (structural misfit); \textbf{bold} $=$ cells underlying the primary recommendation of each class; shaded rows $=$ the rows you computed today. $^{\dagger}$\,HX is a delta pattern -- it composes with a host (typically MM), its cells read ``as the internal discipline of the class's core''. L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the grid: the rows you computed}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item The matrix is the three cases of Section 30, \textbf{done seventy times}
|
|
\item Rows C6, C1, C2: the rows you have just computed; the remaining seven were produced by exactly the same three stages -- knock-out and shape gate, then the H-dimension veto with documented mitigations, then the holistic ordinal reading
|
|
\item Every cell is traceable to $R(a) \times C(p)$ through the per-class rationales (Section 33 -- Lecture 10)
|
|
\item $^{\dagger}$\,HX: a delta pattern -- it composes with a host (typically MM), and its cells read ``as the internal discipline of the class's core''
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize Read a matrix cell as the answer to one question only: \emph{how well does this pattern serve as the dominant structure of this class's core?} The edges of the same system routinely use patterns whose cell reads $\circ$ or $-$; the hybrid roles are stated in the rationales, and Section 35 (Lecture 10) shows that \textbf{hybrids are the normal case, not the exception}.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% READING THE MATRIX AS A WHOLE
|
|
% ============================================
|
|
\section{Reading the Matrix as a Whole}
|
|
|
|
\begin{frame}{Column patterns (1/2): the unfashionable default}
|
|
\footnotesize
|
|
\emph{\textcolor{bankblue}{What does the grid say as a whole that no single cell can?}} The matrix rewards a second reading -- not cell by cell but by columns, rows, and boundaries.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Column-wise, the \textbf{modular monolith is primary or secondary in seven of ten classes} -- not because it is fashionable (it is conspicuously unfashionable) but because most requirements profiles weight consistency, evolvability, cost, and time-to-market higher than independent scaling, and \textbf{MM is the only pattern rated $+$ or better on all four} of those dimensions (capability table, deck 6)
|
|
\item The matrix-level restatement of Fowler's \textbf{MonolithFirst}: do not start with microservices even if you expect to need them -- stable service boundaries cannot be cut before the domain is understood, and refactoring \emph{between} services is far costlier than \emph{within} a monolith
|
|
\item \textbf{Microservices earn their premium in exactly two situations}, both visible in the grid: where High-weight read scalability, fault isolation, and team scaling coincide (C2, and conditionally C5 and C8) -- and nowhere else
|
|
\item The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO \textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \textbf{pay the premium and collect nothing}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Column patterns (2/2): workload-shaped columns, HX never negative}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.58\textwidth}
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{PF and EDA are workload-shaped columns.} Their $++$ cells sit precisely where the class's dominant workload shape matches the pattern's native shape -- scheduled batch for PF (C6, C7), continuous stream or fan-out for EDA (C8, C9, and the C2 fan-out)
|
|
\item The shape gate caps them at $\circ$ -- or, by the harm clause, below -- everywhere the class core is interactive
|
|
\item The clearest demonstration that the gate of Stage 1 does real work: \textbf{no amount of merit on other dimensions lets a batch pipeline carry an interactive core}
|
|
\item \textbf{The HX column is never negative} -- not a free lunch but a property of orthogonality: as a delta pattern, hexagonal architecture composes with the host rather than competing with it, and its cost ($c_8 = -$) surfaces only as capped cells where the change rate is low (C6, C7)
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.38\textwidth}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}lccccc@{}}
|
|
\toprule
|
|
\textbf{Class} & \textbf{MM} & \textbf{MS} & \textbf{HX} & \textbf{EDA} & \textbf{PF} \\
|
|
\midrule
|
|
C1 & $++$ & $\circ$ & $++$ & $-$ & $\circ$ \\
|
|
C2 & $+$ & $++$ & $\circ$ & $++$ & $\circ$ \\
|
|
C3 & $++$ & $--$ & $+$ & $-$ & $\circ$ \\
|
|
C4 & $++$ & $--$ & $+$ & $-$ & $\circ$ \\
|
|
C5 & $++$ & $+$ & $+$ & $+$ & $\circ$ \\
|
|
C6 & $\circ$ & $--$ & $\circ$ & $\circ$ & $++$ \\
|
|
C7 & $+$ & $-$ & $\circ$ & $\circ$ & $++$ \\
|
|
C8 & $-$ & $+$ & $\circ$ & $++$ & $+$ \\
|
|
C9 & $+$ & $+$ & $\circ$ & $++$ & $-$ \\
|
|
C10 & $++$ & $\circ$ & $++$ & $+$ & $+$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{0.05cm}
|
|
\centering Five columns of the matching matrix
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Row patterns and the five empirical support points}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Row-wise: \textbf{no class is served above $\circ$ by every pattern, and no pattern serves every class above $\circ$} -- Assumption A2 made visible in a single glance at the grid
|
|
\item If a dominant pattern existed, its column would be uniformly positive, and this part of the module would be one page long
|
|
\item Cell-wise: the five case-study systems of the module each sit \textbf{exactly on a cell boundary} -- the empirical support points at which fit and misfit have been \emph{measured in money}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.4cm}p{4.6cm}p{6.1cm}@{}}
|
|
\toprule
|
|
\textbf{System} & \textbf{Cell it sits on} & \textbf{What was measured} \\
|
|
\midrule
|
|
Prime Video (deck 6) & the split serverless cost cell & over 90\,\% infrastructure cost reduction after consolidating a data-intensive flow into one process \\
|
|
Segment & the MS evolvability cell, read against a wrongly cut boundary & services per configuration instance, not per domain seam \\
|
|
Shopify & the MM write-scalability mitigation & pod-sharded replication \\
|
|
Uber (DOMA) & the MS team-scaling cell & the point where service count itself became the problem \\
|
|
Stack Overflow & the layered read-scalability deviation & cache-friendly read dominance served by roughly nine web servers \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion: the C5 row under two variations}
|
|
\footnotesize
|
|
\textbf{The C5 row (e-commerce) for reference:} L $-$ $\cdot$ MM {\boldmath$++$} $\cdot$ HX $+$ $\cdot$ MS $+$ $\cdot$ EDA $+$ $\cdot$ PF $\circ$ $\cdot$ SL $+$
|
|
|
|
\vspace{0.1cm}
|
|
\begin{thinkbox}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item Take the C5 row (e-commerce) and \textbf{increase the organisation from 3 teams to 30} while holding traffic constant. Which cells change, through which dimension, and at which stage of the three-stage procedure?
|
|
\item Now hold the organisation at 3 teams and \textbf{multiply traffic by 50}.
|
|
\item Why does the second variation move the row so much less than the first -- and what does that say about the popular claim that ``we need microservices to scale''?
|
|
\end{enumerate}
|
|
\end{thinkbox}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize The modular monolith dominates the matrix as default \emph{not despite but because of} its unfashionableness: most requirements profiles weight consistency, evolvability, cost, and time-to-market above independent scaling. Microservices earn their documented premium only where read scalability, fault isolation, and team scaling are simultaneously High -- and the premium is paid in platform staffing either way.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE MEASUREMENT CONTRACT, INTRODUCED
|
|
% ============================================
|
|
\section{The Measurement Contract, Introduced}
|
|
|
|
\begin{frame}{How a decision made this year stays honest in year five}
|
|
\emph{\textcolor{bankblue}{How does a decision made this year stay honest in year five?}} \small One case motivates the apparatus.
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item What actually triggered the Prime Video re-architecture (deck 6) was \textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay -- and that measurement, not an opinion, first forced and then vindicated the redesign
|
|
\item The cost dashboard was a \textbf{fitness function in everything but name}: an objective, continuously evaluated check on an architectural characteristic whose breach converted a running structure from ``accepted'' into ``falsified''
|
|
\item Empirical anchor for building such checks systematically: DORA's finding that \textbf{loosely coupled architectures and teams are the strongest predictor of continuous delivery} -- coupling, this theory's leading dimension, is a \emph{measurable} property
|
|
\item The seventh step of the eight-step decision procedure (Section 36, Lecture 10) generalises the observation into a concept -- where this course differs from a classical architecture lecture: the chosen fit is codified as a \textbf{measurement contract} -- the set of executable invariants under which the architecture is allowed to keep evolving. \textcolor{bankblue}{\textbf{``The architecture may change freely as long as the contract stays green.''}}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Fitness functions -- the definition}
|
|
\footnotesize Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD, the four-layer cascade, Boehm vs.\ Menzies) in Lecture 11.
|
|
|
|
\vspace{0.1cm}
|
|
\begin{definitionbox}[Architectural fitness function]
|
|
\footnotesize ``Any mechanism that provides an objective integrity assessment of some architectural characteristic.'' Fitness functions turn quality attributes into \textbf{executable, objective checks} and move architecture governance from review meetings into the CI/CD pipeline.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Classified along two primary dimensions:
|
|
|
|
\vspace{0.05cm}
|
|
\renewcommand{\arraystretch}{1.1}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{1.6cm}p{11.6cm}@{}}
|
|
\toprule
|
|
\textbf{Scope} & \emph{atomic} -- one characteristic in isolation (e.g.\ a dependency rule as a unit test) \newline \emph{holistic} -- combined characteristics in interplay (e.g.\ security and data freshness under load) \\
|
|
\midrule
|
|
\textbf{Cadence} & \emph{triggered} -- event-based, on every build or deployment \newline \emph{continual} -- running permanently in operation (e.g.\ chaos experiments) \newline \emph{temporal} -- time-scheduled (e.g.\ dependency-freshness time bombs) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Three instrument families}
|
|
\footnotesize Three worked instrument families recur throughout the module:
|
|
|
|
\vspace{0.1cm}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.0cm}p{4.8cm}>{\raggedright\arraybackslash}p{1.6cm}p{4.2cm}@{}}
|
|
\toprule
|
|
\textbf{Family} & \textbf{Instruments} & \textbf{Scope /}\newline\textbf{cadence} & \textbf{What it makes testable} \\
|
|
\midrule
|
|
1 Dependency checks as CI gates (decks 3--4) & ArchUnit (analogues: NetArchTest, dependency-cruiser, import-linter): ``the domain layer imports no framework'', ``no cycles between modules'' as unit tests that fail the build; Spring Modulith for declared module boundaries & atomic, triggered & what makes the MM ratings of the capability table \emph{enforceable} rather than aspirational -- without automated boundary verification, boundary erosion is the documented failure mode of the pattern \\[0.15cm]
|
|
2 Performance and cost budgets as pipeline gates & latency thresholds, bundle sizes, Lighthouse scores declared in a budget file & (pipeline gate) & \textbf{Axis B transfer is direct: token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units} \\[0.15cm]
|
|
3 Chaos experiments & Netflix's Chaos Monkey terminates production instances to test resilience assumptions permanently; formalised as the principles of chaos engineering & holistic, continual & verifies the \textbf{D5 cells}: a claimed blast radius is a hypothesis until an instance has actually been killed under load \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{DORA metrics: the delivery layer -- and the coupling finding}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item The four DORA metrics measure whether the delivery-relevant promises of a structure are being kept: \textbf{deployment frequency} and \textbf{lead time for changes} (tempo); \textbf{change failure rate} and \textbf{failed-deployment recovery time} (stability)
|
|
\item Central empirical finding: elite performers lead on \emph{all four} -- \textbf{tempo and stability are not a trade-off}
|
|
\item The strongest single result in the field supports coupling as the leading dimension of this entire theory: ``loosely coupled architectures and teams are the strongest predictor of continuous delivery'' -- in the 2017 analysis, testability and deployability contributed more to continuous delivery than test and deployment automation itself
|
|
\item High performance is possible with all kinds of systems -- including mainframes -- provided systems and teams are loosely coupled: the label ``microservices'' is \emph{neither necessary nor sufficient}
|
|
\item Second follow-on finding (deck 5, depth in Lecture 11): as team count grows, deployments per developer per day \emph{rise} for high performers and \emph{fall} for low performers
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize DORA's evidence is survey-based and analysed with structural equation models -- \textbf{prediction, not experimental causal proof}. The theory treats it as the best available large-$n$ evidence, to be triangulated against case studies and your own measurements, not as settled law.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: the design-review gate and Deliverable A2}
|
|
\begin{projektbox}
|
|
\footnotesize \textbf{The design phase closes this week.} Finalise the solution design:
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{Service cut and contracts} -- bounded contexts $\to$ service decomposition and the contracts between the deterministic core, the edges, and the AI subsystem
|
|
\item \textbf{Walking-skeleton plan} -- the thin end-to-end slice you will build first in Sprint 1
|
|
\item \textbf{Measurement contract} -- in today's vocabulary: a \emph{token budget} (family 2: cost budget as a pipeline gate), an \emph{eval threshold} (pass rate on the golden set before rollout), and \emph{module-boundary checks} (family 1: dependency rules as CI gates, ArchUnit / import-linter style)
|
|
\item \textbf{Design-review gate} -- defend the ADR: which vetoes fired, which mitigations are \emph{documented}, what the sensitivity check showed
|
|
\end{enumerate}
|
|
\textbf{Deliverable A2 (end of week 7): architecture dossier} -- ADR $+$ C4 diagram $+$ measurement contract. Production code starts only after the gate (exploratory spikes are allowed).
|
|
\end{projektbox}
|
|
|
|
\vspace{0.1cm}
|
|
\small From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (M3, walking skeleton) begins.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Three cases, three stages}: C6 -- the gate empties six of seven cells before scoring; C1 -- the veto rule decides, mitigations priced as documented engineering; C2 -- the reading flags its own instability and returns a hybrid
|
|
\item \textbf{Two kinds of mitigation}: an operational weakness is repaired outright (hot standby); a structural one is only made survivable under a condition most organisations do not meet (Monzo)
|
|
\item \textbf{The formal statement}: $\mathrm{fit}(a,p)$ -- ordinal, non-compensatory, three stages of decreasing hardness; the gate is read per constitutive path; a weighted sum would have destroyed exactly the three decisive facts
|
|
\item \textbf{Cell semantics}: a cell rates the pattern as the dominant structure of the core only; $-$ is not a prohibition; HX reads as the internal discipline of the core
|
|
\item \textbf{The grid}: MM primary or secondary in seven of ten; MS premium in two situations only; PF/EDA workload-shaped; HX never negative; no row or column uniformly positive (A2)
|
|
\item \textbf{Five support points}: Prime Video, Segment, Shopify, Uber, Stack Overflow each sit on a cell boundary -- fit and misfit measured in money
|
|
\item \textbf{Measurement contract}: fitness functions (scope $\times$ cadence; dependency checks, budgets, chaos) and the four DORA metrics; \emph{the architecture may change freely as long as the contract stays green}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 8 (week 8, 3 lessons) -- Part III: application classes C1--C5}}
|
|
\begin{itemize}\small
|
|
\item challenges $\to$ requirements profiles $\to$ what real systems chose
|
|
\item the rows C1--C5 of today's matrix, derived from the demand side
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part IV, Sections 30--32, 34; Section 37 (introduction)
|
|
\item ahead: Part III, Sections 18--23
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item \textbf{A2 $+$ design-review gate: this week}
|
|
\item from week 8: Sprint 1 / M3 -- walking skeleton (\texttt{MarketDataService} $+$ minimal \texttt{ResearchAgent} $+$ stable API); the exercise slot becomes a one-lesson standup/coaching
|
|
\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}
|