898 lines
62 KiB
TeX
898 lines
62 KiB
TeX
% !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, 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{0pt}
|
|
\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}%
|
|
\setlength{\tabcolsep}{4pt}%
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}c>{\raggedright\arraybackslash}p{8.9cm}@{}}
|
|
\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{0pt}
|
|
\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}%
|
|
\setlength{\tabcolsep}{4pt}%
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}c>{\raggedright\arraybackslash}p{8.9cm}@{}}
|
|
\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 A 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 lineage (S3) and purpose limitation survive the convenience. Failure mode to design against: \textbf{silent plausibility} (a valid but semantically wrong query returns confident nonsense); the Part V eval harness -- golden question/answer sets over a \emph{frozen} warehouse state -- is the test instrument, kept stable by note 10's refresh contract.
|
|
\end{ailinse}
|
|
|
|
\vspace{-0.05cm}
|
|
\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 (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.
|
|
\begin{projektbox}
|
|
\footnotesize
|
|
\begin{columns}[T,totalwidth=\linewidth]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{The C6 subsystems}} -- ingestion (chunking, embedding, indexing -- in the sheet: news ingestion $\to$ \texttt{ResearchAgent}) 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}
|
|
\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 -- produced by the world at the world's own rate and \textbf{losing 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{0pt}
|
|
\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}{@{}>{\raggedright\arraybackslash}p{2.4cm}>{\raggedright\arraybackslash}p{4.0cm}>{\raggedright\arraybackslash}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}%
|
|
\setlength{\tabcolsep}{4pt}%
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}c>{\raggedright\arraybackslash}p{8.9cm}@{}}
|
|
\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 ML's 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; pre-trained, locally served models are demanded. The stream is also the \textbf{monitoring instrument}: input-distribution statistics computed in the pipeline detect data and concept drift (the ML Test Score rubric assumes exactly this telemetry). The model is \textbf{one more stateful stream operator} -- checkpointed, versioned, replayable -- so S2's exactly-once discipline extends to inference results.
|
|
\end{ailinse}
|
|
|
|
\vspace{-0.05cm}
|
|
\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, 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 $+$), MS processors secondary where team ownership demands it.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% C9
|
|
% ============================================
|
|
\section{C9 -- Collaboration / Messaging}
|
|
|
|
\begin{frame}{C9 -- Collaboration / messaging}
|
|
\emph{\textcolor{bankblue}{Five million people are connected at this moment, and every message must reach its channel within half a second: what holds the connections?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize The class: chat, team-collaboration and messaging applications -- a resource profile classical request/response never modelled: the system holds \textbf{millions of long-lived, stateful connections} (WebSockets) and pushes every message to all channel members immediately; latency must feel instantaneous; ordering \textbf{causal per channel} -- global ordering unnecessary, a deliberate weakening that buys scalability (note 12).
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{Three challenges define the class:}
|
|
\begin{enumerate}\setlength\itemsep{0pt}
|
|
\item \textbf{The connections themselves} -- the boot storm, not the message rate, threatens the core databases: the binding load is \textbf{connection fan-out and push} $\to$ D1/D2 Medium (note 9); the crux is D3/D5: a message must reach its channel in 100--500\,ms, and \emph{a disconnected messenger is a dead messenger}
|
|
\item \textbf{The history tail} -- message histories are enormous and users scroll deep into them expecting low-tens-of-milliseconds reads: a D3 demand on the read path
|
|
\item \textbf{Consistency relaxed by design} -- causal order per channel suffices (D4 Medium, note 12), the deliberate weakening that makes the fan-out scalable; feature churn high while the core protocol stays stable (D7 Medium); lifetimes exceed ten years
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- the connections and the history tail: two measured cases}
|
|
\footnotesize
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.0cm}>{\raggedright\arraybackslash}p{1.5cm}>{\raggedright\arraybackslash}p{3.7cm}>{\raggedright\arraybackslash}p{5.0cm}@{}}
|
|
\toprule
|
|
\textbf{System} & \textbf{Problem} & \textbf{Magnitude} & \textbf{Measure and result} \\
|
|
\midrule
|
|
\textbf{Slack} & connection storms & more than \textbf{five million} simultaneous WebSocket sessions at peak; a morning peak rolling across a timezone means millions of clients connecting and booting within minutes & application-level edge cache \textbf{Flannel} at global points of presence: p99 latency for channel-membership queries from roughly \textbf{2{,}000\,ms to roughly 200\,ms}, shielding the core from the boot storms \\
|
|
\addlinespace
|
|
\textbf{Discord} \newline {\scriptsize\textcolor{codegray}{(week 4: D7/D9 seam; today: D3 on storage)}} & the history tail & stores \textbf{trillions of messages}; users scroll deep expecting low-tens-of-milliseconds reads & storage migrations MongoDB $\to$ Cassandra $\to$ ScyllaDB behind Rust data services performing request coalescing: p99 read latency from \textbf{40--125\,ms to roughly 15\,ms} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\textbf{Reading:} every message is one write and $N$ push-deliveries; load arrives as office-hour waves travelling with the timezones (Slack) or as evening peaks (Discord) -- Slack is the D5 scenario in the class's \emph{connection} reading (note 9), Discord the D3 demand on the \emph{storage} tier: \textbf{two tails, two tiers, one class}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- the binding scenarios}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{S1 (delivery latency).} A user sends a channel message in normal global operation; all online channel members receive it \textbf{within 100--500\,ms, in causal order per channel}. \textcolor{codegray}{(The D3/D4 scenario.)}
|
|
\item \textbf{S2 (connection fan-out).} Morning peak rolls across a timezone; millions of clients connect and boot with \textbf{connection establishment and initial payload within budget while protecting the core databases} -- the exact scenario Slack built its edge cache for. \textcolor{codegray}{(The D5 scenario in the connection reading, note 9.)}
|
|
\item \textbf{S3 (history read tail).} A user scrolls deep into channel history; the store serves the read with \textbf{p99 read latency in the low tens of milliseconds} -- the target of Discord's migrations. \textcolor{codegray}{(A D3 demand on the storage tier.)}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
$K(\text{C9})$: the GDPR, with \textbf{data residency} as an explicit selling argument in the self-hosted segment; in enterprise deployments, \textbf{compliance archiving} (MiFID~II and FINRA record-keeping rules for trader communication) makes exportable, tamper-evident message archives a hard requirement.
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Knock-out reading:} for regulated enterprise customers, an architecture that cannot guarantee complete capture and retention of business communication is excluded -- precisely the market logic behind \textbf{Mattermost's single-binary, self-hostable design}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- requirements profile (column C9)}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\setlength{\tabcolsep}{4pt}%
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.4cm}c>{\raggedright\arraybackslash}p{8.9cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{Weight} & \textbf{Why} \\
|
|
\midrule
|
|
D1 Read scalability & M & the binding load is connection fan-out and push, not raw reads (note 9) \\
|
|
D2 Write scal.\ \& elasticity & M & one write becomes $N$ push deliveries -- amplification, not raw write rate (note 9) \\
|
|
D3 Latency & \textbf{H} & delivery within 100--500\,ms or the conversation dies (S1, S3) \\
|
|
D4 Consistency \& integrity & M & causal order per channel suffices; global order is deliberately waived (note 12) \\
|
|
D5 Availability \& isolation & \textbf{H} & presence is the product: a disconnected messenger is a dead messenger (S2) \\
|
|
D6 Security \& auditability & M & enterprise segments harden archiving duties into $K(a)$; consumer segments do not \\
|
|
D7 Evolvability & M & feature churn is high while the core protocol stays stable \\
|
|
D8 Simplicity \& TTM & M & a small install must stay operable -- the self-hosted market demands it \\
|
|
D9 Testability \& deployability & M & staged rollouts across a heterogeneous client fleet \\
|
|
D10 Operating cost & M & connection infrastructure costs scale with concurrency, not usage \\
|
|
D11 Team scaling & M & platform teams for gateway and storage, feature teams above \\
|
|
D12 AI integrability & L & assistants and summarisation decorate the edges; the fan-out core is untouched \\
|
|
\midrule
|
|
Shape $S(a)$ & \multicolumn{2}{l}{interactive, connection-stateful} \\
|
|
Constraints $K(a)$ & \multicolumn{2}{l}{compliance archiving (MiFID/FINRA) in enterprise segments} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- same domain, four structures}
|
|
\scriptsize
|
|
\begin{center}
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{tabular}{@{}p{1.7cm}>{\raggedright\arraybackslash}p{5.2cm}>{\raggedright\arraybackslash}p{5.8cm}@{}}
|
|
\toprule
|
|
\textbf{System} & \textbf{Structure} & \textbf{Which column, and why} \\
|
|
\midrule
|
|
\textbf{Mattermost} & \emph{one} Go binary with PostgreSQL -- the monolith as a \emph{feature} for self-hosting and compliance customers & MM column: its D8/D10 strengths are what the enterprise $K(a)$ segment buys; the D5 weakness is mitigated by replicated instances \\
|
|
\addlinespace
|
|
\textbf{Rocket.Chat} & Node.js and MongoDB & sits in the middle \\
|
|
\addlinespace
|
|
\textbf{Slack} & hybrid: a PHP/Hack monolithic core for persistence and business logic, a specialised distributed real-time push layer in front & the push layer is publish/subscribe fan-out -- the EDA column owns this row: message delivery \emph{is} event fan-out with causal per-channel ordering; domain semantics and pattern coincide \\
|
|
\addlinespace
|
|
\textbf{Discord} & polyglot specialisation per quality attribute: BEAM for connection concurrency, Rust for tail latency & targeted microservices exactly where the D3 tail demands them \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize \textbf{The trade-off (A2) is resolved by scale and business model, not by the domain:} below roughly $10^5$ concurrent connections a specialised push layer is premature optimisation -- \textbf{the measured concurrent-connection count is the tiebreaker}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- key concept}
|
|
\begin{keypoint}
|
|
\footnotesize C9's binding load is connection fan-out and push, not raw read/write rates -- a resource profile request/response never modelled. The same business domain spans Mattermost's single, deliberately monolithic binary and Discord's polyglot specialised cluster: \textbf{the profile's core is stable, but scale and business model move the weights at its edges} -- the measured concurrent-connection count is the tiebreaker.
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{In one sentence:} a hybrid -- a monolithic persistence and business core with a specialised event-driven push layer, Slack's documented shape (EDA at $++$ at the fan-out crux; MM and MS at $+$) -- with a modular monolith alone as secondary for the self-hosted segment.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
\small Mattermost and Discord implement substantially the same user-visible functionality. Using the twelve dimensions:
|
|
|
|
\vspace{0.15cm}
|
|
Which \emph{three} dimensions differ most strongly between the requirements profile of a \textbf{self-hosted compliance deployment (500 users, banking client)} and a \textbf{global consumer platform (150 million users)}?
|
|
|
|
\vspace{0.15cm}
|
|
Would any weight flip from L to H?
|
|
|
|
\vspace{0.15cm}
|
|
What does that imply for the claim that ``the application class determines the profile''?
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% STEPPING BACK
|
|
% ============================================
|
|
\section{Stepping Back: Ten Profiles Side by Side}
|
|
|
|
\begin{frame}{Stepping back: ten profiles side by side -- three reading rules}
|
|
\footnotesize
|
|
Ten times the same movement -- what no single section could deliver is the view \emph{across} the ten; that is what this section adds. The consolidated table: $w_i(a)$, $S(a)$, $K(a)$ per class -- the \textbf{demand-side counterpart of the capability table} (week 6), one of the two inputs to the fit matrix of Part IV.
|
|
|
|
\vspace{0.1cm}
|
|
\begin{enumerate}\setlength\itemsep{3pt}
|
|
\item \textbf{Read columns to see a class:} each column repeats the per-class table of its section cell for cell; every H is backed by a binding scenario with a response measure
|
|
\item \textbf{Read rows to see what a dimension discriminates:} D7 (evolvability) is High in six classes and Low in none -- long life is the norm, not the exception -- and Medium exactly in the four classes taught today \textcolor{codegray}{(read off the table)}; D12 is High only in C10, the definitional case
|
|
\item \textbf{The seventeen footnotes are part of the table's semantics, not decoration:} testability as reproducibility in C6 (note 14), as eval pass rate in C10 (note 15), read scalability as OLAP scan capacity in C7 (note 7); the D4 row of C6--C9 carries the same letter M with four footnoted meanings (notes 8, 10, 11, 12) \textcolor{codegray}{(read off the table)} -- \emph{using the bare letter without its footnote produces wrong matches in Part IV}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The consolidated requirements table (1/2): D1--D6}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\setlength{\tabcolsep}{1.5pt}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.4cm}*{10}{>{\centering\arraybackslash}p{1.03cm}}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{C1}\newline\tiny core banking & \textbf{C2}\newline\tiny social/ content & \textbf{C3}\newline\tiny back-office & \textbf{C4}\newline\tiny ERP & \textbf{C5}\newline\tiny e-commerce & \textbf{C6}\newline\tiny simulation/ batch & \textbf{C7}\newline\tiny DSS/BI & \textbf{C8}\newline\tiny IoT streaming & \textbf{C9}\newline\tiny collab/ messaging & \textbf{C10}\newline\tiny AI-native advisory \\
|
|
\midrule
|
|
D1 Read scalability & M & \textbf{H} & L & L & \textbf{H} & L & \textbf{H}\textsuperscript{7} & M & M\textsuperscript{9} & M \\
|
|
D2 Write scal.\ \& elasticity & M & M\textsuperscript{1} & L & L & \textbf{H} & \textbf{H}\textsuperscript{2} & L & \textbf{H} & M\textsuperscript{9} & L \\
|
|
D3 Latency & M\textsuperscript{3} & \textbf{H} & M & M & \textbf{H} & L\textsuperscript{4} & M & \textbf{H} & \textbf{H} & M\textsuperscript{5} \\
|
|
D4 Consistency \& integrity & \textbf{H} & L & \textbf{H} & \textbf{H} & M\textsuperscript{6} & M\textsuperscript{8} & M\textsuperscript{10} & M\textsuperscript{11} & M\textsuperscript{12} & M\textsuperscript{13} \\
|
|
D5 Availability \& isolation & \textbf{H} & \textbf{H} & L & M & \textbf{H} & L & L & \textbf{H} & \textbf{H} & M \\
|
|
D6 Security \& auditability & \textbf{H} & M & \textbf{H} & \textbf{H} & \textbf{H} & M & M & L & M & \textbf{H} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Superscripts refer to the seventeen footnotes (next frames) -- integral to the cell semantics. H $=$ High (veto trigger), M $=$ Medium, L $=$ Low.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The consolidated requirements table (2/2): D7--D12 and $S(a)$}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\setlength{\tabcolsep}{1.5pt}%
|
|
\begin{center}
|
|
\begin{tabular}{@{}>{\raggedright\arraybackslash}p{2.4cm}*{10}{>{\centering\arraybackslash}p{1.03cm}}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{C1}\newline\tiny core banking & \textbf{C2}\newline\tiny social/ content & \textbf{C3}\newline\tiny back-office & \textbf{C4}\newline\tiny ERP & \textbf{C5}\newline\tiny e-commerce & \textbf{C6}\newline\tiny simulation/ batch & \textbf{C7}\newline\tiny DSS/BI & \textbf{C8}\newline\tiny IoT streaming & \textbf{C9}\newline\tiny collab/ messaging & \textbf{C10}\newline\tiny AI-native advisory \\
|
|
\midrule
|
|
D7 Evolvability & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & M & M & M & M & \textbf{H} \\
|
|
D8 Simplicity \& TTM & L & M & \textbf{H} & M & M & M & M & L & M & M \\
|
|
D9 Testability \& deployability & \textbf{H} & \textbf{H} & M & M & \textbf{H} & \textbf{H}\textsuperscript{14} & M & M & M & \textbf{H}\textsuperscript{15} \\
|
|
D10 Operating cost & L & M & \textbf{H} & M & M & \textbf{H} & \textbf{H} & M & M & \textbf{H}\textsuperscript{16} \\
|
|
D11 Team scaling & M & \textbf{H} & L & M & M\textsuperscript{17} & L & L & M & M & L \\
|
|
D12 AI integrability & M & M & L & L & M & M & M & M & L & \textbf{H} \\
|
|
\midrule
|
|
Dominant workload shape $S(a)$ & \tiny interactive ($+$ batch edges) & \tiny interactive read-heavy & \tiny interactive & \tiny interactive ($+$ batch runs) & \tiny interactive, seasonal & \tiny scheduled batch & \tiny batch $+$ thin serving & \tiny continuous stream & \tiny interactive, connection-stateful & \tiny hybrid: interactive $+$ batch/async \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize The D12 row: one H -- the definitional case. The D7 row: six H, no L -- and M exactly in C6--C9. The $S(a)$ row feeds the shape gate of stage 1.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Hard constraints $K(a)$ -- the knock-out row}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{C1 core banking:} BCBS 239; FINMA 2023/1; DORA (EU 2022/2554); ACID booking core; 10+ yr retention
|
|
\item \textbf{C2 social/content:} DSA; GDPR
|
|
\item \textbf{C3 back-office:} retention law (e.g.\ OR 958\emph{f}); internal control systems; GDPR
|
|
\item \textbf{C4 ERP:} GoBD/GeB\"uV; SOX; IFRS audit chains
|
|
\item \textbf{C5 e-commerce:} PCI DSS v4.0 scope minimisation; PSD2/SCA
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{C6 simulation/batch:} model validation and backtesting (finance); deterministic seeds
|
|
\item \textbf{C7 DSS/BI:} BCBS 239 lineage (banks)
|
|
\item \textbf{C8 IoT streaming:} per-key ordering; exactly-once where stated
|
|
\item \textbf{C9 collab/messaging:} compliance archiving (MiFID/FINRA) in enterprise segments
|
|
\item \textbf{C10 AI-native advisory:} EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.25cm}
|
|
\textbf{Reading:} $K(a)$ feeds stage 1 of the match (knock-out) together with the shape gate; C8's entry is \emph{technical rather than statutory}; C6's pairs a supervisory duty (Basel model validation and backtesting) with a technical one (deterministic seeds).
|
|
\end{frame}
|
|
|
|
\begin{frame}{The seventeen footnotes are part of the semantics (1/2): notes 1--9}
|
|
\scriptsize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item[$^{1}$] \textbf{C2, D2 $=$ M:} raw write rate is modest (Twitter: ca.\ 6\,k tweet writes/s vs.\ ca.\ 300\,k timeline reads/s); fan-out amplification is real but absorbed by the fan-out subsystem, not the write path
|
|
\item[$^{2}$] \textbf{C6, D2 $=$ H:} throughput as makespan and batch-window compute bursts, not requests/s
|
|
\item[$^{3}$] \textbf{C1, D3 $=$ M:} class-internal spread of orders of magnitude -- batch clearing hours, instant payments $<10$\,s end-to-end, card authorisation 1--2\,s, trading microseconds
|
|
\item[$^{4}$] \textbf{C6, D3 $=$ L:} per-request latency irrelevant; makespan and batch window are the measures
|
|
\item[$^{5}$] \textbf{C10, D3 $=$ M:} users accept seconds-to-minutes for advisory answers; the High-grade concern is cost per request, not speed
|
|
\item[$^{6}$] \textbf{C5, D4 $=$ M:} the class-defining hybrid -- catalogue eventual, checkout/payment strictly ACID
|
|
\item[$^{7}$] \textbf{C7, D1 $=$ H:} ``read'' means heavy OLAP scans by few users; serving typically delegated to the warehouse
|
|
\item[$^{8}$] \textbf{C6, D4 $=$ M:} bit-level reproducibility (seeds, versioned inputs) -- a scientific and, for risk models, regulatory duty
|
|
\item[$^{9}$] \textbf{C9, D1/D2 $=$ M:} connection fan-out and push, not raw read/write rates, are the binding load (Slack: $>5$\,M concurrent WebSockets); hence M with the crux carried by D3/D5
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The seventeen footnotes are part of the semantics (2/2): notes 10--17 and the rule}
|
|
\scriptsize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item[$^{10}$] \textbf{C7, D4 $=$ M:} a third semantics beside ACID and eventual -- freshness by refresh contract (``as of yesterday 24:00'')
|
|
\item[$^{11}$] \textbf{C8, D4 $=$ M:} stream semantics -- exactly-once state, event-time windows, watermarks
|
|
\item[$^{12}$] \textbf{C9, D4 $=$ M:} causal order per channel suffices; global order unnecessary
|
|
\item[$^{13}$] \textbf{C10, D4 $=$ M:} hybrid -- knowledge index eventual, transaction/audit path ACID
|
|
\item[$^{14}$] \textbf{C6, D9 $=$ H:} reproducibility (golden datasets, versioned pipelines) is the operative meaning of testability
|
|
\item[$^{15}$] \textbf{C10, D9 $=$ H:} evals are the operative meaning of testability (Part V)
|
|
\item[$^{16}$] \textbf{C10, D10 $=$ H:} cost per \emph{request} (tokens, GPU) -- a run-cost class no classical profile contains
|
|
\item[$^{17}$] \textbf{C5, D11 $=$ M:} organisation-size dependent -- the Shopify-vs-Amazon contrast
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize An H in the table is a \textbf{veto trigger} backed by a scenario with a response measure; an L is a \textbf{licence to not pay} for that dimension. The footnotes carry class-specific semantics that the letters alone cannot: \emph{whoever matches profiles by letters without footnotes has not read the table}.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading rows: what discriminates -- the two questions to ask first}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.8}%
|
|
\vspace{-0.3cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{3.6cm}p{5.2cm}p{2.6cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{High in} & \textbf{Count} \\
|
|
\midrule
|
|
D1 Read scalability & C2, C5, C7 & 3 \\
|
|
D2 Write scal.\ \& elasticity & C5, C6, C8 & 3 \\
|
|
D3 Latency & C2, C5, C8, C9 & 4 \\
|
|
D4 Consistency \& integrity & C1, C3, C4 & 3 \\
|
|
D5 Availability \& isolation & C1, C2, C5, C8, C9 & 5 \\
|
|
D6 Security \& auditability & C1, C3, C4, C5, C10 & 5 \\
|
|
D7 Evolvability & C1, C2, C3, C4, C5, C10 & 6 (Low in none) \\
|
|
D8 Simplicity \& TTM & C3 & 1 \\
|
|
D9 Testability \& deployability & C1, C2, C5, C6, C10 & 5 \\
|
|
D10 Operating cost & C3, C6, C7, C10 & 4 \\
|
|
D11 Team scaling & C2 & 1 \\
|
|
D12 AI integrability & C10 & 1 \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\textcolor{codegray}{(H positions read off the consolidated table.)}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize \textbf{Observation 1 -- the strongest discriminators are the read/write ratio (the D1/D2 rows) and the consistency semantics (the D4 row).} C1 (write-critical, strict ACID) and C2 (roughly 50:1 read-heavy, deliberately eventual) are mirror images across both at once -- the fastest diagnostic pair in the catalogue. \emph{When classifying an unknown system, ask these two questions first}: they eliminate more patterns via the shape gate and the D4 row than any other pair.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the catalogue as a whole (1/3): scale does not force microservices}
|
|
\footnotesize
|
|
\textbf{Observation 2 -- scale does not force microservices.} The documented monolith-at-scale cases span four classes \textcolor{codegray}{(all cases met in weeks 3--6; now read from the demand side)}:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{2.4cm}>{\raggedright\arraybackslash}p{5.6cm}>{\raggedright\arraybackslash}p{5.0cm}@{}}
|
|
\toprule
|
|
\textbf{System} & \textbf{Documented scale} & \textbf{Structure} \\
|
|
\midrule
|
|
Instagram & global consumer platform & horizontally replicated Django monolith \\
|
|
Stack Overflow & $\sim 1.3$ billion page views/month, $> 6{,}000$ requests/s & roughly nine on-premise web servers, monolithic .NET application \\
|
|
Shopify & ca.\ 280 million requests/min at BFCM peak & pod-sharded modular Rails monolith \\
|
|
LMAX & six million orders/s & one thread \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
Stateless replication, sharding and mechanical sympathy scale monoliths far; what microservices primarily solve is an \emph{organisational} scaling problem -- deployments per developer as team count grows. \textbf{In profile terms: D1/D2 rarely force distribution; D11 $=$ H is what does.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the catalogue as a whole (2/3): rollbacks and regulation}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{6pt}
|
|
\setcounter{enumi}{2}
|
|
\item \textbf{The rollback case studies share one pattern.} Segment and Prime Video both cut \emph{one} coherent dataflow along technical rather than domain seams -- one service per integration destination, one function per processing step -- and the interaction costs (queues, orchestrator state transitions, storage round-trips, the test matrix) consumed the benefit. Granularity must follow the coupling structure of the domain. For the catalogue: \textbf{a class's workload shape is not merely a gate for pattern selection -- it also predicts where the expensive boundaries lie \emph{within} a pattern}
|
|
\item \textbf{Regulation is a first-class architectural requirement.} $K(a)$ translates directly into structure: BCBS~239 and FINMA 2023/1 into immutable journals, lineage and resilience testing; DORA into incident-reporting and third-party risk machinery; PCI~DSS v4.0 into cardholder-data zoning and scope minimisation; the EU AI Act into logging and human-oversight duties for AI components. None can be bolted on late at reasonable cost -- \textbf{Booch-significant decisions}, which is exactly why they live in $K(a)$ as knock-outs rather than in the weights
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the catalogue as a whole (3/3): inheritance}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{4pt}
|
|
\setcounter{enumi}{4}
|
|
\item \textbf{The AI-native class inherits before it innovates.} C10 inherits the disciplines of C6/C7 (batch index and eval pipelines) and C3 (deterministic transactional services), and adds exactly \textbf{two} genuinely new elements: a cost model that is expensive per request rather than per user, and evals as the operative meaning of testability. \emph{Design instruction for the project in one sentence: solve the inherited profiles with the inherited, well-understood structures, and concentrate the architectural attention on the two novelties}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The other operand is ready}
|
|
\begin{keypoint}
|
|
\footnotesize The ten requirements profiles are \textbf{derivable, not arbitrary}: every weight traces to binding scenarios with response measures, every constraint to a statute or a contract, every workload signature to documented production numbers. \textbf{The other operand is ready}: Part IV matches these profiles against the capability profiles of Part II cell by cell (the fit matrix), and every cell can be traced back to $R(a) \times C(p)$ rather than to fashion or taste.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{thinkbox}
|
|
\footnotesize The catalogue contains ten classes -- why not nine, why not fourteen?
|
|
|
|
\vspace{0.1cm}
|
|
Propose a candidate eleventh class (for example: computer games, embedded control, blockchain ledgers) and test it against the definition of an application class: a \emph{recurring} ASR bundle with typical response measures, a characteristic workload shape, a regulatory frame.
|
|
|
|
\vspace{0.1cm}
|
|
Does its profile differ from all ten columns of the consolidated table on at least \textbf{two High weights}? If it does not differ, it is an instance, not a class.
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: the walking skeleton runs end-to-end (M3 closes)}
|
|
\begin{projektbox}
|
|
\footnotesize \textbf{Coaching session (1 lesson): finish the walking skeleton.}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{Milestone check M3 (week 9):} the end-to-end thin slice runs -- \texttt{MarketDataService} delivers prices $\to$ a \emph{minimal} \texttt{ResearchAgent} produces \textbf{one validated \texttt{Insight}} $\to$ through the \textbf{stable API}; a placeholder UI calls it
|
|
\item \textbf{Checklist from the exercise sheet:} keep the deterministic core \textbf{free of LLM calls} (the line that is graded); use a \textbf{snapshot} of market/news data so demo and grading are reproducible even if the live APIs misbehave; commit after the milestone; record decisions as ADRs as you go
|
|
\item \textbf{Today's lecture applied:} your ingestion and eval pipelines are \textbf{C6}, your analytics are \textbf{C7} -- the skeleton should already show where an \texttt{Insight}'s freshness stamp comes from
|
|
\end{itemize}
|
|
\end{projektbox}
|
|
|
|
\vspace{0.15cm}
|
|
\small \textbf{Next:} weeks 10--11 (M4) -- \texttt{Performance}, \texttt{Risk}, \texttt{Optimization} services with exact tests against the reference vectors; resilience on all external calls.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{C6} replaces the interactive vocabulary wholesale -- makespan, batch-window adherence, cost per simulation; correctness $=$ bit-level reproducibility (Highs D2/D9/D10); with C7 it defines the \textbf{third consistency semantics}: ``as of this run'' and ``as of yesterday 24:00'' -- contracts with response measures
|
|
\item \textbf{C7}: an integration product over C1--C5; Highs D1 (OLAP scans, delegated) and D10 (the warehouse bill); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8
|
|
\item \textbf{C8}: keep pace with the world indefinitely; the hard requirement is declared correctness semantics under failure (Highs D2/D3/D5); at-least-once $+$ idempotence decided per stream, per scenario
|
|
\item \textbf{C9}: the binding load is connection fan-out and push (Highs D3/D5); same domain, four structures -- the measured concurrent-connection count is the tiebreaker
|
|
\item \textbf{Five observations}: read/write ratio and consistency semantics discriminate most; scale does not force microservices (D11 $=$ H does); rollbacks cut dataflows along technical seams; regulation lives in $K(a)$; C10 inherits before it innovates
|
|
\item \textbf{The consolidated table}: an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics -- \textbf{the other operand is ready}: $R(a) \times C(p)$, every cell traceable, none to fashion or taste
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 10 -- Part IV continued: hybrids, evolution paths, the eight-step procedure}}
|
|
\begin{itemize}\small
|
|
\item hybrids and evolution paths: Segment, Prime Video, Shopify
|
|
\item the eight-step decision procedure with the worked course-project run (ADR-007)
|
|
\item the cell rationales of the matrix, row by row
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part III, Sections 24--27, 29
|
|
\item ahead: Part IV, Sections 33, 35--36
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item coaching; deterministic services (\texttt{Performance}, \texttt{Risk}, \texttt{Optimization}) with exact tests against the reference vectors (M4 begins)
|
|
\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}
|