Auto-commit 2026-09-07 14:49: 14 files changed, 4071 insertions(+)
This commit is contained in:
parent
6dd749e958
commit
bbb024974f
BIN
Folien/AISE502_Vorlesung_10_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_10_Folien.pdf
Normal file
Binary file not shown.
596
Folien/AISE502_Vorlesung_10_Folien.tex
Normal file
596
Folien/AISE502_Vorlesung_10_Folien.tex
Normal file
@ -0,0 +1,596 @@
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% ============================================================================
|
||||
% AISE502 -- AI in Software Engineering II
|
||||
% Lecture 10 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 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure\\[0.4ex]{\small Script: Part IV, Sections 35--36 and 33}}
|
||||
\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 \textbf{Hybrids and evolution paths} -- fit as a function of time
|
||||
\item The \textbf{eight-step decision procedure}
|
||||
\item The reference run: \textbf{ADR-007} -- compare it with your A2
|
||||
\item The \textbf{ten matrix rows} in detail
|
||||
\item This week's exercise: \textbf{the deterministic core (M4)}
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% RECAP
|
||||
% ============================================
|
||||
\section{Recap}
|
||||
|
||||
\begin{frame}{Recap: where we are}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Both operands are now yours}: $C(p)$ for seven patterns (Part II, weeks 4--6) and $R(a)$ for ten classes (Part III: C10 in week 6, C1--C5 in week 8, C6--C9 in week 9)
|
||||
\item \textbf{Lecture 7} (Part IV, first lecture): three cases, three stages -- knock-out and shape gate, veto with documented mitigation, holistic ordinal reading; $\mathrm{fit}(a,p)$ formally; why not a weighted sum; cell semantics; the $7 \times 10$ grid read by column and by row; the measurement contract introduced
|
||||
\item \textbf{Lectures 8--9}: all ten class profiles -- challenges $\to$ binding scenarios $\to$ weights $\to$ what real systems chose
|
||||
\item \textbf{Your project}: A2 (ADR $+$ C4 $+$ measurement contract) passed the design-review gate in week 7; the walking skeleton runs end-to-end (M3); \textbf{M4 -- the deterministic core -- starts this week}
|
||||
\item \textbf{Today, three moves}: (1) what the matrix cannot say -- hybrids and fit as a function of time; (2) the eight-step procedure and the reference run ADR-007, to hold against your own A2; (3) the ten rows cell by cell -- the same evidence, now matched
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% HYBRIDS AND EVOLUTION PATHS
|
||||
% ============================================
|
||||
\section{Hybrids and Evolution Paths}
|
||||
|
||||
\begin{frame}{Hybrids and evolution paths -- four episodes you already know}
|
||||
\emph{\textcolor{bankblue}{What happens when a fit that was right stops being right?}}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize You know all four episodes (Lectures 1, 4, 5, 6 and the support points of Lecture 7) -- the new reading is the sentence after them:
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{2018, Segment}: more than 140 per-destination services a small team could no longer test or operate -- consolidated into one deployable
|
||||
\item \textbf{2023, Amazon Prime Video}: monitoring workflow moved from serverless orchestration into a single process -- infrastructure cost cut by over $90\,\%$
|
||||
\item \textbf{Shopify}: the opposite of extraction -- stay a monolith, enforce module boundaries with Packwerk, shard whole-monolith pods
|
||||
\item The classical \textbf{outward} move -- growing the new structure around a legacy core -- has carried its own name since 2004: the \textbf{Strangler Fig}
|
||||
\item \textbf{None of these corrects a \emph{wrong} initial decision}: each is a fit that \emph{was} right decaying as profile, organisation, or measured load drifted -- \textbf{Assumption A5 in production}
|
||||
\item Two instruments for exactly that situation, taught as rules rather than footnotes: \textbf{hybrids} (different patterns where one no longer serves all subsystems) and \textbf{evolution paths} (documented, repeatable repairs between patterns)
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Hybrids are the normal case -- and the unit of evaluation}
|
||||
\footnotesize
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textbf{Eight of the ten primary recommendations of \S 33 are compositions:}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.9}%
|
||||
\begin{tabular}{@{}p{0.9cm}p{5.0cm}@{}}
|
||||
\toprule
|
||||
\textbf{Class} & \textbf{Composition} \\
|
||||
\midrule
|
||||
C1, C5 & a consistent core with event-driven edges \\
|
||||
C7 & a pipeline feeding a serving layer \\
|
||||
C8 & a log with stream processors \\
|
||||
C9 & a monolith with a specialised push layer \\
|
||||
C10 & a hexagonal core with pipelines and orchestration \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item only \textbf{C4} (pure MM) and \textbf{C6} (pure PF) come close to a single-pattern answer -- and even they carry subordinate pipelines and glue
|
||||
\item \textcolor{codegray}{(Lecture 7)} a cell rates the \emph{dominant structure of the core} (bold $=$ primary); the composition lives in the row rationale, never in the cell value
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\begin{column}{0.50\textwidth}
|
||||
\begin{keypoint}
|
||||
\footnotesize The unit of fit evaluation is the \textbf{subsystem with its own architecture quantum} -- its own unit of deployment, scaling, and failure. Applying the matrix to a whole enterprise in one stroke is a \textbf{category error the theory explicitly forbids}: the question is never ``is this company a microservices company?'' but ``what is the dominant structure of \emph{this} subsystem's core, and which patterns serve its edges?''. The composition must be \textbf{recorded} -- a C4-model container diagram is the natural notation, since the seven patterns differ most visibly at container level.
|
||||
\end{keypoint}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textcolor{bankblue}{\textbf{Project link:}} your A2 C4 container diagram should be that record -- check that it shows which patterns own which container.
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Fit is a function of time -- Lehman's laws and MonolithFirst}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Lehman's laws} guarantee the drift the four episodes displayed: a system embedded in the real world must \textbf{continually change or become progressively less useful}, and its \textbf{complexity increases unless work is invested to reduce it}
|
||||
\item Hence a fit established at design time \emph{decays} (Assumption A5) -- and every recommendation must carry a \textbf{migration strategy}; three documented strategies span the space
|
||||
\item \textbf{MonolithFirst} \textcolor{codegray}{(recap: Lecture 7, \S 34 column reading -- MM primary or secondary in seven of ten classes; Lecture 4's choose-when line)}: stable service boundaries cannot be cut before the domain is understood, so do not start with microservices even if you expect to need them
|
||||
\item New here: the matrix encodes this as the MM column's default dominance -- Lecture 7's ``unfashionable default''; the evolution path encodes it as the \textbf{sanctioned starting state}
|
||||
\item \textcolor{codegray}{(Strategies two and three -- Strangler Fig and sacrificial architecture -- on the next frame)}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Fit is a function of time -- Strangler Fig in both directions, and sacrificial architecture}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Strangler Fig.} Grow the new structure around the old, intercepting and capturing function by function -- the migration stays \emph{incremental and stoppable at any point}
|
||||
\item The pattern works in \textbf{both directions}: \emph{outward} -- extracting services from a monolith along verified module boundaries; \emph{inward} -- the Segment and Prime Video consolidations that opened the section
|
||||
\item A \textbf{third direction}, Uber's DOMA \textcolor{codegray}{(Lecture 5)}: beyond roughly 2{,}200 services, a \emph{second} structuring level (about 70 domains with gateways) had to be re-introduced -- convergence back towards macro-modules
|
||||
\item \textbf{Sacrificial architecture.} Consciously accept that the current structure will be replaced in a few years while keeping internal quality high
|
||||
\item Especially legitimate for AI-native components whose model and tool landscape turns over in months \textcolor{codegray}{(AI Lens, three frames on)}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The documented evolution paths -- a state diagram}
|
||||
\begin{center}
|
||||
\resizebox{0.9\textwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
sysbox/.style={rectangle, draw, rounded corners=4pt, minimum width=3.2cm, minimum height=1.1cm, align=center, font=\small\sffamily, line width=0.8pt},
|
||||
core/.style={sysbox, fill=bankblue!20, draw=bankblue, font=\small\sffamily\bfseries},
|
||||
comp/.style={sysbox, fill=bankgreen!15, draw=bankgreen},
|
||||
extern/.style={sysbox, fill=gray!15, draw=gray!60!black},
|
||||
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
|
||||
lbl/.style={font=\footnotesize\sffamily, align=center}
|
||||
]
|
||||
\node[extern] (L) at (0,0) {L\\Layered monolith};
|
||||
\node[core] (MM) at (7,0) {MM\\Modular monolith};
|
||||
\node[comp] (MS) at (14,0) {MS\\Microservices};
|
||||
\node[extern] (SL) at (0,-3.2) {SL\\Serverless orchestration};
|
||||
\node[comp] (DOM) at (14,-3.2) {Domain-bundled\\services (DOMA)};
|
||||
|
||||
\draw[arr] (L) -- node[lbl, above=1pt] {enforce domain boundaries\\(Packwerk, ArchUnit, Modulith)} (MM);
|
||||
\draw[arr] (MM) -- node[lbl, above=1pt] {Strangler-Fig extraction\\when D11 measurably binds} (MS);
|
||||
\draw[arr] (MS.south west) to[bend left=22] node[lbl, below=3pt] {consolidation (Segment 2018)} (MM.south east);
|
||||
\draw[arr] (MS) -- node[lbl, right=3pt] {re-bundle into $\sim$70 domains\\(Uber DOMA 2020)} (DOM);
|
||||
\draw[arr] (SL.east) -| node[lbl, above=2pt, pos=0.22] {process consolidation\\(Prime Video 2023, $-90\,\%$ cost)} (MM.south);
|
||||
\draw[arr, dashed] (L.north) to[out=55, in=125, looseness=1.1] node[lbl, above=2pt] {sacrificial rebuild (planned replacement)} (MM.north);
|
||||
\end{tikzpicture}}%
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize \emph{The modular monolith is both the sanctioned starting state (MonolithFirst) and the documented consolidation target.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Maxim 5 -- buy options on tomorrow's profile}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Maxim 5.} Choose the pattern for the requirements profile you can \emph{verify today}; buy \emph{options} on the profile you expect tomorrow -- via module boundaries, ports, and a strangler-ready seam, \textbf{not via speculative distribution}. Every arrow in the evolution diagram is cheaper to traverse when the boundaries it needs were bought in advance as \textbf{modules and ports} rather than as \textbf{processes}.
|
||||
\end{keypoint}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\footnotesize
|
||||
\textbf{Reading against the diagram:}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item L $\to$ MM \emph{buys} the boundaries
|
||||
\item MM $\to$ MS \emph{spends} them -- only when D11 \emph{measurably} binds
|
||||
\item the inward arrows (Segment, Prime Video) are cheaper when the seams already exist as modules and ports
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textcolor{bankblue}{\textbf{Project link:}} your Spring-Modulith-verified modules and the LLM gateway port are exactly such options (ADR-007, later today).
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{AI Lens: sacrificial architecture for AI-native components}
|
||||
\begin{ailinse}[Axis B]
|
||||
\footnotesize LLM providers deprecate models on windows of \textbf{months, not years}, and the agent-framework landscape turns over even faster. For the AI layer of a C10 system, sacrificial architecture is therefore \textbf{not an admission of failure but the rational default}: design the AI subsystem \emph{to be replaced} -- behind a port, with an \textbf{eval harness as the acceptance gate for its successor} -- while the \textbf{deterministic core is designed to last}. The port boundary converts a provider deprecation from an \emph{architecture revision} (the steep part of the cost-of-change curve, \S 37 next week) into an \emph{adapter task}.
|
||||
\end{ailinse}
|
||||
|
||||
\vspace{0.25cm}
|
||||
\begin{projektbox}
|
||||
\footnotesize The AI layer you build in weeks 12--13 is \textbf{sacrificial by design}; the deterministic core you build this week (M4) is the part \textbf{designed to last}.
|
||||
\end{projektbox}
|
||||
\end{frame}
|
||||
|
||||
|
||||
% ============================================
|
||||
% THE DECISION PROCEDURE
|
||||
% ============================================
|
||||
\section{The Decision Procedure}
|
||||
|
||||
\begin{frame}{From a pre-filtered shortlist to a defensible decision}
|
||||
\emph{\textcolor{bankblue}{How does a pre-filtered shortlist become a defensible decision?}}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize \textbf{The matrix pre-filters; it does not decide.} The teachable, auditable procedure compresses the SEI method family into \textbf{eight steps}, each with a defined \emph{artefact} and a defined \emph{measurement}, and continues into the life cycle per Assumption A5.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.9}%
|
||||
\begin{tabular}{@{}p{5.2cm}p{7.6cm}@{}}
|
||||
\toprule
|
||||
\textbf{Step} & \textbf{Artefact / measurement} \\
|
||||
\midrule
|
||||
(i) Identify the ASRs & ASR list, class hypothesis \\
|
||||
(ii) Quality attribute scenarios & six-part scenarios with response measures \\
|
||||
(iii) Utility tree & $(H,H)$ leaves $=$ the weights of $R(a)$ \\
|
||||
(iv) Pre-filter via the matrix & shortlist of two to three candidates or compositions \\
|
||||
(v) Trade-off analysis (ATAM-light) & sensitivity and tradeoff points, risks, weight variation \\
|
||||
(vi) Decide and record as ADR & MADR record with drivers and options \\
|
||||
(vii) Measurement contract & fitness functions with thresholds \\
|
||||
(viii) Measure in operation & DORA and QA measures continually, Lehman indicators quarterly \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize (i)--(iii) the \textbf{demand side} $\cdot$ (iv)--(vi) the \textbf{match under governance} $\cdot$ (vii)--(viii) the \textbf{genuinely new obligations} -- detailed on the next three frames.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Steps (i)--(iii): the demand side -- ASRs, scenarios, utility tree}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{(i) Identify the ASRs.} Mine business goals, stakeholder interviews, and the regulatory frame -- \emph{not} the requirements document alone, which empirically under-specifies architecturally significant requirements
|
||||
\item Classify the system as an instance (or blend) of the ten application classes -- a \textbf{hypothesis about its ASR bundle} to inherit and then correct
|
||||
\item \textbf{(ii) Formulate quality attribute scenarios with response measures.} Six parts each; \textbf{no scenario without a number}
|
||||
\item An unfalsifiable requirement cannot discriminate between patterns (Assumption A4)
|
||||
\item \textbf{(iii) Prioritise in a utility tree.} Rate each leaf on (business importance, achievement difficulty) $\in \{H,M,L\}^2$
|
||||
\item The $(H,H)$ leaves \emph{are} the weights of $R(a)$ -- this is where the matrix weights come from, so they are \textbf{derivable, not arbitrary}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textcolor{codegray}{You did exactly this in weeks 2--3 (A1); the formal mapping follows in three frames.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Steps (iv)--(v): pre-filter via the matrix, then ATAM-light}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{(iv) Pre-filter candidate patterns via the matrix.} Knock-out constraints and shape gate first, then the veto rule (the three stages of Lecture 7). Output: \textbf{two to three candidate patterns or compositions}, including the hybrid options named in the relevant class row
|
||||
\item \textbf{(v) Trade-off analysis (ATAM-light).} Walk the $(H,H)$ scenarios against each candidate's tactic bundle; classify each point found as \emph{risk} or \emph{non-risk}
|
||||
\item Where money decides, extend with \textbf{CBAM} utility-response curves -- what is $99.99\,\%$ availability \emph{worth}, versus $99.9\,\%$?
|
||||
\item \textcolor{codegray}{Lecture 3's rule, now mandatory at step (v):} \textbf{sensitivity analysis} -- vary the weights plausibly; if the recommendation flips, you have found a genuine tradeoff point that deserves \textbf{stakeholder negotiation, not a formula}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{definitionbox}[Sensitivity point / tradeoff point]
|
||||
\footnotesize \textbf{Sensitivity point}: one decision, large effect on \emph{one} attribute. \textbf{Tradeoff point}: one decision, opposing effects on \emph{several} attributes.
|
||||
\end{definitionbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Steps (vi)--(viii): record, contract, measure -- and keep the paths open}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{(vi) Decide and record as an ADR} \textcolor{codegray}{(Lecture 3's format: context, decision, consequences including the negative ones; superseded, never edited)}, now as step (vi). The one new element: the MADR fields ``decision drivers / considered options'' \textbf{carry the utility-tree weights and the matrix row into the record} -- ISO/IEC/IEEE 42010 Clause 6.10 fulfilled by construction, architectural knowledge vaporisation countered
|
||||
\item \textbf{(vii) Define the measurement contract.} Every ADR ends with the fitness functions that would \emph{falsify} it -- with thresholds (\S 37, next week)
|
||||
\item \textbf{(viii) Measure in operation and keep evolution paths open.} The DORA metrics and the quality-attribute-specific measures run \emph{continually}; Lehman indicators (growth, complexity trend, debt stock) run \emph{quarterly}
|
||||
\item When measurements falsify the decision, the sanctioned responses are the \textbf{documented evolution paths} of \S 35 (the arrows of the state diagram); a revised decision is a \textbf{new ADR that supersedes} -- never silently overwrites -- the old one
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Note how much of this you have already done -- and Maxim 6}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.95}%
|
||||
\begin{tabular}{@{}p{1.6cm}p{7.2cm}p{4.2cm}@{}}
|
||||
\toprule
|
||||
\textbf{Steps} & \textbf{Where you did it} & \textbf{Your project} \\
|
||||
\midrule
|
||||
(i)--(iii) & the pipeline Part III ran ten times (challenges $\to$ binding scenarios $\to$ utility-tree weights) -- inherited work, corrected against elicited scenarios & A1, weeks 2--3 \\
|
||||
(iv)--(vi) & the three cases of Lecture 7 performed \emph{under governance} -- same gate, veto, ordinal reading; sensitivity analysis escalated to stakeholders, outcome recorded & the match and ADR, weeks 6--7 \\
|
||||
(vii)--(viii) & the genuinely new obligations -- the remainder of Part IV (next week) & A2 measurement contract $=$ a first pass at (vii); from M4 on, CI gates generate the first data the contract measures; (viii) proper begins once the system is operated \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Maxim 6} (restated from Part I). An architecture decision without a response measure is an \emph{opinion}; with a response measure and a fitness function it is a \emph{testable hypothesis}. The eight steps exist to manufacture exactly that transformation -- from stakeholder concern to falsifiable, monitored commitment.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% THE REFERENCE RUN: ADR-007
|
||||
% ============================================
|
||||
\section{The Reference Run: ADR-007}
|
||||
|
||||
\begin{frame}{The reference run -- step (i): ASRs and classification}
|
||||
\emph{\textcolor{bankblue}{You ran this procedure yourselves in weeks 6--7; here is the reference run to hold your A2 against.}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (i)]
|
||||
\footnotesize \textbf{(i) ASRs.} The platform analyses client portfolios and generates advisory answers with LLM support. Stakeholder interviews and the regulatory frame yield the ASR bundle:
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{grounded answers with provenance}
|
||||
\item \textbf{complete per-step audit logging} (EU AI Act duties may attach)
|
||||
\item \textbf{per-request cost control}
|
||||
\item \textbf{provider-migration robustness}
|
||||
\item an \textbf{extreme change rate} for prompts and models
|
||||
\end{itemize}
|
||||
\textbf{Classification:} an instance of \textbf{C10}, inheriting C6/C7 traits (index and eval pipelines) and C3 traits (deterministic services) -- the inheritance diagram of week 6, now as the step-(i) hypothesis.
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize \textcolor{bankblue}{\textbf{Check against your A2:}} which of these five ASRs does your dossier name -- and which did you find that this list lacks?
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The reference run -- step (ii): the binding scenario, six parts and a number}
|
||||
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (ii)]
|
||||
\footnotesize \textbf{(ii) Scenarios.} The binding scenario: a customer (\textbf{source}) submits a request for which the LLM generates a factually wrong recommendation (\textbf{stimulus}) in normal operation (\textbf{environment}) of the advisory platform (\textbf{artifact}); the deterministic validation layer blocks the answer and escalates to a human (\textbf{response}); detection rate $\geq 99\,\%$ at $< 2$\,s added latency (\textbf{response measure}).
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{Companion scenarios} fix three more numbers:
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{cost budget}: token cost per request $\leq$ CHF~0.40 at p95
|
||||
\item \textbf{latency budget}: advisory answer $< 20$\,s end-to-end
|
||||
\item \textbf{migration scenario}: provider deprecation absorbed within \textbf{one sprint}, \textbf{zero domain-code changes}
|
||||
\end{itemize}
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize \textbf{No scenario without a number} -- each of these becomes a fitness function in step (vii). \textcolor{codegray}{(S1 and S2 of Lecture 6 carry the same numbers; the migration scenario adds two response measures S3 did not fix.)}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The reference run -- steps (iii) and (iv): utility tree and matrix shortlist}
|
||||
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- steps (iii)--(iv)]
|
||||
\footnotesize \textbf{(iii) Utility tree.} The $(H,H)$ leaves land on D6 (auditability), D7 (evolvability under model churn), D9 (testability, operationalised as eval pass rate), D10 (cost per request), D12 (AI integrability) -- \textbf{reproducing the High weights of the C10 column}, as the theory predicts.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{(iv) Matrix shortlist.} The C10 row yields MM $++$ and HX $++$ as core candidates, with EDA $+$ (job/audit spine) and PF $+$ (ingestion and eval pipelines) as named edge patterns; L is excluded by \textbf{veto}, MS and SL are \textbf{capped at $\circ$}.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\begin{tabular}{@{}lccccccc@{}}
|
||||
\toprule
|
||||
& \textbf{L} & \textbf{MM} & \textbf{HX} & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
|
||||
\midrule
|
||||
C10 AI-native analysis / advisory & $-$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $+$ & $+$ & $\circ$ \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\textbf{Shortlist: (a)} hexagonal modular monolith with pipelines and an async job spine; \textbf{(b)} the same core with a fuller EDA backbone.
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize Two candidates, both compositions -- the hybrid options named in the class row, exactly as step (iv) prescribes.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The reference run -- step (v): ATAM-light, one sensitivity point, one tradeoff point}
|
||||
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (v)]
|
||||
\footnotesize \textbf{(v) ATAM-light.} Walking the $(H,H)$ scenarios against both candidates identifies
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item one dominant \textbf{sensitivity point}: the placement of the \textbf{LLM gateway}, on which auditability, cost telemetry, and migration cost all hinge
|
||||
\item one genuine \textbf{tradeoff point}: LLM \textbf{context length} (answer quality up; cost and latency down)
|
||||
\end{itemize}
|
||||
\vspace{0.05cm}
|
||||
\textbf{Weight variation test:} flips nothing between (a) and (b) for the core; it \emph{does} flip the job-spine choice when audit-log completeness is weighted maximally -- recorded as a \textbf{risk to be retired by a spike}.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\textbf{CBAM reasoning settles the spine:} the fuller EDA backbone buys availability the class only weights \textbf{Medium}, at an operations cost the class weights \textbf{High} -- candidate \textbf{(a) wins}.
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize \textcolor{codegray}{Against the C10 profile of Lecture 6: D5 $=$ M, D10 $=$ H -- CBAM here is a weight comparison, not a curve.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The reference run -- steps (vi)--(viii): ADR, contract, operation, declared evolution paths}
|
||||
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- steps (vi)--(viii)]
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{(vi) ADR.} Recorded as \textbf{ADR-007}: decision drivers $=$ the utility-tree weights; considered options $=$ the matrix shortlist -- \emph{one matrix row, narrated}
|
||||
\item \textbf{(vii) Measurement contract.} ADR-007 ends with the fitness functions of the contract table (\S 37): module-boundary verification, the determinism-boundary rule, latency and token budgets, eval pass rate, reconciliation, chaos drills -- each with threshold and cadence
|
||||
\item \textbf{(viii) Operation.} DORA four keys per deployable unit; the eval harness gates every prompt and model change; Lehman indicators quarterly
|
||||
\item \textbf{Declared evolution paths}, each a new, superseding ADR: extract the ingestion pipeline to its own quantum if batch load grows; replace the LLM adapter on deprecation (sacrificial by design); escalate to an EDA spine if audit volume demands it
|
||||
\end{itemize}
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize What makes the record more than paperwork: the \textbf{considered options carry the matrix reasoning} (auditable) and the \textbf{final section carries the measurement contract} (falsifiable). The gateway rule it relies on is subsequently fixed in its own record, \textbf{ADR-011} \textcolor{codegray}{(Lecture 3)}.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{ADR-007 (1/3): context and decision drivers}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.10\textwidth}
|
||||
\scriptsize\color{codegray}
|
||||
\vspace{0.75cm}
|
||||
step (i)
|
||||
|
||||
\vspace{2.15cm}
|
||||
step (iii)
|
||||
\end{column}
|
||||
\begin{column}{0.88\textwidth}
|
||||
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\scriptsize\ttfamily
|
||||
\textbf{ADR-007: Hexagonal modular monolith with LLM gateway}\\[2pt]
|
||||
Status: accepted (2026-10-12) | supersedes: ADR-003\\[4pt]
|
||||
\textbf{Context and problem statement:} The Portfolio Intelligence Platform (class C10) must deliver grounded advisory answers with full audit logging (EU AI Act), per-request cost control, and robustness against LLM provider deprecation. Change rate of prompts/models is extreme; the deterministic services (data access, portfolio computation, audit) have classical back-office profiles.\\[4pt]
|
||||
\textbf{Decision drivers (utility-tree (H,H) leaves):}\\
|
||||
* D6 auditability: every agent step reconstructable\\
|
||||
* D7 evolvability under model churn\\
|
||||
* D9 testability = eval pass rate >= 95\% in CI\\
|
||||
* D10 token cost per request <= CHF 0.40 (p95)\\
|
||||
* D12 AI integrability: queue, port, measurement point
|
||||
\end{tcolorbox}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{ADR-007 (2/3): considered options and decision}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.10\textwidth}
|
||||
\scriptsize\color{codegray}
|
||||
\vspace{0.2cm}
|
||||
step (iv)
|
||||
|
||||
\vspace{1.55cm}
|
||||
steps (v)/(vi)
|
||||
\end{column}
|
||||
\begin{column}{0.88\textwidth}
|
||||
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\scriptsize\ttfamily
|
||||
\textbf{Considered options (matrix shortlist, Table fit-c10):}\\
|
||||
1. Hexagonal modular monolith + PF pipelines + async jobs (++)\\
|
||||
2. Same core + full EDA backbone for jobs/audit (+)\\
|
||||
3. Microservices per capability (o)\\
|
||||
4. Layered monolith (-, veto D7)\\[4pt]
|
||||
\textbf{Decision:} Option 1. Deterministic core as Spring-Modulith-verified modules; all LLM access via one gateway port (adapter owns prompts, schema validation, retries, cost telemetry); ingestion/eval as versioned pipelines; agent workflow orchestrated, not autonomous: \textbf{agents propose, deterministic services decide and book}.
|
||||
\end{tcolorbox}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize The options block is the record form of the step-(iv) shortlist: the ASCII ratings (++, +, o, --) are the C10 row, and every exclusion names its veto.
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{ADR-007 (3/3): consequences and measurement contract}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.10\textwidth}
|
||||
\scriptsize\color{codegray}
|
||||
\vspace{0.2cm}
|
||||
step (vi)
|
||||
|
||||
\vspace{1.25cm}
|
||||
steps (vii)/(viii)
|
||||
\end{column}
|
||||
\begin{column}{0.88\textwidth}
|
||||
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\scriptsize\ttfamily
|
||||
\textbf{Consequences:}\\
|
||||
+ Provider deprecation = adapter task, not architecture revision\\
|
||||
+ Single measurement point for cost, latency, audit\\
|
||||
- Release coordination across modules (accepted, 2 teams)\\
|
||||
- Async job spine limited; EDA escalation path documented\\[4pt]
|
||||
\textbf{Measurement contract (falsifies this ADR):}\\
|
||||
* ArchUnit/Modulith verify: 0 undeclared cross-module deps\\
|
||||
* Static rule: no domain service imports the LLM gateway except via the declared port (0 violations)\\
|
||||
* p95 advisory answer < 20 s (CI gate + production SLO)\\
|
||||
* Eval harness pass rate >= 95\% on golden set; 0 ontology-violating outputs shipped\\
|
||||
* Token cost per request <= CHF 0.40 at p95 (continual)\\
|
||||
* Daily reconciliation booked vs. journaled: 0 discrepancies\\
|
||||
* DORA four keys per deployable unit; review quarterly
|
||||
\end{tcolorbox}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Discussion}
|
||||
\begin{thinkbox}
|
||||
\small \textbf{Hold your A2 against the reference run:}
|
||||
\begin{enumerate}\setlength\itemsep{4pt}
|
||||
\item Do your \textbf{considered options} name the matrix row and the vetoes behind each exclusion -- or only the winner?
|
||||
\item Which of the \textbf{seven ADR-007 fitness functions} does your measurement contract carry, with a threshold and a cadence? Which is missing?
|
||||
\item Your \textbf{step (v)}: what was your sensitivity point, what your tradeoff point -- and did any weight variation flip a choice?
|
||||
\item Which \textbf{evolution path} did you declare -- and is the seam for it bought as a module or port, or would it require a process boundary?
|
||||
\end{enumerate}
|
||||
\end{thinkbox}
|
||||
\end{frame}
|
||||
|
||||
\end{document}
|
||||
BIN
Folien/AISE502_Vorlesung_11_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_11_Folien.pdf
Normal file
Binary file not shown.
956
Folien/AISE502_Vorlesung_11_Folien.tex
Normal file
956
Folien/AISE502_Vorlesung_11_Folien.tex
Normal file
@ -0,0 +1,956 @@
|
||||
% !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 \textbf{The measurement contract} -- step (vii)
|
||||
\item \textbf{Fitness functions}: taxonomy and three instrument families
|
||||
\item \textbf{DORA} and the coupling finding
|
||||
\item \textbf{The four-layer cascade}; the C10 reference contract
|
||||
\item \textbf{Cost of change}: Boehm vs Menzies
|
||||
\item \textbf{AI Lens}, both axes; the project's contract
|
||||
\item \textbf{Conway's law} and Team Topologies
|
||||
\item \textbf{Limits of the theory}; 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 follows below.
|
||||
\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}
|
||||
\small \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}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=2pt, bottom=2pt, left=6pt, right=6pt]
|
||||
\scriptsize\ttfamily
|
||||
``the domain layer imports no framework''\\
|
||||
``no cycles between modules''\\
|
||||
``repositories are called only by services''
|
||||
\end{tcolorbox}
|
||||
|
||||
\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 as continual holistic fitness functions}
|
||||
\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{tcolorbox}[colback=bankblue!7!white, colframe=bankblue, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\small \emph{``A claimed blast radius is a hypothesis until an instance has actually been killed under load.''}
|
||||
\end{tcolorbox}
|
||||
|
||||
\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
|
||||
\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{tcolorbox}[colback=bankblue!7!white, colframe=bankblue, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\small \emph{``Loosely coupled architectures and teams are the strongest predictor of continuous delivery.''}
|
||||
\end{tcolorbox}
|
||||
|
||||
\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}
|
||||
\small
|
||||
\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}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize The four-layer measurement cascade of the measurement contract: instruments and example checks per layer.
|
||||
\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}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, AI correctness, AI cost}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.7cm}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.15cm}
|
||||
\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} (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{tcolorbox}[colback=bankblue!7!white, colframe=bankblue, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\small \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{tcolorbox}
|
||||
|
||||
\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}
|
||||
\begin{tikzpicture}[
|
||||
box/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt, minimum width=3.4cm, minimum height=0.8cm},
|
||||
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 (7,0) {target architecture};
|
||||
\draw[arr] ([yshift=2pt]org.east) -- node[above, font=\scriptsize\sffamily] {Conway's law: structure copies communication} ([yshift=2pt]arch.west);
|
||||
\draw[arr, bankblue] ([yshift=-2pt]arch.west) -- node[below, font=\scriptsize\sffamily, text=bankblue] {inverse Conway manoeuvre: organisation mirrors the target} ([yshift=-2pt]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}
|
||||
\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}
|
||||
\small \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.3cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{3.0cm}p{3.0cm}p{3.0cm}p{3.0cm}@{}}
|
||||
\toprule
|
||||
\centering \textbf{the matrix} & \centering \textbf{ATAM} & \centering \textbf{the ADR} & \centering\arraybackslash \textbf{the fitness function} \\
|
||||
\midrule
|
||||
\centering skeleton & \centering court of appeal & \centering record & \centering\arraybackslash parole condition \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.3cm}
|
||||
\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}
|
||||
\small 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}
|
||||
\small
|
||||
\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}
|
||||
BIN
Folien/AISE502_Vorlesung_12_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_12_Folien.pdf
Normal file
Binary file not shown.
496
Folien/AISE502_Vorlesung_12_Folien.tex
Normal file
496
Folien/AISE502_Vorlesung_12_Folien.tex
Normal file
@ -0,0 +1,496 @@
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% ============================================================================
|
||||
% AISE502 -- AI in Software Engineering II
|
||||
% Lecture 12 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 12: The AI Dimension I -- Axis A Evidence, Axis B Foundations\\[0.4ex]{\small Script: Part V, Sections 40--41, 42.1--42.5}}
|
||||
\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 \textbf{Two axes, one method} -- Assumption A6 falls due
|
||||
\item \textbf{Axis A}: two contradictory RCTs and the empirical record
|
||||
\item Reconciling the divergence; the verification bottleneck (\textbf{Maxim 7}); Axis A compact
|
||||
\item \textbf{Axis B}: the news-sentiment call, wired the obvious way
|
||||
\item The three component types; why containment: the SE4AI classics
|
||||
\item The reference architecture: \textbf{LLM gateway, queue, ontology guard}
|
||||
\item The eval harness as an engineering artefact
|
||||
\item This week's exercise: \textbf{AdvisorAgent $+$ sub-agents behind the gateway}
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% RECAP
|
||||
% ============================================
|
||||
\section{Recap}
|
||||
|
||||
\begin{frame}{Recap: where we are}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Parts I--IV complete; Lecture 11 closed Part IV}: fitness functions -- three families (dependency gates, budgets, chaos experiments); the four-layer cascade and the eight-row C10 reference contract; cost of change flat \emph{within} / steep \emph{across} architecture boundaries; Conway -- the fit is three-way; six limits; \textbf{Maxim 9} -- Part IV closed
|
||||
\item \textbf{AI Lens threads so far} -- deck 1: the two AI axes and Assumption A6; deck 3: an LLM component stresses D3, D10, D12; an agent drafts the ADR, a human owns the decision; \textbf{ADR-011}: all LLM calls through one gateway port
|
||||
\item \textbf{Deck 6}: C10 profile -- D12 $=$ H, evals as the operative meaning of testability, cost per request; outlook: agent orchestration reuses the catalogue's topologies, workflows before agents ($15\times$ token finding); \textbf{deck 11}: fitness functions are the operating licence for agents (A); eval pass rate and token budget are fitness functions with old mechanics (B)
|
||||
\item \textbf{Today}: Part V redeems A6 systematically -- the two axes as one method; the Axis A evidence and its resolution; the Axis B foundations up to the eval harness
|
||||
\item \textbf{Project}: M4 delivered (deterministic core fully tested and resilient); \textbf{M5 begins} -- AdvisorAgent $+$ 2--3 sub-agents behind the gateway, ontology guard active; the reference architecture today is just-in-time
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% TWO AXES, ONE METHOD
|
||||
% ============================================
|
||||
\section{Two Axes, One Method}
|
||||
|
||||
\begin{frame}{Part V opens: the promissory note falls due}
|
||||
\emph{\textcolor{bankblue}{Four parts built a complete decision theory without ever making artificial intelligence its subject -- does the construction survive the technology that defines its decade?}}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item Not a rhetorical flourish but a \textbf{promissory note falling due}: Part I issued it as \textbf{Assumption A6} -- \emph{AI components extend the quality attribute space but do not change the method}. The bet in two sentences: everything AI does to software engineering can be absorbed by the apparatus you now own
|
||||
\item If AI-bearing systems required a genuinely different method, the bet would be lost -- this part is where the claim must \textbf{survive contact with the evidence}
|
||||
\item Roadmap -- \textbf{cases first, generalisation after}: two contradictory randomised experiments open Axis A (\S41); one concrete LLM call, wired wrongly and then rightly, opens Axis B (\S42); the matrix reading (\S43) and the emergent pattern (\S44) follow next week
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The two axes of the AI dimension}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.55\textwidth}
|
||||
\begin{definitionbox}[The two axes of the AI dimension]
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Axis A -- AI as a tool in the SDLC.} Code assistants, agentic coding tools, review bots participate in \emph{building} the software (code, tests, documentation, design drafts); what ships may contain no AI at all. Unit of analysis: the \emph{development process} and its economics
|
||||
\item \textbf{Axis B -- AI as a runtime component.} LLM services, trained ML models, optimisation solvers are \emph{part of the delivered system} and execute in production. Unit of analysis: the \emph{running system} and its quality attributes
|
||||
\item \textbf{The axes are independent}: a payroll system built with heavy agent support (A without B); a hand-crafted AI-native advisory platform (B without A). In the course project both apply simultaneously -- which is why they must be kept conceptually apart
|
||||
\end{itemize}
|
||||
\end{definitionbox}
|
||||
\end{column}
|
||||
\begin{column}{0.42\textwidth}
|
||||
\begin{center}
|
||||
\resizebox{\linewidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
sysbox/.style={rectangle, draw, rounded corners=4pt, minimum width=3.6cm, minimum height=1.0cm, align=center, font=\small\sffamily, line width=0.8pt},
|
||||
ax/.style={sysbox, fill=aiviolet!15, draw=aiviolet},
|
||||
proc/.style={sysbox, fill=bankgreen!15, draw=bankgreen},
|
||||
core/.style={sysbox, fill=bankblue!20, draw=bankblue, font=\small\sffamily\bfseries},
|
||||
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
||||
]
|
||||
\node[ax] (axisa) at (0,2.4) {\textbf{Axis A}\\AI as tool: agents, assistants};
|
||||
\node[ax] (axisb) at (5.0,2.4) {\textbf{Axis B}\\AI as component: LLM, ML, solver};
|
||||
\node[proc] (sdlc) at (0,0) {Development process\\(specify, build, verify, operate)};
|
||||
\node[core] (system) at (5.0,0) {Delivered system\\(structure, quality attributes)};
|
||||
\draw[arr] (axisa) -- node[right, font=\scriptsize\sffamily, align=left]{shifts SDLC\\economics} (sdlc);
|
||||
\draw[arr] (axisb) -- node[right, font=\scriptsize\sffamily, align=left]{stretches quality\\attribute space} (system);
|
||||
\draw[arr] (sdlc) -- node[above, font=\scriptsize\sffamily]{produces} (system);
|
||||
\end{tikzpicture}%
|
||||
}
|
||||
\end{center}
|
||||
\vspace{-0.1cm}
|
||||
\scriptsize Axis A changes \emph{how} systems are built; Axis B \emph{what} the built system contains -- both absorbed by the same method: scenarios, tactics, profiles, ADRs, fitness functions.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Two axes, one method}: independent, kept apart -- and both analysed with the apparatus of Parts I--IV, \emph{nothing new}.
|
||||
\end{keypoint}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% AXIS A -- EVIDENCE AND RESOLUTION
|
||||
% ============================================
|
||||
\section{Axis A -- Evidence and Resolution}
|
||||
|
||||
\begin{frame}{Case 1 -- the Copilot RCT: $+55.8\,\%$ on a greenfield task}
|
||||
\emph{\textcolor{bankblue}{AI makes developers 55.8\,\% faster -- or 19\,\% slower. Which study is wrong?}}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\small Both numbers come from randomised controlled trials, both methodologically sound; few topics in software engineering carry a larger gap between headline and evidence.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Case 1 (published 2023)}: 95 professional developers randomly split into two groups; same task -- implement an HTTP server in JavaScript; one group with GitHub Copilot, one without; the clock measured time to completion
|
||||
\item The treatment group finished \textbf{55.8\,\% faster}
|
||||
\item \textbf{Qualification 1}: the confidence interval (\textbf{21--89\,\%}) is very wide -- the headline number is a point estimate, not a natural constant
|
||||
\item \textbf{Qualification 2}: a bounded, well-defined \emph{greenfield} exercise -- no legacy context, no architectural constraints, no review process
|
||||
\item \textbf{Qualification 3}: speed was measured, not quality; completion rates did not differ significantly
|
||||
\item Within those bounds the result is real -- and it is the origin of the ``AI doubles productivity'' headline genre
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Case 2 -- the METR RCT: $19\,\%$ slower in your own mature codebase}
|
||||
\emph{\textcolor{bankblue}{What happens when the same technology meets experts on their own terrain?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{16 experienced open-source maintainers}; 246 real issues in repositories they had maintained for years -- large, mature codebases (over a million lines) with high implicit quality standards; each issue randomly assigned to an AI-allowed condition (predominantly Cursor with frontier models of early 2025) or an AI-forbidden condition
|
||||
\item With AI, the developers took \textbf{19\,\% longer}
|
||||
\item \textbf{The perception data are the didactic core}: forecast before the study \textbf{$+24\,\%$} speed-up; measured \textbf{$-19\,\%$}; post-hoc estimate \textbf{$+20\,\%$} faster -- even experts cannot validly introspect their own AI-assisted productivity
|
||||
\item METR's own explanation \emph{maps boundary conditions} rather than refuting Case 1: deep repository familiarity left little for AI-supplied context to add; codebases large and conventionally dense; substantial time spent checking, repairing, discarding AI proposals
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The full empirical record, 2023--2025}
|
||||
\footnotesize The two cases are the extreme corners of a larger record -- seven strands, 2023--2025, from randomised experiments to organisational telemetry and longitudinal code analysis; read every row \emph{setting first, finding second}.
|
||||
|
||||
\vspace{-0.1cm}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{2.1cm}p{4.3cm}p{7.0cm}@{}}
|
||||
\toprule
|
||||
\textbf{Evidence} & \textbf{Setting} & \textbf{Finding} \\
|
||||
\midrule
|
||||
Copilot RCT & 95 developers; greenfield HTTP server (JavaScript) & \textbf{$+55.8\,\%$} task speed (95\,\% CI 21--89\,\%); completion rate not significantly different \\
|
||||
Three field experiments & 4{,}867 developers; Microsoft, Accenture, Fortune-100 firm & \textbf{$+26.1\,\%$} completed tasks (s.e.\ 10.3\,\%); less experienced developers gain most \\
|
||||
METR RCT & 16 expert OSS maintainers; 246 real issues, own mature repositories & \textbf{19\,\% slower} with AI -- while estimating afterwards that AI had made them 20\,\% faster \\
|
||||
DORA 2024 & $\sim$3{,}000 respondents; organisational delivery level & $+25\,\%$ AI adoption associated with \textbf{$-1.5\,\%$ throughput} and \textbf{$-7.2\,\%$ delivery stability} \\
|
||||
DORA 2025 & $\sim$5{,}000 respondents & throughput association now positive; \textbf{instability persists}; AI acts as an \emph{amplifier} of existing strengths and dysfunctions \\
|
||||
GitClear longitudinal & 211 million changed code lines, 2020--2024 & \textbf{$4\times$} growth in code duplication; moved-code share (the refactoring signature) collapsed from $\sim$25\,\% to below 10\,\% \\
|
||||
Stack Overflow survey & $>$49{,}000 developers & 84\,\% use or plan to use AI; \textbf{46\,\% actively distrust} its output; top frustration: ``almost right'' code \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{-0.15cm}
|
||||
\scriptsize \textcolor{codegray}{Caution from GitHub's own telemetry-plus-survey study: the best predictor of \emph{perceived} productivity is the suggestion acceptance rate, not the persistence of accepted code in the repository -- much vendor-reported ``productivity'' evidence measures perception, not verified output. Case 2's perception gap is the controlled-trial demonstration of the same fact.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The system level: DORA 2024 and 2025}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item DORA measures neither task times nor perceptions but \textbf{delivery performance at the level of the organisation} -- throughput and stability -- exactly the level at which architecture acts
|
||||
\item \textbf{2024} ($\sim$3{,}000 respondents; 75.9\,\% use AI for at least part of their work, roughly three quarters report productivity gains) -- a 25\,\% increase in AI adoption is associated with:
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.85}%
|
||||
\begin{tabular}{@{}ll@{}}
|
||||
\toprule
|
||||
\textbf{Gains} & \textbf{Losses} \\
|
||||
\midrule
|
||||
$+7.5\,\%$ documentation quality & $-1.5\,\%$ delivery throughput \\
|
||||
$+3.4\,\%$ code quality & $-7.2\,\%$ delivery stability \\
|
||||
$+3.1\,\%$ review speed & \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\vspace{-0.1cm}
|
||||
Proposed mechanism is classical: more code per change, and larger batch sizes have been a documented risk driver for years
|
||||
\item \textbf{2025} ($\sim$5{,}000 respondents): adoption near saturation (90\,\%, median about two hours of daily use); more than 80\,\% report productivity gains; 30\,\% still express little or no trust in AI-generated code; the throughput association has \textbf{turned positive} as tools and practices matured -- the negative association with delivery stability \textbf{persists}
|
||||
\item Central metaphor: \textbf{AI is an amplifier} -- it magnifies the strengths of well-run organisations and the dysfunctions of badly run ones
|
||||
\item \emph{Individual acceleration and system-level performance are different quantities, and only the second one pays salaries}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Code structure and practitioner trust in the longitudinal record}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item \textbf{GitClear}, 211 million changed lines (2020--2024): duplicated code blocks (five or more lines) at \textbf{four times} their pre-AI level in 2024; \emph{moved} lines -- the fingerprint of refactoring and modularisation -- fell from roughly \textbf{25\,\% to under 10\,\%}: 2024 was the first year in which copy-paste exceeded code movement
|
||||
\item \textbf{Churn} -- code reworked or discarded within two weeks of commit -- rose from a pre-AI baseline of roughly 3--4\,\% to \textbf{5.7\,\%} in 2024, trend continuing; two obligatory caveats: GitClear is a commercial analytics vendor, and the analysis is \emph{correlational} -- AI's causal share is plausible but not isolated
|
||||
\item Converges with DORA's stability data: \textbf{more code, produced faster, structurally worse maintained} -- reuse by abstraction displaced by reuse by duplication, the opposite of what Parnas-style modularisation (Part II) works to achieve
|
||||
\item \textbf{Stack Overflow 2025} ($>$49{,}000 developers): \textbf{84\,\%} use or plan to use AI tools; \textbf{46\,\%} actively distrust the accuracy of the output; most-cited frustration (45\,\%): ``almost right, but not quite'' -- \emph{adoption rises while trust falls}, consistent with METR and DORA: the effort has migrated from writing to verifying
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Reconciling the divergence: five moderator variables}
|
||||
\footnotesize \textbf{So which study is wrong? Neither} -- resolving the contradiction \emph{is} the lesson: different populations (task novices vs.\ domain experts in their own code), different codebases (greenfield vs.\ mature), different tasks (bounded vs.\ real issues) -- the results never actually compete; the resolution requires reading \emph{study designs}, not abstracts. Indexed by their moderator variables, Case 1 and Case 2 sit at opposite corners of a five-dimensional design space -- and every other row of the record finds its place in the same coordinates.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize
|
||||
\renewcommand{\arraystretch}{0.9}%
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{2.2cm}p{5.0cm}p{5.2cm}@{}}
|
||||
\toprule
|
||||
\textbf{Moderator} & \textbf{Gains high} & \textbf{Gains low or negative} \\
|
||||
\midrule
|
||||
Experience & juniors, task novices (Copilot RCT, field experiments) & domain experts in their own code (METR) \\
|
||||
Codebase & greenfield, small, standard stack & mature, large, dense implicit conventions \\
|
||||
Task & well-defined, bounded & under-specified, cross-cutting \\
|
||||
Measurement & task time, perceived productivity & delivery stability, maintainability, churn (DORA 2024, GitClear) \\
|
||||
Organisation & small batches, test automation, loose coupling & large batches, weak guardrails, tight coupling (DORA 2025) \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize The same technology yields $+55.8\,\%$ and $-19\,\%$ because the two cases differ on \textbf{every one of the five rows}.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Discussion: which setting is yours?}
|
||||
\begin{thinkbox}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item The same class of technology produced $+55.8\,\%$ in one randomised experiment and $-19\,\%$ in another. Walk through the five moderators: \textbf{on which rows do the two studies differ?}
|
||||
\item Consider the systems you are likely to work on two years after graduation -- greenfield exercises, or mature codebases with implicit conventions? \textbf{Which study's setting is closer to that reality?}
|
||||
\item What does the METR perception gap (forecast $+24\,\%$, measured $-19\,\%$, post-hoc estimate $+20\,\%$) imply about \textbf{relying on your own felt productivity as evidence}?
|
||||
\end{itemize}
|
||||
\end{thinkbox}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\scriptsize \textcolor{codegray}{\textbf{Project transfer:} which moderator row describes your repository in week 12?}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The verification bottleneck}
|
||||
\small The structural conclusion underneath the moderator table, in one sentence:
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\textbf{Code generation became cheap; specification, verification, and architecture became the binding constraints.}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item When the marginal cost of producing plausible code approaches zero, the scarce resource is no longer typing but \textbf{everything that surrounds it}: understanding the requirement precisely enough to specify it, reviewing and testing what was generated, and accepting responsibility for shipping it
|
||||
\item \textbf{The strands converge}: DORA -- individual acceleration coexists with delivery instability where control systems are weak; two thirds of surveyed developers spend more time on almost-right code; a substantial share of METR's slow-down is time spent checking, repairing, discarding AI proposals; industry analyses describe \emph{code review as the new bottleneck} -- more and larger pull requests meeting unchanged human review capacity
|
||||
\item Economically put: \textbf{AI lowers the cost of \emph{producing} code, not the cost of \emph{taking responsibility} for code}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Three consequences bind Axis A into the fit theory -- Maxim 7}
|
||||
\footnotesize
|
||||
\begin{enumerate}\setlength\itemsep{2pt}
|
||||
\item \textbf{Architecture quality gates AI gains} -- DORA 2025's core finding: teams in loosely coupled architectures with fast feedback loops convert AI adoption into throughput; tightly coupled systems with slow processes do not -- the AI-era echo of loosely coupled architectures and teams as the strongest predictor of continuous delivery performance \textcolor{codegray}{(the coupling finding of Lecture 11)}. In the theory's vocabulary: \textbf{D7} (evolvability) and \textbf{D9} (testability and deployability) gain weight in \emph{every} requirements profile -- architecture--application fit acquires a second reading: fit to a \emph{mode of work} in which change volume rises by an order of magnitude
|
||||
\item \textbf{Architecture documentation becomes a control interface} -- ADRs, repository convention files, and machine-readable rules are no longer passive records; agents execute them on every run (\S41.6)
|
||||
\item \textbf{Fitness functions become the operating licence for agents} -- an agent iterating against a dense test suite and CI-enforced architecture rules is contained; without them, every agent change is unpriced risk (\S41.7)
|
||||
\end{enumerate}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Maxim 7.} Good architecture was always the art of making change cheap and safe; AI raises the change rate by an order of magnitude -- and therefore \textbf{raises, not lowers, the value of architecture}.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
|
||||
% ============================================
|
||||
% AXIS A -- CONTROL INTERFACE AND GUARDRAILS
|
||||
% ============================================
|
||||
\section{Axis A -- Control Interface and Guardrails}
|
||||
|
||||
\begin{frame}{Architecture documentation as a control interface for agents (1/2)}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{5pt}
|
||||
\item Agentic tools are \textbf{context-driven}: they produce architecture-conformant code only if the architecture is \emph{explicit, machine-readable, and in the repository} -- Part I's documentation artefacts, written for human readers, upgrade into a \textbf{control interface for machine collaborators}. \textbf{ADRs} (preferably MADR) serve agents twice: as \emph{input context} (why is the system structured this way? which options were rejected, and why?) and as \emph{output format} -- an agent drafts, a human decides and signs, per Assumption A1 \textcolor{codegray}{\scriptsize (deck 3)}
|
||||
\item \textbf{Agent instruction files} -- project-local \texttt{CLAUDE.md} and the vendor-neutral \texttt{AGENTS.md} (published 2025, adopted within months by over 60{,}000 open-source repositories) -- carry stack, conventions, build and test commands, module boundaries, no-go zones; loaded at every session start: documentation once ``too expensive to maintain for human readers'' now amortises because it is \emph{executed} on every agent run. \textbf{Machine-checkable conventions} (dependency directions, naming, layering) are a failing test rather than a prose exhortation -- the fitness-function discipline of Part IV
|
||||
\item \textbf{The corollary cuts both ways}: documentation debt is now reproduced at machine speed -- a stale convention file or ADR is executed by every agent session; DORA 2025: ``AI-accessible internal knowledge'' and healthy data ecosystems rank among the seven capabilities that amplify AI benefits
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Architecture documentation as a control interface for agents (2/2)}
|
||||
\footnotesize Excerpt from the course project's agent instruction file (\texttt{AGENTS.md}):
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
||||
\scriptsize\ttfamily
|
||||
\# Portfolio Intelligence Platform -- agent instructions\\
|
||||
\textbf{\#\# Architecture (binding; see docs/adr/)}\\
|
||||
- Modular monolith, module boundaries enforced by CI\\
|
||||
~~(see fitness\_functions/boundaries\_test.py). Do not add\\
|
||||
~~cross-module imports; use the module's public API.\\
|
||||
- All LLM access goes through gateway/ -- never call a\\
|
||||
~~provider SDK from domain code (ADR-011).\\
|
||||
\textbf{\#\# Verification (run before proposing changes)}\\
|
||||
- make test~~~~~~~~~~\# unit + module-boundary rules\\
|
||||
- make evals~~~~~~~~~\# eval harness; required for any\\
|
||||
~~~~~~~~~~~~~~~~~~~~~\# change under prompts/ or gateway/\\
|
||||
\textbf{\#\# No-go zones}\\
|
||||
- ledger/ : append-only audit journal. Propose changes\\
|
||||
~~as an ADR draft instead of editing code.
|
||||
\end{tcolorbox}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\scriptsize \textcolor{codegray}{Every line is a control statement that an agent executes on each run -- and that therefore must be kept as current as code.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Guardrails as the precondition for safe agent use}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item If verification is the scarce resource, then everything that \emph{automates} verification multiplies the value of AI tooling -- and everything that leaves verification informal converts AI speed into instability
|
||||
\item \textbf{Test suites are the operating licence}: against a dense, fast test suite an agent can iterate -- wrong code fails immediately and is repaired or discarded at machine speed; without that net every agent-generated change ships \emph{unpriced risk} (DORA's ``strong version control and test automation'' amplifier pair)
|
||||
\item \textbf{Architectural fitness functions fence the structure}: an objective integrity assessment of an architectural characteristic is the machine-readable form of an architecture decision -- dependency rules, cycle checks, module-boundary verification as CI gates were good practice before AI; with agents in the loop they are the mechanism by which an architect constrains \emph{a collaborator who never attends design meetings}
|
||||
\item \textbf{The delivery pipeline becomes a defence instrument}: static analysis, SAST, dependency and secret scanning, contract tests, progressive delivery move from hygiene to necessity -- the only controls that \emph{scale with generation volume}
|
||||
\item \textbf{Continuity with Part IV}: nothing here is new machinery -- the measurement contract already demanded executable invariants; Axis A merely adds a new class of change producer whose volume makes the contract \emph{non-optional}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The tool landscape, soberly -- and the AI Lens on MCP}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Record the landscape \emph{as a geologist records a riverbed} -- evidence of forces, not a map that stays accurate. Generation 2021--2023 (autocomplete-style assistants) suggested lines; generation 2024/2025 onwards \textbf{plans, edits multiple files, runs builds and tests, iterates on failures} -- agentic loops with tool access
|
||||
\item \textbf{Claude Code} (Anthropic): agentic CLI tool, research preview February 2025, GA May 2025; repository-level anchor \texttt{CLAUDE.md}
|
||||
\item \textbf{Cursor} (Anysphere): AI-first IDE with an agent mode; the dominant tool among the METR study's experts
|
||||
\item \textbf{GitHub Copilot}: Copilot Workspace retired May 2025; its concepts live on in the asynchronous \emph{Copilot coding agent} (issues to pull requests, in CI) and the synchronous IDE agent mode
|
||||
\item \textbf{Devin} (Cognition): ``first AI software engineer'' (2024); 13.86\,\% SWE-bench in March 2024 triggered the agent wave; acquired Windsurf July 2025 -- rapid market consolidation
|
||||
\item \textbf{Two open standards matter more than any product, because they are architectural}: the \textbf{Model Context Protocol} (MCP, Anthropic, November 2024; JSON-RPC, servers expose tools, resources, prompts; over 10{,}000 public servers) and \textbf{\texttt{AGENTS.md}} for project-level instructions; vendor SDKs extract the agent loop as a library -- the bridge to Axis B (\S44, next week)
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{ailinse}[MCP is ports-and-adapters at ecosystem scale]
|
||||
\footnotesize Strip the branding and MCP is a familiar shape: a technology-neutral \emph{port} (the protocol) with swappable \emph{adapters} (servers wrapping databases, ticket systems, browsers), letting any conforming client use any conforming tool -- the role JDBC/ODBC played for databases. \textbf{The hexagonal pattern of Part II did not become obsolete in the agent era; it became an ecosystem standard.}
|
||||
\end{ailinse}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Benchmarks and their limits -- an expiry date on this section}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{SWE-bench}: 2{,}294 real GitHub issues from twelve Python projects -- given repository and issue text, produce a patch that passes hidden tests. Trajectory: \textbf{1.96\,\%} (best 2023 setup) $\to$ \textbf{13.86\,\%} (Devin, March 2024) $\to$ around \textbf{77--81\,\%} for frontier models by late 2025 on the human-validated 500-task \emph{SWE-bench Verified} subset
|
||||
\item \textbf{Four qualifications keep the number honest}: (1) \emph{contamination} -- the repositories are in the training data; (2) \emph{scope} -- Python only, issues with tests only; (3) \emph{criterion} -- ``tests pass'' is not ``maintainable, architecture-conformant''; (4) \emph{saturation} -- on the contamination-resistant SWE-bench Pro, frontier models initially scored around 23\,\%. Near-80\,\% benchmark scores next to METR's measured slow-down: \textbf{the module's canonical exercise in benchmark literacy}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{hinweisbox}
|
||||
\footnotesize This section encodes the state of \textbf{early 2026}; product names carry an expiry date measured in months (Copilot Workspace lived roughly a year). Stable -- and \textbf{examinable} -- are the \emph{patterns}: the synchronous pair-agent versus the asynchronous task-agent as interaction modes, context files and ADRs as the control interface, fitness functions as the containment mechanism. Every concrete tool claim carries its own temporal fitness function: \emph{re-verify on every tool generation}.
|
||||
\end{hinweisbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Risks and responsibility: security, bias, skill, accountability}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Security} -- the evidence predates the agent wave and gains relevance with volume: roughly \textbf{40\,\%} of 1{,}689 Copilot-generated programs (89 security-relevant scenarios) contained CWE top-25 vulnerabilities; a user study: participants with an AI assistant wrote \textbf{less secure code while believing it more secure}; package hallucination (``slopsquatting''): across roughly 576{,}000 generations, \textbf{about a fifth} of recommended package references did not exist -- names an attacker can register pre-emptively. Consequence: SAST, dependency and secret scanning, licence checks in CI are not optional; security review capacity must scale with generation volume
|
||||
\item \textbf{Automation bias}: over-trust in automated systems is a decades-old human-factors finding -- Perry et al.'s participants overestimated their security, METR's experts overestimated their speed
|
||||
\item \textbf{Skill formation}: a randomised study of engineers learning a new library -- AI assistance reduced comprehension-test scores by roughly \textbf{17\,\%}; the usage pattern is the decisive moderator (conceptual questions preserved learning, wholesale delegation destroyed it); \textbf{entry-level developer positions are measurably declining}. For this module: the role being trained is the \emph{specifier, verifier, and architect} -- rebuild the competence ladder deliberately, including AI-free practice of fundamentals
|
||||
\item \textbf{Accountability}: legally and professionally, \emph{the person who merges code answers for it}, regardless of what generated it; AI tools are not liability-bearing entities -- treat AI output as the contribution of an unknown third party: mandatory review, provenance labelling, an explicit policy for permitted uses (DORA 2025: a clearly communicated AI policy first among the seven amplifier capabilities)
|
||||
\item AI may \emph{draft} an ADR; a nameable person decides, signs, and defends it \textcolor{codegray}{(deck 3)} -- \textcolor{bankblue}{\textbf{architecture is an accountability performance, not a text-production performance}}. IP risk open but manageable: \emph{Doe v.\ GitHub} -- the DMCA claim dismissed in 2024, licence-related claims continue; response: provider duplication filters and indemnification, licence scanning in CI, a documented residual risk in the governance record
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Project link: Axis A governs how you build the platform}
|
||||
\begin{projektbox}
|
||||
\footnotesize Axis A governs \emph{how} you build the Portfolio Intelligence Platform; the project applies every mechanism of this section:
|
||||
\begin{enumerate}\setlength\itemsep{2pt}
|
||||
\item[(i)] the repository carries an \texttt{AGENTS.md}\,/\,\texttt{CLAUDE.md} in the spirit of the listing -- and you are expected to \textbf{keep it as current as code}
|
||||
\item[(ii)] every architecture decision is an \textbf{ADR} -- agents may draft, but a named team member signs
|
||||
\item[(iii)] agent-generated changes enter the main branch \textbf{only through the CI gate}: module-boundary fitness functions, the test suite, and -- for anything touching prompts or the gateway -- the \textbf{eval harness} of \S42.5
|
||||
\item[(iv)] your project handbook contains a \textbf{one-page AI policy}: permitted tools, provenance labelling, review rules
|
||||
\end{enumerate}
|
||||
\vspace{0.05cm}
|
||||
\textbf{The graded artefact is not the generated code -- it is the control system around it.}
|
||||
\end{projektbox}
|
||||
\end{frame}
|
||||
|
||||
\end{document}
|
||||
BIN
Folien/AISE502_Vorlesung_13_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_13_Folien.pdf
Normal file
Binary file not shown.
698
Folien/AISE502_Vorlesung_13_Folien.tex
Normal file
698
Folien/AISE502_Vorlesung_13_Folien.tex
Normal file
@ -0,0 +1,698 @@
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% ============================================================================
|
||||
% AISE502 -- AI in Software Engineering II
|
||||
% Lecture 13 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 13: Threats, the Shifted Matrix, Agent Orchestration -- and Synthesis\\[0.4ex]{\small Script: Part V, Sections 42.6--42.7, 43--45}}
|
||||
\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 Axis B completed: a new threat class -- \textbf{OWASP LLM Top 10}, prompt injection; regulation as a hard constraint -- the \textbf{EU AI Act}
|
||||
\item How AI \textbf{shifts the matrix}: the C10 row cell by cell; D12 across the seven patterns; five shifted cells; MLOps maturity; A6 restated
|
||||
\item \textbf{Agent orchestration} -- the emergent eighth pattern: the advisor workflow; agent vs.\ workflow; topologies and classical analogues
|
||||
\item The economics of autonomy and the default rule; a capability-profile sketch
|
||||
\item Synthesis: one theory, five parts -- \textbf{Maxim 8}; one discipline at two binding sites
|
||||
\item Exam orientation
|
||||
\item This week's exercise: \textbf{M5 closes} -- eval harness in CI, guard, cost observability; threat model incl.\ prompt injection via news $+$ basic hardening; optional distinction work (K\"ur)
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% RECAP
|
||||
% ============================================
|
||||
\section{Recap}
|
||||
|
||||
\begin{frame}{Recap: where we are}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Part V is the framework's stress test on two axes: \textbf{Axis A} -- AI in the process; \textbf{Axis B} -- AI in the product (components that are non-deterministic, fallible, latency-heavy, priced per call)
|
||||
\item Lecture 12: Axis-A evidence -- two RCTs and their resolution; the \textbf{verification bottleneck} (Maxim 7: generation is cheap, verification and architecture are binding -- D7 and D9 gain weight); Axis A compact: documentation as control interface, fitness functions as operating licence, who merges answers; Axis B: sentiment call wired wrong and right; three component types; SE4AI classics; reference architecture (\textbf{LLM gateway} as single measurement point); eval-harness basics
|
||||
\item The C10 verdict has been computed \textbf{three times}: mini-match (L, MM, MS -- Lecture 3), profile and real systems (Lecture 6), the full row with its cell rationales (Lecture 10; the $7 \times 10$ matrix itself was read in Lecture 7)
|
||||
\item Lecture 6 filed the outlook: agent orchestration is a \emph{composition pattern} reusing the catalogue's topologies -- workflows before agents ($15\times$ tokens). Today that claim is paid out
|
||||
\item Today: Axis B completed (threats, regulation) $\to$ how AI \emph{shifts} the matrix $\to$ the eighth pattern with a profile sketch $\to$ synthesis and exam orientation. \textbf{The last lecture of new material}; week 14: one lesson synthesis and exam hints, three lessons final presentations, architecture defence and peer reviews (A3, M6)
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\centering\textcolor{codegray}{tenth class (done) -- twelfth dimension (done) -- shifted cells (today) -- one composition pattern (today)}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% AXIS B COMPLETED -- THREATS AND REGULATION
|
||||
% ============================================
|
||||
\section{Axis B Completed -- Threats and Regulation}
|
||||
|
||||
\begin{frame}{A new threat class -- OWASP Top 10 for LLM Applications (1/2)}
|
||||
\emph{\textcolor{bankblue}{AI components add an attack surface that classical threat models do not cover.}}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize The OWASP Top 10 for LLM Applications 2025 codifies it; the script pairs each risk with its \textbf{architectural} counter-measure -- deliberately, because the defence is \emph{structural, not model-internal}.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{1.2cm}p{4.2cm}p{7.2cm}@{}}
|
||||
\toprule
|
||||
\textbf{ID} & \textbf{Risk} & \textbf{Architectural counter-measure} \\
|
||||
\midrule
|
||||
LLM01 & Prompt injection (direct and indirect) & Defence in depth: privilege separation, output validation, human-in-the-loop for sensitive actions \\
|
||||
LLM02 & Sensitive information disclosure & Data minimisation in prompts; output filtering at the gateway \\
|
||||
LLM03 & Supply chain & Vetting of models, weights, and dependencies; registry discipline \\
|
||||
LLM04 & Data and model poisoning & Data governance and provenance for training/index data \\
|
||||
LLM05 & Improper output handling & Treat output as untrusted input: schema validation, encoding, ontology guard \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{A new threat class -- OWASP Top 10 for LLM Applications (2/2)}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{1.2cm}p{4.2cm}p{7.2cm}@{}}
|
||||
\toprule
|
||||
\textbf{ID} & \textbf{Risk} & \textbf{Architectural counter-measure} \\
|
||||
\midrule
|
||||
LLM06 & Excessive agency & Least-privilege tool design; deterministic services own irreversible actions \\
|
||||
LLM07 & System prompt leakage & No secrets or authorisation logic in prompts \\
|
||||
LLM08 & Vector and embedding weaknesses & Access control and tenant isolation on the retrieval index \\
|
||||
LLM09 & Misinformation & Grounding with mandatory citations; domain-axiom checks \\
|
||||
LLM10 & Unbounded consumption & Rate limits, token budgets, cost circuit breakers per tenant \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\footnotesize \emph{Most counter-measures are elements of the gateway architecture of Lecture 12.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Prompt injection -- why the model cannot solve it}
|
||||
\begin{hinweisbox}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item Prompt injection is \textbf{not fully solvable inside the model}, because LLMs process instructions and data in the \emph{same channel}
|
||||
\item Any document, e-mail, or web page the system reads can carry instructions (``ignore your previous rules and \dots'') -- and no reliable in-model separator exists
|
||||
\item The defence is therefore \textbf{defence in depth at the system level}: least-privilege tools (LLM06), output validation (LLM05), human approval for consequential actions, consumption limits (LLM10)
|
||||
\item This is the security-flavoured restatement of the section's design rule: \textbf{the architecture, not the model, is the trust boundary}
|
||||
\item For the course project, concretely: no LLM output may reach the booking path without passing the \textbf{ontology guard}; no agent tool may perform an \textbf{irreversible action}
|
||||
\end{itemize}
|
||||
\end{hinweisbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Regulation as a hard constraint: the EU AI Act}
|
||||
\footnotesize Regulation closes the quality-attribute loop with legal force -- \textbf{Regulation (EU) 2024/1689}, the AI Act, entered into force on 1~August 2024; a risk-based approach with four classes:
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.55\textwidth}
|
||||
\scriptsize
|
||||
\begin{tabular}{@{}p{1.9cm}p{5.2cm}@{}}
|
||||
\toprule
|
||||
\textbf{Class} & \textbf{Examples / duties} \\
|
||||
\midrule
|
||||
\textbf{Unacceptable risk} & prohibited practices, e.g.\ social scoring \\
|
||||
\textbf{High risk} & Annex III use cases: creditworthiness assessment, employment, critical infrastructure -- duties: risk management, data governance, documentation, logging, oversight, accuracy/robustness/cybersecurity \\
|
||||
\textbf{Limited risk} & transparency duties: labelling AI interaction and generated content \\
|
||||
\textbf{Minimal risk} & -- \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{column}
|
||||
\begin{column}{0.42\textwidth}
|
||||
\scriptsize
|
||||
\begin{tabular}{@{}p{1.7cm}p{3.7cm}@{}}
|
||||
\toprule
|
||||
\textbf{Date} & \textbf{What applies} \\
|
||||
\midrule
|
||||
2 Feb 2025 & prohibitions; AI-literacy duties \\
|
||||
2 Aug 2025 & governance; GPAI duties \\
|
||||
2 Aug 2026 & general applicability incl.\ Annex III high-risk \\
|
||||
2 Aug 2027 & high-risk AI in regulated products \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{AI Act obligations -- K(a), not weights}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item For this theory the AI Act has a precise, limited role: its obligations are \textbf{quality attributes with legal force} that enter the requirements profile as \textbf{hard constraints K(a), not as weights} -- Part I: constraints are knock-out filters, never averaged away
|
||||
\item A finance-related advisory platform -- class C10, particularly with any \emph{creditworthiness} bearing -- can fall into the \textbf{high-risk} class
|
||||
\item Then logging of agent steps, technical documentation, human oversight, and demonstrated robustness stop being engineering preferences and become \textbf{conditions of legal operation}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{3.2cm}p{9.4cm}@{}}
|
||||
\toprule
|
||||
\textbf{Obligation} & \textbf{Architectural element it lands on} \\
|
||||
\midrule
|
||||
\textbf{logging} & gateway telemetry $+$ audit journal \\
|
||||
\textbf{human oversight} & human-in-the-loop interfaces at the determinism boundary \\
|
||||
\textbf{robustness} & fallback chains $+$ eval harness \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize Compliance, correctly designed, is not a parallel work stream -- \textbf{it is the same architecture, documented}.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% HOW AI SHIFTS THE MATRIX
|
||||
% ============================================
|
||||
\section{How AI Shifts the Matrix}
|
||||
|
||||
\begin{frame}{How AI shifts the matrix}
|
||||
\emph{\textcolor{bankblue}{You have computed the C10 verdict three times -- what were those computations doing to the rest of the matrix?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item The verdict itself needs \textbf{no fourth derivation} -- the three computations of the recap (Lectures 3, 6, 10)
|
||||
\item Two of the four absorption forms on the recap's map -- the \textbf{tenth class} and the \textbf{twelfth dimension} -- are exactly the artefacts those computations used
|
||||
\item This section supplies the generalisation in three steps:
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item[(i)] the \emph{supply-side} reading of the row you own
|
||||
\item[(ii)] the full \textbf{D12 column} it exercised
|
||||
\item[(iii)] the \textbf{cells that moved} -- cell by cell, with stated and measurable reasons
|
||||
\end{enumerate}
|
||||
\item Then: when the pipeline promise is real (MLOps maturity) -- and A6 restated as a falsifiable claim
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The C10 row -- which D12 mechanism each cell exercises}
|
||||
\footnotesize Start from the row you own (Lecture 10) -- the one reading the three computations used but never stated in one place: \emph{which D12 mechanism each cell exercises}.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{1.6cm}cp{9.6cm}@{}}
|
||||
\toprule
|
||||
\textbf{Cells} & \textbf{Fit} & \textbf{D12 mechanism exercised} \\
|
||||
\midrule
|
||||
MM, HX & $++$ & \textbf{boundary and port}: a CI-verifiable module boundary and an anti-corruption adapter on a port contain a fallible, entangled component \\
|
||||
EDA, PF & $+$ & \textbf{queue}: asynchronous absorption of latency, rate limits, and outages; pipeline-shaped ingestion and evals \\
|
||||
L & $-$ & none of the three -- no queue, no port, no measurement point \\
|
||||
MS & $\circ$ & seconds-scale, fallible calls in synchronous chains (the missing queue) \\
|
||||
SL & $\circ$ & minutes-long LLM and solver work against platform timeout ceilings \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Recommendation (Part IV, ADR-007):} a hexagonal modular monolith plus pipelines and an orchestrated agent workflow, with EDA as the secondary job/audit spine -- governed by token and latency budgets and the determinism boundary: \emph{agents propose; deterministic services decide and book}.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{D12 across the seven patterns}
|
||||
\footnotesize The D12 row of the Lecture-6 consolidated table, now with tactic-level rationales -- D12 (AI integrability) measures whether the pattern naturally provides \textbf{the queue, the port, and the measurement point} a slow, fallible, per-call-priced component requires.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{2.6cm}cp{8.4cm}@{}}
|
||||
\toprule
|
||||
\textbf{Pattern} & \textbf{D12} & \textbf{Rationale} \\
|
||||
\midrule
|
||||
L -- Layered & $\circ$ & technical layers give the non-deterministic component no boundary, no queue, and no measurement point of its own \\
|
||||
MM -- Modular monolith & $+$ & a dedicated AI module with a hard, CI-verifiable interface contains the component cheaply \\
|
||||
HX -- Hexagonal & $++$ & the LLM is an adapter on a port: swappable, mockable, contract-guarded -- the ACL discipline structurally built in \\
|
||||
MS -- Microservices & $\circ$ & per-service isolation helps; synchronous chains through seconds-scale calls hurt -- net neutral \\
|
||||
EDA -- Event-driven & $++$ & queues absorb exactly what LLMs are worst at: latency, rate limits, outages; natural batching points \\
|
||||
PF -- Pipes-and-filters & $++$ & ingestion, training, and eval pipelines are pipes-and-filters by construction \\
|
||||
SL -- Serverless & $\circ$ & event-glue around batch AI APIs fits; platform timeout ceilings collide with minutes-long LLM/solver runs \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Which existing cells shift, and why (1/2)}
|
||||
\footnotesize Beyond the new row and column, AI as a runtime component moves \emph{existing} evaluations in stated directions -- all five visible in the D12 ratings, each carrying a measurable reason:
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{enumerate}\setlength\itemsep{3pt}
|
||||
\item \textbf{Asynchronous patterns gain (EDA, PF $\uparrow$).} Queues and pipelines absorb what LLMs are worst at -- latency, rate limits, outage -- and ingestion and eval pipelines are pipes-and-filters by construction
|
||||
\item \textbf{Hexagonal gains most (HX $\uparrow$).} The ACL/port discipline is exactly what the CACE problem demands; Assumption A1's cost-of-change criterion bites hardest at \emph{model replacement}; testing against deterministic fakes is the only way to keep the deterministic 95\,\% of the system deterministic
|
||||
\item \textbf{Synchronous distributed chains lose (MS $\downarrow$ where LLM calls sit in the request path).} Seconds-scale latency and per-hop failure probability multiply along the chain; without constitutive stability patterns this is a cascade design
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Which existing cells shift, and why (2/2)}
|
||||
\footnotesize
|
||||
\begin{enumerate}\setlength\itemsep{3pt}
|
||||
\setcounter{enumi}{3}
|
||||
\item \textbf{Serverless is conditional (SL $\sim$).} Platform timeout ceilings against minutes-long LLM and solver runs cap it; event-glue around batch APIs remains a fit
|
||||
\item \textbf{A cost dimension becomes load-bearing everywhere.} Cost per request, feature, and tenant is a runtime quality attribute with no counterpart in classical profiles; it belongs in the gateway and in CI budgets. Routing across cheap and expensive models is the new incarnation of a classical resource-arbitration tactic: \textbf{cascades} up to $\sim$98\,\% cost reduction at comparable quality; \textbf{learned routers} more than $2\times$ cheaper without quality loss
|
||||
\end{enumerate}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize The matrix does not get \emph{rewritten} by AI; it gets \emph{shifted} -- in \textbf{five stated directions, for five stated and measurable reasons}. A student who can name, for any cell movement, the quality-attribute mechanism behind it (which tactic the pattern bundles or impedes for a slow, fallible, per-call-priced component) has understood both Part IV and Part V.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{MLOps maturity: the three-level ladder}
|
||||
\footnotesize For type-(b) components the PF cells' promise (the D12 $++$) is realised only at sufficient process maturity -- the canonical three-level ladder:
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{1.0}%
|
||||
\begin{tabular}{@{}p{1.4cm}p{7.0cm}p{4.4cm}@{}}
|
||||
\toprule
|
||||
\textbf{Level} & \textbf{Characteristics} & \textbf{Key trait} \\
|
||||
\midrule
|
||||
\textbf{Level 0} & manual, script-driven, interactive; data science and operations separated; releases rare, no CI/CD, minimal monitoring -- \emph{the documented reality of many teams} & model handed ``over the fence'' as an artefact \\
|
||||
\textbf{Level 1} & automated ML pipeline with continuous training; automated data and model validation, triggers, metadata store, feature store & \emph{the pipeline, not the model, is the deployment artefact} \\
|
||||
\textbf{Level 2} & CI/CD automation of the pipeline components themselves & fast, reliable experiment-to-production cycles \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\scriptsize\textcolor{codegray}{Nine consolidated MLOps principles: CI/CD automation, workflow orchestration, reproducibility, versioning of data/model/code, collaboration, continuous training and evaluation, metadata tracking, monitoring, feedback loops.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{When the pipeline promise is real: the fit-theoretical reading}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Fit-theoretical reading:} the MLOps level describes how much of \textbf{D9} (testability/deployability) and \textbf{D12} the organisation can actually \emph{cash in}.
|
||||
\end{keypoint}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item A Level-0 team holding a $++$ pattern rating realises little of it
|
||||
\item This is the \textbf{Axis-B echo of DORA's Axis-A finding} (Lecture 12): \emph{guardrail maturity, not tool adoption}, converts potential into performance
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Assumption A6 restated as a falsifiable claim}
|
||||
\footnotesize Three of the four absorption forms are now on the table, each \emph{computed rather than asserted}: the tenth class, the twelfth dimension, the shifted cells -- the fourth, the emergent composition pattern, follows next.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{Assumption A6 restated as a falsifiable claim.}
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Runtime AI components are non-deterministic, fallible, latency-heavy, per-call-priced, and subject to drift and vendor deprecation
|
||||
\item They \emph{stretch} existing quality dimensions by orders of magnitude and add sub-attributes: token cost per request, eval pass rate, provider deprecation risk, prompt-injection resistance
|
||||
\item What does \emph{not} change is the method: scenarios with response measures, tactics, trade-off analysis, ADRs, fitness functions
|
||||
\item The theory absorbs AI -- as a tenth application class, a twelfth profile dimension, shifted cell values, and one emergent composition pattern -- instead of being reinvented for it
|
||||
\item The quality gate is carried by the one new test-artefact class A6 named from the start: the \textbf{eval harness}
|
||||
\end{itemize}
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% AGENT ORCHESTRATION -- THE EMERGENT EIGHTH PATTERN
|
||||
% ============================================
|
||||
\section{Agent Orchestration -- The Emergent Eighth Pattern}
|
||||
|
||||
\begin{frame}{Agent orchestration -- the emergent eighth pattern}
|
||||
\emph{\textcolor{bankblue}{``Should I reduce my exposure to European industrials?'' -- no single model call can answer that responsibly, so what structure can?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item The final structural novelty of the AI era is the \textbf{orchestration of agents}
|
||||
\item As everywhere in this script, \textbf{the concrete system comes before the catalogue}: first the advisory workflow the course project actually builds, then the name of what it is an instance of
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\footnotesize \textbf{Rhythm of this block:} case $\to$ what an agent is and is not $\to$ topologies and classical analogues $\to$ choosing a topology $\to$ economics and the default rule $\to$ capability-profile sketch $\to$ project link
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Case: the course project's advisor workflow}
|
||||
\begin{center}
|
||||
\resizebox{0.92\textwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt},
|
||||
agent/.style={sysbox, fill=aiviolet!15, draw=aiviolet, minimum width=2.7cm, minimum height=0.9cm},
|
||||
det/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.7cm, minimum height=0.9cm},
|
||||
extern/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=2.2cm, minimum height=0.9cm},
|
||||
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
||||
]
|
||||
\node[extern] (req) at (-8.6,1.7) {request};
|
||||
\node[agent] (orch) at (0,1.7) {Orchestrator\\ \scriptsize LLM call, fixed system prompt};
|
||||
\node[agent] (da) at (-4.2,-0.4) {Document analyst\\ \scriptsize findings with citations};
|
||||
\node[agent] (pq) at (0,-0.4) {Portfolio quant\\ \scriptsize exposure, concentration};
|
||||
\node[agent] (cc) at (4.2,-0.4) {Compliance checker\\ \scriptsize citations, ontology, mandate};
|
||||
\node[det] (ana) at (0,-2.4) {deterministic analytics services};
|
||||
\node[det] (guard) at (7.4,1.7) {guard};
|
||||
\node[extern] (out) at (10.9,1.7) {user / books};
|
||||
\draw[dashed, aiviolet, rounded corners=6pt, line width=0.8pt] (-6.1,-1.15) rectangle (6.1,2.75);
|
||||
\node[font=\small\sffamily, text=aiviolet, anchor=west] at (-6.0,2.45) {LLM gateway -- every call};
|
||||
\draw[arr] (req) -- (orch);
|
||||
\draw[arr] (orch) -- node[left, font=\scriptsize\sffamily, pos=0.4] {sub-tasks} (da);
|
||||
\draw[arr] (orch) -- (pq);
|
||||
\draw[arr] (orch) -- (cc);
|
||||
\draw[arr] (pq) -- (ana);
|
||||
\draw[arr] (orch) -- node[above, font=\scriptsize\sffamily] {merged answer} (guard);
|
||||
\draw[arr] (guard) -- (out);
|
||||
\end{tikzpicture}%
|
||||
}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize
|
||||
\textbf{Orchestrator} (an LLM call with a fixed system prompt) splits the request into sub-tasks, delegates, then merges the results into one grounded answer. \textbf{Document analyst}: extracted findings from the ingestion corpus \emph{with citations}; \textbf{portfolio quant}: exposure and concentration numbers by calling only deterministic analytics services -- \emph{arithmetic is not a job for a language model}. \textbf{Compliance checker}: verifies the draft -- every cited passage exists, every entity resolves against the ontology, every mandate constraint holds.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Strip the labels: a shape you know cell by cell}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item Every call by every participant flows through the \textbf{LLM gateway} -- routed, cached, budgeted, logged -- and nothing any agent produces reaches the user or the books without passing the \textbf{guard}: \emph{agents propose; deterministic services decide and book}
|
||||
\item Now strip the labels: a coordinator decomposing work for specialised workers is the \textbf{mediator topology of event-driven architecture} (Lecture 5); the fixed retrieve--extract--check sequence inside each specialist is a \textbf{pipeline} (Lecture 6); peers coordinating over shared context would be the \textbf{broker topology}
|
||||
\item This is the claim the Part II outlook (Lecture 6) filed in advance; this section pays it out -- the full six-row mapping follows
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize The section's deliberately \emph{deflationary} claim: agent orchestration is \textbf{not a new architectural style} but a \textbf{composition pattern for non-deterministic runtime components} that reuses the topologies of the seven patterns you already know -- which is why it can be evaluated with the \textbf{rating grid you already have}.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{What an agent is -- and is not}
|
||||
\begin{definitionbox}[Agent; workflow vs.\ agent]
|
||||
\footnotesize An \emph{agent} is an LLM running in a loop with tools and state: at each iteration the model observes the current state (conversation, tool results, working memory), selects an action (a tool call or an answer), and the loop executes it and feeds the result back -- until a termination condition holds.
|
||||
\begin{center}\textbf{agent $=$ loop $+$ tools $+$ state}\end{center}
|
||||
The load-bearing distinction: a \textbf{workflow} orchestrates LLM calls and tools along \emph{predefined code paths} -- deterministic structure, non-deterministic building blocks; an \textbf{agent} lets the model \emph{steer its own process and tool use} -- the control flow itself becomes model output. Autonomy is therefore not a binary but a \textbf{dial}, and every notch on it costs latency, tokens, and testability.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize Engineering guidance of the source that defined this vocabulary -- matching the module's philosophy verbatim:
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{find the simplest solution possible}
|
||||
\item \textbf{prefer simple, composable patterns over frameworks}
|
||||
\item \textbf{escalate to agents only when the task genuinely requires open decision paths}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.05cm}
|
||||
Orchestration frameworks that model workflows as \emph{explicit graphs} make the topology \textbf{inspectable} -- an architectural virtue for the same reason a C4 diagram is (Lecture 3).
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Topologies and their classical analogues}
|
||||
\footnotesize The Lecture-6 outlook table, now with its third column: every workflow topology maps exactly onto a structure from Part II that you know cell by cell -- and every property the classical pattern is known for (and every weakness) \emph{transfers}.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{3.2cm}p{3.0cm}p{6.4cm}@{}}
|
||||
\toprule
|
||||
\textbf{Topology} & \textbf{Classical analogue} & \textbf{Structure and use} \\
|
||||
\midrule
|
||||
Prompt chaining (chain) & Pipes-and-filters (PF) & each call processes the previous output; programmatic gates between stages; fixed decomposition \\
|
||||
Routing & Routing layer / mediator & a classification step directs inputs to specialised prompts or models; the runtime sibling of model routing \\
|
||||
Parallelisation (sectioning, voting) & Broker-style fan-out & independent subtasks in parallel, or repeated runs with majority vote \\
|
||||
Orchestrator--workers (tree/graph) & Mediator EDA & a lead model decomposes the task dynamically and delegates to workers; central workflow control \\
|
||||
Evaluator--optimizer & Feedback control loop & generator and evaluator model iterate until a quality criterion holds \\
|
||||
Autonomous multi-agent & Broker topology & peer agents coordinate over shared context; maximal flexibility, minimal central control \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Four topologies, drawn -- gates in code, judgement in the model}
|
||||
\begin{center}
|
||||
\resizebox{0.85\textwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
agentbox/.style={rectangle, draw, rounded corners=3pt, minimum width=1.5cm, minimum height=0.7cm, align=center, font=\scriptsize\sffamily, fill=aiviolet!15, draw=aiviolet, line width=0.7pt},
|
||||
gatebox/.style={rectangle, draw, rounded corners=3pt, minimum width=1.2cm, minimum height=0.7cm, align=center, font=\scriptsize\sffamily, fill=bankgreen!15, draw=bankgreen, line width=0.7pt},
|
||||
lbl/.style={font=\scriptsize\sffamily\bfseries, align=center},
|
||||
arr/.style={-{Stealth[length=2mm]}, semithick, gray!60!black}
|
||||
]
|
||||
% --- Chain ---
|
||||
\node[agentbox] (c1) {LLM 1};
|
||||
\node[gatebox, right=0.5cm of c1] (g1) {gate};
|
||||
\node[agentbox, right=0.5cm of g1] (c2) {LLM 2};
|
||||
\node[agentbox, right=0.5cm of c2] (c3) {LLM 3};
|
||||
\draw[arr] (c1) -- (g1); \draw[arr] (g1) -- (c2); \draw[arr] (c2) -- (c3);
|
||||
\node[lbl, above=0.25cm of g1, xshift=0.9cm] {Chain $\;\hat{=}\;$ pipes-and-filters};
|
||||
|
||||
% --- Orchestrator-workers ---
|
||||
\node[agentbox, right=1.6cm of c3, yshift=0.65cm] (orch) {Orchestrator};
|
||||
\node[agentbox, below=0.55cm of orch, xshift=-1.7cm] (w1) {Worker A};
|
||||
\node[agentbox, below=0.55cm of orch] (w2) {Worker B};
|
||||
\node[agentbox, below=0.55cm of orch, xshift=1.7cm] (w3) {Worker C};
|
||||
\draw[arr] (orch) -- (w1); \draw[arr] (orch) -- (w2); \draw[arr] (orch) -- (w3);
|
||||
\node[lbl, above=0.25cm of orch] {Orchestrator--workers $\;\hat{=}\;$ mediator EDA};
|
||||
|
||||
% --- Evaluator-optimizer ---
|
||||
\node[agentbox, below=2.4cm of c1, xshift=0.6cm] (gen) {Generator};
|
||||
\node[agentbox, right=1.5cm of gen] (ev) {Evaluator};
|
||||
\draw[arr] (gen.10) -- (ev.170);
|
||||
\draw[arr] (ev.190) -- node[below, font=\tiny\sffamily]{feedback} (gen.350);
|
||||
\node[lbl, above=0.25cm of gen, xshift=1.4cm] {Evaluator--optimizer $\;\hat{=}\;$ control loop};
|
||||
|
||||
% --- Multi-agent broker ---
|
||||
\node[gatebox, right=2.6cm of ev, minimum width=3.4cm, minimum height=0.5cm] (bus) {shared context / bus};
|
||||
\node[agentbox, above=0.5cm of bus, xshift=-1.2cm] (a1) {Agent 1};
|
||||
\node[agentbox, above=0.5cm of bus, xshift=1.2cm] (a2) {Agent 2};
|
||||
\node[agentbox, below=0.5cm of bus] (a3) {Agent 3};
|
||||
\draw[arr] (a1) -- (bus); \draw[arr] (a2) -- (bus); \draw[arr] (bus) -- (a3);
|
||||
\node[lbl, below=0.3cm of a3] {Multi-agent $\;\hat{=}\;$ broker topology};
|
||||
\end{tikzpicture}%
|
||||
}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize Deterministic gates (green) between non-deterministic stages (violet) are the \textbf{workflow discipline}: \emph{structure stays in code, judgement stays in the model}.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The evaluation logic applies unchanged -- sharpened along three axes}
|
||||
\footnotesize Because the topologies are the old topologies, the evaluation logic of this theory applies \textbf{unchanged} -- sharpened along exactly three axes:
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item \textbf{Non-determinism} -- testability is read as \emph{eval coverage} (the eval harness of Lecture 12)
|
||||
\item \textbf{Token economics} -- cost per \emph{request}, not per infrastructure
|
||||
\item \textbf{Fallibility} -- fault tolerance is read as guardrails, evaluator loops, and deterministic fallbacks behind ports
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.2cm}
|
||||
Consequence: the choice of topology can be compressed into the same style of decision aid the matrix provides -- next frame.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Choosing a topology from the task signature}
|
||||
\footnotesize Read top-down and \textbf{stop at the first matching row} -- the ordering encodes ``simplest structure first''.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\footnotesize
|
||||
\begin{tabular}{@{}p{4.6cm}p{3.2cm}p{4.8cm}@{}}
|
||||
\toprule
|
||||
\textbf{Task signature} & \textbf{Topology} & \textbf{Cost/risk note} \\
|
||||
\midrule
|
||||
Fixed decomposition; every intermediate result verifiable & Prompt chain (workflow) & cheapest and most testable; deterministic gates between stages \\
|
||||
Heterogeneous input categories with specialised handling & Routing & cheap; the router itself needs its own eval \\
|
||||
Broad, parallelisable subtasks; breadth-first search & Parallelisation or orchestrator--workers & token cost multiplies with worker count ($\sim$15$\times$ class) \\
|
||||
Output must clear a measurable quality bar & Evaluator--optimizer & latency and cost grow per iteration; needs a reliable evaluator \\
|
||||
Path genuinely unknown; open-ended tool use & Agent & highest cost and risk; guardrails, budgets, and oversight mandatory \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{projektbox}
|
||||
\footnotesize Your Axis-B ADR must justify your topology \emph{against this table}.
|
||||
\end{projektbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The economics of autonomy -- and the default rule}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item The rigour case for restraint, quantified by the best-documented production account (previewed in the Lecture-6 outlook): Anthropic's multi-agent research system -- an orchestrator--workers design -- beat a single agent by \textbf{90.2\,\%} at roughly \textbf{15$\times$ the tokens} of a chat interaction (simple agents $\sim$4$\times$); token use alone explains \textbf{80\,\%} of the variance
|
||||
\item A textbook \textbf{CBAM decision} in the sense of Part IV: autonomy is bought with cost, latency, and error accumulation -- justified only where the task's utility-response curve clears the price: broad, parallelisable research questions do; a form-filling workflow does not
|
||||
\item Regulation closes the loop from the other side: the AI Act's logging, documentation, human-oversight, and robustness duties attach to \emph{exactly the autonomy this section prices}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize \textbf{The default rule for agent architecture.} Workflows before agents; the simplest structure first; autonomy only on demonstrated need; every escalation an ADR with a measurement contract. \emph{An orchestration decision without a token budget and an eval threshold is an opinion -- Maxim 6 applies to agents without modification.}
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Agent orchestration -- capability-profile sketch}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\vspace{-0.35cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{2.9cm}cp{7.8cm}@{}}
|
||||
\toprule
|
||||
\textbf{Dimension} & \textbf{Rating} & \textbf{Ground} \\
|
||||
\midrule
|
||||
D1 Read scalability & $\circ$ & orchestration state small and replicable; throughput bounded by provider rate limits \\
|
||||
D2 Write scal.\ \& elasticity & $\circ$ & fan-out cheap in structure, expensive in tokens; sustained volume quota-bound \\
|
||||
D3 Latency \& predictability & $--$ & seconds per step, steps multiply along the loop; open-ended loops have no tail bound \\
|
||||
D4 Consistency \& integrity & $--$ & non-deterministic by construction; integrity exists only outside, in deterministic validation \\
|
||||
D5 Availability \& isolation & $-$ & every step adds provider failure modes and error accumulation; evaluator loops and fallbacks mitigate \\
|
||||
D6 Security \& auditability & $\circ$ & step and tool logging natural ($+$), legally required in high-risk uses; injection and excessive agency widen the surface ($-$) \\
|
||||
D7 Evolvability & $+$ & prompts, tools, models swap behind contracts; framework and model churn claws part back \\
|
||||
D8 Simplicity \& TTM & $-$ & a chain workflow is genuinely simple; every notch of autonomy is not \\
|
||||
D9 Testability \& deployability & $--$ & exhaustive testing impossible; evals with statistical thresholds replace assertions \\
|
||||
D10 Operating cost & $--$ & token cost per request orders of magnitude above classical calls; multi-agent $\sim$15$\times$ chat \\
|
||||
D11 Team scaling & $\circ$ & sub-agent and tool ownership parallelises teams moderately -- the PF filter-ownership analogy \\
|
||||
D12 AI integrability & $++$ & it \emph{is} the composition pattern for AI components -- trivially its own best host \\
|
||||
\midrule
|
||||
Status & \multicolumn{2}{l}{provisional profile (state 2025/26): default hypotheses; re-verified on every model generation} \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Agent orchestration -- reading the sketch}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Why only a \emph{sketch} -- three caveats:} no Richards--Ford star ratings; no decade of production case studies; every cell is a \textbf{default hypothesis} in the sense of the theory's own limits discussion -- to be replaced by measurement and \textbf{re-verified on every model generation}
|
||||
\item The cells read, as always, ``as the dominant structure of the subsystem it governs'' -- here the \textbf{AI subsystem}, not the whole platform
|
||||
\item \textbf{The reading:} the profile explains at a glance why agent orchestration can never be the dominant structure of a whole platform of class C1--C9 -- it is \textbf{vetoed by every High weight on D3, D4, D9, or D10} (stage 2 of the three-stage match, Lecture 7)
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize Agent orchestration is, and remains, an \textbf{edge pattern} -- hosted behind the ports of a deterministic core, exactly where the C10 recommendation places it.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Project link: Axis B is what you build -- and what you build it as}
|
||||
\begin{projektbox}
|
||||
\footnotesize Axis B is \emph{what} you build; the advisor workflow -- an orchestrator with two to three specialised sub-agents (document analyst, portfolio quant, compliance checker), all behind the LLM gateway -- is what you build it \emph{as}. The graded Axis-B deliverables are the \textbf{containment artefacts}:
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item[(i)] the \textbf{gateway} with model routing, fallback chain, and per-request \textbf{cost observability} -- cost per request, per feature, reported on a dashboard and enforced as a CI budget
|
||||
\item[(ii)] the \textbf{ontology guard} -- every extracted entity resolves against the deterministic data store, every cited passage exists, portfolio axioms hold
|
||||
\item[(iii)] the \textbf{eval harness} (Lecture 12 listing) wired as a \textbf{CI gate}
|
||||
\item[(iv)] one \textbf{ADR} that justifies your chosen orchestration topology against the task-signature table, with its \textbf{token budget and eval threshold} as the measurement contract
|
||||
\end{enumerate}
|
||||
\emph{Sub-agents propose; your deterministic services decide and book.}
|
||||
\end{projektbox}
|
||||
\end{frame}
|
||||
|
||||
\end{document}
|
||||
BIN
Folien/AISE502_Vorlesung_7_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_7_Folien.pdf
Normal file
Binary file not shown.
431
Folien/AISE502_Vorlesung_7_Folien.tex
Normal file
431
Folien/AISE502_Vorlesung_7_Folien.tex
Normal file
@ -0,0 +1,431 @@
|
||||
% !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.1cm}
|
||||
\begin{center}
|
||||
\resizebox{\textwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
box/.style={rectangle, draw, rounded corners=3pt, align=center, font=\small\sffamily, minimum height=0.75cm, inner sep=5pt},
|
||||
today/.style={box, fill=bankblue!20, draw=bankblue},
|
||||
later/.style={box, fill=gray!15, draw=gray!60!black, text=gray!60!black},
|
||||
node distance=0.2cm
|
||||
]
|
||||
\node[today] (a) {\S30 cases};
|
||||
\node[today, right=of a] (b) {\S31 procedure};
|
||||
\node[today, right=of b] (c) {\S32 matrix};
|
||||
\node[today, right=of c] (d) {\S34 reading};
|
||||
\node[today, right=of d] (e) {\S37 contract (intro)};
|
||||
\node[later, right=0.7cm of e] (f) {\S33 rationales};
|
||||
\node[later, right=of f] (g) {\S35 hybrids, evolution};
|
||||
\node[later, right=of g] (h) {\S36 eight steps};
|
||||
\node[later, right=0.7cm of h] (i) {\S37 in depth};
|
||||
\node[later, right=of i] (j) {\S38 organisation};
|
||||
\node[later, right=of j] (k) {\S39 limits};
|
||||
\node[font=\small\sffamily\bfseries, text=bankblue, above=0.1cm of c] {today};
|
||||
\node[font=\small\sffamily, text=gray!60!black, above=0.1cm of g] {Lecture 10};
|
||||
\node[font=\small\sffamily, text=gray!60!black, above=0.1cm of j] {Lecture 11};
|
||||
\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 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}
|
||||
\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}
|
||||
\item Monzo (deck 5): roughly 2{,}800 microservices in production banking -- under \textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation): a condition most organisations do not meet; the premium is paid in platform staffing with no gain for typical team sizes
|
||||
\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.48\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.48\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
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\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.1cm}
|
||||
\textbf{The verdict the class's Part III section states (Lecture 9): 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 tradeoff 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 downgrade one step; a \emph{ranking with exclusions}, never ``12\,\% better''; a flip under plausible weight variation marks a tradeoff 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{5.0cm}@{}}
|
||||
\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:}
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{C6}: it would have averaged the shape gate away under good scores elsewhere
|
||||
\item \textbf{C1}: it would have let MS's missing cross-service ACID be compensated by team scaling
|
||||
\item \textbf{C2}: it would have manufactured a decimal-point winner exactly where the honest output is a flagged tradeoff point
|
||||
\end{itemize}
|
||||
\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}
|
||||
|
||||
\end{document}
|
||||
BIN
Folien/AISE502_Vorlesung_8_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_8_Folien.pdf
Normal file
Binary file not shown.
408
Folien/AISE502_Vorlesung_8_Folien.tex
Normal file
408
Folien/AISE502_Vorlesung_8_Folien.tex
Normal file
@ -0,0 +1,408 @@
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% ============================================================================
|
||||
% AISE502 -- AI in Software Engineering II
|
||||
% Lecture 8 slides, typeset with the official FHGR beamer theme
|
||||
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
|
||||
% Slide content is unchanged; only the presentation layer is the FHGR template.
|
||||
% ============================================================================
|
||||
\documentclass[aspectratio=169]{beamer}
|
||||
|
||||
\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}
|
||||
|
||||
% ============================================
|
||||
% PACKAGES
|
||||
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
|
||||
% listings, hyperref, environ and xparse -- only the extras are needed here.
|
||||
% ============================================
|
||||
\usepackage[british]{babel}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amssymb}
|
||||
\usepackage{tcolorbox}
|
||||
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}
|
||||
|
||||
% ============================================
|
||||
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
|
||||
% The names used throughout the slides are kept, so no slide text changes;
|
||||
% they now resolve to the FHGR brand colours defined by the theme.
|
||||
% ============================================
|
||||
\colorlet{bankblue}{blue} % FHGR blue (4B92A4)
|
||||
\colorlet{bankgreen}{green} % FHGR green (817E65)
|
||||
\colorlet{bankred}{red} % FHGR red (C60219)
|
||||
\colorlet{codegray}{gray} % FHGR gray (595959)
|
||||
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
||||
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
||||
|
||||
% Attribution labels in English (theme default is German)
|
||||
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
|
||||
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}
|
||||
|
||||
% ============================================
|
||||
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
|
||||
% ============================================
|
||||
\newtcolorbox{keypoint}{
|
||||
colback=bankblue!7!white,
|
||||
colframe=bankblue,
|
||||
title=Key Concept,
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{examplebox}[1][]{
|
||||
colback=bankgreen!10!white,
|
||||
colframe=bankgreen,
|
||||
title={Example: #1},
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{definitionbox}[1][]{
|
||||
colback=linen!40!white,
|
||||
colframe=camel!85!black,
|
||||
title={Definition: #1},
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{thinkbox}{
|
||||
colback=lightGray!35!white,
|
||||
colframe=darkGray,
|
||||
title=Discussion,
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{hinweisbox}{
|
||||
colback=bankred!5!white,
|
||||
colframe=bankred,
|
||||
title=Important Note,
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{ailinse}[1][]{
|
||||
colback=aiviolet!7!white,
|
||||
colframe=aiviolet,
|
||||
title={AI Lens: #1},
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
\newtcolorbox{projektbox}{
|
||||
colback=bankblue!4!white,
|
||||
colframe=bankblue!70!black,
|
||||
title=Project Link: Portfolio Intelligence Platform,
|
||||
fonttitle=\bfseries\small,
|
||||
boxrule=0.8pt,
|
||||
arc=2pt,
|
||||
top=2pt, bottom=2pt, left=4pt, right=4pt
|
||||
}
|
||||
|
||||
% ============================================
|
||||
% TITLE METADATA
|
||||
% ============================================
|
||||
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
|
||||
\subtitle{Lecture 8: Requirements Profiles I -- Application Classes C1--C5\\[0.4ex]{\small Script: Part III, Sections 18--23}}
|
||||
\author{Dr.\ Florian Herzog}
|
||||
\shortname{AISE502}
|
||||
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
||||
|
||||
\begin{document}
|
||||
|
||||
% ============================================
|
||||
% TITLE SLIDE
|
||||
% ============================================
|
||||
\FHGRTitlePage
|
||||
|
||||
% ============================================
|
||||
% AGENDA
|
||||
% ============================================
|
||||
\begin{frame}{Agenda}
|
||||
\small
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item Application classes as requirements profiles -- method recall (weights, shape, constraints); the map of ten classes
|
||||
\item \textbf{C1} -- Core banking / transaction systems: the double impossibility
|
||||
\item \textbf{C2} -- Social media / content platforms: 50:1 and the fan-out
|
||||
\item \textbf{C3} -- Back-office / workflow: the modal, unglamorous case
|
||||
\item \textbf{C4} -- ERP / enterprise core: integration \emph{is} the product
|
||||
\item \textbf{C5} -- E-commerce: quality attributes with price tags
|
||||
\item Five classes side by side -- five verdicts as previews for Part IV
|
||||
\item This week's exercise: \textbf{the walking skeleton} (M3)
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% RECAP
|
||||
% ============================================
|
||||
\section{Recap}
|
||||
|
||||
\begin{frame}{Recap: where we are}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Lecture 6 closed Part II}: the consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis
|
||||
\item \textbf{Lecture 6 opened Part III with C10}: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal MM $+$ PF $+$ EDA) -- and the C1/C2 mirror pair in one frame: \emph{weights, not dimensions, define a class}
|
||||
\item \textbf{Lecture 7 (Part IV)}: three cases, three stages; the procedure in general; reading the $7 \times 10$ matrix; the measurement contract introduced -- A2 dossier and design-review gate passed: \emph{implementation is free}
|
||||
\item \textbf{Method recall (Lectures 2--3)}: $R(a) = (w_1 \ldots w_{12};\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves of the utility tree; shape gates; constraints knock out; every High is a veto trigger with the cap rule of the three-stage procedure
|
||||
\item \textbf{Today}: the demand side in its full class rhythm for C1--C5 -- \emph{challenges $\to$ binding scenarios $\to$ profile $\to$ what real systems chose}; each closing verdict is a preview that Part IV recomputes
|
||||
\item \textbf{Project}: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9)
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% APPLICATION CLASSES AS REQUIREMENTS PROFILES
|
||||
% ============================================
|
||||
\section{Application Classes as Requirements Profiles}
|
||||
|
||||
\begin{frame}{Part III: the demand side, in the same vocabulary}
|
||||
\small\emph{\textcolor{bankblue}{Part II priced the supply side: seven patterns, each a capability profile $C(p)$ over the twelve dimensions. Part III characterises the demand side -- and A2 and A3 require it in the \textbf{same} vocabulary at the \textbf{same} resolution.}}
|
||||
|
||||
\vspace{0.02cm}
|
||||
\footnotesize ``We are building a banking system'' carries almost no architectural information; ``an instant payment must reach confirmed finality in under ten seconds end-to-end, with zero transaction loss, under a regulator-enforced audit obligation'' carries almost all of it. The unit that packages such statements is the \textbf{application class}.
|
||||
|
||||
\vspace{0.02cm}
|
||||
\begin{definitionbox}[Application class]
|
||||
\footnotesize A recurring bundle of architecturally significant requirements (ASRs): a set of dominant quality attribute scenarios with \emph{typical response measures}, a characteristic \emph{workload shape} with its quantitative signature, and a \emph{regulatory frame} acting as hard constraints. Formally, $R(a) = \bigl(w_1(a), \ldots, w_{12}(a);\; S(a);\; K(a)\bigr)$ with $w_i(a) \in \{\text{H}, \text{M}, \text{L}\}$, $S(a)$ the dominant workload shape and $K(a)$ the set of hard constraints.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{-0.05cm}
|
||||
\begin{center}
|
||||
\begin{tikzpicture}[
|
||||
rstep/.style={rectangle, draw, rounded corners=4pt, align=center, font=\scriptsize\sffamily, line width=0.8pt, fill=bankblue!20, draw=bankblue, minimum height=0.5cm, minimum width=2.7cm},
|
||||
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
||||
]
|
||||
\node[rstep] (q) at (0,0) {leading question};
|
||||
\node[rstep] (c) at (3.3,0) {the challenges it brings};
|
||||
\node[rstep] (p) at (6.6,0) {the requirements profile};
|
||||
\node[rstep] (r) at (9.9,0) {what real systems chose\\-- and why};
|
||||
\draw[arr] (q) -- (c); \draw[arr] (c) -- (p); \draw[arr] (p) -- (r);
|
||||
\end{tikzpicture}
|
||||
\end{center}
|
||||
\vspace{-0.2cm}
|
||||
\footnotesize Ten sections, one rhythm -- Part II turned around: challenges first, weights after, structures last; every closing recommendation is a \emph{preview} that Part IV recomputes.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Method recall: where the weights come from (Lectures 2--3)}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textcolor{codegray}{(Lecture 2)} A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are \emph{elicited}, not guessed (QAW, ATAM utility tree), each leaf rated (business importance, achievement difficulty) on \{H, M, L\}
|
||||
\item \textcolor{codegray}{(Lecture 2)} \textbf{The (H,\,H) leaves of a class's characteristic utility tree \emph{are} the High weights of $R(a)$}
|
||||
\item \textbf{New in Part III}: a weight is a \textbf{compressed empirical claim} -- ``systems of this class recurrently produce (H,\,H) scenario leaves on this dimension'' -- and each class section makes it \textbf{auditable}: documented challenges (incidents, production numbers, statutory obligations) $\to$ two to three \emph{binding scenarios} with response measures, populating the (H,\,H) region
|
||||
\item \textcolor{codegray}{(Lecture 3)} \textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps it at $\circ$, unless a documented mitigation with production evidence exists; \textbf{M} -- measured, conflicts noted not vetoed, clustered Medium conflicts downgrade one step; \textbf{L} -- does not discriminate for this class; optimising it is waste
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{hinweisbox}
|
||||
\footnotesize There is no weighted sum: profiles are ordinal, the aggregation non-compensatory. \textbf{An H weight is a veto trigger, not a coefficient.} Ten excellent Medium ratings cannot buy back one violated High.
|
||||
\end{hinweisbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Workload shape and hard constraints}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{0pt}
|
||||
\item \textcolor{codegray}{(recall, Lecture 2)} $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core. Every shape has a quantitative signature with production numbers -- \emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}
|
||||
\item \textcolor{codegray}{(recall, Lecture 2)} $K(a)$ -- \textbf{knock-out filters, not weights}: a violating pattern or deployment form is excluded before any scoring and can never be averaged away
|
||||
\item The regulatory inventory of this catalogue: BCBS~239, FINMA Circular 2023/1, DORA, PCI~DSS v4.0, the EU AI Act -- plus organisational facts (team size and skills, mandated platforms, budget)
|
||||
\item Regulation is a first-class architectural requirement that \textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.03cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize An application class is an ASR bundle, not an industry label -- weights from the (H,\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting and increasingly a C10 advisory layer -- so the fit matrix is read \textbf{per subsystem, never per company logo}: your project's inheritance diagram (Lecture 6: C10 inherits C6/C7/C3) is exactly that reading.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{A map of the ten classes}
|
||||
\begin{center}
|
||||
\resizebox{!}{4.75cm}{%
|
||||
\begin{tikzpicture}[
|
||||
x=1cm, y=1cm,
|
||||
classnode/.style={rectangle, draw, rounded corners=3pt, minimum width=2.1cm, minimum height=0.72cm, align=center, font=\small\sffamily, line width=0.6pt},
|
||||
inter/.style={classnode, fill=bankblue!15, draw=bankblue},
|
||||
stream/.style={classnode, fill=bankgreen!15, draw=bankgreen},
|
||||
batchn/.style={classnode, fill=gray!15, draw=gray!60!black},
|
||||
hybridn/.style={classnode, fill=bankblue!70!black!15, draw=bankblue!70!black, font=\small\sffamily\bfseries},
|
||||
today/.style={line width=1.6pt},
|
||||
bandlabel/.style={font=\small\sffamily\bfseries, anchor=west, text=gray!50!black},
|
||||
axislabel/.style={font=\small\sffamily, text=gray!50!black}
|
||||
]
|
||||
% --- workload-shape bands ---
|
||||
\fill[gray!6] (0,3.75) rectangle (16.4,6.1);
|
||||
\fill[gray!12] (0,2.55) rectangle (16.4,3.75);
|
||||
\fill[gray!6] (0,1.35) rectangle (16.4,2.55);
|
||||
\fill[gray!12] (0,0.15) rectangle (16.4,1.35);
|
||||
\node[bandlabel] at (0.15,5.85) {interactive request/response};
|
||||
\node[bandlabel] at (0.15,3.5) {continuous stream};
|
||||
\node[bandlabel] at (0.15,2.3) {scheduled batch};
|
||||
\node[bandlabel] at (0.15,1.1) {hybrid: interactive + batch/async};
|
||||
% --- consistency axis ---
|
||||
\draw[-{Stealth[length=2.5mm]}, thick, gray!60!black] (0,0) -- (16.4,0);
|
||||
\foreach \x in {2.0,6.9,11.3,15.0} \draw[gray!60!black, thick] (\x,0) -- (\x,0.12);
|
||||
\node[axislabel, anchor=north] at (2.0,-0.08) {strict ACID};
|
||||
\node[axislabel, anchor=north] at (6.9,-0.08) {hybrid (split by subsystem)};
|
||||
\node[axislabel, anchor=north] at (11.3,-0.08) {causal / per-key / by contract};
|
||||
\node[axislabel, anchor=north] at (15.0,-0.08) {eventual};
|
||||
\node[axislabel, anchor=north] at (8.2,-0.62) {consistency semantics required by the class core (guarantee weakens $\rightarrow$)};
|
||||
% --- interactive band ---
|
||||
\node[inter, today] at (2.0,5.15) {C1 core banking\\ \tiny ACID ledger};
|
||||
\node[inter, today] at (2.0,4.2) {C4 ERP\\ \tiny + batch runs};
|
||||
\node[inter, today] at (4.7,5.15) {C3 back-office};
|
||||
\node[inter, today] at (6.9,4.2) {C5 e-commerce\\ \tiny checkout ACID, catalogue eventual};
|
||||
\node[inter] at (11.3,5.15) {C9 collab/messaging\\ \tiny connection-stateful, causal per channel};
|
||||
\node[inter, today] at (14.7,4.2) {C2 social/content\\ \tiny stale feed acceptable};
|
||||
% --- stream band ---
|
||||
\node[stream] at (13.0,3.15) {C8 IoT streaming\\ \tiny event time, exactly-once state};
|
||||
% --- batch band ---
|
||||
\node[batchn] at (8.9,1.95) {C6 simulation/batch\\ \tiny reproducible (seeds)};
|
||||
\node[batchn] at (12.4,1.95) {C7 DSS/BI\\ \tiny fresh by refresh contract};
|
||||
% --- hybrid band ---
|
||||
\node[hybridn] at (6.9,0.75) {C10 AI-native advisory\\ \tiny index eventual, audit path ACID};
|
||||
\end{tikzpicture}}%
|
||||
\end{center}
|
||||
|
||||
\vspace{-0.1cm}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item C1 and C2 at opposite ends of the consistency axis within the same band -- the didactic \textbf{mirror pair}; C10 the only class whose \emph{shape} is constitutively hybrid
|
||||
\item Today's five (thick frames) all sit in the interactive band -- read them along the axis: C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Discussion: classification is a hypothesis -- test it on three systems}
|
||||
\begin{hinweisbox}
|
||||
\footnotesize Classifying a concrete system as an instance of a class is step~(i) of the decision procedure -- a \emph{hypothesis about the system's ASR bundle}, to be inherited and then corrected against elicited scenarios, never a verdict. Real systems blend classes; \textbf{the blend, not the label}, is what the utility tree must capture.
|
||||
\end{hinweisbox}
|
||||
|
||||
\vspace{0.25cm}
|
||||
\begin{thinkbox}
|
||||
\small Take three software systems you have used this week -- your e-banking app, a messaging tool, a streaming service.
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item Which application classes do they instantiate?
|
||||
\item Which single quality attribute scenario, with which response measure, would you nominate as each system's most binding requirement?
|
||||
\item Where would a failure of that scenario become visible first: in revenue, in a regulator's report, or in user churn?
|
||||
\end{itemize}
|
||||
\end{thinkbox}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% C1 -- CORE BANKING
|
||||
% ============================================
|
||||
\section{C1 -- Core Banking}
|
||||
|
||||
\begin{frame}{Part III in the class rhythm: C1 -- Core banking / transaction systems}
|
||||
\emph{\textcolor{bankblue}{A payment is booked twice, or not at all: which of the two can a bank survive?}}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\small Neither -- and that double impossibility is the class in one sentence.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Systems of record for accounts, payments and positions: the booking core of a bank, a payment-clearing platform, an exchange's matching and settlement layer -- the machinery behind your e-banking balance, the card authorisation at the till, the salary on the 25th
|
||||
\item Defining property: a lost or double-posted booking event is an \textbf{existential} defect -- it creates or destroys money -- whereas unavailability is expensive but reversible
|
||||
\item Double-entry bookkeeping demands atomic, serialisable transactions over the ledger: classical ACID territory. Auditability is a regulator-enforced obligation: every state change journaled and reconstructable -- which is why event-sourced journals and ledger data models fit naturally
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize \textbf{Three challenges define the class:}
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item \textbf{The sums at stake} (D4, D6)
|
||||
\item \textbf{A speed spread of six orders of magnitude} within one class (D3, D2, D5)
|
||||
\item \textbf{Time} -- lifetimes measured in decades (D7)
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C1 -- the challenges in numbers}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{0pt}
|
||||
\item \textbf{Sums.} Swiss Interbank Clearing settles on average roughly CHF~226 billion per day, peaks above CHF~386 billion -- a double-posted or lost booking is a balance-sheet event: D4 and D6 first. Every payment is a write surrounded by reads (cover checks, sanctions screening, fraud scoring): \emph{write-critical} -- but the \emph{concurrency} of writes against shared accounts, not their raw rate, stresses D4
|
||||
\item \textbf{Speed spread.} Batch clearing hours; instant payments under 10\,s; card authorisation 1--2\,s; exchange trading microseconds -- latency means something different in each regime, hence D3 \textbf{Medium with a footnote}, not High
|
||||
\item SIC5 instant-payment infrastructure: dimensioned for peaks in the order of 2{,}000 payments/s (clustered in-memory replicated state machine). VisaNet: \emph{capacity} above 65{,}000 transaction messages/s, average load orders of magnitude below -- capacity dimensioning vs.\ normal load: D2 is \emph{planned, not elastic}
|
||||
\item Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability a loss event on national infrastructure, with regulator-defined disruption tolerances -- D5
|
||||
\item \textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\,\% of US banking systems COBOL-based -- ossification is the documented failure mode: D7 a High \emph{requirement} precisely because it is so often unmet. Change rate bimodal: booking core rarely, periphery (channels, onboarding, products) constantly. Data structured, records small, retention extreme -- ten years and more
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C1 -- the binding scenarios and the knock-outs}
|
||||
\footnotesize
|
||||
Three scenarios compress these challenges into the (H,\,H) region of the C1 utility tree -- \textbf{Assumption A4 in action}; every High in the next table traces to one of them.
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{S1 (instant payment finality).} A customer submits an instant payment in normal operation to the payment core; it clears, settles and posts with confirmed finality \textbf{in under 10 seconds end-to-end, with zero transaction loss} -- the SIC5 operating regime. \textcolor{codegray}{(D3, D4, D5.)}
|
||||
\item \textbf{S2 (ledger integrity under concurrency).} Concurrent postings against the same account at peak load leave the double-entry invariant intact: \textbf{zero invariant violations, verified by a daily reconciliation job with zero unexplained discrepancies}. The D4 veto scenario -- and, through the reconciliation job, D9.
|
||||
\item \textbf{S3 (audit-trail reconstruction).} An auditor requests the complete causal history of one transaction chosen at random, up to ten years back; the full trail is reproduced \textbf{within one working day, from immutable records} -- BCBS~239's aggregation and reporting principles read operationally. \textcolor{codegray}{(D6, D9.)}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
$K(\text{C1})$ -- \textbf{the densest constraint set in the catalogue:} BCBS~239 (risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1~January 2024: ICT risk, protection of \emph{critical data}, business continuity with disruption tolerances); DORA (EU 2022/2554, applicable 17~January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR throughout.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\textbf{Knock-out reading:} any structure that cannot guarantee an ACID booking core, an immutable and complete audit journal, and ten-plus-year retention is eliminated \emph{before} any fit scoring -- however well it scales.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C1 -- requirements profile (column C1)}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\vspace{-0.35cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{3.0cm}cp{7.7cm}@{}}
|
||||
\toprule
|
||||
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
||||
\midrule
|
||||
D1 Read scalability & M & reads surround every posting; volumes modest \\
|
||||
D2 Write scal.\ \& elasticity & M & constant load, deterministic peaks; capacity planned, not elastic \\
|
||||
D3 Latency & M & spread of orders of magnitude: microseconds to hours \\
|
||||
D4 Consistency \& integrity & \textbf{H} & a lost or double-posted booking creates or destroys money \\
|
||||
D5 Availability \& isolation & \textbf{H} & payment rails are national infrastructure; outages are loss events \\
|
||||
D6 Security \& auditability & \textbf{H} & the immutable audit journal is a statutory obligation \\
|
||||
D7 Evolvability & \textbf{H} & decades-long lifetimes; ossification is the failure mode \\
|
||||
D8 Simplicity \& TTM & L & time-to-market traded for integrity without hesitation \\
|
||||
D9 Testability \& deployability & \textbf{H} & reconciliation and trail reconstruction verifiable by construction \\
|
||||
D10 Operating cost & L & run cost traded for integrity as willingly as D8 \\
|
||||
D11 Team scaling & M & binds only at neobank organisational scale -- the Monzo condition \\
|
||||
D12 AI integrability & M & fraud scoring at the edge; the booking path stays deterministic \\
|
||||
\midrule
|
||||
Shape $S(a)$ & \multicolumn{2}{l}{interactive ($+$ batch edges)} \\
|
||||
Constraints $K(a)$ & \multicolumn{2}{l}{BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention} \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C1 -- what real systems chose, and why}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item \textbf{LMAX} (retail trading): six million orders/s on a \emph{single} JVM thread -- in-memory, event-sourced, deterministic sequential core with lock-free ring buffers. Serialisable \emph{by construction}, the strongest answer to the D4 veto; journal replay answers D6 and D9 at once; surrenders elastic write scaling (D2), weighted only Medium
|
||||
\item \textbf{Monzo} (UK digital bank): ca.\ 2{,}800 Go microservices (ca.\ 1{,}600 in 2020), viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, where the MS column excels; the $--$ on simplicity and cost paid deliberately; the D4 risk of sagas in the money path mitigated by homogeneity and central tooling
|
||||
\item \textbf{Apache Fineract} (the 34-module single deployable of week 4), read from the demand side: a modular monolith behind a REST facade -- one ACID quantum serves the D4 veto, domain modules absorb the peripheral change rate (D7), the weak cell ($-$ on D5: one process as blast radius) mitigated by hot-standby replication; a standing counter-example to ``banking at scale implies microservices''
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.02cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize Two documented production systems, one profile -- $R(a)$ alone does not force one pattern: it defines the feasible set, and constraints decide within it. C1's veto dimensions D4/D5/D6/D7/D9 eliminate structures that cannot carry an ACID, journaled, decades-lived core -- they do \emph{not} rank the survivors. The LMAX/Monzo pair is evidence \textbf{for} the theory, not against it.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C1 -- AI lens and the verdict}
|
||||
\begin{ailinse}[Fraud scoring at the edge of the ledger (Axis B)]
|
||||
\footnotesize AI enters C1 at the periphery, never in the booking path: fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \emph{before} a posting is committed; increasingly LLM-based components for case triage and customer communication. D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \textbf{The rule ``agents propose, deterministic services decide and book'' originates in this class.}
|
||||
\end{ailinse}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize Where the winning structures' weak cells bite, practice \emph{places} patterns rather than replacing them: the immutable event journal -- EDA's natural artefact -- serves as the regulatory audit trail at the core's edges; end-of-day clearing, statements and risk runs are genuine PF batch runs beside the interactive core.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\footnotesize \textbf{Verdict (preview):} primary -- a hexagonal modular monolith for the booking core (MM and HX at $++$); secondary -- EDA at the edges, PF for the batch runs; microservices only when organisation size forces D11 to High, the Monzo condition. Part IV computes this through the three-stage procedure.
|
||||
\end{frame}
|
||||
|
||||
\end{document}
|
||||
BIN
Folien/AISE502_Vorlesung_9_Folien.pdf
Normal file
BIN
Folien/AISE502_Vorlesung_9_Folien.pdf
Normal file
Binary file not shown.
486
Folien/AISE502_Vorlesung_9_Folien.tex
Normal file
486
Folien/AISE502_Vorlesung_9_Folien.tex
Normal file
@ -0,0 +1,486 @@
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% ============================================================================
|
||||
% AISE502 -- AI in Software Engineering II
|
||||
% Lecture 9 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 9: Classes C6--C9 -- and Ten Profiles Side by Side\\[0.4ex]{\small Script: Part III, Sections 24--27, 29}}
|
||||
\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: C1--C5 and the class rhythm
|
||||
\item \textbf{C6} -- Scientific simulation / batch compute: the third consistency semantics
|
||||
\item \textbf{C7} -- Decision support / BI analytics: the refresh contract
|
||||
\item Closing the loop: C6 and C7 inside your C10 project
|
||||
\item \textbf{C8} -- Real-time / IoT streaming: correctness under failure
|
||||
\item \textbf{C9} -- Collaboration / messaging: connection fan-out and push
|
||||
\item Stepping back: \textbf{ten profiles side by side} -- the consolidated table and its seventeen footnotes
|
||||
\item Reading the catalogue as a whole: five cross-class observations
|
||||
\item This week's exercise: \textbf{the walking skeleton runs end-to-end}
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% RECAP
|
||||
% ============================================
|
||||
\section{Recap}
|
||||
|
||||
\begin{frame}{Recap: where we are}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Framework position:} Part III $=$ the demand side -- $R(a)$: weights $w_i(a)$ over D1--D12, workload shape $S(a)$, hard constraints $K(a)$; Part II gave $C(p)$; Part IV matches them (the three-stage non-compensatory match, Lectures 3 and 7)
|
||||
\item \textbf{Last week (C1--C5):} an application class \emph{is} a requirements profile -- a recurring ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame; the rhythm: leading question $\to$ challenges $\to$ S1--S3 $\to$ 12-row profile $\to$ what real systems chose
|
||||
\item \textbf{Last week (C1--C5):} C1 (ACID ledger) and C2 ($\sim 50{:}1$ read-heavy, deliberately eventual) as the mirror pair; C3 back-office; C4 ERP; C5 e-commerce, the only class \emph{defined} by a hybrid consistency profile
|
||||
\item \textbf{Week 6 (C10):} Highs on D6/D7/D9/D10/D12; \emph{inherits} C6/C7/C3; spend the design budget on the two novelties (cost per request, evals as testability)
|
||||
\item \textbf{The map of the ten classes:} two axes -- workload shape and consistency semantics; C6 and C7 sit at semantics that are neither ACID nor eventual -- today we develop that third family
|
||||
\item \textbf{Today:} C6--C9 in the same rhythm; then ten profiles side by side -- the consolidated table, its seventeen footnotes, five cross-class observations
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% C6
|
||||
% ============================================
|
||||
\section{C6 -- Scientific Simulation / Batch Compute}
|
||||
|
||||
\begin{frame}{Part III continues: C6 -- scientific simulation / batch compute}
|
||||
\emph{\textcolor{bankblue}{The nightly risk run must reproduce, to the bit, on ten thousand cores by 06:00: what does that demand?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize The class: \textbf{compute-dominated batch systems} -- the cost function is CPU/GPU-hours; availability in the online sense is irrelevant (\emph{an aborted job is restarted from a checkpoint, not mourned}); correctness means \textbf{reproducibility}: regenerable from versioned inputs, versioned code and deterministic seeds.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\textbf{Three challenges define the class:}
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item \textbf{The interactive vocabulary does not apply} -- no read/write ratio, only read-input $\to$ compute $\to$ write-output over immutable datasets; the response measures are \textbf{makespan} (hours to weeks) and \textbf{batch-window adherence}: D2 High in its makespan reading (note 2), D3 Low (note 4); planned, queue-based load at a utilisation target near 100\,\%
|
||||
\item \textbf{The reproducibility obligation} -- bit-identical reruns from versioned inputs, code and seeds: a scientific duty and, for regulated risk models, a supervisory one $\to$ D9 in its reproducibility reading (note 14), D4 ``as of this run'' (note 8)
|
||||
\item \textbf{Physics: scaling has a measurable ceiling} -- OpenFOAM domain decomposition pays down to roughly 50{,}000--200{,}000 cells per core, below which communication overhead dominates (Amdahl's law as an architecture boundary); Monte-Carlo is embarrassingly parallel -- the ideal pipeline case
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C6 -- the binding scenarios}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{S1 (batch-window adherence).} The overnight risk run starts after close of business; the full portfolio revaluation completes \textbf{within the batch window, results published before start of trading}. \textcolor{codegray}{(The D2 scenario in its makespan reading.)}
|
||||
\item \textbf{S2 (bit-level reproducibility).} A model validator re-executes a historical run months later; the pipeline regenerates the results \textbf{bit-identically from versioned inputs, code and seeds}. \textcolor{codegray}{(The D9/D4 scenario.)}
|
||||
\item \textbf{S3 (cost efficiency).} The quarterly compute bill is reviewed; cost per simulation and cluster utilisation stay \textbf{within budget at a utilisation target near 100\,\%} -- queue-based scheduling exists to meet exactly this measure. \textcolor{codegray}{(The D10 scenario.)}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
$K(\text{C6})$ in financial applications: internal models are subject to \textbf{model validation and backtesting} under the Basel framework; the traceability of model runs is audit-relevant -- the BCBS~239 lineage obligation extends into the simulation stack.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{Knock-out reading:} any structure that cannot pin \emph{data version $+$ code version $+$ seed} per run is excluded for regulated risk computation, whatever its throughput. \textbf{Deterministic seeds are a hard constraint, not a nicety.}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{The third consistency semantics: reproducibility and refresh contracts}
|
||||
\small Beside \textbf{ACID} (``concurrent operations preserve invariants'') and \textbf{eventual consistency} (``replicas converge, staleness is bounded''), the batch world defines a \emph{third family} of consistency semantics.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{definitionbox}[The third consistency semantics: reproducibility and refresh contracts]
|
||||
\footnotesize \textbf{Reproducibility (C6):} immutable inputs and idempotent, seeded stages guarantee that a rerun yields the identical result -- consistency ``\textbf{as of this run}''.
|
||||
|
||||
\textbf{Freshness by refresh contract (C7):} consumers see a complete, internally consistent state ``\textbf{as of the last refresh}'' (e.g.\ yesterday 24:00), never a half-updated one.
|
||||
|
||||
Both are \emph{weaker} than ACID and \emph{stronger} than unqualified eventual consistency -- and both are \textbf{contracts with response measures}, testable in CI like any other scenario.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize \textbf{Supply side, already seen:} the PF column's D4 $= +$ (week 6: ``the subtlest cell in the table''). \textbf{Demand side, today:} footnotes 8 (C6) and 10 (C7) of the consolidated table.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C6 -- requirements profile (column C6)}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\vspace{-0.35cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{3.0cm}cp{7.7cm}@{}}
|
||||
\toprule
|
||||
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
||||
\midrule
|
||||
D1 Read scalability & L & no interactive readers; outputs are files and tables \\
|
||||
D2 Write scal.\ \& elasticity & \textbf{H} & throughput as makespan and batch-window compute bursts (S1; note 2) \\
|
||||
D3 Latency & L & per-request latency is meaningless; the window is the measure (note 4) \\
|
||||
D4 Consistency \& integrity & M & consistency ``as of this run'': bit-level reproducibility from versioned inputs and seeds (note 8) \\
|
||||
D5 Availability \& isolation & L & an aborted job is restarted from a checkpoint, not mourned \\
|
||||
D6 Security \& auditability & M & lineage of regulated model runs is audit-relevant; no online attack surface \\
|
||||
D7 Evolvability & M & model code churns research-driven; numeric kernels live 30+ years \\
|
||||
D8 Simplicity \& TTM & M & orchestration should stay simple; the kernels never are \\
|
||||
D9 Testability \& deployability & \textbf{H} & reproducibility is the operative meaning of testability (S2; note 14) \\
|
||||
D10 Operating cost & \textbf{H} & the cost function \emph{is} CPU/GPU-hours at near-100\,\% utilisation (S3) \\
|
||||
D11 Team scaling & L & small research and engineering teams \\
|
||||
D12 AI integrability & M & training and simulation pipelines host ML natively, at batch cadence \\
|
||||
\midrule
|
||||
Shape $S(a)$ & \multicolumn{2}{l}{scheduled batch} \\
|
||||
Constraints $K(a)$ & \multicolumn{2}{l}{model validation and backtesting (finance); deterministic seeds} \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C6 -- what real systems chose, and why}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Dominant form: pipes-and-filters on HPC or batch infrastructure} -- the PF column reads like a transcript of this class's Highs: immutable inputs $+$ deterministic, idempotent stages give reproducibility (D9) \emph{by construction}; batch scheduling drives utilisation towards the D10 target; the shape matches the gate that eliminates every interactive pattern outright
|
||||
\item \textbf{OpenFOAM}: domain decomposition via graph partitioning, MPI communication, scheduled by \textbf{Slurm} as batch resource manager; \textbf{OpenMC}: a modern parallel Monte-Carlo transport code of the same family; \textbf{Spark} (data-parallel) and \textbf{Airflow} (DAG orchestration) as the cloud-native incarnations, Dask/Ray Python-native
|
||||
\item \textbf{Where the trade-off bites (A2): data affinity} -- distributing a tightly coupled numeric dataflow across expensive boundaries multiplies communication cost
|
||||
\item \textbf{Prime Video} (already met; now read from the demand side) as this class's cautionary tale in miniature: a tightly coupled processing flow distributed across orchestrator transitions and S3 round-trips per frame, until consolidation into one process cut cost by over 90\,\% -- \emph{when inter-stage communication dominates, consolidate, do not distribute}
|
||||
\item \textbf{Serverless fan-out earns only a conditional role}: embarrassingly parallel, communication-light bursts (Monte-Carlo) fit FaaS elasticity; data-heavy stages recreate the Prime Video cost trap
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C6 -- key concept}
|
||||
\begin{keypoint}
|
||||
\footnotesize C6 replaces the interactive vocabulary wholesale: the response measures are \textbf{makespan, batch-window adherence and cost per simulation}; correctness means \textbf{bit-level reproducibility} from versioned inputs and seeds; consistency means ``as of this run''. A structure fits this class exactly to the degree that it makes these three \emph{measurable by construction} -- which is why immutable-input pipelines dominate it.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{In one sentence:} pipes-and-filters on HPC/batch infrastructure (PF at $++$), serverless fan-out secondary for bursty, communication-light parallel sections -- Part IV computes the verdict through the three-stage procedure.
|
||||
\end{keypoint}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\small \textbf{Project link:} the ingestion pipeline and the eval pipeline of your platform are C6-shaped subsystems -- \emph{the loop closes after C7}.
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% C7
|
||||
% ============================================
|
||||
\section{C7 -- Decision Support / BI Analytics}
|
||||
|
||||
\begin{frame}{C7 -- decision support / BI analytics}
|
||||
\emph{\textcolor{bankblue}{Monday, 08:00: the management dashboard must be complete as of yesterday 24:00 -- and every number must prove where it came from. What delivers that, night after night?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize The class: data warehouses, BI platforms, reporting systems -- an \textbf{integration product over C1--C5}: it owns almost no data of its own but integrates everyone else's, so data quality, lineage and governance are first-class; its consistency semantics is the \textbf{refresh contract} (the definition just given): ``consistent as of yesterday 24:00'' is a deliberate design choice, not a deficiency.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\textbf{Three challenges define the class:}
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item \textbf{The shape of the reads} -- almost pure read, but \textbf{heavy OLAP scans by few users}, not point reads by many (note 7): a D1 demand in its own reading, scan capacity \emph{delegated} to the warehouse engine; writes bundled into the ELT/ETL window (D2 Low); dashboards render in seconds (D3 Medium)
|
||||
\item \textbf{The refresh contract} -- marts refreshed within the window and visible \emph{atomically}; consumers never see a half-updated state (D4 Medium, note 10); adherence tracked as a fitness function (D9)
|
||||
\item \textbf{Provenance under interrogation} -- a regulator questions a reported risk figure: trace it back through every transformation to the source systems (D6); BCBS~239 hardens this into $K(a)$ where banking data are involved
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C7 -- the binding scenarios}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{S1 (dashboard latency).} A controller opens the standard management dashboard on Monday morning; it renders \textbf{in under 5 seconds}, ad-hoc analytical queries in seconds to minutes. \textcolor{codegray}{(The D1/D3 scenario in the class's OLAP reading.)}
|
||||
\item \textbf{S2 (refresh contract).} The nightly ELT run executes; all marts are refreshed \textbf{within the refresh window, atomically visible, refresh-window adherence tracked as a fitness function}. \textcolor{codegray}{(The D4/D9 scenario.)}
|
||||
\item \textbf{S3 (lineage on demand).} A regulator or auditor questions a reported risk figure; the platform traces it \textbf{back through every transformation to the source systems, on demand}. \textcolor{codegray}{(The D6 scenario, hardened into $K(a)$ for banks.)}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
$K(\text{C7})$: BCBS~239 for banks (risk reporting: accuracy, completeness, timeliness, demonstrable lineage); the GDPR (purpose limitation, anonymisation in analyses); sector-specific reporting duties.
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{Knock-out reading:} a pipeline whose transformations are not versioned and traceable cannot serve regulated reporting -- \emph{lineage is a structural property; retrofitting it is a rebuild}.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C7 -- requirements profile (column C7)}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\vspace{-0.35cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{3.0cm}cp{7.7cm}@{}}
|
||||
\toprule
|
||||
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
||||
\midrule
|
||||
D1 Read scalability & \textbf{H} & heavy OLAP scans by few users, delegated to the warehouse engine (S1; note 7) \\
|
||||
D2 Write scal.\ \& elasticity & L & writes are bundled into the nightly ELT window \\
|
||||
D3 Latency & M & dashboards in under 5\,s; ad-hoc queries in seconds to minutes \\
|
||||
D4 Consistency \& integrity & M & freshness by refresh contract -- ``consistent as of yesterday 24:00'' (S2; note 10) \\
|
||||
D5 Availability \& isolation & L & a dashboard down for an hour is an annoyance, not a loss event \\
|
||||
D6 Security \& auditability & M & lineage and purpose limitation; BCBS~239 hardens them into $K(a)$ where banking data flow (S3) \\
|
||||
D7 Evolvability & M & report-level churn is high; the core dimensional model moves slowly \\
|
||||
D8 Simplicity \& TTM & M & thin serving keeps the estate simple; the pipeline carries the complexity \\
|
||||
D9 Testability \& deployability & M & refresh-window adherence is tracked as a fitness function (S2) \\
|
||||
D10 Operating cost & \textbf{H} & warehouse compute is the bill; cost discipline is the operative FinOps concern \\
|
||||
D11 Team scaling & L & a data team, not a fleet of feature teams \\
|
||||
D12 AI integrability & M & text-to-SQL docks onto the governed semantic layer, not onto raw tables \\
|
||||
\midrule
|
||||
Shape $S(a)$ & \multicolumn{2}{l}{batch $+$ thin serving} \\
|
||||
Constraints $K(a)$ & \multicolumn{2}{l}{BCBS 239 lineage (banks)} \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C7 -- what real systems chose, and why}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{Documented modern form: a batch/ELT pipeline in front of a thin serving layer} -- sources $\to$ orchestrated DAGs (\textbf{Apache Airflow}: scheduler, executor, workers, metadata database; DAGs as code) $\to$ warehouse $\to$ BI frontend
|
||||
\item The ``modern data stack'' is architecturally \textbf{a layered application over a batch pipeline}: the PF column serves the refresh contract and lineage by construction (note 10, D6); the L column serves the thin tier because it \emph{delegates} the D1-High scans to the warehouse and keeps its D8/D10 virtues
|
||||
\item \textbf{Apache Superset} (Python/Flask, originating at Airbnb): deliberately a \emph{thin} visualisation layer with no data storage of its own, connecting directly to SQL engines; \textbf{Metabase} ships as a single JAR -- a literal monolith, mirroring how little serving infrastructure the class needs. Both delegate scaling to the database: \emph{division of labour as an architectural principle}
|
||||
\item \textbf{Where the trade-off bites (A2): freshness} -- streaming ingestion (EDA) earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window; tightening towards real time is \textbf{not a tuning exercise but a class change into C8 economics}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C7 -- AI lens and key concept}
|
||||
\begin{ailinse}[Natural-language analytics (Axis B)]
|
||||
\footnotesize The visible frontier: the natural-language query (``show me revenue by region, last four quarters'') compiled by an LLM into SQL against the semantic layer. The profile dictates the containment: the LLM \emph{proposes} a query; the semantic layer's schema and access-control contracts \emph{validate and execute} it -- \textbf{text-to-SQL against governed models, not raw tables} -- so that lineage (S3) and purpose limitation survive the convenience. Failure mode to design against: \textbf{silent plausibility} -- a syntactically valid, semantically wrong query returns confident nonsense; the Part V eval harness (golden question/answer sets over a \emph{frozen} warehouse state) is the class-appropriate test instrument, and note 10's refresh contract keeps such golden sets stable.
|
||||
\end{ailinse}
|
||||
|
||||
\vspace{0.08cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize C7 is an integration product over C1--C5 whose consistency semantics -- freshness by refresh contract -- is a \emph{designed} third option beside ACID and eventual. \textbf{The ADR to write is the freshness contract itself}; fitness functions: refresh-window adherence and p95 dashboard latency; tightening towards real time is a class change into C8 economics. \textbf{In one sentence:} PF (ELT) feeding a thin layered serving tier -- the canonical hybrid of the row (PF at $++$; L, MM, SL at $+$) -- EDA ingestion secondary where the freshness contract demands it.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Closing the loop: C6 and C7 inside your C10 project}
|
||||
\small Week 6's inheritance diagram: C10 inherits C6, C7 and C3 -- today the two batch parents are taught.
|
||||
|
||||
\vspace{0.05cm}
|
||||
\begin{projektbox}
|
||||
\footnotesize
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{The C6 subsystems}} -- ingestion (chunking, embedding, indexing) and the eval pipeline
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item the C6 discipline transfers literally: versioned inputs, idempotent stages, deterministic reruns, golden datasets
|
||||
\item note 14 is the bridge: for batch pipelines, \emph{reproducibility is the operative meaning of testability}
|
||||
\item when eval scores change, prove whether the \textbf{model, prompt, data or pipeline} changed -- that proof is a C6 property
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{The C7 subsystem}} -- portfolio analytics, exposure aggregation, report generation over the deterministic data store
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item its refresh contract: ``\textbf{analysis as of last completed ingestion}''
|
||||
\item it bounds what the advisory layer may claim -- \emph{an answer must never cite data fresher than the index actually is}
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
\end{projektbox}
|
||||
|
||||
\vspace{0.05cm}
|
||||
\footnotesize \textbf{Key concept:} the freshness contract appears \textbf{twice} in your measurement contract -- as a pipeline fitness function (C7 discipline) and as a grounding rule for generated answers (C10 discipline).
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% C8
|
||||
% ============================================
|
||||
\section{C8 -- Real-Time / IoT Streaming}
|
||||
|
||||
\begin{frame}{C8 -- real-time / IoT streaming}
|
||||
\emph{\textcolor{bankblue}{The sensors never stop: what ingests the world at the world's own rate, indefinitely -- and stays exactly right when a node dies mid-window?}}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\footnotesize The class: systems that process continuously arriving event data -- sensor telemetry, clickstreams, vehicle positions, market data. Defining property: data are produced by the world at the world's own rate and \textbf{lose value quickly}; the system must sustain ingest at the production rate \emph{indefinitely}, master backpressure, and guarantee state correctness across failures.
|
||||
|
||||
\vspace{0.15cm}
|
||||
\textbf{Three challenges define the class:}
|
||||
\begin{enumerate}\setlength\itemsep{1pt}
|
||||
\item \textbf{The sheer, unending inflow} -- ingest around the clock with bounded consumer lag and mastered backpressure $\to$ D2 (the \emph{inversion} of C2's read-heavy profile); 24/7 without pause $\to$ D5 (the world does not stop producing while a node recovers); value decay $\to$ D3
|
||||
\item \textbf{The genuinely hard one: declared correctness semantics under failure} -- event time vs.\ processing time, windowing, watermarks (the Dataflow model); exactly-once state via checkpointing -- bought with machinery and \emph{permanent operational competence}: D4 in its stream reading (note 11), D8 Low (nobody chooses streaming for its ease)
|
||||
\item \textbf{Longevity of the plumbing} -- topologies change moderately but \textbf{schema evolution is a permanent concern} (D7 Medium); the largest data volume of all classes (append-only logs), retention often TTL-bounded, the infrastructure long-lived even where the data are not
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C8 -- the verified magnitudes}
|
||||
\footnotesize
|
||||
\textit{Seen in week 5 from the supply side -- the existence proof for EDA D1/D2 $= ++$; today the same numbers as the demand-side D2 reading of C8.}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{2.4cm}p{4.0cm}p{6.6cm}@{}}
|
||||
\toprule
|
||||
\textbf{System} & \textbf{Scale} & \textbf{Structure} \\
|
||||
\midrule
|
||||
\textbf{LinkedIn} (Kafka's birthplace) & more than \textbf{seven trillion} Kafka messages per day & \textbf{new today:} roughly 100 clusters; over 4{,}000 brokers; about 100{,}000 topics; seven million partitions \\
|
||||
\addlinespace
|
||||
\textbf{Uber} & \textbf{trillions of messages and petabytes per day} & integrated real-time stack: Kafka (transport), Flink (stream processing), Pinot (OLAP serving) -- documented in a SIGMOD paper \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.2cm}
|
||||
\textbf{Read:} D2 in the \emph{ingest} reading -- around the clock, bounded consumer lag, mastered backpressure; D5 because it never pauses; D3 because value decays.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C8 -- the binding scenarios}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{3pt}
|
||||
\item \textbf{S1 (sustained ingest).} Sensors emit at full production rate around the clock; the platform ingests and processes with \textbf{consumer lag bounded and no data loss, indefinitely}. \textcolor{codegray}{(The D2/D5 scenario.)}
|
||||
\item \textbf{S2 (exactly-once state).} A processing node fails mid-window under load; the system recovers with \textbf{state restored to exactly-once semantics via checkpointing, zero duplicated or lost aggregate updates}. \textcolor{codegray}{(The D4 scenario in its note-11 reading.)}
|
||||
\item \textbf{S3 (end-to-end latency).} An anomalous reading arrives; the alert fires \textbf{within milliseconds to a few seconds end-to-end, per-key ordering preserved}. \textcolor{codegray}{(The D3 scenario.)}
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
$K(\text{C8})$ is \textbf{technical rather than statutory}: per-key ordering and exactly-once semantics \emph{where declared} are contractual knock-outs -- a billing stream that double-counts under failure is not ``mostly correct'', it is wrong; the GDPR adds purpose limitation and retention duties where streams carry personal data (vehicle telemetry, wearables).
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textbf{The pragmatic industry norm} -- at-least-once delivery plus idempotent consumers -- is legitimate exactly where the scenario says so; the decision is taken \textbf{per stream, per scenario, never platform-wide}.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C8 -- requirements profile (column C8)}
|
||||
\scriptsize
|
||||
\renewcommand{\arraystretch}{0.8}%
|
||||
\vspace{-0.35cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{3.0cm}cp{7.7cm}@{}}
|
||||
\toprule
|
||||
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
||||
\midrule
|
||||
D1 Read scalability & M & consumers read the log at their own pace; serving is delegated to OLAP sinks \\
|
||||
D2 Write scal.\ \& elasticity & \textbf{H} & ingest at the world's production rate, indefinitely, with backpressure mastered (S1) \\
|
||||
D3 Latency & \textbf{H} & alerts fire within milliseconds to seconds, end to end (S3) \\
|
||||
D4 Consistency \& integrity & M & stream semantics: exactly-once state, event-time windows, watermarks (S2; note 11) \\
|
||||
D5 Availability \& isolation & \textbf{H} & the world does not pause when a node fails; recovery must preserve state \\
|
||||
D6 Security \& auditability & L & low relative to the ledger classes; GDPR applies where streams carry personal data \\
|
||||
D7 Evolvability & M & topologies change moderately; schema evolution is the permanent concern \\
|
||||
D8 Simplicity \& TTM & L & nobody chooses this class for its simplicity \\
|
||||
D9 Testability \& deployability & M & correctness under failure is verified by chaos experiments, not unit suites alone \\
|
||||
D10 Operating cost & M & broker fleets cost, but the class's economics absorb them \\
|
||||
D11 Team scaling & M & platform and stream teams coordinate around shared topics \\
|
||||
D12 AI integrability & M & models score events in the stream as checkpointed operators \\
|
||||
\midrule
|
||||
Shape $S(a)$ & \multicolumn{2}{l}{continuous stream} \\
|
||||
Constraints $K(a)$ & \multicolumn{2}{l}{per-key ordering; exactly-once where stated} \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C8 -- what real systems chose, and why}
|
||||
\footnotesize
|
||||
\begin{itemize}\setlength\itemsep{4pt}
|
||||
\item \textbf{Documented form: EDA plus pipes-and-filters over a durable log} -- producers $\to$ Kafka (durable, partitioned, replayable) $\to$ stream processors (Flink) $\to$ sinks (OLAP, alerting, data lake)
|
||||
\item The EDA column is this class's mirror: a durable, partitioned, replayable log with decoupled producers and consumers serves \textbf{D2 and D5 at $++$} -- the two demands that eliminate every single-quantum interactive pattern at the shape gate; the streaming incarnation of PF supplies the processing layer whose \textbf{checkpointing answers S2}
|
||||
\item \textbf{Netflix}: the consumer-scale EDA reference -- event-driven telemetry pipelines, resilience institutionalised through \textbf{chaos engineering}: chaos experiments are exactly how this class tests its D4/D5 claims
|
||||
\item \textbf{Counter-lessons from this class's neighbourhood, both already met} (Segment: week 5; Prime Video: week 6 and the C6 case today) -- the shared A2 pattern is read in observation 3 later today
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{C8 -- AI lens and key concept}
|
||||
\begin{ailinse}[Online inference and drift on streams (Axis B)]
|
||||
\footnotesize C8 is where ML meets its hardest operational constraint: models score events \emph{in the stream} (fraud, anomaly, predictive maintenance) at \textbf{millisecond budgets} -- per-event LLM calls are ruled out entirely; pre-trained, locally served models are demanded. The stream is simultaneously the \textbf{monitoring instrument}: input-distribution statistics computed in the pipeline detect data and concept drift (production-readiness rubrics such as the ML Test Score assume exactly this telemetry). Architecturally, the model is \textbf{one more stateful stream operator} -- checkpointed, versioned, replayable -- so that S2's exactly-once discipline extends to inference results.
|
||||
\end{ailinse}
|
||||
|
||||
\vspace{0.08cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize C8 must keep pace with the production rate of the world -- indefinitely. The genuinely hard requirement is \emph{not throughput} but \textbf{declared correctness semantics under failure}: exactly-once state and event-time correctness are bought with checkpointing machinery and permanent operational competence -- so the pragmatic norm is at-least-once plus idempotence, decided per stream, per scenario, and recorded as such. \textbf{In one sentence:} EDA over a durable log with streaming PF as the processing layer -- the documented Uber stack (EDA at $++$; PF and MS at $+$) -- microservice processors secondary where team ownership demands it.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
\end{document}
|
||||
Loading…
x
Reference in New Issue
Block a user