947 lines
47 KiB
TeX
947 lines
47 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 11 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 11: The Fit III -- The Measurement Contract, Conway's Law, and the Limits of the Theory\\[0.4ex]{\small Script: Part IV, Sections 37--39}}
|
|
\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 The \textbf{measurement contract} -- step (vii)
|
|
\item Fitness functions: taxonomy and three instrument families
|
|
\item \textbf{DORA} and the coupling finding
|
|
\item The four-layer cascade; the C10 reference contract
|
|
\item Cost of change: Boehm vs.\ Menzies
|
|
\item AI Lens, both axes; the project's contract
|
|
\item \textbf{Conway's law} and Team Topologies
|
|
\item Limits of the theory; \textbf{Maxim 9}
|
|
\item \textbf{This week's exercise}: resilience complete
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\textbf{Part IV so far:}
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item \textbf{L7}: three cases, three stages, the procedure, the $7 \times 10$ matrix, the contract introduced
|
|
\item \textbf{L8--9}: Part III, classes C1--C9
|
|
\item \textbf{L10}: hybrids and evolution paths (Segment, Prime Video, Shopify), Maxim 5; the eight-step procedure with ADR-007, Maxim 6 (a response measure turns an opinion into a testable hypothesis); the ten matrix rows cell by cell -- recurring resolution: \emph{consistent core, asynchronous edges}
|
|
\end{itemize}
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item Deck 1 (A5) and deck 2 (D9, D11) already named the four DORA metrics, the scaling finding, the \emph{within}/\emph{of} cost asymmetry and Conway's law -- today the instrument taxonomy, the numbers and the evidence behind them
|
|
\item The measurement contract is the \textbf{fifth framework element}; ADR-011 (lecture 3) already ended with an embryonic three-line contract -- its lines are rows 2, 7 and 8 of today's reference contract; the static rule tightened from ``no provider-SDK import'' to ``gateway only via the declared port''
|
|
\item Deck 6: every cell is a \textbf{default hypothesis}, replaced by measurement once the system exists -- today: how that measurement is organised (steps (vii)--(viii))
|
|
\item Deck 6: \emph{Conway is a decision filter, not a footnote}, and the evidence base has honest gaps -- today \S 38 makes the organisation the third party to the fit, \S 39 turns the gaps into six limits the theory states about itself
|
|
\item \textbf{Today closes Part IV; next week opens Part V}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE MEASUREMENT CONTRACT
|
|
% ============================================
|
|
\section{The Measurement Contract}
|
|
|
|
\begin{frame}{How does a decision made this year stay honest in year five?}
|
|
\emph{\textcolor{bankblue}{How does a decision made this year stay honest in year five?}}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{examplebox}[Prime Video -- the trigger was a measurement]
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item What actually triggered the Prime Video re-architecture was \textbf{not an architecture review but a telemetry signal}: infrastructure cost per stream, measured continuously, crossed what the team was willing to pay
|
|
\item That measurement, not an opinion, first \emph{forced} and then \emph{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''
|
|
\end{itemize}
|
|
\end{examplebox}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize The empirical anchor for building such checks systematically is DORA: coupling -- this theory's leading dimension -- is a \textbf{measurable} property -- the finding itself comes with the delivery layer (37.2), after the three instrument families.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Step (vii): the fit becomes a measurement contract}
|
|
\small
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item Step (vii) of the procedure generalises the Prime Video observation into a concept -- and it is where this course differs from a classical architecture lecture
|
|
\item The chosen fit is codified as a \textbf{measurement contract}: the set of \emph{executable invariants} under which the architecture is allowed to keep evolving
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
\footnotesize \emph{``The architecture may change freely as long as the contract stays green.''}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize \textbf{What today adds to the week-7 introduction:}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the instrument taxonomy (37.1)
|
|
\item the delivery layer -- DORA (37.2)
|
|
\item the four-layer cascade and the C10 reference contract (37.3)
|
|
\item the economics -- cost of change (37.4)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Architectural fitness function -- the definition}
|
|
\begin{definitionbox}[Architectural fitness function]
|
|
\footnotesize An architectural fitness function is ``any mechanism that provides an objective integrity assessment of some architectural characteristic''. Fitness functions turn quality attributes into \textbf{executable, objective checks} and thereby move architecture governance from review meetings into the CI/CD pipeline.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Classified along two primary dimensions -- \textbf{scope} and \textbf{cadence}:
|
|
|
|
\vspace{0.05cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{1.5cm}p{3.6cm}p{3.6cm}p{3.6cm}@{}}
|
|
\toprule
|
|
\textbf{Scope} & \emph{atomic}: one characteristic in isolation, e.g.\ a dependency rule as a unit test & \emph{holistic}: combined characteristics in interplay, e.g.\ security and data freshness under load & \\
|
|
\midrule
|
|
\textbf{Cadence} & \emph{triggered}: event-based, on every build or deployment & \emph{continual}: running permanently in operation, e.g.\ chaos experiments & \emph{temporal}: time-scheduled, e.g.\ dependency-freshness time bombs \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Instrument family 1: dependency checks as CI gates}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{ArchUnit} (Java); analogues: NetArchTest (.NET), dependency-cruiser (JavaScript), import-linter (Python)
|
|
\item Rules formulated as \textbf{unit tests that fail the build on violation}:
|
|
\end{itemize}
|
|
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item[] \quad \emph{``the domain layer imports no framework''}
|
|
\item[] \quad \emph{``no cycles between modules''}
|
|
\item[] \quad \emph{``repositories are called only by services''}
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{Spring Modulith verification} does the same for module boundaries \emph{declared} in a modular monolith
|
|
\item Classification: \textbf{atomic, triggered}
|
|
\item For the matrix: this is what makes the MM ratings of the capability table \textbf{enforceable rather than aspirational}
|
|
\item \textcolor{codegray}{(recap, deck 4)} without automated boundary verification, \emph{boundary erosion} is the documented failure mode of the pattern -- ``the first fitness function most teams ever write''
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Instrument family 2: performance and cost budgets as pipeline gates}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.44\textwidth}
|
|
\textcolor{bankblue}{\textbf{Classical budgets}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item latency thresholds, bundle sizes, or Lighthouse scores
|
|
\item declared in a \textbf{budget file}
|
|
\item gate the pipeline (Lighthouse CI)
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.10\textwidth}
|
|
\vspace{0.6cm}
|
|
\begin{center}
|
|
{\Large $\Longrightarrow$}\\[0.1cm]
|
|
\scriptsize same\\mechanism
|
|
\end{center}
|
|
\end{column}
|
|
\begin{column}{0.44\textwidth}
|
|
\textcolor{bankblue}{\textbf{Axis-B budgets}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{token-cost budgets} per AI use case
|
|
\item \textbf{p95 latency budgets} per AI use case
|
|
\item the same mechanism with \emph{new units}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.4cm}
|
|
\textbf{The transfer to Axis B is direct.} In the C10 reference contract the units read:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item advisory answer p95 $< 20$\,s end-to-end (triggered $+$ continual)
|
|
\item token cost $\leq$ budget, e.g.\ CHF~0.40/request at p95 (continual)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Instrument family 3: chaos experiments (continual, holistic)}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Netflix's \textbf{Chaos Monkey} terminates production instances to test resilience assumptions \emph{permanently}
|
|
\item Formalised as the \emph{principles of chaos engineering}; cited by Ford et al.\ as the paradigm of a \textbf{continual, holistic} fitness function
|
|
\item \textcolor{codegray}{(recap, deck 2 D5)} for the matrix: chaos experiments are the instrument that \textbf{verifies the D5 cells}
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize \emph{``A claimed blast radius is a hypothesis until an instance has actually been killed under load.''}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item In the C10 contract: kill one instance/broker under load -- SLO holds; blast radius $\leq$ declared -- there run as a scheduled blast-radius drill (cadence \emph{temporal}); Chaos Monkey's permanent termination is the \emph{continual} form
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{DORA metrics: the delivery layer}
|
|
\footnotesize
|
|
The four DORA metrics measure whether the \textbf{delivery-relevant promises} of a structure are being kept:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{4.6cm}p{4.6cm}@{}}
|
|
\toprule
|
|
\textbf{Tempo} & \textbf{Stability} \\
|
|
\midrule
|
|
deployment frequency & change failure rate \\
|
|
lead time for changes & failed-deployment recovery time \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item The central empirical finding: elite performers lead on \emph{all four} -- tempo and stability are \textbf{not a trade-off}
|
|
\item In the contract: DORA four keys per deployable unit (in the cascade: \emph{per architecture quantum})
|
|
\item Example thresholds: change failure rate $< 15\,\%$, restore $< 1$ day; cadence continual
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The coupling finding -- the strongest single result in the field}
|
|
\footnotesize
|
|
\textcolor{codegray}{(recap) deck 2, D9 and D11 already named these -- today the evidence behind them}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize \emph{``Loosely coupled architectures and teams are the strongest predictor of continuous delivery.''}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Supports coupling as the \textbf{leading dimension of this entire theory}
|
|
\item \textcolor{codegray}{(recap, deck 2 D9)} 2017 analysis: the architecture characteristics \textbf{testability and deployability} contributed more to continuous delivery than test and deployment automation itself
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
Two follow-on findings matter for the matrix:
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item High performance is possible with \emph{all kinds of systems -- including mainframes} -- provided systems and teams are loosely coupled; the label ``microservices'' is \textbf{neither necessary nor sufficient}
|
|
\item \textcolor{codegray}{(recap, deck 2 D11 / deck 5)} as team count grows, deployments per developer per day \textbf{rise} for high performers and \textbf{fall} for low performers
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Honesty requires the caveat: prediction, not proof}
|
|
\begin{hinweisbox}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item DORA's evidence is \textbf{survey-based} and analysed with structural equation models -- \emph{prediction, not experimental causal proof}
|
|
\item The theory treats it as the \textbf{best available large-$n$ evidence}
|
|
\item To be \emph{triangulated} against case studies and the reader's own measurements
|
|
\item Not settled law -- the caveat returns in \S 39 as limit 4
|
|
\end{itemize}
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The four-layer cascade: four falsification questions}
|
|
\small The contract has four layers, forming a \textbf{cascade from design time to evolution}; each layer answers a different falsification question.
|
|
|
|
\vspace{0.2cm}
|
|
\begin{center}
|
|
\resizebox{0.9\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
layer/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt, fill=bankblue!20, draw=bankblue, minimum width=3.4cm, minimum height=1.3cm},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[layer] (l1) at (0,0) {\textbf{Design time}\\\emph{is the structure intact?}};
|
|
\node[layer] (l2) at (3.8,-0.9) {\textbf{Delivery}\\\emph{is the structure delivering?}};
|
|
\node[layer] (l3) at (7.6,-1.8) {\textbf{Operation}\\\emph{is the structure keeping}\\\emph{its runtime promises?}};
|
|
\node[layer] (l4) at (11.4,-2.7) {\textbf{Evolution}\\\emph{is the structure ageing?}};
|
|
\draw[arr] (l1.east) -- (l2.west);
|
|
\draw[arr] (l2.east) -- (l3.west);
|
|
\draw[arr] (l3.east) -- (l4.west);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize Instruments and example checks per layer: next frame.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The cascade: instruments and example checks per layer}
|
|
\scriptsize
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{1.8cm}p{5.3cm}p{5.6cm}@{}}
|
|
\toprule
|
|
\textbf{Layer} & \textbf{Instruments} & \textbf{Example checks} \\
|
|
\midrule
|
|
Design time & Dependency rules as CI gates; coupling and cohesion metrics; complexity gates & ``The domain layer imports no framework''; ``no cycles between modules''; ``no domain service calls the LLM gateway except via the declared port'' \\
|
|
\addlinespace
|
|
Delivery & The four DORA metrics & Deployment frequency, lead time, change failure rate, failed-deployment recovery time -- \emph{per architecture quantum} \\
|
|
\addlinespace
|
|
Operation & SLOs and error budgets; latency and \emph{cost} budgets as pipeline gates; chaos experiments as continual holistic fitness functions & p95 latency budget per scenario; token-cost budget per request; blast-radius drills \\
|
|
\addlinespace
|
|
Evolution & Lehman indicators; change scatter; technical-debt inventory & Complexity trend per module; share of features touching more than two modules; debt-register review \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference contract for C10 (1/2): structure, latency, consistency}
|
|
\footnotesize The reference contract instantiates the cascade for the \textbf{course-project class C10} -- the concrete table that ADR-007 points to.
|
|
|
|
\vspace{0.15cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.7cm}>{\raggedright\arraybackslash}p{4.5cm}>{\raggedright\arraybackslash}p{3.3cm}>{\raggedright\arraybackslash}p{2.2cm}@{}}
|
|
\toprule
|
|
\textbf{Concern} & \textbf{Fitness function} & \textbf{Threshold (example)} & \textbf{Cadence} \\
|
|
\midrule
|
|
Module boundaries & ArchUnit / Spring Modulith verify: no undeclared cross-module dependency & 0 violations & triggered (every build) \\
|
|
\addlinespace
|
|
Determinism boundary & Static rule: no domain service imports the LLM gateway except via the declared port & 0 violations & triggered \\
|
|
\addlinespace
|
|
Latency & p95 end-to-end per critical scenario & advisory answer $< 20$\,s & triggered $+$ continual \\
|
|
\addlinespace
|
|
Consistency & Ledger/audit reconciliation job: booked vs.\ journaled & 0 discrepancies & temporal (daily) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Rows 1--4 of the reference contract: fitness functions with thresholds and cadences -- continued on the next frame.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference contract for C10 (2/2): delivery, resilience, the AI rows}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.7cm}>{\raggedright\arraybackslash}p{4.5cm}>{\raggedright\arraybackslash}p{3.3cm}>{\raggedright\arraybackslash}p{2.2cm}@{}}
|
|
\toprule
|
|
\textbf{Concern} & \textbf{Fitness function} & \textbf{Threshold (example)} & \textbf{Cadence} \\
|
|
\midrule
|
|
Delivery performance & DORA four keys per deployable unit & e.g.\ change failure rate $< 15\,\%$; restore $< 1$ day & continual \\
|
|
\addlinespace
|
|
Resilience & Chaos experiment: kill one instance/broker under load & SLO holds; blast radius $\leq$ declared & temporal \\
|
|
\addlinespace
|
|
AI correctness & Eval-harness pass rate on golden set plus domain axioms & $\geq 95\,\%$ pass; 0 ontology-violating outputs shipped & triggered (every prompt/model change) \\
|
|
\addlinespace
|
|
AI cost & Token cost per request, per feature & $\leq$ budget (e.g.\ CHF~0.40/request at p95) & continual \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize \textcolor{codegray}{Resilience cadence: the contract runs the chaos experiment as a scheduled blast-radius drill (temporal); Chaos Monkey's permanent termination (37.1) is the continual form of the same instrument.}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize For AI components the contract gains \textbf{one artefact of the first rank -- the eval harness}: a versioned suite of test cases, scoring logic, and statistical thresholds that runs in CI like a test suite and gates every prompt change, model update, and provider migration. Part V develops it in full.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The cost of change -- what is flat}
|
|
\emph{\textcolor{bankblue}{Why does the contract matter economically?}}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{Boehm (1981 / 2001) -- the classical answer}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Boehm's cost-of-change escalation}: on waterfall project data of the 1970s, fixing a problem after delivery is up to \textbf{one hundred times} more expensive than fixing it during requirements and design
|
|
\item honest qualification: for small, uncritical systems the factor is closer to \textbf{2:1}
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{Menzies et al.\ (2017) -- the replication}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item modern practice has empirically \textbf{flattened} that curve for changes \emph{within} an architecture
|
|
\item the largest replication to date -- \textbf{171 projects from 2006--2014} -- found \emph{no consistent delayed-issue effect}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.3cm}
|
|
\footnotesize Version control, automated tests, and continuous delivery did exactly what the economic argument of Extreme Programming said they would.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The cost of change -- what is still steep}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{4pt}
|
|
\item The nuance the module insists on: flattened is the curve for changes \emph{within} an architecture \textcolor{codegray}{(deck 1, Assumption A5 -- stated then, evidenced now)}
|
|
\item For changes \emph{of} the architecture -- \textbf{splitting a monolith}, \textbf{changing the communication paradigm}, \textbf{moving a data-intensive flow across expensive distributed boundaries} -- the curve remains steep
|
|
\item The evidence is the case studies themselves: Segment's consolidation and Prime Video's rewrite were, at their core, \textbf{expensive architecture revisions}
|
|
\item This asymmetry is the \textbf{economic justification of the whole apparatus}: justify the fit \emph{up front} (architecture revision is the change class that still costs) and keep the architecture \emph{evolvable under a green contract} (everything else is now cheap to change)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Key concept: the contract as a standing experiment}
|
|
\footnotesize Maintenance and evolution consume roughly \textbf{40--80\,\%} -- typically about \textbf{60\,\%} -- of life-cycle cost, mostly for \emph{enhancement} rather than repair \textcolor{codegray}{(deck 1, A5 -- stated then, sourced now)}; the contract is how a structure \textbf{earns the right to survive that phase}.
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
\footnotesize The measurement contract converts an architecture decision into a \textbf{standing experiment}:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item design-time gates verify the \emph{structure}
|
|
\item DORA metrics verify the \emph{delivery}
|
|
\item budgets and chaos experiments verify the \emph{runtime promises}
|
|
\item Lehman indicators verify the \emph{ageing}
|
|
\end{itemize}
|
|
\vspace{0.05cm}
|
|
The cost-of-change curve is \textbf{flat inside a green contract} and \textbf{steep across architecture boundaries} -- which is why \emph{the contract, not the diagram}, is the artefact that protects the investment.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AI Lens (Axis A): fitness functions as the operating licence for agents}
|
|
\begin{ailinse}[Axis A -- fitness functions as the operating licence for agents]
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item An agentic coding tool iterating against a dense test suite and CI-enforced architecture rules is \textbf{contained}
|
|
\item Every generated change must pass the \emph{same} dependency rules, budgets, and evals as a human change -- the blast radius of ``almost right'' code is bounded by the contract
|
|
\item Without those gates, every agent change is \textbf{unpriced risk}
|
|
\item The empirical record shows AI adoption \emph{amplifying} existing delivery dysfunction rather than fixing it (DORA 2025 AI report)
|
|
\item The measurement contract is therefore the prerequisite for raising the change rate by an order of magnitude safely: \textbf{fitness functions are the operating licence for agents}
|
|
\end{itemize}
|
|
\end{ailinse}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AI Lens (Axis B): two new fitness-function types with old mechanics}
|
|
\begin{ailinse}[Axis B -- eval pass rate and token budget]
|
|
\footnotesize
|
|
The contract absorbs AI components through \textbf{two new fitness-function types with old mechanics}:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Eval-harness pass rate}: a \emph{triggered} gate on every prompt and model change, statistically thresholded
|
|
\item \textbf{Token-cost budget per request}: a \emph{continual} gate, exactly analogous to a performance budget
|
|
\end{itemize}
|
|
\vspace{0.05cm}
|
|
Cost per request is a runtime quality attribute with \textbf{no counterpart in classical profiles}; making it a fitness function is what turns FinOps from a \emph{monthly surprise} into an \textbf{architectural control loop}.
|
|
\end{ailinse}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize \textcolor{codegray}{(deck 6, C10 profile)} D9 $=$ H in its eval reading, D10 $=$ H cost per request -- these are the two rows now measurable.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Project link: your submission ships its contract}
|
|
\begin{projektbox}
|
|
\footnotesize Your project submission must ship its \textbf{measurement contract}, not just its architecture -- the repository must contain, \emph{wired into CI}:
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item module-boundary verification with \textbf{zero violations} (Python: import-linter; Java: ArchUnit or Spring Modulith verify), including the determinism-boundary rule: no domain service reaches the LLM gateway except via its declared port
|
|
\item an eval harness with a versioned golden set and a \textbf{pass rate $\geq 95\,\%$} gating every prompt or model change
|
|
\item a \textbf{token-cost budget per request} enforced as a pipeline gate and reported per feature
|
|
\item a p95 latency budget for the advisory scenario (\textbf{$< 20$\,s} end-to-end)
|
|
\item the ADR (in MADR form) whose final section \emph{is} this contract
|
|
\end{enumerate}
|
|
\vspace{0.05cm}
|
|
At the project review you will be asked to demonstrate \textbf{one contract violation being caught by CI} -- \emph{a contract that has never failed is a contract that has never been tested}.
|
|
\end{projektbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CONWAY'S LAW AND TEAM TOPOLOGIES
|
|
% ============================================
|
|
\section{Conway's Law and Team Topologies}
|
|
|
|
\begin{frame}{The third fit dimension: why do correct matrix readings still fail?}
|
|
\emph{\textcolor{bankblue}{Why do correct matrix readings still fail in real organisations?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textcolor{codegray}{(recap, deck 2 D11)} Conway's law in one sentence, and its consequence: every architecture decision is a team-structure decision -- named there, sourced here
|
|
\item The matrix matches patterns to application classes; D11 (team scaling) has appeared throughout as \emph{one dimension among twelve} -- this section makes explicit why it is more than that: the organisation is a \textbf{third party to the fit}, and ignoring it is the most common way correct matrix readings fail in practice
|
|
\item The source is older than every pattern in the matrix -- Conway, 1968:
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize \emph{``Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.''}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Named ``Conway's law'' by Brooks (1975); empirically supported by mirroring studies of organisation and product structure (MacCormack et al.\ 2012)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Every architecture decision is a team-structure decision}
|
|
\small The consequence for this theory is direct: every architecture decision is \emph{simultaneously} a team-structure decision, whether acknowledged or not.
|
|
|
|
\vspace{0.25cm}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{MS to one team}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{a microservices topology assigned to a single five-person team} produces a \textbf{distributed monolith}
|
|
\item many quanta, one communication structure, the worst cells of \emph{two} columns at once
|
|
\end{itemize}
|
|
\vspace{0.1cm}
|
|
\textcolor{codegray}{(recap, deck 5: the distributed monolith and its lockstep-release signature)}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{MM to thirty teams}}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{a modular monolith assigned to thirty independent teams} produces a \textbf{release-coordination bottleneck}
|
|
\item that no amount of code quality repairs
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Team Topologies: four team types, three interaction modes}
|
|
\footnotesize
|
|
Team Topologies (Skelton and Pais 2019) turns the law \textbf{from a hazard into a design instrument}. Its four fundamental team types:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{3.6cm}p{8.8cm}@{}}
|
|
\toprule
|
|
\textbf{Team type} & \textbf{Role} \\
|
|
\midrule
|
|
\emph{Stream-aligned} & delivering end-to-end on one value stream \\
|
|
\emph{Platform} & reduce the load of stream teams \\
|
|
\emph{Enabling} & build missing capabilities \\
|
|
\emph{Complicated-subsystem} & encapsulate specialist knowledge -- \emph{an ML inference subsystem is the canonical course-relevant example} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item Three interaction modes: \textbf{collaboration}, \textbf{X-as-a-service}, \textbf{facilitating}
|
|
\item Together: the vocabulary for matching team structure to pattern choice
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Two concepts that bind directly into the matrix}
|
|
\footnotesize
|
|
\textbf{1. Cognitive load as a design criterion}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item team and software boundaries should be cut so that \emph{no team's cognitive load exceeds its capacity}
|
|
\item ``team-sized software'' is an \textbf{architectural yardstick}
|
|
\item it explains why the MS column demands stream-aligned teams with full ownership as a \textbf{precondition, not an outcome} \textcolor{codegray}{(recap, decks 5 and 6: stream-aligned $+$ platform -- a precondition)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{2. The inverse Conway manoeuvre}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item deliberately structure the organisation to mirror the \emph{target} architecture
|
|
\item so that Conway's law works \emph{for} the design instead of against it
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\resizebox{0.9\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
box/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt, minimum width=3.0cm, minimum height=0.9cm},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[box, fill=gray!15, draw=gray!60!black] (org) at (0,0) {organisation};
|
|
\node[box, fill=bankblue!20, draw=bankblue] (arch) at (10.5,0) {target architecture};
|
|
\draw[arr] ([yshift=5pt]org.east) -- node[above, font=\scriptsize\sffamily] {Conway's law: the structure copies the communication structure} ([yshift=5pt]arch.west);
|
|
\draw[arr, bankblue] ([yshift=-5pt]arch.west) -- node[below, font=\scriptsize\sffamily, text=bankblue] {inverse Conway manoeuvre: the organisation mirrors the target} ([yshift=-5pt]org.east);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The empirical anchor -- and the contested rows D11 decides}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item The DORA scaling finding, read again: loose coupling of \emph{architectures and teams} -- measured \textbf{jointly}, which is itself a Conway statement -- is the strongest predictor of continuous delivery
|
|
\item It is the mechanism that lets deployments per developer per day \textbf{scale linearly with team count}
|
|
\item The matrix encodes the organisational variable in D11; the class rationales repeatedly show it \emph{deciding contested rows}:
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{1.2cm}p{3.4cm}p{4.0cm}p{4.0cm}@{}}
|
|
\toprule
|
|
\textbf{Class} & \textbf{Same profile} & \textbf{Smaller organisation} & \textbf{Larger organisation} \\
|
|
\midrule
|
|
C1 & one C1 profile, different organisation sizes & LMAX: single-threaded core & Monzo: 2{,}800 services \\
|
|
C5 & one C5 profile, split along team count, not traffic & Shopify: modular monolith & Amazon: microservices \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item No twelve-dimensional profile fully captures an organisation (limit 5 in \S 39) -- but the rule of thumb is teachable
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Key concept: the fit is three-way}
|
|
\begin{center}
|
|
\resizebox{0.6\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
nd/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt, minimum width=3.0cm, minimum height=0.75cm},
|
|
arr/.style={{Stealth[length=2.5mm]}-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[nd, fill=bankblue!20, draw=bankblue] (p) at (-3.6,0) {pattern $C(p)$};
|
|
\node[nd, fill=bankgreen!15, draw=bankgreen] (a) at (3.6,0) {application class $R(a)$};
|
|
\node[nd, fill=gray!15, draw=gray!60!black] (t) at (0,1.8) {team structure};
|
|
\draw[arr] (p) -- (a);
|
|
\draw[arr] (p) -- (t);
|
|
\draw[arr] (a) -- (t);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize The fit is three-way: \textbf{pattern $\leftrightarrow$ application class $\leftrightarrow$ team structure}. \textbf{Check D11 last but veto on it first}: a pattern whose team precondition is not met -- microservices without stream-aligned ownership, a monolith across too many coordinating teams -- will fail regardless of how well the other eleven dimensions match. If the target architecture and the organisation disagree: either apply the \textbf{inverse Conway manoeuvre} or \textbf{change the target}. \emph{Conway's law does not negotiate.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% LIMITS OF THE THEORY
|
|
% ============================================
|
|
\section{Limits of the Theory}
|
|
|
|
\begin{frame}{Limit 1: ordinal scales, no arithmetic}
|
|
\footnotesize
|
|
\emph{A theory whose declared standard is that unfalsifiable claims have no place in architecture decisions must state how it can itself mislead.} Six limits, stated plainly -- the first:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item The ratings support \textbf{rankings and exclusions, never percentages}
|
|
\item Any weighted-sum reading of the matrix imports the documented defects of additive multi-criteria methods over ordinal data:
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{6.2cm}p{6.2cm}@{}}
|
|
\toprule
|
|
\textbf{rank reversal} \newline \textcolor{codegray}{Belton and Gear 1983} & \textbf{axiomatic conflict with utility theory} \newline \textcolor{codegray}{Dyer 1990} \\
|
|
\midrule
|
|
\textbf{scale misinterpretation} \newline \textcolor{codegray}{Bana e Costa and Vansnick 2008} & \textbf{pseudo-precision} \newline \textcolor{codegray}{priorities with three decimal places from coarse verbal comparisons} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item We keep the \emph{explication discipline} of multi-criteria decision analysis and drop its \emph{arithmetic pretensions}
|
|
\item \textbf{Sensitivity analysis is mandatory, not decorative}; unstable rankings are \emph{findings} (tradeoff points), not errors
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Limits 2 and 3: context-dependent cells, hybrids as the normal case}
|
|
\footnotesize
|
|
\textbf{Limit 2. Context-dependence of ratings} -- every capability cell encodes a \emph{typical} workload
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the serverless cost cell literally inverts with load shape (Prime Video); the layered read-scalability cell inverts with cache-friendliness (Stack Overflow)
|
|
\item skilled teams can move individual cells -- LMAX and Monzo both did
|
|
\item a rating is a \textbf{default hypothesis} to be replaced by measurement in step (viii); \emph{the matrix predicts the default, not the exceptional}
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textbf{Limit 3. Hybrids are the normal case, not the exception}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item eight of ten class recommendations involve a core pattern plus different edge patterns
|
|
\item the matrix is defined over \textbf{subsystems}; applying it to a whole enterprise in one stroke is a \emph{category error the theory explicitly forbids}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Limit 4: the evidence base is heterogeneous}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}p{3.6cm}p{4.4cm}p{4.4cm}@{}}
|
|
\toprule
|
|
\textbf{Source} & \textbf{Nature} & \textbf{Weakness} \\
|
|
\midrule
|
|
Star ratings (Richards and Ford) & expert judgement & not measurements \\
|
|
DORA & survey-based prediction & not causal proof \\
|
|
Case studies & self-reported engineering blogs & selection and framing bias \\
|
|
\midrule
|
|
Hexagonal and serverless & -- & no star ratings at all \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
Prime Video in particular is routinely misquoted as ``Amazon abandons microservices'' when it documents \emph{one service} with a data-intensive streaming workload -- you met it in deck 6 (SL, the split cell).
|
|
|
|
\vspace{0.1cm}
|
|
Compensation: \textbf{triangulation} -- ratings against cases against metrics -- and the \textbf{measurement contract}, which converts every adopted claim into a testable one.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Limits 5 and 6: the hidden organisation, AI-era volatility}
|
|
\footnotesize
|
|
\textbf{Limit 5. The organisation is a hidden variable} -- Conway's law makes every architecture decision a team-structure decision
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the same requirements profile admits \emph{opposite} optimal patterns at different organisation sizes (LMAX vs.\ Monzo; Shopify vs.\ Amazon)
|
|
\item D11 partially captures this; no twelve-dimensional profile fully does (\S 38)
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textbf{Limit 6. AI-era volatility} -- the D12 ratings encode the \textbf{2025/26 state} of a field whose tools deprecate in months
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the \emph{method} -- Assumption A6: scenarios, tactics, trade-off analysis, ADRs, fitness functions -- is the stable part; the specific cells are \textbf{perishable}
|
|
\item they carry, in effect, their own \textbf{temporal fitness function}: re-verify on every model generation -- \emph{Lehman's laws apply to theories too}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Six limits -- and what compensates each}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{2.6cm}p{4.4cm}p{5.4cm}@{}}
|
|
\toprule
|
|
\textbf{Limit} & \textbf{What it means} & \textbf{What compensates} \\
|
|
\midrule
|
|
1 Ordinal scales & rankings and exclusions only & sensitivity analysis, mandatory; unstable rankings are findings \\
|
|
\addlinespace
|
|
2 Context-dependence & cells are typical-workload defaults & measurement replaces the rating in step (viii) \\
|
|
\addlinespace
|
|
3 Hybrids normal & 8 of 10 classes core $+$ edges & apply the matrix to subsystems, never to a whole enterprise \\
|
|
\addlinespace
|
|
4 Heterogeneous evidence & expert stars, survey prediction, self-reported blogs & triangulation $+$ the measurement contract \\
|
|
\addlinespace
|
|
5 Hidden organisation & same profile, opposite optima by organisation size & D11 captures it only partially -- check the team precondition separately (\S 38) \\
|
|
\addlinespace
|
|
6 AI-era volatility & D12 cells encode 2025/26 & method (A6) stable; cells re-verified on every model generation \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Important note: the matrix is a hypothesis, not an authority}
|
|
\begin{hinweisbox}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item A student who cites the matrix as an \emph{authority} rather than as a \emph{hypothesis} has misunderstood the module
|
|
\item The matrix cannot tell you what to build; it can only \textbf{force your criteria, weights, and assumptions into the open}, \textbf{pre-filter the candidates}, and \textbf{hand the contested cells to scenario-based analysis}
|
|
\item Its numbers are ordinal, its ratings are context-typical defaults, its evidence is triangulated but partly survey-based and partly self-reported -- and it \emph{decays}: every cell is a claim awaiting your measurement
|
|
\item The canonical exercise in this scepticism: reading contradictory study designs against each other -- the METR-versus-Copilot contradiction of Part V (next week)
|
|
\item The assessment of this module tests the \textbf{discipline}, not the memorisation of the grid
|
|
\end{itemize}
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Key concept: Maxim 9}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Maxim 9.} The matrix is the argument's \textbf{skeleton}, ATAM is its \textbf{court of appeal}, the ADR is its \textbf{record}, and the fitness function is its \textbf{parole condition}.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.4cm}
|
|
\small The matrix is the \emph{lecture-hall form} of a discipline whose \emph{engineering form} is:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\small scenarios with numbers $\cdot$ ATAM for the contested cells $\cdot$ ADRs for the decisions $\cdot$ fitness functions for the lifetime
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
\footnotesize Limit 4 says the evidence base is heterogeneous, and limit 2 says skilled teams can move cells. Suppose your team measures, over a year, that its microservices system beats every prediction of the MS column for its class.
|
|
|
|
\vspace{0.2cm}
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item Has the theory been \textbf{falsified} -- or has your measurement contract done exactly what step (viii) designed it to do?
|
|
\item What would have to be true of your \emph{next} project for the difference to matter?
|
|
\end{itemize}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: resilience complete -- M4 closes}
|
|
\begin{projektbox}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item Coaching session (1 lesson). \textbf{Resilience patterns on all external calls}: timeout, retry, circuit breaker, fallback
|
|
\item \textbf{Graceful degradation verified}
|
|
\item \textbf{Milestone M4 of the exercise sheet closes (end of week 11)}: deterministic core \emph{fully tested} against the reference vectors \emph{and resilient}
|
|
\item Hint: keep the deterministic core free of LLM calls -- \emph{this is the line that is graded}
|
|
\end{itemize}
|
|
\end{projektbox}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize Looking ahead: the resilience row of the reference contract (kill one instance/broker under load -- SLO holds) is the fitness function that would verify what you build now -- it is not a graded deliverable.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Fitness functions}: objective integrity assessments; scope atomic/holistic, cadence triggered/continual/temporal; three families -- dependency gates, budgets, chaos experiments
|
|
\item \textbf{DORA}: four keys, elite performers lead on all four; loosely coupled architectures \emph{and teams} predict continuous delivery -- prediction, not causal proof
|
|
\item \textbf{Four-layer cascade} -- four falsification questions; the C10 reference contract, eight rows with thresholds and cadences
|
|
\item \textbf{Cost of change}: flat \emph{within}, steep \emph{across} architecture boundaries -- the contract, not the diagram, protects the investment
|
|
\item \textbf{AI lens}: fitness functions are the operating licence for agents (A); eval pass rate and token budget, two new types with old mechanics (B)
|
|
\item \textbf{Conway}: the fit is three-way; check D11 last but veto on it first; inverse Conway manoeuvre
|
|
\item \textbf{Six limits}: ordinal, context-dependent, hybrids, heterogeneous evidence, hidden organisation, AI-era volatility -- a hypothesis, not an authority
|
|
\item \textbf{Maxim 9}: skeleton, court of appeal, record, parole condition -- Part IV closes
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 12 -- Part V: two axes, one method}}
|
|
\begin{itemize}\small
|
|
\item Axis A: Copilot vs.\ METR -- two contradictory RCTs and their resolution; the verification bottleneck
|
|
\item Axis A compact: architecture documentation as control interface, guardrails, the tool landscape and MCP, risks and accountability (sections 41.6--41.9)
|
|
\item Axis B (I): the news-sentiment call wired the obvious way vs.\ the right way; the three component types; the SE4AI classics
|
|
\item Axis B (I): integration patterns -- reference architecture with the LLM gateway; eval-harness foundations
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part IV, sections 37--39
|
|
\item ahead: Part V, sections 40--41, 42.1--42.5
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item coaching: AdvisorAgent $+$ 2--3 sub-agents behind the gateway (mandatory)
|
|
\item ontology guard active on all insights
|
|
\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}
|