130da6298f
Decks 1-8: every abbreviation (DORA, ADR, ACID, SLO, CI/CD, LLM, ATAM, AHP, CBAM, MADR, TCO, FTE, regulatory acronyms, ...) is now expanded or glossed where it first appears; "TTM" table labels written out as time-to-market; SL pattern code no longer used before its definition (deck 3); "A1" assumption vs deliverable disambiguated where they collide (deck 3); the two meanings of DORA (DevOps metrics vs EU Digital Operational Resilience Act) made explicit in deck 8. Deck 1: new section "Monolith and Microservices: A First Look" with six slides (layered monolith, modular monolith, cost/benefit; microservices topology, organisational problem, cost/benefit) using the Part II topology diagrams, placed before the four production cases. All decks rebuilt: zero errors, zero overfull vboxes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
709 lines
42 KiB
TeX
709 lines
42 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 6 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 6: Pipelines, Serverless, the View Across -- and Your Class (C10)\\[0.4ex]{\small Script: Part II, Sections PF / SL $+$ closing; Part III, Section C10}}
|
|
\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{PF} -- Pipes-and-filters: the throughput pattern
|
|
\item \textbf{SL} -- Serverless: pay per execution, own no capacity
|
|
\item Stepping back: the quantum, partitioning beats distribution
|
|
\item The consolidated capability table -- all seven, side by side
|
|
\item Outlook: agent orchestration as a composition pattern
|
|
\item Part III opens: \textbf{C10 in depth} -- the class of your project
|
|
\item The C1/C2 mirror pair
|
|
\item This week's exercise: \textbf{the match}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% PF
|
|
% ============================================
|
|
\section{PF -- Pipes-and-Filters}
|
|
|
|
\begin{frame}{PF -- Pipes-and-filters / batch pipeline}
|
|
\emph{\textcolor{bankblue}{The nightly risk run must process millions of rows, reproducibly, by 06:00: what structure is born for exactly that?}}
|
|
|
|
\vspace{0.15cm}
|
|
\small This one -- the \textbf{oldest pattern in the catalogue}, and the one most precisely matched to its workload shape.
|
|
|
|
\vspace{0.15cm}
|
|
\begin{definitionbox}[Pipes-and-filters / batch pipeline (PF)]
|
|
\footnotesize A macro-structure of independent, composable transformation steps (\emph{filters}) connected by unidirectional data conduits (\emph{pipes}) into a chain or directed acyclic graph (DAG). Each filter is self-contained -- ideally \textbf{stateless and idempotent} -- and knows only its own data contracts, never its neighbours; the composition logic is explicit and \emph{external} to the filters.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize Historical root: the Unix pipe. Modern incarnations dominate the data world: ETL/ELT (extract--transform--load and extract--load--transform), DAG orchestration (Airflow), data-parallel engines (Spark), HPC (high-performance computing) job chains (Slurm), streaming pipelines (Flink -- the bridge to EDA), and \textbf{ML (machine-learning) and retrieval pipelines} -- the current incarnation.
|
|
\end{frame}
|
|
|
|
\begin{frame}{PF -- topology and the problem it solves}
|
|
\begin{center}
|
|
\resizebox{0.8\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\footnotesize\sffamily, line width=0.8pt},
|
|
filter/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.0cm, minimum height=0.9cm},
|
|
extern/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=2.0cm, minimum height=0.9cm},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[extern] (src) at (-5.6,0) {Source\\(producer)};
|
|
\node[filter] (f1) at (-2.9,0) {Filter 1\\(transform)};
|
|
\node[filter] (f2a) at (0,1.1) {Filter 2a\\(transform)};
|
|
\node[filter] (f2b) at (0,-1.1) {Filter 2b\\(transform)};
|
|
\node[filter] (f3) at (2.9,0) {Filter 3\\(merge/test)};
|
|
\node[extern] (sink) at (5.7,0) {Output store\\(consumer)};
|
|
\draw[arr] (src) -- node[above, font=\scriptsize\sffamily] {pipe} (f1);
|
|
\draw[arr] (f1) -- (f2a);
|
|
\draw[arr] (f1) -- (f2b);
|
|
\draw[arr] (f2a) -- (f3);
|
|
\draw[arr] (f2b) -- (f3);
|
|
\draw[arr] (f3) -- node[above, font=\scriptsize\sffamily] {pipe} (sink);
|
|
\node[font=\footnotesize\sffamily, text=gray!60!black, align=center] at (0,-2.3)
|
|
{every pipe is a versioned data contract; every filter is stateless, idempotent,\\and independently testable against golden datasets};
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize \textbf{The problem is the oldest workload in commercial computing:} when the business day closes, the day's records must be collected, validated, transformed, aggregated -- reliably, repeatably, \emph{before the next day begins}. Payroll, end-of-day processing, warehouse loads, overnight risk runs: a finite body of data flows through fixed transformations, and nobody waits interactively. What matters: the run finishes \textbf{inside its window}, and the same inputs \textbf{provably produce the same outputs}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{PF -- capability profile (column PF)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.9cm}cp{7.8cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Rating} & \textbf{Structural reason} \\
|
|
\midrule
|
|
D1 Read scalability & $\circ$ & the pipeline does not serve reads; precomputation \emph{delegates} to the output store \\
|
|
D2 Write scal.\ \& elasticity & $+$ & data-parallel frameworks are the standard operating mode \\
|
|
D3 Latency \& predictability & $--$ & answers arrive in makespans, not milliseconds -- by design \\
|
|
D4 Consistency \& integrity & $+$ & immutable inputs $+$ idempotent stages: \emph{reproducibility}, ``as of last run'' \\
|
|
D5 Availability \& isolation & $-$ & a failed stage stalls the run; recovery is re-execution \\
|
|
D6 Security \& auditability & $+$ & versioned inputs, deterministic reruns: audit trail on demand \\
|
|
D7 Evolvability & $+$ & filters individually replaceable behind explicit data contracts \\
|
|
D8 Simplicity \& time-to-market & $++$ & explicit composition over self-contained filters -- shipping this week \\
|
|
D9 Testability \& deployability & $+$ & golden datasets per filter; bit-level assertions \\
|
|
D10 Operating cost & $++$ & compute in schedulable bursts, near-zero platform staff \\
|
|
D11 Team scaling & $\circ$ & DAG/filter ownership parallelises data teams moderately \\
|
|
D12 AI integrability & $++$ & ingestion, training, evals \emph{are} pipes-and-filters; non-determinism localised \\
|
|
\midrule
|
|
Native shape $S(p)$ & \multicolumn{2}{l}{scheduled batch} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{PF -- the cells with a story}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{D3 $= --$ is not a defect but the definition}: the pattern optimises \emph{makespan} (first filter starts $\to$ last finishes) and batch-window adherence, and delegates interactive serving to the stores it fills. The streaming incarnation escapes the cell.
|
|
\item \textbf{D4 $= +$ is the subtlest cell in the table}: not ACID (atomic, all-or-nothing transactions) -- immutable inputs plus deterministic, \emph{idempotent} stages give \textbf{reproducibility}, a \emph{third} consistency semantics beside ACID and eventual (``as of last run''). For scientific and regulatory workloads, the one that matters.
|
|
\item \textbf{The most deterministically testable pattern in the catalogue} -- as long as no AI filter sits inside.
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{examplebox}[a Monte-Carlo risk run -- reproducibility by construction]
|
|
\footnotesize Immutable market-data snapshots and versioned parameters enter; embarrassingly parallel simulation stages fan out; deterministic aggregation produces versioned risk figures. Fixed seeds $+$ versioned inputs make the run \textbf{bit-level reproducible} -- not a nicety but a regulatory duty for risk models: ``the same inputs produce the same books, provably, on demand.''
|
|
\end{examplebox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{PF -- engineering, build it and study it}
|
|
\footnotesize
|
|
\textbf{Engineering:} the pipeline versions \emph{three} things -- code, data, schemas; \textbf{backfills} (re-running history through changed logic) are their own deployment class with their own runbook. Test with \textbf{golden datasets} per filter. The on-call page: ``the 02:00 run missed its window'' -- standing measures: makespan trend, window adherence. Coupling risk hides in the \emph{pipes} (implicit schemas).
|
|
|
|
\vspace{0.1cm}
|
|
\begin{examplebox}[Build it and study it -- pipes-and-filters]
|
|
\footnotesize \textbf{Build.} Apache Airflow (DAG-as-code; read its shipped example DAGs first). dbt Core: each filter as one SQL model. Dagster as an active alternative.
|
|
|
|
\textbf{Study.} \texttt{dbt-labs/jaffle\_shop\_duckdb} (Apache-2.0): every \texttt{.sql} model under \texttt{models/} is a filter, \texttt{ref()} wires the pipes, \texttt{dbt build} materialises the DAG. Runs fully locally on DuckDB: \emph{very easy}. (Status check again: the classic \texttt{jaffle\_shop} was archived in 2024; its successor ships \emph{no licence file} -- use the DuckDB variant.)
|
|
\end{examplebox}
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Anti-patterns:} \emph{stateful filters with side effects} (alarm: non-zero \textbf{rerun-diff rate}); \emph{pipeline sprawl} (DAGs without owners or version control); \emph{implicit schema coupling} (alarm: downstream breakage per upstream schema change).
|
|
\end{frame}
|
|
|
|
\begin{frame}{PF -- AI lens and key concept}
|
|
\begin{ailinse}[Pipelines are where AI work naturally lives]
|
|
\footnotesize D12 $= ++$. The AI-adjacent workloads are pipes-and-filters \emph{by construction}: retrieval ingestion (documents $\to$ chunking $\to$ embedding $\to$ index), model training and batch inference, and \textbf{the eval harness itself} -- a versioned pipeline from golden set to statistical verdict. One precise change when an AI filter enters a deterministic chain: \emph{that stage's} test regime switches from golden-dataset equality to \textbf{statistical acceptance thresholds} (pass rates, score distributions) -- the rest keeps its deterministic tests. \textbf{Few structures contain AI more cheaply.}
|
|
\end{ailinse}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
\footnotesize PF is the most deterministically testable pattern in the catalogue and the natural home of batch, data, and ML workloads. Its $--$ latency cell is its \emph{definition}: makespan and reproducibility, with interactive serving delegated to the stores it fills.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SL
|
|
% ============================================
|
|
\section{SL -- Serverless / FaaS}
|
|
|
|
\begin{frame}{SL -- Serverless / Function-as-a-Service}
|
|
\emph{\textcolor{bankblue}{Your load is zero at night and spikes at noon: why pay for idle servers at 03:00?}}
|
|
|
|
\vspace{0.15cm}
|
|
\small The serverless answer is radical -- \textbf{pay per execution, own no capacity} -- and the whole profile is the fine print of that offer.
|
|
|
|
\vspace{0.15cm}
|
|
\begin{definitionbox}[Serverless / FaaS (SL)]
|
|
\footnotesize A macro-structure of \textbf{event-triggered, short-lived, stateless functions} on a managed platform that provides provisioning, elastic scaling \emph{from zero} to massive parallelism, and per-execution billing. State lives outside the functions, in managed backing services; \textbf{the function is simultaneously the unit of code, of deployment, of scaling, and of cost}.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize The scientific reference point is the Berkeley view: it predicted the dominance of simplified cloud programming \emph{while cataloguing the structural limits with unusual precision} -- cold starts, enforced statelessness, communication through storage, vendor lock-in. The CNCF (Cloud Native Computing Foundation) whitepaper draws the line between FaaS (your code, event-triggered) and BaaS (backend as a service: API-consumed third-party services).
|
|
\end{frame}
|
|
|
|
\begin{frame}{SL -- topology}
|
|
\begin{center}
|
|
\resizebox{0.8\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\footnotesize\sffamily, line width=0.8pt},
|
|
evt/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.2cm, minimum height=0.8cm},
|
|
fn/.style={sysbox, fill=bankblue!20, draw=bankblue, minimum width=2.6cm, minimum height=0.85cm},
|
|
mgd/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=2.4cm, minimum height=0.8cm},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
|
]
|
|
\node[evt] (http) at (-5.6,1.6) {HTTP request};
|
|
\node[evt] (q) at (-5.6,0) {queue event};
|
|
\node[evt] (sched) at (-5.6,-1.6) {schedule};
|
|
\draw[dashed, gray!60!black, rounded corners=6pt] (-2.6,2.6) rectangle (2.6,-2.6);
|
|
\node[font=\footnotesize\sffamily, text=gray!60!black] at (0,2.25) {managed FaaS platform};
|
|
\node[fn] (f1) at (0,1.2) {Function A\\ \scriptsize $0 \dots n$ instances};
|
|
\node[fn] (f2) at (0,-0.3) {Function B\\ \scriptsize $0 \dots n$ instances};
|
|
\node[font=\scriptsize\sffamily, text=bankred, align=center] at (0,-1.75)
|
|
{scale-to-zero $\leftrightarrow$ burst parallelism\\per-invocation billing; cold starts};
|
|
\node[mgd] (obj) at (5.4,1.6) {object storage};
|
|
\node[mgd] (db) at (5.4,0) {managed database};
|
|
\node[mgd] (api) at (5.4,-1.6) {third-party API\\(BaaS)};
|
|
\draw[arr] (http) -- (f1.west);
|
|
\draw[arr] (q) -- (f2.west);
|
|
\draw[arr] (sched) -- ([yshift=-0.25cm]f2.west);
|
|
\draw[arr] (f1.east) -- (obj.west);
|
|
\draw[arr] (f1.east) -- (db.west);
|
|
\draw[arr] (f2.east) -- (db.west);
|
|
\draw[arr] (f2.east) -- (api.west);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize Functions are stateless: all state lives outside, and \textbf{inter-function communication runs through storage} -- the documented cost trap. The problem it solves: \textbf{idle capacity} -- much real work is spiky or rare (thumbnails, webhooks, reports), and provisioned machines force a bad choice between sizing for the peak and failing at it.
|
|
\end{frame}
|
|
|
|
\begin{frame}{SL -- capability profile (no star anchor: Berkeley/CNCF-derived)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.35cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.9cm}cp{7.8cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Rating} & \textbf{Structural reason} \\
|
|
\midrule
|
|
D1 Read scalability & $+$ & wide parallelism, tempered by concurrency limits and the database-connection bottleneck \\
|
|
D2 Write scal.\ \& elasticity & $++$ & scale-to-zero to mass parallelism, no capacity planning \\
|
|
D3 Latency \& predictability & $-$ & cold starts make tail latency structurally unpredictable \\
|
|
D4 Consistency \& integrity & $-$ & stateless functions push all state through external storage \\
|
|
D5 Availability \& isolation & $+$ & platform-managed redundancy; small blast radius per function \\
|
|
D6 Security \& auditability & $\circ$ & platform identity per function vs.\ a fragmented audit trail \\
|
|
D7 Evolvability & $\circ$ & fine-grained deployability vs.\ vendor lock-in and sprawl \\
|
|
D8 Simplicity \& time-to-market & $\circ$ & no server management vs.\ a large configuration surface \\
|
|
D9 Testability \& deployability & $\circ$ & trivial unit tests vs.\ cloud wiring no laptop reproduces \\
|
|
D10 Operating cost & $++$/$--$ & \textbf{split by load shape}: zero idle cost vs.\ billing $+$ storage round trips \\
|
|
D11 Team scaling & $+$ & the smallest teams in the catalogue ship to production \\
|
|
D12 AI integrability & $\circ$ & fine event glue; platform timeouts collide with minutes-long runs \\
|
|
\midrule
|
|
Native shape $S(p)$ & \multicolumn{2}{l}{event-triggered, short-lived} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SL -- the split cell, observed in production}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{D10 $= ++/--$ is the most workload-sensitive cell in the table}: $++$ for spiky load (zero idle cost); $--$ for sustained, data-intensive load. \emph{It does not average to $\circ$ -- averaging would erase precisely the information an architect needs.}
|
|
\item \textbf{D3 $= -$ has a mitigation with a sting}: provisioned concurrency removes cold starts -- at the price of exactly the idle cost the pattern exists to avoid.
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{examplebox}[Amazon Prime Video -- a measured cost inversion]
|
|
\footnotesize The video-monitoring service: AWS Step Functions coordinating Lambdas, S3 buffering frames between stages. A hard scaling limit at $\sim 5\,\%$ of expected load, and consolidation into one ECS (container-service) process cut infrastructure cost by $> 90\,\%$. \textbf{The correct reading}: \emph{one} service with a data-intensive, tightly coupled flow -- PF pushed across expensive distributed boundaries -- not a verdict on serverless. \emph{(Widely reported as ``Amazon abandons microservices'' -- which measurement, taken before the first release, would have predicted the inversion?)}
|
|
\end{examplebox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SL -- engineering, build it and study it}
|
|
\footnotesize
|
|
\textbf{Engineering:} infrastructure-as-code becomes \emph{part of the test subject}; integration tests run against emulators or ephemeral environments. Above all: \textbf{cost monitoring becomes an engineering discipline (FinOps)} -- cost per request belongs on the same dashboards as latency.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{examplebox}[Build it and study it -- serverless]
|
|
\footnotesize \textbf{Build.} Knative (Go, Apache-2.0): clean, self-hostable FaaS on Kubernetes, runs on a local kind cluster. Moto (Python, Apache-2.0) mocks AWS APIs in local tests. Deliberately \emph{off} this list: LocalStack (archived into a closed model, 2026) and Serverless Framework v4 (proprietary) -- \textbf{the licence check, twice over}.
|
|
|
|
\textbf{Study.} The Knative Bookstore sample: independent Knative Services wired by Brokers and Triggers in YAML -- the most involved setup of the seven boxes, but self-hostable end to end.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.05cm}
|
|
\textbf{Anti-patterns:} \emph{Lambda pinball} (alarm: function hops per request); \emph{cost inversion under load growth} (alarm: cost-per-request trend vs.\ load trend, break-even utilisation as a standing fitness function); \emph{cold-start denial} (alarm: cold-start rate on p99 -- 99th-percentile -- routes).
|
|
\end{frame}
|
|
|
|
\begin{frame}{SL -- AI lens and key concept}
|
|
\begin{ailinse}[Serverless and AI: excellent glue -- conditional runtime]
|
|
\footnotesize D12 $= \circ$, and the split mirrors the D10 cell. Event glue around \emph{batch} AI APIs fits beautifully: a function that submits, polls, and stores an asynchronous AI job is serverless at its best. But \textbf{platform timeout ceilings collide with minutes-long LLM (large language model) and solver runs} -- a hard constraint, not a tuning issue -- and per-call cost stacking across functions \emph{plus} tokens is opaque without a single gateway measurement point. \textbf{A fine chauffeur for AI jobs, and a poor place for them to live.}
|
|
\end{ailinse}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
\footnotesize The serverless profile is dominated by one variable more than any other pattern's: \textbf{load shape}. Unmatched elasticity and scale-to-zero economics for spiky workloads -- inverting into the catalogue's worst cost cell under sustained, data-intensive load. The split D10 rating is the table being honest where an average would lie.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% STEPPING BACK
|
|
% ============================================
|
|
\section{Stepping Back}
|
|
|
|
\begin{frame}{Stepping back: the architecture quantum}
|
|
\small
|
|
Seven times the same movement: problem $\to$ topology $\to$ profile $\to$ engineering $\to$ runnable code. What no single section could deliver is the view \emph{across} -- and it starts with the unit you met in every topology figure: \textbf{the dashed boundary}.
|
|
|
|
\vspace{0.15cm}
|
|
\begin{definitionbox}[Architecture quantum]
|
|
\footnotesize An \emph{independently deployable} unit that can be deployed, scaled, and can fail independently of the rest -- the joint unit of deployment, scaling, and failure. L, MM, and PF form exactly \textbf{one} quantum; EDA one or more; MS \textbf{many}; SL many small, short-lived ones.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Maxim 3.} One quantum $\to$ cheap, simple, consistent, rigid. Many quanta $\to$ expensive, complex, eventually consistent, elastic. \emph{The quantum count explains most of the capability table.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Partitioning beats distribution}
|
|
\footnotesize
|
|
The second axis is orthogonal: \emph{how} the units are cut. \textbf{Technical partitioning} groups by technical role (layers, filter stages); \textbf{domain partitioning} by business capability (modules, services). Change requests arrive in the \emph{domain's} vocabulary -- so a feature cuts across every technical unit, but lands \emph{inside one} domain unit. \textcolor{codegray}{(Parnas's criterion, six decades on.)}
|
|
|
|
\vspace{0.1cm}
|
|
You watched the axis operate \textbf{in isolation}:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{L $\to$ MM}: quantum count constant, only the cut flips -- D7/D9 rise from $-$ to $+$
|
|
\item \textbf{MM $\to$ MS}: domain cut constant, quanta multiply -- evolvability stays, the bill arrives on D8/D10
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Maxim 4.} The partitioning axis beats the distribution axis: \emph{domain-oriented partitioning, not the number of deployment units, is the strongest single predictor of evolvability.}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.05cm}
|
|
The $2 \times 2$ logic: L, PF $=$ technical/single quantum $\cdot$ MM $=$ domain/single $\cdot$ MS $=$ domain/many $\cdot$ EDA, SL multiply quanta along technical seams $\cdot$ HX orthogonal to both.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The evidence base -- and its honest gaps}
|
|
\footnotesize
|
|
The most systematic public rating: the star scheme of Richards \& Ford -- eleven characteristics, one to five stars, calibrated here via the fixed mapping ($5\star \to ++$ \dots\ $1\star \to --$). Its own headline result proves a matching problem exists: \textbf{no style dominates} -- microservices lead the aggregate yet one star on cost and simplicity; layered is the exact mirror.
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize Four caveats before comparative use: (i) star ratings are structured \textbf{expert judgement}, not measurements -- transcribed from the first edition, to be reconciled against the second before print; (ii) \textbf{HX carries no star profile at all} -- correctly, as a dependency-organisation pattern; its column is a flagged delta; (iii) \textbf{SL} likewise -- its column derives from Berkeley $+$ CNCF; (iv) \textbf{MM} is a rated style only since the second edition. Compensation: \emph{triangulation} -- expert ratings $\times$ documented production cases $\times$ defined response measures -- plus the measurement contract, which converts every adopted claim into a testable one.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The consolidated capability table}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.6cm}ccccccc@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{L} & \textbf{MM} & \textbf{HX} & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
|
|
\midrule
|
|
D1 Read scalability & $\circ$ & $\circ$ & $\diamond$ & $++$ & $++$ & $\circ$ & $+$ \\
|
|
D2 Write scalability \& elasticity & $--$ & $-$ & $\diamond$ & $++$ & $++$ & $+$ & $++$ \\
|
|
D3 Latency \& predictability & $+$ & $+$ & $\diamond$ & $-$ & $+$ & $--$ & $-$ \\
|
|
D4 Consistency \& integrity & $++$ & $++$ & $\diamond$ & $--$ & $--$ & $+$ & $-$ \\
|
|
D5 Availability \& fault isolation & $-$ & $-$ & $\diamond$ & $++$ & $++$ & $-$ & $+$ \\
|
|
D6 Security \& auditability & $+$ & $+$ & $+$ & $\circ$ & $\circ$ & $+$ & $\circ$ \\
|
|
D7 Evolvability \& maintainability & $-$ & $+$ & $++$ & $++$ & $++$ & $+$ & $\circ$ \\
|
|
D8 Simplicity \& time-to-market & $++$ & $+$ & $-$ & $--$ & $--$ & $++$ & $\circ$ \\
|
|
D9 Testability \& deployability & $-$ & $+$ & $++$ & $+$ & $-$ & $+$ & $\circ$ \\
|
|
D10 Operating cost efficiency & $++$ & $++$ & $\diamond$ & $--$ & $\circ$ & $++$ & $++$/$--$ \\
|
|
D11 Team scaling (Conway) & $-$ & $\circ$ & $\diamond$ & $++$ & $+$ & $\circ$ & $+$ \\
|
|
D12 AI integrability & $\circ$ & $+$ & $++$ & $\circ$ & $++$ & $++$ & $\circ$ \\
|
|
\midrule
|
|
Native shape $S(p)$ & interact. & interact. & (host's) & interact. & stream & batch & event-trig. \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize The 21 table notes (every deviation, with evidence) are in the script.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Four reading rules -- and the table's status}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{HX is a delta pattern}: $\diamond$ inherits the host; its own cells are what the cut adds
|
|
\item \textbf{Every deviation is footnoted} -- an unexplained deviation would violate the theory's own rigour standard
|
|
\item \textbf{One cell is split}: SL's D10 genuinely inverts with load shape -- a standing sensitivity point, not a $\circ$
|
|
\item \textbf{The last row feeds the shape gate}: $S(p)$ vs.\ $S(a)$ in stage-1 knock-out screening
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize \emph{Ordinal} reading only: rankings and exclusions, never weighted sums. Every cell is a \textbf{default hypothesis} -- replaced by measurement once the system exists. Two cells documented to invert with context: SL cost (Prime Video), L read scalability (Stack Overflow). \emph{The matrix predicts the default, not the exception.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the catalogue as a whole}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{No column dominates -- so a matching problem exists.} A2 made visible in data; two variables -- quantum count (Maxim 3) and partitioning axis (Maxim 4) -- explain most of 84 cells.
|
|
\item \textbf{The cost curves cross.} Single quanta: low fixed cost, superlinear maintenance growth unless governance holds. Many quanta: high fixed cost (platform staffing) or load-proportional cost. The five case studies are where fit and misfit were \emph{measured in money}.
|
|
\item \textbf{Conway is a decision filter, not a footnote.} Every column presupposes a team topology: L one team $\cdot$ MM 3--5 coordinated $\cdot$ MS stream-aligned $+$ platform. Loosely coupled architectures \emph{and teams} predict continuous delivery.
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{thinkbox}
|
|
\footnotesize Stack Overflow: $\sim 1.3$bn page views/month from \emph{one} quantum. Monzo: a licensed bank on $\sim 2{,}800$. What exactly does this pair falsify about ``microservices scale better than monoliths'' -- and what does it \emph{not} falsify?
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Outlook: agent orchestration -- an emergent composition pattern}
|
|
\footnotesize
|
|
One candidate for an ``eighth pattern'', filed correctly: agent orchestration is \textbf{not a new style} -- it is a \emph{composition pattern} for non-deterministic components that \textbf{reuses this catalogue's topologies}:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}ll@{}}
|
|
\toprule
|
|
\textbf{Agent construct} & \textbf{Classical topology} \\
|
|
\midrule
|
|
prompt chaining & pipes-and-filters \\
|
|
routing & dispatch layer \\
|
|
parallelisation with voting & broker-style fan-out \\
|
|
orchestrator--workers & mediator EDA \\
|
|
evaluator--optimizer loop & feedback control loop \\
|
|
multi-agent systems & broker fan-out of autonomous quanta \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
Load-bearing distinction: \textbf{workflows} (predefined code paths) vs.\ \textbf{agents} (the model steers its own process). The rigour case for restraint is quantified: a multi-agent research system beat a single agent by $90.2\,\%$ -- at roughly \textbf{fifteen times} the token consumption, with token use alone explaining $80\,\%$ of the variance. The module's default rule: \emph{workflows before agents}; every escalation is an ADR (architecture decision record) with a measurement contract.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% PART III: C10
|
|
% ============================================
|
|
\section{C10 -- Your Class}
|
|
|
|
\begin{frame}{Part III opens: C10 -- AI-native advisory platforms}
|
|
\emph{\textcolor{bankblue}{The component your product is built around is non-deterministic, priced per call, and deprecated within months: what structure contains it?}}
|
|
|
|
\vspace{0.15cm}
|
|
\small The youngest class in the catalogue, \textbf{the profile of the course project}, and the reason this course exists in its present form. The architecture must \emph{contain} the AI component: deterministic services for everything deterministic, LLM calls only where determinism cannot reach, every generated statement grounded in retrievable sources.
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{Accountability for probabilistic output} -- provenance per claim, a log per agent step: observability is \emph{domain functionality}, with EU AI Act force behind it (potentially high-risk classification)
|
|
\item \textbf{A genuinely new cost model} -- requests rare but heavy: cost \emph{per request} (tokens, GPU time), not per user; batch APIs $\sim 50\,\%$ cheaper; model cascades up to $98\,\%$ cost reduction; learned routers halve cost
|
|
\item \textbf{Churn at the core's edge} -- models, prompts, frameworks turn over in months: the most extreme change rate in the catalogue, and the strongest argument for ports and adapters
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- the binding scenarios}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{S1 (grounded answer).} A client asks for a recommendation; \textbf{every factual claim carries a resolvable provenance reference}, failing answers are blocked and escalated -- \textbf{detection rate $\geq 99\,\%$ at $< 2$\,s added latency}. \textcolor{codegray}{(The D6 scenario.)}
|
|
\item \textbf{S2 (cost per request).} A session triggers a multi-step agent workflow; it completes \textbf{within a per-request token-cost budget (e.g.\ CHF~0.40 at the 95th percentile, p95) and a p95 latency budget (e.g.\ 20\,s)} -- both fitness functions gated in CI (continuous integration). \textcolor{codegray}{(The D10 scenario.)}
|
|
\item \textbf{S3 (model migration).} The provider deprecates the production model; the platform migrates with \textbf{eval-harness pass rate $\geq$ threshold on the golden set before rollout, rollback available}. \textcolor{codegray}{(The D7/D9 scenario.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Knock-out reading of $K$:} an architecture in which agent steps are not loggable, tool privileges not boundable, or provenance not reconstructable is \textbf{excluded before scoring} -- C1's ACID veto logic, transposed to accountability. Prompt injection cannot be fully solved in the model $\to$ system-level defence in depth is \emph{constitutive}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- requirements profile (the only column with an H on D12)}
|
|
\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 & retrieval reads; user concurrency modest \\
|
|
D2 Write scal.\ \& elasticity & L & requests rare; batch pipelines scheduled, not elastic \\
|
|
D3 Latency & M & users accept seconds-to-minutes for advisory answers \\
|
|
D4 Consistency \& integrity & M & hybrid: knowledge index eventual, audit path ACID \\
|
|
D5 Availability \& isolation & M & degraded answers beat no answers \\
|
|
D6 Security \& auditability & \textbf{H} & provenance per claim, a log per agent step -- AI Act force (S1) \\
|
|
D7 Evolvability & \textbf{H} & models, prompts, frameworks turn over in months (S3) \\
|
|
D8 Simplicity \& time-to-market & M & start simplest -- but never simpler than the audit path \\
|
|
D9 Testability \& deployability & \textbf{H} & \textbf{evals are the operative meaning of testability} (S3) \\
|
|
D10 Operating cost & \textbf{H} & cost per \emph{request} -- a run-cost class no classical profile contains (S2) \\
|
|
D11 Team scaling & L & small product teams; the platform premium is unaffordable \\
|
|
D12 AI integrability & \textbf{H} & definitional: the class exists to contain the probabilistic component \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{hybrid: interactive $+$ batch/async} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR (data protection)} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- what real systems chose, and why}
|
|
\footnotesize
|
|
Three documented building blocks define the reference shape:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{Retrieval-augmented generation}: ingestion $\to$ vector index $\to$ retrieval $\to$ context $\to$ generation with citations -- structurally a \textbf{PF pipeline plus a serving layer}
|
|
\item \textbf{Agent orchestration}: \emph{workflows before agents} -- the restraint case is quantified ($90.2\,\%$ better at $15\times$ the tokens)
|
|
\item \textbf{Compound AI systems}: results come from systems of retrievers, models, tools, verifiers -- \emph{the system architecture becomes the differentiator}
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
The capability tables explain the host choice:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{MM} hosts the deterministic majority in one ACID quantum \emph{and} gives the AI subsystem a hard, CI-verifiable boundary
|
|
\item \textbf{HX} answers the two hardest Highs: the LLM as a swappable adapter behind a port (D7); the port is where the \textbf{eval harness and cost gateway dock} (D9, D10)
|
|
\item where A2 bites: synchronous chains multiply LLM latency -- what keeps \textbf{MS at $\circ$}; the monolith's weak cells are mitigated by \textbf{asynchronous edges}
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}{The C1/C2 mirror pair -- weights, not dimensions, define a class}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{C1 core banking}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item a lost or double-posted booking \emph{creates or destroys money}: D4/D5/D6/D7/D9 High
|
|
\item verdict: \textbf{MM$+$HX core}, EDA edges, PF batch runs; MS only at the Monzo condition (D11 forced High)
|
|
\item LMAX vs.\ Monzo: \emph{same profile, opposite structures} -- $R(a)$ defines the feasible set, $K(a)$ decides within it
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{C2 social/content platforms}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item $\sim 50{:}1$ read/write ratio; a \emph{stale} feed is invisible, an \emph{unavailable} feed is the defect: D1/D3/D5/D7/D9/D11 High, \textbf{D4 Low}
|
|
\item verdict: \textbf{EDA$+$MS hybrid} at organisational scale; MM secondary until that scale is \emph{measured} (Instagram: a Django monolith at 100 deployments/day)
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize C1 and C2 are \textbf{mirror images} across the consistency/availability trade: same twelve dimensions, inverted weights on D1 and D4. \emph{Weights, not dimensions, define a class.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- your project as an inheritance diagram}
|
|
\begin{projektbox}
|
|
\footnotesize The Portfolio Intelligence Platform \emph{is} a C10 instance. \textbf{Inherited:} ingestion and eval pipelines are C6 (reproducible batch); analytics are C7 (refresh contracts, lineage); the deterministic services are C3 (ACID, boring on purpose). \textbf{New:} the cost model -- \emph{expensive per request}: a token-cost budget, enforced in CI. \textbf{Also new:} D12 $=$ H, and D9 $=$ H in its eval reading -- a versioned golden set gates every prompt change and model migration. \emph{Spend your design budget on the new elements -- the inherited disciplines are solved problems.}
|
|
\end{projektbox}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize C10 \textbf{stress-tests} the method rather than overthrowing it: one new High dimension, one new cost semantics, one new test-artefact class -- otherwise \emph{inherited} (A6 made concrete). In one sentence: a \emph{hexagonal modular monolith} -- AI adapters at ports, an LLM gateway as the single measurement point -- plus PF for ingestion and evals, EDA for the job and audit spine.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: the match}
|
|
\begin{projektbox}
|
|
\footnotesize Run the \textbf{full three-stage procedure} for your platform, against your A1 requirements profile:
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{Knock-out}: constraints and the workload-shape gate -- which candidates cannot carry the core?
|
|
\item \textbf{Veto}: hold every High weight against the capability columns -- which vetoes fire, which have \emph{documented} mitigations?
|
|
\item \textbf{Ordinal reading}: rank the survivors on the High set; run the sensitivity check
|
|
\end{enumerate}
|
|
\textbf{Take the decision -- and begin the ADR} (in the MADR -- Markdown ADR -- template: drivers, options, consequences, confirmation).
|
|
\end{projektbox}
|
|
|
|
\vspace{0.1cm}
|
|
\small Next week's lecture shows the same procedure formally -- you will recognise every step.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{PF}: makespan and reproducibility -- a \emph{third} consistency semantics (``as of last run''); the most deterministically testable pattern; the natural home of ingestion, training, and evals
|
|
\item \textbf{SL}: the profile is dominated by load shape; the split D10 cell is the table being honest -- Prime Video is note 18 observed in production, with a price tag
|
|
\item \textbf{Maxims 3 and 4}: quantum count and partitioning axis explain most of the 84 cells
|
|
\item The \textbf{consolidated table} supports ordinal reading only -- every cell a default hypothesis, two cells documented to invert with context
|
|
\item \textbf{Agent orchestration} reuses this catalogue's topologies -- workflows before agents ($15\times$ token finding)
|
|
\item \textbf{C10}: Highs on D6/D7/D9/D10/D12 -- accountability, churn, evals, cost per request, containment; inherits C6/C7/C3, adds the eval harness and the token budget
|
|
\item \textbf{C1/C2}: mirror images across the consistency/availability axis -- weights, not dimensions, define a class
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 7 -- Part IV: the match, formally}}
|
|
\begin{itemize}\small
|
|
\item three cases, three stages
|
|
\item the procedure in general; reading the $7 \times 10$ matrix
|
|
\item the measurement contract, introduced
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part II close; Part III, C10
|
|
\item ahead: Part IV, sections 1--3
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item the match; decision; ADR begun
|
|
\item \textbf{A2 $+$ design gate: next week}
|
|
\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}
|