herzogfloria/AISE502
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Slides 1-8: introduce every abbreviation at first use; add monolith/microservices primer to deck 1

Browse Source 
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>
This commit is contained in:
herzogflorian 2026-09-16 15:38:35 +02:00
parent d82452b764
commit 130da6298f
15 changed files with 378 additions and 169 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Folien/AISE502_Vorlesung_1_Folien.pdf
View File

Binary file not shown.

241
Folien/AISE502_Vorlesung_1_Folien.tex
View File

@ -132,6 +132,7 @@
\begin{frame}{Agenda}
\begin{enumerate}
\item The module: aims, assessment, semester plan, project
\item Monolith and microservices: a first look
\item Four production systems -- two facts
\item The decision problem
\item What software architecture is (and is not)
@ -171,7 +172,7 @@ After this module you can \dots
\item construct a \textbf{requirements profile} $R(a)$: scenarios with response measures, utility tree, weights
\item derive the \textbf{capability profile} $C(p)$ of seven architectural patterns from their tactics
\item run the \textbf{three-stage, non-compensatory match} and defend the result
\item record decisions as \textbf{ADRs} and attach a \textbf{measurement contract} (fitness functions, DORA)
\item record decisions as \textbf{architecture decision records (ADRs)} and attach a \textbf{measurement contract} -- fitness functions and the four delivery metrics of DORA (DevOps Research and Assessment)
\item engineer \textbf{AI components} into a system (Axis B) and use \textbf{AI tools} in the process (Axis A) -- with the same discipline
\end{itemize}
\end{frame}
@ -224,10 +225,10 @@ After this module you can \dots
\begin{frame}{The course project}
\begin{projektbox}
You will design and build an \textbf{AI-augmented portfolio intelligence platform} (exercise sheet): market prices and company news in; deterministic risk, performance, and optimisation services; an LLM component turning news into validated \texttt{Insight}s; a multi-agent advisor that explains -- API-first. Everything this module teaches -- profiles, matching, ADRs, measurement -- you will apply to \emph{this} system, and defend at the end.
You will design and build an \textbf{AI-augmented portfolio intelligence platform} (exercise sheet): market prices and company news in; deterministic risk, performance, and optimisation services; a large language model (LLM) component turning news into validated \texttt{Insight}s; a multi-agent advisor that explains -- API-first. Everything this module teaches -- profiles, matching, ADRs, measurement -- you will apply to \emph{this} system, and defend at the end.
\end{projektbox}
\vspace{0.2cm}
\vspace{0.05cm}
\textbf{This week (kickoff exercise):}
\begin{itemize}
\item form teams; set up repository and tooling (including agentic coding tools)
@ -235,14 +236,13 @@ You will design and build an \textbf{AI-augmented portfolio intelligence platfor
\item collect \emph{raw} stakeholder wishes -- unfiltered, unweighted
\end{itemize}
\vspace{0.05cm}
\textcolor{codegray}{\small Next week those wishes become \emph{scenarios}; in week 3 they become your requirements profile (deliverable A1).}
\end{frame}
% ============================================
% SECTION 2: FOUR SYSTEMS, TWO FACTS
% SECTION 2: MONOLITH AND MICROSERVICES -- A FIRST LOOK
% ============================================
\section{Four Production Systems -- Two Facts}
\section{Monolith and Microservices: A First Look}
\begin{frame}{Discussion}
\begin{thinkbox}
@ -253,8 +253,218 @@ You will design and build an \textbf{AI-augmented portfolio intelligence platfor
\item How would you even \emph{decide} -- and how would you defend the decision a year later?
\end{itemize}
\end{thinkbox}
\vspace{0.3cm}
\small Before the evidence, the two words themselves -- the next six slides give each structure a picture, its purpose, and its price. Part II of the script rates both in full (weeks 4--5).
\end{frame}
\begin{frame}{The monolith: one deployable -- classically cut into layers}
\begin{columns}[T]
\begin{column}{0.42\textwidth}
\begin{center}
\resizebox{\textwidth}{!}{%
\begin{tikzpicture}[
sysbox/.style={rectangle, draw, rounded corners=4pt, minimum width=3.2cm, minimum height=1.2cm, align=center, font=\small\sffamily, line width=0.8pt},
layer/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=7.2cm, minimum height=0.95cm},
extern/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=7.2cm, minimum height=0.95cm},
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
]
\node[layer] (pres) at (0,0) {Presentation layer};
\node[layer, below=0.45cm of pres] (biz) {Business layer};
\node[layer, below=0.45cm of biz] (pers) {Persistence layer};
\node[extern, below=0.45cm of pers] (db) {Database};
\draw[arr] (pres) -- (biz);
\draw[arr] (biz) -- (pers);
\draw[arr] (pers) -- (db);
\draw[dashed, gray!60!black, rounded corners=6pt]
([xshift=-0.5cm,yshift=0.35cm]pres.north west) rectangle ([xshift=0.5cm,yshift=-0.35cm]db.south east);
\node[font=\footnotesize\sffamily, text=gray!60!black, below=0.15cm of db, yshift=-0.35cm, align=center]
{one deployment unit: deployed, scaled,\\and failing as a whole};
\draw[-{Stealth[length=2.5mm]}, thick, bankred, dashed]
([xshift=-1.3cm]pres.west) -- ([xshift=-1.3cm]db.west)
node[midway, left, font=\footnotesize\sffamily, text=bankred, align=center] {typical\\feature\\change};
\end{tikzpicture}%
}
\end{center}
\end{column}
\begin{column}{0.56\textwidth}
\begin{definitionbox}[Monolith]
\footnotesize A system delivered as \textbf{one deployment unit}: one build, one artefact, one process, typically one database -- deployed, scaled, and failing \textbf{as a whole}. In this module's vocabulary: \emph{one architecture quantum}.
\end{definitionbox}
\vspace{0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
\item classical interior: \textbf{layered} (``3-tier'') -- horizontal \emph{technical} layers with one rule: \textbf{dependencies point downwards only}
\item mirrors technology and team: something renders screens, something runs rules, something persists rows
\item the default scaffold of Spring MVC, .NET, Rails, Django -- most business software ever built
\item structural weakness (dashed red): a business feature cuts across \textbf{every} layer
\end{itemize}
\end{column}
\end{columns}
\end{frame}
\begin{frame}{The modular monolith: same deployable, domain-cut interior}
\begin{center}
\resizebox{0.64\textwidth}{!}{%
\begin{tikzpicture}[
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt},
module/.style={sysbox, fill=bankblue!20, draw=bankblue, minimum width=3.0cm, minimum height=1.1cm, font=\small\sffamily\bfseries},
data/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=3.0cm, minimum height=0.8cm, font=\footnotesize\sffamily},
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
darr/.style={{Stealth[length=2.5mm]}-{Stealth[length=2.5mm]}, thick, bankgreen}
]
\node[module] (m1) at (-4.2,0) {Portfolio\\module};
\node[module] (m2) at (0,0) {Instrument\\module};
\node[module] (m3) at (4.2,0) {Reporting\\module};
\node[data, below=0.5cm of m1] (d1) {owned tables};
\node[data, below=0.5cm of m2] (d2) {owned tables};
\node[data, below=0.5cm of m3] (d3) {owned tables};
\draw[arr] (m1) -- (d1);
\draw[arr] (m2) -- (d2);
\draw[arr] (m3) -- (d3);
\draw[darr] (m1) -- node[above, font=\footnotesize\sffamily, text=bankgreen] {public API /} node[below, font=\footnotesize\sffamily, text=bankgreen] {in-process events} (m2);
\draw[darr] (m2) -- node[above, font=\footnotesize\sffamily, text=bankgreen] {public API /} node[below, font=\footnotesize\sffamily, text=bankgreen] {in-process events} (m3);
\draw[rounded corners=6pt, line width=1pt, gray!60!black]
(-6.1,1.1) rectangle (6.1,-2.6);
\node[font=\footnotesize\sffamily, text=gray!60!black, align=center] at (0,-3.05)
{single deployable: one process, one architecture quantum};
\node[font=\footnotesize\sffamily, text=bankred, align=center] at (0,1.55)
{boundary conformance verified in the build pipeline (ArchUnit, Spring Modulith, Packwerk)};
\end{tikzpicture}%
}
\end{center}
\vspace{0.1cm}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
\item keeps the monolith's economics -- one process, one build, one database -- but replaces technical layers with \textbf{domain modules}: each owns its data and talks to the others only through a published API (application programming interface) or in-process events
\item the boundaries are \textbf{enforced by tools}, not by good intentions: a violation fails the build in CI (continuous integration), not a code review
\item canonical case: \textbf{Shopify} -- more than $2.8$ million lines of Ruby, deliberately \emph{not} microservices; Black Friday peaks of $\sim 280$ million requests/minute carried by replicating whole monolith instances (``pods'')
\end{itemize}
\end{frame}
\begin{frame}{The monolith: what it buys, what it costs}
\footnotesize
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\textcolor{bankgreen}{\textbf{What it buys}}
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{one build, one deployment, one thing to operate} -- the cheapest structure to ship and run at moderate scale
\item \textbf{transactions for free}: one database gives all-or-nothing consistency (ACID: atomic, consistent, isolated, durable) without any distributed protocol
\item one process, one stack trace: the simplest system to \textbf{test and debug}
\item a small team can hold the whole system in its head
\end{itemize}
\end{column}
\begin{column}{0.48\textwidth}
\textcolor{bankred}{\textbf{What it costs}}
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{blast radius $100\,\%$}: one process -- when it dies, everything dies
\item scaling only \textbf{as a whole}: scale \emph{up} (bigger machines -- Stack Overflow) or replicate whole copies (Shopify's pods), never one hot part alone
\item \textbf{one release train}: every team ships together, on the same cadence
\item without enforced boundaries it decays into the \emph{big ball of mud} -- the failure mode the modular monolith exists to prevent
\end{itemize}
\end{column}
\end{columns}
\vspace{0.3cm}
\begin{hinweisbox}
\footnotesize ``Outdated''? Stack Overflow, Shopify, and Instagram serve hundreds of millions of users from monoliths. The pattern has a \textbf{price list}, not an expiry date -- and Part II prices every line of it.
\end{hinweisbox}
\end{frame}
\begin{frame}{Microservices: many independently deployable services}
\begin{definitionbox}[Microservices]
\footnotesize Small, \textbf{independently deployable services}, each modelled around one business capability, each owning its data exclusively (\emph{database per service}), communicating over lightweight network protocols. \textbf{Every service is its own architecture quantum} -- its own unit of deployment, scaling, and failure. (Lewis \& Fowler 2014; Newman 2021)
\end{definitionbox}
\begin{center}
\resizebox{0.49\textwidth}{!}{%
\begin{tikzpicture}[
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt},
gateway/.style={sysbox, fill=bankblue!20, draw=bankblue, minimum width=4.6cm, minimum height=0.95cm, font=\small\sffamily\bfseries},
svc/.style={sysbox, fill=bankgreen!15, draw=bankgreen, minimum width=2.9cm, minimum height=1.0cm},
data/.style={sysbox, fill=gray!15, draw=gray!60!black, minimum width=2.9cm, minimum height=0.75cm, font=\footnotesize\sffamily},
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
saga/.style={-{Stealth[length=2.5mm]}, thick, bankred, dashed}
]
\node[gateway] (gw) at (0,2.6) {API gateway};
\node[svc] (s1) at (-4.2,0.6) {Catalogue\\service};
\node[svc] (s2) at (0,0.6) {Order\\service};
\node[svc] (s3) at (4.2,0.6) {Payment\\service};
\node[data, below=0.45cm of s1] (db1) {own database};
\node[data, below=0.45cm of s2] (db2) {own database};
\node[data, below=0.45cm of s3] (db3) {own database};
\draw[arr] (gw) -- (s1);
\draw[arr] (gw) -- (s2);
\draw[arr] (gw) -- (s3);
\draw[arr] (s1) -- (db1);
\draw[arr] (s2) -- (db2);
\draw[arr] (s3) -- (db3);
\draw[saga] (s2) -- node[above, font=\footnotesize\sffamily, text=bankred] {saga, no ACID} (s3);
\draw[dashed, gray!60!black, rounded corners=5pt] (-5.85,1.25) rectangle (-2.55,-1.75);
\draw[dashed, gray!60!black, rounded corners=5pt] (-1.65,1.25) rectangle (1.65,-1.75);
\draw[dashed, gray!60!black, rounded corners=5pt] (2.55,1.25) rectangle (5.85,-1.75);
\node[font=\footnotesize\sffamily, text=gray!60!black, align=center] at (0,-2.3)
{one quantum per service: own pipeline, own release, own blast radius, own database};
\end{tikzpicture}%
}
\end{center}
\textcolor{codegray}{\scriptsize API gateway $=$ the single entry point routing client requests to the right service. ACID transactions exist \emph{inside} a service; across services, consistency is stitched together by a \emph{saga} (next slides).}
\end{frame}
\begin{frame}{The problem microservices solve is organisational}
\footnotesize
By the mid-2000s Amazon -- and a few years later Netflix -- had \textbf{hundreds of teams contributing to shared deployables}. A shared deployable means a shared \textbf{release train}: every team's change waits on every other team's; integration scope grows with the \emph{organisation}, not with the change; one team's defect rolls back everyone's release. Past a certain size, \emph{the queue for the release train} -- not compute, not traffic -- limits how fast the company ships.
\vspace{0.15cm}
\begin{keypoint}
\footnotesize \textbf{Make the team's unit of ownership the system's unit of deployment.} Cut the system along business capabilities, give each service its own data and its own pipeline, and let each team release on its own -- ``you build it, you run it.''
\end{keypoint}
\vspace{0.15cm}
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{Conway's law} made deliberate: a system's structure mirrors the communication structure of the organisation that builds it -- microservices choose that mirror on purpose
\item the empirical support is organisational: in high-performing organisations, deployment frequency \textbf{grows with team count} instead of collapsing under coordination (DORA -- DevOps Research and Assessment)
\item ``micro'' names \textbf{independence}, not lines of code -- service size is the secondary question
\end{itemize}
\end{frame}
\begin{frame}{Microservices: what they buy, what they cost}
\footnotesize
\begin{columns}[T]
\begin{column}{0.46\textwidth}
\textcolor{bankgreen}{\textbf{What they buy}}
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{independent release} per team -- no shared release train
\item \textbf{independent scaling}: replicate only the hot service
\item \textbf{fault isolation}: blast radius one service -- when built for it
\item technology freedom per service
\end{itemize}
\end{column}
\begin{column}{0.52\textwidth}
\textcolor{bankred}{\textbf{What they cost}}
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{no transaction across services}: an invariant spanning order $\to$ stock $\to$ payment becomes a \emph{saga} -- local transactions with compensating actions; intermediate states are visible
\item \textbf{every call is a network call}: latency, partial failure, retries, timeouts
\item the \textbf{``microservice premium''}: platform team, orchestration, service discovery, observability -- \emph{before} the first feature
\item hardest to test end to end; Segment: $> 140$ services crushed a small team
\end{itemize}
\end{column}
\end{columns}
\vspace{0.1cm}
\begin{hinweisbox}
\footnotesize ``The professional default''? Netflix and Amazon needed the pattern because of \textbf{organisational size}; Segment paid the premium without the organisation. Whether it fits \emph{your} system is the question this module makes decidable.
\end{hinweisbox}
\end{frame}
% ============================================
% SECTION 3: FOUR SYSTEMS, TWO FACTS
% ============================================
\section{Four Production Systems -- Two Facts}
\begin{frame}{Four production systems, four structures}
\footnotesize
\begin{center}
@ -265,7 +475,7 @@ You will design and build an \textbf{AI-augmented portfolio intelligence platfor
Stack Overflow & \texttt{.NET} monolith, $\sim 9$ on-premise web servers & $\sim 1.3$ billion page views/month at $\sim 12$\,ms render -- scaled \emph{up}, not \emph{out} \\
Monzo & $\sim 2{,}800$ Go microservices; one language, one monorepo & retail banking at scale -- viable through extreme technological homogeneity \\
Segment & $> 140$ microservices, one per analytics destination & public 2018 \textbf{rollback to a monolith}: complexity crushed a small team \\
Prime Video & serverless orchestration: Step Functions, Lambda, S3 & consolidation into one process cut infrastructure cost by $> 90\,\%$ \\
Prime Video & serverless orchestration on AWS: Step Functions, Lambda, S3 & consolidation into one process cut infrastructure cost by $> 90\,\%$ \\
\bottomrule
\end{tabular}
\end{center}
@ -358,7 +568,7 @@ a conformant architecture description \textbf{must record architecture decisions
\end{itemize}
\vspace{0.1cm}
\textcolor{bankblue}{\textbf{4. Structural-analytic (SEI)}}
\textcolor{bankblue}{\textbf{4. Structural-analytic (SEI, Software Engineering Institute)}}
\begin{itemize}\setlength\itemsep{1pt}
\item ``the set of structures needed to reason about the system''
\item functionality is structure-neutral; structure determines \emph{how well}
@ -440,7 +650,7 @@ Every judgement in this module must trace to a \textbf{measurable} property of a
\begin{frame}{The framework as a pipeline -- and the map of the script}
\begin{center}
\resizebox{0.94\textwidth}{!}{%
\resizebox{0.90\textwidth}{!}{%
\begin{tikzpicture}[
node distance=0.9cm and 1.0cm,
sysbox/.style={rectangle, draw, rounded corners=4pt, text width=3.2cm, minimum height=1.3cm, align=center, font=\small\sffamily, line width=0.8pt},
@ -467,14 +677,15 @@ Every judgement in this module must trace to a \textbf{measurable} property of a
\end{center}
\vspace{0.15cm}
\small Demand is matched against supply; the match ends in a \textbf{recorded decision} with a \textbf{measurement contract} -- and operation continuously tests whether the decision's promises hold. The dashed edge is not decoration.
\small Demand is matched against supply; the match ends in a \textbf{recorded decision} with a \textbf{measurement contract} -- and operation continuously tests whether the decision's promises hold. The dashed edge is not decoration.\\[0.05cm]
\textcolor{codegray}{\scriptsize CI/CD $=$ continuous integration / continuous delivery pipeline; DORA $=$ DevOps Research and Assessment, four delivery metrics; SLO $=$ service level objective, a stated availability or latency target.}
\end{frame}
\begin{frame}{The two AI axes of this module}
\begin{ailinse}[Where AI enters -- twice]
\begin{itemize}
\item \textbf{Axis A -- AI as a tool in the development process:} assistants and agents generate code, tests, documentation -- changing \emph{how} we make and guard architectural decisions.
\item \textbf{Axis B -- AI as a runtime component of the system:} an LLM, an ML model, an optimiser \emph{inside} the architecture -- bringing non-determinism, seconds-scale latency, per-call cost -- changing \emph{what} we must decide about.
\item \textbf{Axis B -- AI as a runtime component of the system:} an LLM, a machine-learning (ML) model, an optimiser \emph{inside} the architecture -- bringing non-determinism, seconds-scale latency, per-call cost -- changing \emph{what} we must decide about.
\end{itemize}
\end{ailinse}
@ -546,7 +757,7 @@ A6 & AI extends the space, not the method & D12 $+$ eval harness -- nothing else
\begin{itemize}\setlength\itemsep{1pt}
\item ``the system shall be scalable'' decides nothing and tests nothing
\item decision-relevant only as a six-part scenario with a \textbf{response measure} -- number and unit
\item empirically, such requirements are vague and implicit -- they must be \emph{elicited} (next week: QAW, utility tree)
\item empirically, such requirements are vague and implicit -- they must be \emph{elicited} (next week: the Quality Attribute Workshop (QAW), the utility tree)
\end{itemize}
\end{frame}
@ -562,7 +773,7 @@ A6 & AI extends the space, not the method & D12 $+$ eval harness -- nothing else
\textbf{A6 -- AI components extend the quality attribute space but do not change the method.}
\begin{itemize}\setlength\itemsep{1pt}
\item non-deterministic, fallible, latency-heavy, priced per call, subject to drift -- yet ISO/IEC 25010:2023 already carries the vocabulary (Safety, Flexibility, Security/resistance)
\item AI is \textbf{absorbed}: one new dimension (D12) $+$ one new test artefact (eval harness) -- \emph{the method stays}
\item AI is \textbf{absorbed}: one new dimension (D12) $+$ one new test artefact (the eval harness: an automated evaluation suite for AI behaviour) -- \emph{the method stays}
\end{itemize}
\end{frame}
@ -603,7 +814,7 @@ Forget frameworks for a moment. You are responsible -- personally -- for a syste
\begin{frame}{\dots and the questions keep coming}
\small
\begin{itemize}\setlength\itemsep{3pt}
\item \emph{Two students must ship a working MVP in one semester: does the structure let them -- or does it demand a platform team they do not have?}
\item \emph{Two students must ship a working MVP (minimum viable product) in one semester: does the structure let them -- or does it demand a platform team they do not have?}
\item \emph{The monthly cloud bill triples: which part of the structure is spending the money, and what was it doing at 03:00?}
\item \emph{The team grows from three to thirty: do releases get faster -- or does everyone now wait for everyone else?}
\item \emph{Product adds a feature whose core is an LLM call: it takes eight seconds, costs money on every single request, and is sometimes confidently wrong. Where does that live in the architecture?}
@ -688,7 +899,7 @@ Pick an app you use daily.
\item D1--D12 one by one: question, vocabulary, instrument
\item why exactly these twelve (ISO/IEC 25010:2023)
\item six-part quality attribute scenarios
\item ASR, Quality Attribute Workshop
\item architecturally significant requirements (ASRs); the Quality Attribute Workshop (QAW)
\item the utility tree: from scenarios to \textbf{weights}
\end{itemize}
\end{column}

44
Folien/AISE502_Vorlesung_2_Folien.tex
View File

@ -146,7 +146,7 @@
\item Economics and organisation: D10--D11
\item The new dimension: D12 (AI integrability)
\item Why exactly these twelve -- ISO/IEC 25010:2023
\item From wishes to scenarios: ASR, QAW, the six-part form
\item From wishes to scenarios: architecturally significant requirements (ASRs), the Quality Attribute Workshop (QAW), the six-part form
\item The utility tree: from scenarios to weights
\item Workload shape, hard constraints -- $R(a)$ assembled
\end{enumerate}
@ -162,7 +162,7 @@
\textbf{Last week:}
\begin{itemize}\setlength\itemsep{1pt}
\item Maxim 1: patterns are neither good nor bad -- only the \textbf{fit} is
\item the framework: $R(a) \to C(p) \to \mathrm{fit}(a,p) \to$ ADR $\to$ measurement contract
\item the framework: $R(a) \to C(p) \to \mathrm{fit}(a,p) \to$ ADR (architecture decision record) $\to$ measurement contract
\item six assumptions A1--A6; the chain \emph{demand $\to$ supply $\to$ match $\to$ record $\to$ test}
\item nine recurring on-call questions $\to$ five groups of dimensions
\end{itemize}
@ -197,7 +197,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\item Stack Overflow: $\sim 1.3$ billion page views/month from a handful of servers; Instagram: a monolith -- \textbf{the single write path is the hard part}
\end{itemize}
\measured{throughput at $k\times$ replication (does doubling servers double throughput?); cache hit ratio; p95 read latency}{step-profile load tests; production RED metrics (Rate, Errors, Duration)}
\measured{throughput at $k\times$ replication (does doubling servers double throughput?); cache hit ratio; p95 (95th-percentile) read latency}{step-profile load tests; production RED metrics (Rate, Errors, Duration)}
\end{frame}
\begin{frame}{D2 -- Write scalability and elasticity}
@ -208,7 +208,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\begin{itemize}\setlength\itemsep{2pt}
\item the D1 question for requests that \textbf{change} state -- the harder half: a write cannot be served from a copy; every order must reach the \emph{one authoritative record}, durably and in order
\item \textbf{elasticity} adds the time axis: how quickly capacity follows load -- up \emph{and back down}
\item reference point: Shopify's BFCM weekend, peaks $\sim 280$ million requests/minute, carried by replicated ``pods'' of a monolith
\item reference point: Shopify's BFCM (Black Friday / Cyber Monday) weekend, peaks $\sim 280$ million requests/minute, carried by replicated ``pods'' of a monolith
\item the opposite end: \textbf{scale-to-zero} -- costing nothing while unused (the serverless promise)
\end{itemize}
@ -227,7 +227,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\item stakes: Amazon $\sim 1\,\%$ of sales lost per additional $100$\,ms; Akamai: up to $7\,\%$ of conversions
\end{itemize}
\measured{p50/p95/p99 response times; cold-start frequency; tail-latency ratio}{distributed tracing (OpenTelemetry) -- following one request across every component; latency budgets as CI gates}
\measured{p50/p95/p99 response times; cold-start frequency; tail-latency ratio}{distributed tracing (OpenTelemetry) -- following one request across every component; latency budgets as CI (continuous integration) gates}
\end{frame}
% ============================================
@ -258,7 +258,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\begin{itemize}\setlength\itemsep{2pt}
\item availability: share of time the system does its job; fault isolation: \textbf{how much of the product dies when one part dies}
\item \textbf{blast radius}: \% of functionality lost per component failure -- in a single process it is $100\,\%$ \emph{by construction}; \textbf{MTTR}: mean time to recovery
\item operations vocabulary: \textbf{SLO} (``$99.9\,\%$ of requests succeed this month''), \textbf{error budget} (the tolerated $0.1\,\%$), \textbf{burn rate}
\item operations vocabulary: \textbf{SLO}, service level objective (``$99.9\,\%$ of requests succeed this month''), \textbf{error budget} (the tolerated $0.1\,\%$), \textbf{burn rate}
\item run continuously in the pipeline, such an automated check of an architectural property is a \textbf{fitness function} -- a term we will use constantly
\end{itemize}
@ -272,7 +272,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
\item keeping attackers out is necessary \emph{everywhere}; what discriminates between \textbf{structures} is \textbf{auditability} -- the ability to reconstruct history
\item \textbf{audit trail}: complete, tamper-evident record of who changed what, when, on whose authority -- a \emph{legal duty} in supervised industries (FINMA, PCI DSS)
\item \textbf{audit trail}: complete, tamper-evident record of who changed what, when, on whose authority -- a \emph{legal duty} in supervised industries (FINMA, the Swiss financial supervisor; PCI DSS, the card-payment security standard)
\item \textbf{audit scope}: the portion of the system auditors must examine -- confining sensitive flows to a small region shrinks the scope, and the bill
\item some structures record every change as an event \emph{as their normal mode}; others reassemble history from scattered log files
\end{itemize}
@ -297,11 +297,11 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\item \textbf{declared-boundary violations} (code bypassing declared module boundaries): target 0, enforceable in CI with ArchUnit / Spring Modulith
\end{itemize}
\measured{change dispersion over the version history; coupling metrics (CBO, instability); boundary violations (target 0)}{ArchUnit / Spring Modulith verification as CI gates; CK metric suite}
\measured{change dispersion over the version history; coupling metrics (CBO, instability); boundary violations (target 0)}{ArchUnit / Spring Modulith verification as CI gates; CK (Chidamber--Kemerer) metric suite}
\end{frame}
\begin{frame}{D8 -- Simplicity and time-to-market}
\emph{\textcolor{bankblue}{Two students must ship a working MVP in one semester. Does the structure let them?}}
\emph{\textcolor{bankblue}{Two students must ship a working MVP (minimum viable product) in one semester. Does the structure let them?}}
\vspace{0.2cm}
\footnotesize
@ -322,7 +322,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\begin{itemize}\setlength\itemsep{2pt}
\item two abilities, \textbf{deliberately fused}: fast, trustworthy verification \emph{and} independent, low-risk release
\item vocabulary: \textbf{hermetic test} (fully self-contained -- no shared staging, no live external service); \textbf{deployment frequency}; \textbf{change failure rate} (share of releases that break something)
\item why fused: DORA 2017 found precisely this pair -- test without an integrated environment, deploy independently -- predicted delivery performance \emph{more strongly than automation itself}; both are surface expressions of \textbf{coupling}
\item why fused: DORA (DevOps Research and Assessment) found in 2017 precisely this pair -- test without an integrated environment, deploy independently -- predicted delivery performance \emph{more strongly than automation itself}; both are surface expressions of \textbf{coupling}
\end{itemize}
\measured{test feedback time; \% hermetic tests; deployment frequency; change failure rate}{pipeline telemetry; DORA capability items}
@ -340,7 +340,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
\item prices the running system -- \textbf{machines and people}
\item vocabulary: \textbf{cost per request}; \textbf{idle cost} (capacity doing nothing -- the 03:00 question); \textbf{TCO}; \textbf{FTE}
\item vocabulary: \textbf{cost per request}; \textbf{idle cost} (capacity doing nothing -- the 03:00 question); \textbf{TCO} (total cost of ownership); \textbf{FTE} (full-time equivalent -- the people cost)
\item the hidden term matters most: a self-managed container platform is dominated not by compute prices but by \textbf{platform-team FTEs} -- the ``microservice premium'' materialises as staffing
\item Prime Video's $> 90\,\%$ cost cut: the same dimension, seen from the infrastructure side
\end{itemize}
@ -369,7 +369,7 @@ Rule of the day (A4, applied to the theory itself): \textbf{no instrument, no di
\section{The New Dimension: D12}
\begin{frame}{D12 -- AI integrability}
\emph{\textcolor{bankblue}{The new feature's core is an LLM call: eight seconds, paid per request, sometimes confidently wrong. How hard does the structure fight it?}}
\emph{\textcolor{bankblue}{The new feature's core is an LLM (large language model) call: eight seconds, paid per request, sometimes confidently wrong. How hard does the structure fight it?}}
\vspace{0.1cm}
\footnotesize
@ -561,7 +561,7 @@ Empirical finding (Chen et al.\ 2013; 90 practitioners, $> 500$ organisations):
\begin{frame}{Eliciting ASRs: the Quality Attribute Workshop (QAW)}
\small
The SEI's established format -- its essence is two design choices:
The established format of the SEI (Software Engineering Institute) -- its essence is two design choices:
\vspace{0.2cm}
\begin{columns}[T]
@ -651,7 +651,7 @@ The response measure is \textbf{directly executable} as a chaos experiment: kill
\section{The Utility Tree}
\begin{frame}{The utility tree: prioritising scenarios}
\small A workshop produces more scenarios than any analysis can carry. The \textbf{utility tree} (ATAM) prioritises them top-down; every leaf is rated H/M/L on \textbf{business importance} (what does failure cost us?) and \textbf{achievement difficulty} (how hard, architecturally?).
\small A workshop produces more scenarios than any analysis can carry. The \textbf{utility tree} (from ATAM, the Architecture Tradeoff Analysis Method) prioritises them top-down; every leaf is rated H/M/L on \textbf{business importance} (what does failure cost us?) and \textbf{achievement difficulty} (how hard, architecturally?).
\vspace{0.15cm}
\begin{center}
@ -713,10 +713,10 @@ The response measure is \textbf{directly executable} as a chaos experiment: kill
\toprule
\textbf{Dimension} & \textbf{High: example} & \textbf{Low: example} \\
\midrule
D1 Read scalability & a public social/content feed: thousands of reads per write & an ERP used by clerks: load bounded by headcount \\
D2 Write scal.\ \& elasticity & Black Friday checkout: $10$--$50\times$ seasonal write peaks & a BI warehouse loaded once, nightly \\
D1 Read scalability & a public social/content feed: thousands of reads per write & an ERP (enterprise resource planning) system used by clerks: load bounded by headcount \\
D2 Write scal.\ \& elasticity & Black Friday checkout: $10$--$50\times$ seasonal write peaks & a BI (business intelligence) warehouse loaded once, nightly \\
D4 Consistency & a payments ledger: one double booking is existential & a social feed: a stale like-count harms nobody \\
D8 Simplicity \& TTM & an internal back-office tool: its value is shipping this quarter & a core ledger: care beats speed \\
D8 Simplicity \& time-to-market & an internal back-office tool: its value is shipping this quarter & a core ledger: care beats speed \\
D11 Team scaling & a platform built by thirty teams & a two-person project: nothing to mirror \\
D12 AI integrability & the AI-native advisory platform: hosting fallible components \emph{is} the product & a classical accounting module \\
\bottomrule
@ -744,7 +744,7 @@ D12 AI integrability & the AI-native advisory platform: hosting fallible compone
\vspace{0.15cm}
\textbf{Hard constraints $K(a)$} -- an explicit inventory:
\begin{itemize}\setlength\itemsep{1pt}
\item regulatory obligations (BCBS 239, PCI DSS, EU AI Act), team size and skills, budget, mandated platforms
\item regulatory obligations (BCBS 239 -- the Basel risk-data aggregation principles; PCI DSS; the EU AI Act), team size and skills, budget, mandated platforms
\end{itemize}
\vspace{0.15cm}
@ -763,7 +763,7 @@ D12 AI integrability & the AI-native advisory platform: hosting fallible compone
\textbf{Medium} & D1, D3, D4, D5, D8 \\
\textbf{Low} & D2, D11 \\
\textbf{Shape} & \emph{hybrid}: interactive advisory dialogue $+$ batch pipelines (indexing, eval runs) \\
\textbf{Constraints} & EU AI Act (logging, documentation, human oversight); GDPR \\
\textbf{Constraints} & EU AI Act (logging, documentation, human oversight); GDPR (EU data-protection regulation) \\
\bottomrule
\end{tabular}
\end{center}
@ -772,11 +772,11 @@ D12 AI integrability & the AI-native advisory platform: hosting fallible compone
Two Mediums surprise students:
\begin{itemize}\setlength\itemsep{1pt}
\item \textbf{D3}: users accept seconds for an advisory answer -- the concern is \emph{cost per request}, not speed
\item \textbf{D4}: a hybrid -- knowledge index eventually consistent, transaction and audit path strictly ACID
\item \textbf{D4}: a hybrid -- knowledge index eventually consistent, transaction and audit path strictly ACID (atomic, consistent, isolated, durable transactions)
\end{itemize}
\vspace{0.1cm}
Every High traces to (H,\,H) scenarios; the constraints are knock-out conditions for the match.
Every High traces to (H,\,H) scenarios; the constraints are knock-out conditions for the match. (C10 $=$ the AI advisory platform, class 10 of the application-class catalogue in Part III.)
\end{frame}
\begin{frame}{This week's exercise: your QAW}
@ -825,7 +825,7 @@ Every High traces to (H,\,H) scenarios; the constraints are knock-out conditions
\item capability profiles $C(p)$ via \textbf{tactics}
\item the three-stage, non-compensatory \textbf{fit} procedure
\item worked mini-match: the advisory platform (C10!) against three candidates
\item recording decisions: \textbf{ADR / MADR}
\item recording decisions: \textbf{ADR / MADR} (Markdown ADR template)
\end{itemize}
\end{column}
\begin{column}{0.42\textwidth}

BIN
Folien/AISE502_Vorlesung_3_Folien.pdf
View File

Binary file not shown.

51
Folien/AISE502_Vorlesung_3_Folien.tex
View File

@ -157,14 +157,14 @@
\end{center}
\vspace{0.1cm}
\textbf{Done} (weeks 1--2): twelve dimensions; scenarios with response measures; utility tree; weights, shape, constraints -- $R(a)$, worked for C10 and the back-office tool.
\textbf{Done} (weeks 1--2): twelve dimensions; scenarios with response measures; utility tree; weights, shape, constraints -- $R(a)$, worked for C10 (the advisory platform, your project class) and the back-office tool.
\vspace{0.15cm}
\textbf{Today} -- the remaining three framework elements:
\begin{itemize}\setlength\itemsep{1pt}
\item the \textbf{supply side} $C(p)$: seven candidate patterns, rated \emph{by derivation}, not by taste
\item the \textbf{match} $\mathrm{fit}(a,p)$: three stages, non-compensatory -- run live on your project class C10
\item the \textbf{record}: ADR/MADR and the measurement contract
\item the \textbf{record}: the ADR (architecture decision record), its Markdown variant MADR, and the measurement contract
\end{itemize}
\vspace{0.15cm}
@ -198,7 +198,7 @@ Microservices (MS) & many independently deployable services, database per servic
\end{center}
\vspace{0.1cm}
\scriptsize\textcolor{codegray}{You have met four in production dress: Stack Overflow ran L-style, Monzo runs MS, Prime Video's failed design was SL, Segment's rollback was an MS cut.}
\scriptsize\textcolor{codegray}{You have met four in production dress: Stack Overflow ran L-style, Monzo runs MS, Prime Video's failed design was serverless (SL, next slide), Segment's rollback was an MS cut. ACID $=$ atomic, consistent, isolated, durable -- the classical transaction guarantee.}
\end{frame}
\begin{frame}{The seven candidates (2/2)}
@ -210,8 +210,8 @@ Microservices (MS) & many independently deployable services, database per servic
\textbf{Pattern (code)} & \textbf{Structure in one sentence} & \textbf{Signature strength} & \textbf{Signature cost} \\
\midrule
Event-driven (EDA) & components communicate through asynchronous events via a broker & decoupling, elasticity, fault isolation & eventual consistency; end-to-end testing hard \\
Pipes-and-filters (PF) & data flows through a chain or DAG of processing steps & throughput and reproducibility for batch work & not built for interactive latency \\
Serverless / FaaS (SL) & functions on managed infrastructure: scale-to-zero, per-execution billing & elasticity; zero idle cost & cold starts; cost inverts under sustained load \\
Pipes-and-filters (PF) & data flows through a chain or DAG (directed acyclic graph) of processing steps & throughput and reproducibility for batch work & not built for interactive latency \\
Serverless / FaaS (SL) & functions as a service on managed infrastructure: scale-to-zero, per-execution billing & elasticity; zero idle cost & cold starts; cost inverts under sustained load \\
\bottomrule
\end{tabular}
\end{center}
@ -309,7 +309,7 @@ A rating $c_i(p) \in \{++, +, \circ, -, --\}$ is an \emph{ordinal} claim: how we
D2 Write scalability & partitioned ingest with elastic consumers (EDA, SL) & one relational database receiving every write (L) \\
D4 Consistency & one ACID transaction boundary around all state (L, MM) & sagas across service databases (MS); eventual consistency through a broker (EDA) \\
D5 Availability & bulkheaded services: blast radius one service (MS, EDA) & one process: blast radius $100\,\%$ by construction (L, MM: $-$) \\
D8 Simplicity \& TTM & one repository, one pipeline, shipping this week (L, PF) & platform engineering before the first feature (MS, EDA) \\
D8 Simplicity \& time-to-market & one repository, one pipeline, shipping this week (L, PF) & platform engineering before the first feature (MS, EDA) \\
D9 Testability & hermetic domain tests behind ports (HX) & verification only against an integrated environment (L: $-$); event flows resisting end-to-end tests (EDA: $-$) \\
D12 AI integrability & a natural queue, port, and measurement point (EDA, HX, PF) & an honest middle: platform timeouts vs.\ minutes-long AI runs (SL: $\circ$) \\
\bottomrule
@ -349,7 +349,7 @@ Part II derives all seven profiles in full -- starting next week.
\begin{frame}{AI Lens: an LLM component stresses D3, D10, and D12}
\begin{ailinse}[Axis B preview]
\small Suppose one component is an LLM call. Nothing new is needed -- the coordinate system already carries it:
\small Suppose one component is an LLM (large language model) call. Nothing new is needed -- the coordinate system already carries it:
\begin{itemize}\setlength\itemsep{1pt}
\item \textbf{D3}: LLM calls cost \emph{seconds} where classical calls cost milliseconds -- time behaviour becomes a \emph{structural} concern (queues, asynchronous integration, caching)
\item \textbf{D10}: per-token pricing makes operating cost a \emph{per-request} attribute -- a bad prompt chain is a cost regression the way an $n{+}1$ query is a latency regression
@ -387,7 +387,7 @@ These three requirements admit \textbf{essentially one procedure} \dots
\begin{enumerate}\setlength\itemsep{2pt}
\item \textbf{Knock-out screening.} Hard constraints $K(a)$ eliminate patterns before any scoring. The \emph{workload-shape gate}: if $S(p)$ does not match the dominant $S(a)$, the cell is capped at $\circ$ (subsystem role) -- $+$ only for a \emph{constitutive} subsystem of a shape-hybrid class; $-$/$--$ where it would harm binding scenarios.
\item \textbf{Veto rule on High-weight dimensions.} $c_i(p) = --$ on a High dimension caps the fit at $-$; $c_i(p) = -$ caps it at $\circ$ -- \emph{unless a documented mitigation exists} (a tactic or hybrid with production evidence), in which case the cell says so and the cap is lifted.
\item \textbf{Holistic ordinal reading with mandatory sensitivity analysis.} Survivors are ranked by support of the High set; clustering Medium conflicts can downgrade one step. Result: a \emph{ranking with exclusions}. If it flips under plausible re-weighting, that instability is a genuine \textbf{trade-off point} -- escalate to scenario-based analysis (ATAM).
\item \textbf{Holistic ordinal reading with mandatory sensitivity analysis.} Survivors are ranked by support of the High set; clustering Medium conflicts can downgrade one step. Result: a \emph{ranking with exclusions}. If it flips under plausible re-weighting, that instability is a genuine \textbf{trade-off point} -- escalate to scenario-based analysis (ATAM, the Architecture Tradeoff Analysis Method).
\end{enumerate}
\end{definitionbox}
\end{frame}
@ -405,13 +405,13 @@ These three requirements admit \textbf{essentially one procedure} \dots
\vspace{0.15cm}
\begin{examplebox}[Same class -- opposite structures: LMAX and Monzo]
\footnotesize LMAX runs core trading on \emph{one} deterministic, event-sourced JVM thread ($6$M orders/s); Monzo runs banking on $\sim 2{,}800$ microservices. \textbf{Both} satisfy the class's binding scenarios. Lesson: $R(a)$ alone defines a \emph{feasible set}; the constraints and context in $K(a)$ decide \emph{within} it. A theory pretending to compute a single winner would be falsified by this pair.
\footnotesize LMAX runs core trading on \emph{one} deterministic, event-sourced JVM (Java virtual machine) thread ($6$M orders/s); Monzo runs banking on $\sim 2{,}800$ microservices. \textbf{Both} satisfy the class's binding scenarios. Lesson: $R(a)$ alone defines a \emph{feasible set}; the constraints and context in $K(a)$ decide \emph{within} it. A theory pretending to compute a single winner would be falsified by this pair.
\end{examplebox}
\end{frame}
\begin{frame}{The mini-match: $R(\text{C10})$ against L, MM, MS -- stage 1}
\small
\textbf{The demand side} (from week 2): High on $\{$D6, D7, D9, D10, D12$\}$; shape \emph{hybrid}; EU AI Act and GDPR in $K$.
\textbf{The demand side} (from week 2): High on $\{$D6, D7, D9, D10, D12$\}$; shape \emph{hybrid}; EU AI Act and GDPR (data protection) in $K$.
\vspace{0.25cm}
\textbf{Stage 1 -- knock-out and shape gate:}
@ -426,7 +426,7 @@ These three requirements admit \textbf{essentially one procedure} \dots
\footnotesize
\begin{itemize}\setlength\itemsep{4pt}
\item \textbf{L (layered):} rates $-$ on High-weighted \textbf{D7} $\to$ cap $\circ$ unless mitigated -- and at C10's extreme change rate of models, prompts, and frameworks \emph{there is none}: technical layers give the non-deterministic component no boundary, no queue, no measurement point. \textbf{D9} is a second $-$ on a High dimension; D12 offers only $\circ$. Two unmitigated vetoes that \emph{cluster} push the stage-3 reading one step below the cap: $\mathbf{-}$.
\item \textbf{MS (microservices):} rates $--$ on High-weighted \textbf{D10} $\to$ would cap at $-$ -- but here the \emph{mitigation clause earns its keep}: C10's cost concern is \textbf{per-request AI cost} (tokens, GPU), governed at a \emph{gateway} -- orthogonal to distribution. The platform-cost veto relaxes to $\circ$. What stops MS from rising further: synchronous service chains \emph{multiply} seconds-scale LLM latency and failure rates, and the pattern's signature payoff (team scaling) sits on \textbf{Low-weighted} D11 -- for a student-sized team the microservice premium buys nothing.
\item \textbf{MS (microservices):} rates $--$ on High-weighted \textbf{D10} $\to$ would cap at $-$ -- but here the \emph{mitigation clause earns its keep}: C10's cost concern is \textbf{per-request AI cost} (tokens, GPU time), governed at a \emph{gateway} -- orthogonal to distribution. The platform-cost veto relaxes to $\circ$. What stops MS from rising further: synchronous service chains \emph{multiply} seconds-scale LLM latency and failure rates, and the pattern's signature payoff (team scaling) sits on \textbf{Low-weighted} D11 -- for a student-sized team the microservice premium buys nothing.
\item \textbf{MM (modular monolith):} \textbf{no veto fires at all} -- $+$ or better on every High dimension; its one structural $-$ (D5, blast radius) is Medium-weighted and mitigated by replicated instances.
\end{itemize}
\end{frame}
@ -480,7 +480,7 @@ Why not score $1$--$5$, multiply by weights, add up ($V = \sum_i w_i \cdot v_i$)
\end{enumerate}
\vspace{0.2cm}
The AHP repair inherits documented defects: adding an alternative (even a \emph{copy}) can \textbf{reverse the ranking}; Dyer's verdict: ``flawed as a procedure for ranking alternatives''.
The AHP (Analytic Hierarchy Process) repair inherits documented defects: adding an alternative (even a \emph{copy}) can \textbf{reverse the ranking}; Dyer's verdict: ``flawed as a procedure for ranking alternatives''.
\vspace{0.15cm}
\textbf{Kept} from multi-criteria analysis: the \emph{explication discipline} -- criteria on the table, weights argued, options compared. \textbf{Dropped}: the arithmetic pretensions.
@ -525,7 +525,7 @@ Three honest limits, holding throughout:
\begin{frame}{The decision is the primary artefact}
\small
A1 says: what we choose is a \textbf{decision} with high reversal cost -- and undocumented decisions \emph{evaporate}:
Assumption A1 says: what we choose is a \textbf{decision} with high reversal cost -- and undocumented decisions \emph{evaporate}:
\begin{itemize}\setlength\itemsep{2pt}
\item the code shows \emph{what} was built, never \emph{why}
\item within a few staff rotations the rationale is gone; later changes violate constraints nobody remembers -- which is what teams experience as \textbf{``legacy''}
@ -549,7 +549,7 @@ ISO/IEC/IEEE 42010:2022 draws the normative conclusion: a conformant architectur
\end{enumerate}
\vspace{0.15cm}
\textbf{MADR} adds explicit \textbf{decision drivers} and \textbf{considered options} (each with pros and cons), plus an optional \textbf{confirmation} section.
\textbf{MADR} (Markdown Architecture Decision Records) adds explicit \textbf{decision drivers} and \textbf{considered options} (each with pros and cons), plus an optional \textbf{confirmation} section.
\vspace{0.1cm}
\begin{keypoint}
@ -558,36 +558,35 @@ ISO/IEC/IEEE 42010:2022 draws the normative conclusion: a conformant architectur
\end{frame}
\begin{frame}{ADR-011: the LLM gateway decision (your project, week 6)}
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=1pt, bottom=1pt, left=6pt, right=6pt]
\scriptsize\ttfamily
\textbf{ADR-011: Route all LLM calls through one gateway port}\\[2pt]
Status: accepted | supersedes ADR-004\\[4pt]
\textbf{Context:} providers deprecate models on 6--12-month cycles; token costs must be attributable per request; domain logic must stay testable without paid, non-deterministic API calls.\\[4pt]
\textbf{Drivers:} D7 evolvability -- provider change stays cheap $\cdot$ D9 testability -- hermetic tests $\cdot$ D12 -- per-request cost observability\\[4pt]
\textbf{Options:} (1) direct provider-SDK calls from domain services $\cdot$ \textbf{(2) one gateway behind a domain-owned port} $\leftarrow$ chosen $\cdot$ (3) per-feature adapters without a shared gateway\\[4pt]
\textbf{Consequences:} $+$ provider migration is an adapter task; domain tests run against fakes. $-$ one more runtime component; $\sim$20--50\,ms latency; the gateway needs its own SLO.
Status: accepted | supersedes ADR-004\\[2pt]
\textbf{Context:} providers deprecate models on 6--12-month cycles; token costs must be attributable per request; domain logic must stay testable without paid, non-deterministic API calls.\\[2pt]
\textbf{Drivers:} D7 evolvability -- provider change stays cheap $\cdot$ D9 testability -- hermetic tests $\cdot$ D12 -- per-request cost observability\\[2pt]
\textbf{Options:} (1) direct provider-SDK calls from domain services $\cdot$ \textbf{(2) one gateway behind a domain-owned port} $\leftarrow$ chosen $\cdot$ (3) per-feature adapters without a shared gateway\\[2pt]
\textbf{Consequences:} $+$ provider migration is an adapter task; domain tests run against fakes. $-$ one more runtime component; $\sim$20--50\,ms latency; the gateway needs its own SLO (service level objective).
\end{tcolorbox}
\vspace{0.1cm}
\footnotesize
\textbf{Confirmation (measurement contract, in embryonic form):}
\begin{itemize}\setlength\itemsep{0pt}
\item static rule: no domain module imports the provider SDK (ArchUnit, CI gate, 0 violations)
\item eval-harness pass rate $\geq 95\,\%$ on every model/prompt change
\item token cost per request $\leq$ budget (p95), monitored continually
\item static rule: no domain module imports the provider SDK (software development kit) -- ArchUnit as a CI (continuous integration) gate, 0 violations
\item eval-harness (AI evaluation suite) pass rate $\geq 95\,\%$ on every model/prompt change
\item token cost per request $\leq$ budget (95th percentile), monitored continually
\end{itemize}
\end{frame}
\begin{frame}{Diagrams and the measurement contract}
\small
\textbf{C4 -- diagrams for decisions, sparingly:} four zoom levels (system context, container, component, code). For this module, \textbf{container level dominates}: a modular monolith is \emph{one} container with enforced internal boundaries, a microservice system is \emph{many}, an event-driven system inserts a \emph{broker} container between them.
\textbf{The C4 model -- diagrams for decisions, sparingly:} four zoom levels, hence the name (system \textbf{C}ontext, \textbf{C}ontainer, \textbf{C}omponent, \textbf{C}ode). For this module, \textbf{container level dominates}: a modular monolith is \emph{one} container with enforced internal boundaries, a microservice system is \emph{many}, an event-driven system inserts a \emph{broker} container between them.
\vspace{0.25cm}
\textbf{The measurement contract} -- the fifth framework element:
\begin{itemize}\setlength\itemsep{2pt}
\item every ADR ends with the \textbf{fitness functions and thresholds that would tell us the decision has failed}
\item static rules as CI gates $\cdot$ scenario response measures as automated tests $\cdot$ cost and latency budgets as telemetry alarms
\item in operation, the four \textbf{DORA metrics} test whether the delivery-relevant promises hold
\item in operation, the four \textbf{DORA metrics} (DevOps Research and Assessment) test whether the delivery-relevant promises hold
\item on breach: a documented evolution path (Strangler Fig) recorded as a \emph{superseding ADR} -- never a silent rewrite
\end{itemize}
\end{frame}

BIN
Folien/AISE502_Vorlesung_4_Folien.pdf
View File

Binary file not shown.

40
Folien/AISE502_Vorlesung_4_Folien.tex
View File

@ -167,7 +167,7 @@ Every pattern section follows the \textbf{same rhythm}:
\item what the pattern \emph{is} -- definition, topology, variants
\item what real-world \textbf{problem} it was invented to solve, with named production systems
\item how it behaves on the \textbf{twelve dimensions} -- rating and structural reason, side by side
\item what it does to your \textbf{engineering day} -- build, test, CI/CD, operations, teams
\item what it does to your \textbf{engineering day} -- build, test, CI/CD (continuous integration and delivery), operations, teams
\item where you can \textbf{build it and study it} -- plus \textbf{anti-patterns} with measurable alarms, and \textbf{selection signals}
\end{enumerate}
@ -241,11 +241,11 @@ Layering was the natural first answer because it \textbf{mirrors both the techno
\begin{itemize}\setlength\itemsep{1pt}
\item the stack already separates concerns: something renders screens, something executes rules, something persists rows -- and so do the skills in the room
\item one added rule -- \emph{dependencies point downwards only} -- turns the habit into a pattern
\item the reward: one build, one artefact, one ACID database, one thing to operate
\item the reward: one build, one artefact, one ACID database (atomic, consistent, isolated, durable transactions), one thing to operate
\end{itemize}
\vspace{0.2cm}
De-facto standard since the 1990s: Spring MVC, .NET, Rails and Django scaffold it by default; Metabase ships its whole BI tier as a single JAR \emph{deliberately}. What it was never designed to give: independent scaling and change isolation.
De-facto standard since the 1990s: Spring MVC, .NET, Rails and Django scaffold it by default; Metabase ships its whole BI (business intelligence) tier as a single JAR (Java archive) \emph{deliberately}. What it was never designed to give: independent scaling and change isolation.
\end{frame}
\begin{frame}{L -- capability profile (column L of the consolidated table)}
@ -264,7 +264,7 @@ D4 Consistency \& integrity & $++$ & one ACID transaction boundary under one pro
D5 Availability \& isolation & $-$ & one process: blast radius $100\,\%$ by construction \\
D6 Security \& auditability & $+$ & one audit log, one small compliance scope \\
D7 Evolvability & $-$ & technical partitioning: a feature cuts across every layer \\
D8 Simplicity \& TTM & $++$ & one repo, one pipeline -- lowest entry threshold in the catalogue \\
D8 Simplicity \& time-to-market & $++$ & one repo, one pipeline -- lowest entry threshold in the catalogue \\
D9 Testability \& deployability & $-$ & any change redeploys the whole artefact, full regression scope \\
D10 Operating cost & $++$ & one cheap deployable, near-zero platform staff \\
D11 Team scaling & $-$ & one quantum, one release train: a single-team pattern \\
@ -310,7 +310,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{Deployment and operations}}
\begin{itemize}\setlength\itemsep{1pt}
\item whole-system releases and rollbacks; classical APM suffices, \textbf{no distributed tracing needed} -- an underrated virtue
\item whole-system releases and rollbacks; classical APM (application performance monitoring) suffices, \textbf{no distributed tracing needed} -- an underrated virtue
\end{itemize}
\vspace{0.15cm}
@ -350,7 +350,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\textcolor{bankgreen}{\textbf{Choose when}}
\begin{itemize}\footnotesize\setlength\itemsep{1pt}
\item team $\leq$ roughly ten; budget and schedule tight
\item domain not yet understood; CRUD-dominant at modest scale
\item domain not yet understood; CRUD-dominant (create/read/update/delete forms over data) at modest scale
\item one ACID database satisfies consistency
\end{itemize}
\end{column}
@ -367,7 +367,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\begin{frame}{L -- AI lens and key concept}
\begin{ailinse}[The layered pattern and AI components]
\footnotesize D12 $= \circ$ -- instructive because the problem is not difficulty but \textbf{ease}: nothing stops a developer from calling an LLM synchronously from a business-layer service, \emph{and that is precisely the risk}. No structural boundary, no queue, no measurement point; token costs are invisible to classical APM; non-determinism leaks freely across layers, which encode technology, not trust. \textbf{Hosting an AI call is easy; containing one is unsupported.}
\footnotesize D12 $= \circ$ -- instructive because the problem is not difficulty but \textbf{ease}: nothing stops a developer from calling an LLM (large language model) synchronously from a business-layer service, \emph{and that is precisely the risk}. No structural boundary, no queue, no measurement point; token costs are invisible to classical APM; non-determinism leaks freely across layers, which encode technology, not trust. \textbf{Hosting an AI call is easy; containing one is unsupported.}
\end{ailinse}
\vspace{0.2cm}
@ -389,7 +389,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\vspace{0.2cm}
\begin{definitionbox}[Modular monolith (MM)]
\small A single deployment artefact (one process, one quantum) whose interior is partitioned \textbf{by domain} into modules with enforced boundaries: each module encapsulates one \emph{bounded context} -- including sovereignty over its own persistent data -- and inter-module communication passes exclusively through published module APIs or in-process events. \textbf{Boundary conformance is verified automatically.}
\small A single deployment artefact (one process, one quantum) whose interior is partitioned \textbf{by domain} into modules with enforced boundaries: each module encapsulates one \emph{bounded context} -- including sovereignty over its own persistent data -- and inter-module communication passes exclusively through published module APIs (application programming interfaces) or in-process events. \textbf{Boundary conformance is verified automatically.}
\end{definitionbox}
\vspace{0.2cm}
@ -443,7 +443,7 @@ Hence the precise problem: \emph{how does a team keep monolith economics -- one
\vspace{0.1cm}
\begin{examplebox}[Shopify -- the canonical modular monolith]
\footnotesize One of the largest Rails codebases ($> 2.8$M lines of Ruby); decided deliberately \emph{against} microservices. Since 2017: components with enforced boundaries, checked by the purpose-built tool \textbf{Packwerk}. Scaling: \textbf{sharding whole monolith instances into pods} -- carrying BFCM peaks of $\sim 280$M requests/minute. Both halves in one case: microservices-grade modularity (D7) at monolith-grade cost (D10) -- and the mitigation that lifts D2 from $--$ to $-$.
\footnotesize One of the largest Rails codebases ($> 2.8$M lines of Ruby); decided deliberately \emph{against} microservices. Since 2017: components with enforced boundaries, checked by the purpose-built tool \textbf{Packwerk}. Scaling: \textbf{sharding whole monolith instances into pods} -- carrying Black Friday / Cyber Monday (BFCM) peaks of $\sim 280$M requests/minute. Both halves in one case: microservices-grade modularity (D7) at monolith-grade cost (D10) -- and the mitigation that lifts D2 from $--$ to $-$.
\end{examplebox}
\end{frame}
@ -463,7 +463,7 @@ D4 Consistency \& integrity & $++$ & one process, one ACID transaction scope acr
D5 Availability \& isolation & $-$ & single process, single blast radius; replication mitigates \\
D6 Security \& auditability & $+$ & one audit log, one compliance scope; module boundaries as policy seams \\
D7 Evolvability & $+$ & the domain cut absorbs a typical feature \emph{inside one module} \\
D8 Simplicity \& TTM & $+$ & monolith-simple minus one step: boundary governance is a permanent line item \\
D8 Simplicity \& time-to-market & $+$ & monolith-simple minus one step: boundary governance is a permanent line item \\
D9 Testability \& deployability & $+$ & module APIs as natural test seams; module-scoped test selection \\
D10 Operating cost & $++$ & one artefact, one process, classical monitoring \\
D11 Team scaling & $\circ$ & roughly three to five teams can share one release train \\
@ -545,7 +545,7 @@ rule "module boundaries hold" \{\\
\begin{examplebox}[Build it and study it -- modular monolith]
\footnotesize \textbf{Build.} Spring Modulith (Java, Apache-2.0, active): module boundaries as first-class artefacts -- verification tests, recorded event publication, generated module documentation inside one Spring Boot deployable. In Python the same discipline is a linter: \texttt{import-linter} (BSD-2, active) declares layer and independence contracts and fails CI on violation -- \emph{remember it, it returns unchanged for the hexagonal pattern}.
\textbf{Study.} Apache Fineract ($\sim$2.3k stars, Apache-2.0, active): core banking at industrial scale -- \textbf{34 \texttt{fineract-*} Gradle modules} (\texttt{-loan}, \texttt{-accounting}, \texttt{-savings}, \dots) composed into \emph{one} deployable, plus a \texttt{custom/} extension directory. Runs via docker-compose (JVM, heavy: moderate effort). Smaller first contact: \texttt{sivaprasadreddy/spring-modular-monolith} (Apache-2.0).
\textbf{Study.} Apache Fineract ($\sim$2.3k stars, Apache-2.0, active): core banking at industrial scale -- \textbf{34 \texttt{fineract-*} Gradle modules} (\texttt{-loan}, \texttt{-accounting}, \texttt{-savings}, \dots) composed into \emph{one} deployable, plus a \texttt{custom/} extension directory. Runs via docker-compose (JVM -- Java virtual machine -- heavy: moderate effort). Smaller first contact: \texttt{sivaprasadreddy/spring-modular-monolith} (Apache-2.0).
\end{examplebox}
\vspace{0.1cm}
@ -633,7 +633,7 @@ rule "module boundaries hold" \{\\
\begin{frame}{HX -- the problem it solves}
\footnotesize
\textbf{The pain that produced the pattern is testability.} Cockburn's 2005 diagnosis: business logic ends up \emph{welded} to its surroundings -- rules leak into UI event handlers on one side and into data-access code on the other, until the only way to check a discount computation is to start the whole application, click through screens, and inspect database rows. Such tests are slow, brittle, expensive -- \emph{and the logic most worth testing is precisely the logic hardest to reach}.
\textbf{The pain that produced the pattern is testability.} Cockburn's 2005 diagnosis: business logic ends up \emph{welded} to its surroundings -- rules leak into UI (user interface) event handlers on one side and into data-access code on the other, until the only way to check a discount computation is to start the whole application, click through screens, and inspect database rows. Such tests are slow, brittle, expensive -- \emph{and the logic most worth testing is precisely the logic hardest to reach}.
\vspace{0.2cm}
The same weld causes a second, slower problem: \textbf{the system cannot follow its technology}. A new UI generation, a database migration, an additional channel -- each \emph{ought} to be peripheral, but while rules are smeared through UI and persistence code, every peripheral change is open-heart surgery.
@ -661,7 +661,7 @@ D4 Consistency \& integrity & $\diamond$ & inherited \\
D5 Availability \& isolation & $\diamond$ & inherited \\
D6 Security \& auditability & $+$ & ports are natural audit and policy chokepoints \\
D7 Evolvability & $++$ & technology migrations become \textbf{localised adapter tasks} \\
D8 Simplicity \& TTM & $-$ & indirection that amortises only under change -- ceremony for pure CRUD \\
D8 Simplicity \& time-to-market & $-$ & indirection that amortises only under change -- ceremony for pure CRUD \\
D9 Testability \& deployability & $++$ & \textbf{hermetic domain tests}: fakes replace infrastructure, feedback in milliseconds \\
D10 Operating cost & $\diamond$ & inherited \\
D11 Team scaling & $\diamond$ & inherited \\
@ -682,14 +682,14 @@ Native shape $S(p)$ & \multicolumn{2}{l}{(host's)} \\
\vspace{0.2cm}
\begin{examplebox}[Storage migrations behind a seam -- Discord]
\footnotesize Discord's message store migrated \textbf{twice at trillion-row scale} -- MongoDB $\to$ Cassandra $\to$ ScyllaDB, hot paths re-implemented as Rust data services -- cutting p99 reads from 40--125\,ms to $\sim 15$\,ms. Survivable \emph{because} data access sat behind stable interfaces: \textbf{the storage technology churned, the callers did not}. The D7/D9 delta observed in production -- and a preview of why the same discipline turns an LLM-provider deprecation from a crisis into an adapter task.
\footnotesize Discord's message store migrated \textbf{twice at trillion-row scale} -- MongoDB $\to$ Cassandra $\to$ ScyllaDB, hot paths re-implemented as Rust data services -- cutting p99 (99th-percentile) reads from 40--125\,ms to $\sim 15$\,ms. Survivable \emph{because} data access sat behind stable interfaces: \textbf{the storage technology churned, the callers did not}. The D7/D9 delta observed in production -- and a preview of why the same discipline turns an LLM-provider deprecation from a crisis into an adapter task.
\end{examplebox}
\end{frame}
\begin{frame}{HX -- software engineering implications}
\small
\begin{itemize}\setlength\itemsep{3pt}
\item \textbf{Build and CI/CD:} the hexagon is invisible to the pipeline topology, but adds one gate: \emph{the dependency rule itself is a fitness function} -- ``the domain imports no framework, no vendor SDK'' -- enforceable with the same ArchUnit-class tooling as module boundaries
\item \textbf{Build and CI/CD:} the hexagon is invisible to the pipeline topology, but adds one gate: \emph{the dependency rule itself is a fitness function} -- ``the domain imports no framework, no vendor SDK (software development kit)'' -- enforceable with the same ArchUnit-class tooling as module boundaries
\item \textbf{Test:} the pyramid gains a wide, fast base of hermetic domain tests; each port acquires \textbf{contract tests} that every adapter -- \emph{including every fake} -- must pass, so that fakes cannot drift from reality
\item \textbf{Maintenance:} the payoff channel -- volatile peripheries (UIs, providers, AI services) churn in adapters while the core stays still
\item \textbf{Teams:} neutral -- but the pattern demands \emph{design skill}: ports must be cut in domain vocabulary, which is a modelling task, not a refactoring
@ -700,7 +700,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{(host's)} \\
\begin{examplebox}[Build it and study it -- hexagonal]
\footnotesize \textbf{Build.} The hexagon is a discipline, not a runtime -- its ``framework'' is a rule checker. ArchUnit (Java, Apache-2.0, active): its \texttt{onionArchitecture()} API encodes the inward-pointing arrows directly. Python: \texttt{import-linter} (BSD-2, active) enforces the same contracts between packages.
\textbf{Study.} \texttt{cosmicpython/code} ($\sim$2.7k stars): the example application of \emph{Architecture Patterns with Python} (Percival \& Gregory) -- the book's full text is freely readable online, the ideal companion for this module's Python-first audience. Look at \texttt{src/allocation/}: the split into \texttt{domain/}, \texttt{service\_layer/}, \texttt{adapters/}, \texttt{entrypoints/}, and the repository and unit-of-work \emph{ports} with swappable adapters. Runs via docker-compose $+$ pytest. \textbf{Licence caveat, as promised:} the repository is \textbf{CC-BY-ND} -- free to study, \emph{not} free to reuse in derived work.
\textbf{Study.} \texttt{cosmicpython/code} ($\sim$2.7k stars): the example application of \emph{Architecture Patterns with Python} (Percival \& Gregory) -- the book's full text is freely readable online, the ideal companion for this module's Python-first audience. Look at \texttt{src/allocation/}: the split into \texttt{domain/}, \texttt{service\_layer/}, \texttt{adapters/}, \texttt{entrypoints/}, and the repository and unit-of-work \emph{ports} with swappable adapters. Runs via docker-compose $+$ pytest. \textbf{Licence caveat, as promised:} the repository is \textbf{CC-BY-ND} (Creative Commons, no derivatives) -- free to study, \emph{not} free to reuse in derived work.
\end{examplebox}
\vspace{0.1cm}
@ -721,7 +721,7 @@ The folder structure says ports and adapters; the dependencies say otherwise. \t
\begin{frame}{HX -- AI lens and key concept}
\begin{ailinse}[The anti-corruption layer for AI components]
\footnotesize D12 $= ++$ -- \textbf{the strongest cell in the D12 row}. ML components resist modularisation: ``changing anything changes everything'' (CACE), and they \emph{erode} abstraction boundaries unless a boundary is \textbf{imposed} on them. The port is that imposed boundary -- an \emph{anti-corruption layer} in the DDD sense. An LLM behind a port is \textbf{swappable} when the provider deprecates the model, \textbf{mockable} in every test, and \textbf{replaceable by a deterministic fake} -- so the deterministic $95\,\%$ of the system can be tested deterministically.
\footnotesize D12 $= ++$ -- \textbf{the strongest cell in the D12 row}. ML components resist modularisation: ``changing anything changes everything'' (CACE), and they \emph{erode} abstraction boundaries unless a boundary is \textbf{imposed} on them. The port is that imposed boundary -- an \emph{anti-corruption layer} in the DDD (domain-driven design) sense. An LLM behind a port is \textbf{swappable} when the provider deprecates the model, \textbf{mockable} in every test, and \textbf{replaceable by a deterministic fake} -- so the deterministic $95\,\%$ of the system can be tested deterministically.
\end{ailinse}
\vspace{0.2cm}
@ -745,7 +745,7 @@ The folder structure says ports and adapters; the dependencies say otherwise. \t
\midrule
D4 Consistency & $++$ & $++$ & $\diamond$ \\
D7 Evolvability & $-$ & $+$ & $++$ \\
D8 Simplicity \& TTM & $++$ & $+$ & $-$ \\
D8 Simplicity \& time-to-market & $++$ & $+$ & $-$ \\
D9 Testability & $-$ & $+$ & $++$ \\
D10 Operating cost & $++$ & $++$ & $\diamond$ \\
D12 AI integrability & $\circ$ & $+$ & $++$ \\
@ -758,7 +758,7 @@ Three readings:
\begin{itemize}\setlength\itemsep{2pt}
\item L $\to$ MM isolates the \textbf{partitioning axis}: same quantum, same cost -- evolvability and testability bought by the \emph{domain cut}, not by distribution
\item HX \textbf{composes}: a hexagonal modular monolith takes MM's column and lifts D7/D9/D12 towards $++$
\item exactly this composition won the mini-match for C10 last week -- \textbf{your project architecture}
\item exactly this composition won the mini-match for C10 (the advisory platform) last week -- \textbf{your project architecture}
\end{itemize}
\end{frame}
@ -975,7 +975,7 @@ class SoupPipeline:
\vspace{0.2cm}
\textcolor{bankblue}{\textbf{Exercise}}
\begin{itemize}\small
\item architecture study I; C4 drafts
\item architecture study I; C4 diagram drafts (context and container level)
\end{itemize}
\end{column}
\end{columns}

BIN
Folien/AISE502_Vorlesung_5_Folien.pdf
View File

Binary file not shown.

28
Folien/AISE502_Vorlesung_5_Folien.tex
View File

@ -134,7 +134,7 @@
\begin{enumerate}\setlength\itemsep{1pt}
\item Recap: one quantum, three cuts -- today: many quanta
\item \textbf{MS} -- Microservices: what buys team independence, and what it costs
\item Sagas vs.\ ACID: why compensation is not rollback
\item Sagas vs.\ ACID (atomic, consistent, isolated, durable) transactions: why compensation is not rollback
\item \textbf{EDA} -- Event-driven architecture: what an intermediary gives and takes
\item Resilience primitives for distributed edges
\item This week's exercise: Ontologies \& JSON Schema
@ -235,8 +235,8 @@ The answer: \textbf{make the team's unit of ownership the system's unit of deplo
\vspace{0.1cm}
\begin{itemize}\setlength\itemsep{1pt}
\item strongest empirical support is organisational: in high performers, \textbf{deployment frequency scales linearly with team count} instead of collapsing under coordination (DORA)
\item the documented \emph{upper} bound: Uber, at $\sim 2{,}200$ critical services, re-introduced a second structuring level -- $\sim 70$ domains with gateways (DOMA) -- a convergence back towards macro-modules
\item strongest empirical support is organisational: in high performers, \textbf{deployment frequency scales linearly with team count} instead of collapsing under coordination (DORA, DevOps Research and Assessment)
\item the documented \emph{upper} bound: Uber, at $\sim 2{,}200$ critical services, re-introduced a second structuring level -- $\sim 70$ domains with gateways (DOMA, Domain-Oriented Microservice Architecture) -- a convergence back towards macro-modules
\end{itemize}
\end{frame}
@ -256,11 +256,11 @@ D4 Consistency \& integrity & $--$ & database-per-service: no ACID across a boun
D5 Availability \& isolation & $++$ & bulkheads: one failing service is not a failing product \\
D6 Security \& auditability & $\circ$ & expanded attack surface, scattered audit trails vs.\ isolation \\
D7 Evolvability & $++$ & domain partitioning: a change lands inside one deployable service \\
D8 Simplicity \& TTM & $--$ & platform engineering before the first feature -- the premium \\
D8 Simplicity \& time-to-market & $--$ & platform engineering before the first feature -- the premium \\
D9 Testability \& deployability & $+$ & per-service excellent; system-level verification shifts towards production \\
D10 Operating cost & $--$ & the premium is paid mostly as platform staffing \\
D11 Team scaling & $++$ & independent deployability: teams release without queueing \\
D12 AI integrability & $\circ$ & isolation helps, but synchronous chains multiply LLM latency and failure probability \\
D12 AI integrability & $\circ$ & isolation helps, but synchronous chains multiply LLM (large language model) latency and failure probability \\
\midrule
Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\bottomrule
@ -273,7 +273,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{interactive} \\
\begin{itemize}\setlength\itemsep{3pt}
\item \textbf{D11 $= ++$ is the real payoff.} Deployments per developer per day scale \emph{linearly} with team count in high-performing organisations -- teams stop queueing. \textbf{This, not raw traffic, is the requirement that legitimately forces the pattern.}
\item \textbf{D4 $= --$ is structural} (the method's negative example from week 3). A cross-service invariant (order $\to$ stock $\to$ ledger) becomes a saga -- and \emph{compensation is not rollback}: a rollback erases an intermediate state as if it never existed; a compensating action cannot, because \textbf{other services have already seen and acted on that state}. Every ``undo'' is a new business operation (cancel, restock, refund) with its own logic, tests, and failure modes. No implementation skill removes this cell -- it can only be \emph{relocated} by cutting boundaries so invariants live inside one service.
\item \textbf{D8/D10 $= --$: the premium is staffing.} Self-managed Kubernetes TCO runs roughly $3\times$ managed offerings, dominated by personnel.
\item \textbf{D8/D10 $= --$: the premium is staffing.} Self-managed Kubernetes TCO (total cost of ownership) runs roughly $3\times$ managed offerings, dominated by personnel.
\item \textbf{D9 $= +$ averages a genuine split}: per-service testing is excellent; \emph{system-level} verification shifts towards production -- consumer-driven contracts, canary releases, progressive delivery.
\end{itemize}
\end{frame}
@ -293,7 +293,7 @@ Omitting these does not produce a leaner variant of the pattern -- it produces a
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{Operations, maintenance, teams}}
\begin{itemize}\setlength\itemsep{1pt}
\item distributed tracing, per-service SLOs, \textbf{circuit breakers}, \textbf{bulkheads}
\item distributed tracing, per-service SLOs (service level objectives), \textbf{circuit breakers}, \textbf{bulkheads}
\item \textbf{cross-cutting change multiplies by service count} -- the Segment mechanism
\item stream-aligned teams $+$ a platform team: a \emph{precondition}
\end{itemize}
@ -406,7 +406,7 @@ Omitting these does not produce a leaner variant of the pattern -- it produces a
\end{center}
\vspace{0.05cm}
\footnotesize Four things commonly conflated under ``event-driven'' (Fowler): \textbf{event notification} $\cdot$ \textbf{event-carried state transfer} $\cdot$ \textbf{event sourcing} (the log \emph{is} the system of record -- LMAX: $6$M orders/s on one event-sourced JVM thread) $\cdot$ \textbf{CQRS} (separate write and read models).
\footnotesize Four things commonly conflated under ``event-driven'' (Fowler): \textbf{event notification} $\cdot$ \textbf{event-carried state transfer} $\cdot$ \textbf{event sourcing} (the log \emph{is} the system of record -- LMAX: $6$M orders/s on one event-sourced JVM -- Java virtual machine -- thread) $\cdot$ \textbf{CQRS} (command query responsibility segregation: separate write and read models).
\end{frame}
\begin{frame}{EDA -- the problem it solves}
@ -421,7 +421,7 @@ The general form recurs wherever the consumer set is \emph{open-ended}: the prod
\vspace{0.1cm}
\begin{examplebox}[Kafka at LinkedIn; the Uber real-time stack]
\footnotesize By 2019, LinkedIn's Kafka carried $> 7$ \emph{trillion} messages per day -- the existence proof for D1/D2 $= ++$. Uber composes Kafka $+$ Flink $+$ Pinot into an end-to-end event-driven stack -- the canonical EDA-plus-pipeline hybrid for the IoT class (C8).
\footnotesize By 2019, LinkedIn's Kafka carried $> 7$ \emph{trillion} messages per day -- the existence proof for D1/D2 $= ++$. Uber composes Kafka $+$ Flink $+$ Pinot into an end-to-end event-driven stack -- the canonical EDA-plus-pipeline hybrid for the IoT (Internet of Things) class, C8.
\end{examplebox}
\end{frame}
@ -441,7 +441,7 @@ D4 Consistency \& integrity & $--$ & eventual consistency moves correctness into
D5 Availability \& isolation & $++$ & a slow or dead consumer does not stall producers \\
D6 Security \& auditability & $\circ$ & durable log supports audit; causal trails need correlation IDs \\
D7 Evolvability & $++$ & new consumers attach without touching producers \\
D8 Simplicity \& TTM & $--$ & eventuality and broker operations designed and staffed first \\
D8 Simplicity \& time-to-market & $--$ & eventuality and broker operations designed and staffed first \\
D9 Testability \& deployability & $-$ & non-deterministic event flows resist end-to-end testing \\
D10 Operating cost & $\circ$ & few quanta, no premium -- but the broker is a standing cost \\
D11 Team scaling & $+$ & teams per processor decouple well; the broker needs an owner \\
@ -481,7 +481,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{stream / async} \\
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{Operations and maintenance}}
\begin{itemize}\setlength\itemsep{1pt}
\item the RED metrics of this world: \textbf{consumer lag}, \textbf{dead-letter queues}, duplicate rates
\item the RED metrics (rate, errors, duration) of this world: \textbf{consumer lag}, \textbf{dead-letter queues}, duplicate rates
\item debugging $=$ \textbf{correlation-ID tracing} across hops -- a core competency, not an advanced topic
\item additive evolution is the glory (attach a consumer); \emph{changing} an established schema is the most expensive operation
\end{itemize}
@ -491,14 +491,14 @@ Native shape $S(p)$ & \multicolumn{2}{l}{stream / async} \\
\begin{frame}{EDA -- build it and study it, anti-patterns}
\begin{examplebox}[Build it and study it -- event-driven]
\footnotesize \textbf{Build.} Apache Kafka (durable, partitioned, replayable log); RabbitMQ (classic AMQP routing). Python-first layer: FastStream (Apache-2.0) -- FastAPI-style producers/consumers with the broker behind a decorator.
\footnotesize \textbf{Build.} Apache Kafka (durable, partitioned, replayable log); RabbitMQ (classic AMQP -- Advanced Message Queuing Protocol -- routing). Python-first layer: FastStream (Apache-2.0) -- FastAPI-style producers/consumers with the broker behind a decorator.
\textbf{Study.} Home Assistant (\texttt{home-assistant/core}, $\sim$89k stars, Apache-2.0): genuinely event-driven Python -- \texttt{homeassistant/core.py} defines \texttt{Event} and \texttt{EventBus} with \texttt{async\_fire}, and \emph{every} state change flows through that one bus. Runs via \texttt{pip install homeassistant}; the codebase is huge, so \textbf{read exactly that one file} -- the whole pattern is in it.
\end{examplebox}
\vspace{0.1cm}
\footnotesize
\textbf{Anti-patterns with alarms:} \emph{event soup} (no workflow visibility -- alarm: share of events without correlation IDs; time to reconstruct one causal trail); \emph{events as disguised RPCs} (a producer blocking for a reply event -- synchronous coupling with extra steps); \emph{missing idempotency} (at-least-once $+$ non-idempotent consumers $=$ silent corruption); \emph{event sourcing as default} (the burden of proof lies with the auditability requirement).
\textbf{Anti-patterns with alarms:} \emph{event soup} (no workflow visibility -- alarm: share of events without correlation IDs; time to reconstruct one causal trail); \emph{events as disguised RPCs} (remote procedure calls: a producer blocking for a reply event -- synchronous coupling with extra steps); \emph{missing idempotency} (at-least-once $+$ non-idempotent consumers $=$ silent corruption); \emph{event sourcing as default} (the burden of proof lies with the auditability requirement).
\end{frame}
\begin{frame}{Discussion}
@ -546,7 +546,7 @@ Retry with backoff & re-attempts transient failures with growing pauses -- safe
Circuit breaker & callers stop calling a dependency that keeps failing; probes recovery & breaker state transitions; open time \\
Bulkhead & partitions resources so one failing component cannot drain the rest & saturation per pool \\
Fallback / degradation & a defined degraded answer beats no answer & share of degraded responses \\
Dead-letter queue & parks messages that repeatedly fail processing for inspection & DLQ depth and age \\
Dead-letter queue (DLQ) & parks messages that repeatedly fail processing for inspection & DLQ depth and age \\
Idempotent consumer & processing twice $=$ processing once -- makes retries safe & duplicate rate under replay \\
\bottomrule
\end{tabular}

BIN
Folien/AISE502_Vorlesung_6_Folien.pdf
View File

Binary file not shown.

30
Folien/AISE502_Vorlesung_6_Folien.tex
View File

@ -160,7 +160,7 @@
\end{definitionbox}
\vspace{0.1cm}
\footnotesize Historical root: the Unix pipe. Modern incarnations dominate the data world: ETL/ELT, DAG orchestration (Airflow), data-parallel engines (Spark), HPC job chains (Slurm), streaming pipelines (Flink -- the bridge to EDA), and \textbf{ML and retrieval pipelines} -- the current incarnation.
\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}
@ -210,7 +210,7 @@ D4 Consistency \& integrity & $+$ & immutable inputs $+$ idempotent stages: \emp
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 \& TTM & $++$ & explicit composition over self-contained filters -- shipping this week \\
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 \\
@ -226,7 +226,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{scheduled batch} \\
\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 -- 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{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}
@ -279,7 +279,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{scheduled batch} \\
\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. FaaS (your code, event-triggered) vs.\ BaaS (API-consumed third-party services).
\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}
@ -328,14 +328,14 @@ Native shape $S(p)$ & \multicolumn{2}{l}{scheduled batch} \\
\toprule
\textbf{Dimension} & \textbf{Rating} & \textbf{Structural reason} \\
\midrule
D1 Read scalability & $+$ & wide parallelism, tempered by concurrency limits and the DB-connection bottleneck \\
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 \& TTM & $\circ$ & no server management vs.\ a large configuration surface \\
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 \\
@ -356,7 +356,7 @@ Native shape $S(p)$ & \multicolumn{2}{l}{event-triggered, short-lived} \\
\vspace{0.05cm}
\begin{examplebox}[Amazon Prime Video -- a measured cost inversion]
\footnotesize The video-monitoring service: Step Functions coordinating Lambdas, S3 buffering frames between stages. A hard scaling limit at $\sim 5\,\%$ of expected load, and consolidation into one ECS 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?)}
\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}
@ -372,12 +372,12 @@ Native shape $S(p)$ & \multicolumn{2}{l}{event-triggered, short-lived} \\
\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 routes).
\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 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.}
\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}
@ -517,7 +517,7 @@ multi-agent systems & broker fan-out of autonomous quanta \\
\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 with a measurement contract.
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}
% ============================================
@ -535,7 +535,7 @@ Load-bearing distinction: \textbf{workflows} (predefined code paths) vs.\ \textb
\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), not per user; batch APIs $\sim 50\,\%$ cheaper; model cascades up to $98\,\%$ cost reduction; learned routers halve cost
\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}
@ -544,7 +544,7 @@ Load-bearing distinction: \textbf{workflows} (predefined code paths) vs.\ \textb
\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 p95) and a p95 latency budget (e.g.\ 20\,s)} -- both CI-gated fitness functions. \textcolor{codegray}{(The D10 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}
@ -568,14 +568,14 @@ D4 Consistency \& integrity & M & hybrid: knowledge index eventual, audit path A
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 \& TTM & M & start simplest -- but never simpler than the audit path \\
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} \\
Constraints $K(a)$ & \multicolumn{2}{l}{EU AI Act 2024/1689 (logging, oversight; potentially high-risk); GDPR (data protection)} \\
\bottomrule
\end{tabular}
\end{center}
@ -650,7 +650,7 @@ The capability tables explain the host choice:
\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} (MADR: drivers, options, consequences, confirmation).
\textbf{Take the decision -- and begin the ADR} (in the MADR -- Markdown ADR -- template: drivers, options, consequences, confirmation).
\end{projektbox}
\vspace{0.1cm}

BIN
Folien/AISE502_Vorlesung_7_Folien.pdf
View File

Binary file not shown.

35
Folien/AISE502_Vorlesung_7_Folien.tex
View File

@ -137,7 +137,7 @@
\item The procedure in general -- and what a weighted sum would have destroyed
\item The matching matrix: cell semantics and the $7 \times 10$ grid
\item Reading the matrix as a whole: columns, rows, five support points
\item The measurement contract, introduced: fitness functions and the DORA metrics
\item The measurement contract, introduced: fitness functions and the DORA (DevOps Research and Assessment) metrics
\item This week's exercise: \textbf{the design-review gate and Deliverable A2}
\end{enumerate}
\end{frame}
@ -157,7 +157,7 @@
\textbf{Done} (weeks 1--6): Part I -- the framework and the C10 mini-match (L $-$, MM $++$, MS $\circ$); Part II -- seven capability profiles $C(p)$, the consolidated table, Maxims 3 and 4, ordinal reading only; Part III opened -- the C10 profile and the C1/C2 mirror pair (\emph{weights, not dimensions, define a class}).
\vspace{0.1cm}
\textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\to$ veto $\to$ ordinal reading) and began the ADR -- today you will recognise every step.
\textbf{Last week's exercise}: you ran the three stages on your own platform (knock-out $\to$ veto $\to$ ordinal reading) and began the ADR (architecture decision record) -- today you will recognise every step.
\vspace{0.1cm}
\textbf{Today}:
@ -169,7 +169,7 @@
\vspace{0.1cm}
\begin{hinweisbox}
\footnotesize \textbf{A2 is due this week} -- the architecture dossier (ADR $+$ C4 $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate.
\footnotesize \textbf{A2 is due this week} -- the architecture dossier (ADR $+$ C4 diagrams $+$ measurement contract); the design-review gate closes the design phase; production code only after the gate.
\end{hinweisbox}
\end{frame}
@ -240,7 +240,7 @@ L & interactive & gate caps at $\circ$; harm clause -- no answer to makespan or
MM & interactive & gate caps at $\circ$: orchestration codebase around monolithic kernels & $\circ$ \\
HX & (host's) & gate caps at $\circ$: ports touch no binding dimension & $\circ$ \\
MS & interactive & gate caps; harm clause -- communication cost multiplied against High D10 & $--$ \\
EDA & stream / async & gate caps at $\circ$: job-status glue beside scheduler and DAG & $\circ$ \\
EDA & stream / async & gate caps at $\circ$: job-status glue beside scheduler and DAG (directed acyclic graph) & $\circ$ \\
PF & scheduled batch & \textbf{gate passed} -- proceeds to Stages 2--3; no veto on $\{$D2, D9, D10$\}$ & $++$ \\
SL & event-trig., short-lived & gate caps at $\circ$: burst fan-out for communication-light sections only & $\circ$ \\
\bottomrule
@ -255,8 +255,8 @@ SL & event-trig., short-lived & gate caps at $\circ$: burst fan-out for communic
\item Its $--$ on D3 sits on a Low weight and is \emph{inert}; the holistic reading ranks a field of one
\item \textbf{Result: $\mathrm{fit}(\text{C6},\text{PF}) = {++}$, every other pattern at $\circ$ or below} -- the C6 row of the matrix, computed almost entirely at Stage 1
\item The didactic point generalises: \textbf{run the cheapest test first} -- six of seven candidates died before a single rating was weighed
\item The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\text{C1})$ eliminates any structure that cannot guarantee an ACID booking core, an immutable audit journal, and ten-plus-year retention -- \emph{before} scoring, however well it scales
\item The verdict the class's Part III section states (Lecture 9): \textbf{pipes-and-filters on HPC/batch infrastructure as primary}, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\circ$ cells) stated, not hidden
\item The knock-outs of $K(a)$ belong to the same stage and work the same way: $K(\text{C1})$ eliminates any structure that cannot guarantee an ACID (atomic, all-or-nothing transactions) booking core, an immutable audit journal, and ten-plus-year retention -- \emph{before} scoring, however well it scales
\item The verdict the class's Part III section states (Lecture 9): \textbf{pipes-and-filters on HPC (high-performance computing) / batch infrastructure as primary}, serverless fan-out for bursty, communication-light parallel sections as secondary -- with the honest subsystem roles (the $\circ$ cells) stated, not hidden
\end{itemize}
\end{frame}
@ -266,7 +266,7 @@ SL & event-trig., short-lived & gate caps at $\circ$: burst fan-out for communic
\vspace{-0.05cm}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
\item From the deck-6 mirror pair: C1 High on \textbf{D4, D5, D6, D7, D9}; $K(\text{C1})$: ACID booking core, BCBS 239 / FINMA auditability; shape interactive with batch edges. Contested pair: \textbf{MM against MS} -- the two columns side by side
\item From the deck-6 mirror pair: C1 High on \textbf{D4, D5, D6, D7, D9}; $K(\text{C1})$: ACID booking core, BCBS 239 (Basel risk-data rules) / FINMA (Swiss supervisor) auditability; shape interactive with batch edges. Contested pair: \textbf{MM against MS} -- the two columns side by side
\item \textbf{Stage 1.} Both natively interactive $\to$ the gate passes both; no hard constraint in $K(\text{C1})$ eliminates either -- \emph{a constraint names an obligation, not a pattern}; both can in principle be operated under FINMA-grade audit obligations
\item \textbf{Stage 2 for MS.} $c_4(\text{MS}) = {--}$: no ACID transactions across service boundaries; sagas trade atomicity for choreography complexity. D4 is High in C1 $\to$ \textbf{the veto fires and caps the cell at $-$}
\item The fact is \emph{structural}: a mitigation can only show that living without the property is \emph{survivable} -- yes, but conditional: Monzo (deck 5), roughly 2{,}800 microservices in production banking, under \textbf{organisational scale plus extreme technological homogeneity} (one language, one monorepo, central migration automation)
@ -352,7 +352,7 @@ D11 Team scaling & $++$ & $+$ \\
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{Neither dominates}: MS leads where \emph{teams} multiply (D9, D11 -- independent deployments), EDA where \emph{consumers} multiply (D3 on the asynchronous path; D7 in its attach-new-consumers reading)
\item The \textbf{mandatory sensitivity analysis flips the ordering under entirely plausible variation}: weight D11 the way a several-hundred-team organisation must, and MS wins; frame the feed as what it technically is -- an eventually consistent, precomputed product of an event flow -- and EDA wins
\item By Stage 3's own rule, that instability is \textbf{not noise}: it marks a genuine trade-off point in the ATAM sense, to be escalated to scenario-based analysis rather than smoothed over
\item By Stage 3's own rule, that instability is \textbf{not noise}: it marks a genuine trade-off point in the ATAM (Architecture Tradeoff Analysis Method) sense, to be escalated to scenario-based analysis rather than smoothed over
\end{itemize}
\end{frame}
@ -412,12 +412,11 @@ The three stages are ordered by \textbf{decreasing hardness}, and each now has a
\begin{frame}{Why the fit is not a weighted sum}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
\item Deck 3 (Part I): $V(p) = \sum_i w_i \cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all three violated by ordinal profiles (A2); AHP inherits rank reversal
\item Deck 3 (Part I): $V(p) = \sum_i w_i \cdot v_i(p)$ presupposes cardinal scales, preferential independence, and weights as trade-off rates -- all violated by ordinal profiles (A2); AHP (Analytic Hierarchy Process) inherits rank reversal
\item \textbf{What the three cases add -- a demonstration of what the formula would have destroyed:} \textbf{C6} -- it would have averaged the shape gate away under good scores elsewhere $\cdot$ \textbf{C1} -- it would have let MS's missing cross-service ACID be compensated by team scaling $\cdot$ \textbf{C2} -- it would have manufactured a decimal-point winner exactly where the honest output is a flagged trade-off point
\item Kept from multi-criteria decision analysis: the \emph{explication discipline} (criteria, weights, assumptions forced into the open); dropped: its arithmetic pretensions -- the matrix is an \textbf{explication and communication instrument}, not a computation that determines decisions; behind every contested cell stands \textbf{ATAM}, and, where money decides, \textbf{CBAM} (utility-response curves, return on investment)
\item Kept from multi-criteria decision analysis: the \emph{explication discipline} (criteria, weights, assumptions in the open); dropped: the arithmetic -- the matrix is an \textbf{explication and communication instrument}, not a computation; behind every contested cell stands \textbf{ATAM}, and, where money decides, \textbf{CBAM} (Cost Benefit Analysis Method)
\end{itemize}
\vspace{0.1cm}
\begin{keypoint}
\footnotesize The fit computation is \textbf{non-compensatory by design}: constraints knock out before anything is scored, structural failures on High-weight dimensions veto unless a documented mitigation exists, and only then does a holistic ordinal ranking follow -- with mandatory sensitivity analysis. \emph{A weighted sum over ordinal profiles would be formally illegitimate and would average away exactly the failures that matter most.}
\end{keypoint}
@ -467,7 +466,7 @@ C10 AI-native analysis / advisory & $-$ & {\boldmath$++$} & {\boldmath$++$} & $\
\end{center}
\vspace{0.1cm}
Ratings $++$ (excellent fit) to $--$ (structural misfit); \textbf{bold} $=$ cells underlying the primary recommendation of each class; shaded rows $=$ the rows you computed today. $^{\dagger}$\,HX is a delta pattern -- it composes with a host (typically MM), its cells read ``as the internal discipline of the class's core''. L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS.
Ratings $++$ (excellent fit) to $--$ (structural misfit); \textbf{bold} $=$ cells underlying the primary recommendation of each class; shaded rows $=$ the rows you computed today. $^{\dagger}$\,HX is a delta pattern -- it composes with a host (typically MM), its cells read ``as the internal discipline of the class's core''. L $=$ layered/3-tier, MM $=$ modular monolith, MS $=$ microservices, EDA $=$ event-driven, PF $=$ pipes-and-filters/batch pipeline, SL $=$ serverless/FaaS. Class names: ERP $=$ enterprise resource planning, BI $=$ business intelligence, IoT $=$ Internet of Things.
\end{frame}
\begin{frame}{Reading the grid: the rows you computed}
@ -499,7 +498,7 @@ Ratings $++$ (excellent fit) to $--$ (structural misfit); \textbf{bold} $=$ cell
\item Column-wise, the \textbf{modular monolith is primary or secondary in seven of ten classes} -- not because it is fashionable (it is conspicuously unfashionable) but because most requirements profiles weight consistency, evolvability, cost, and time-to-market higher than independent scaling, and \textbf{MM is the only pattern rated $+$ or better on all four} of those dimensions (capability table, deck 6)
\item The matrix-level restatement of Fowler's \textbf{MonolithFirst}: do not start with microservices even if you expect to need them -- stable service boundaries cannot be cut before the domain is understood, and refactoring \emph{between} services is far costlier than \emph{within} a monolith
\item \textbf{Microservices earn their premium in exactly two situations}, both visible in the grid: where High-weight read scalability, fault isolation, and team scaling coincide (C2, and conditionally C5 and C8) -- and nowhere else
\item The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO \textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \textbf{pay the premium and collect nothing}
\item The premium is real and quantified: $--$ on cost and simplicity; the run-cost side materialises as platform staffing -- self-managed Kubernetes TCO (total cost of ownership) \textbf{roughly three times} managed offerings, dominated by personnel (deck 5); the two $--$ cells in the MS column (C3, C4) mark the classes that \textbf{pay the premium and collect nothing}
\end{itemize}
\end{frame}
@ -560,7 +559,7 @@ C10 & $++$ & $\circ$ & $++$ & $+$ & $+$ \\
Prime Video (deck 6) & the split serverless cost cell & over 90\,\% infrastructure cost reduction after consolidating a data-intensive flow into one process \\
Segment & the MS evolvability cell, read against a wrongly cut boundary & services per configuration instance, not per domain seam \\
Shopify & the MM write-scalability mitigation & pod-sharded replication \\
Uber (DOMA) & the MS team-scaling cell & the point where service count itself became the problem \\
Uber (DOMA: domain-oriented microservices) & the MS team-scaling cell & the point where service count itself became the problem \\
Stack Overflow & the layered read-scalability deviation & cache-friendly read dominance served by roughly nine web servers \\
\bottomrule
\end{tabular}
@ -606,7 +605,7 @@ Stack Overflow & the layered read-scalability deviation & cache-friendly read do
\end{frame}
\begin{frame}{Fitness functions -- the definition}
\footnotesize Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD, the four-layer cascade, Boehm vs.\ Menzies) in Lecture 11.
\footnotesize Deck 3 named the contract as the fifth framework element -- today its definition and instruments; depth (taxonomy in CI/CD -- continuous integration and delivery -- the four-layer cascade, Boehm vs.\ Menzies) in Lecture 11.
\vspace{0.1cm}
\begin{definitionbox}[Architectural fitness function]
@ -641,7 +640,7 @@ Stack Overflow & the layered read-scalability deviation & cache-friendly read do
\textbf{Family} & \textbf{Instruments} & \textbf{Scope /}\newline\textbf{cadence} & \textbf{What it makes testable} \\
\midrule
1 Dependency checks as CI gates (decks 3--4) & ArchUnit (analogues: NetArchTest, dependency-cruiser, import-linter): ``the domain layer imports no framework'', ``no cycles between modules'' as unit tests that fail the build; Spring Modulith for declared module boundaries & atomic, triggered & what makes the MM ratings of the capability table \emph{enforceable} rather than aspirational -- without automated boundary verification, boundary erosion is the documented failure mode of the pattern \\[0.15cm]
2 Performance and cost budgets as pipeline gates & latency thresholds, bundle sizes, Lighthouse scores declared in a budget file & (pipeline gate) & \textbf{Axis B transfer is direct: token-cost budgets and p95 latency budgets per AI use case are the same mechanism with new units} \\[0.15cm]
2 Performance and cost budgets as pipeline gates & latency thresholds, bundle sizes, Lighthouse scores declared in a budget file & (pipeline gate) & \textbf{Axis B transfer is direct: token-cost budgets and p95 (95th-percentile) latency budgets per AI use case are the same mechanism with new units} \\[0.15cm]
3 Chaos experiments & Netflix's Chaos Monkey terminates production instances to test resilience assumptions permanently; formalised as the principles of chaos engineering & holistic, continual & verifies the \textbf{D5 cells}: a claimed blast radius is a hypothesis until an instance has actually been killed under load \\
\bottomrule
\end{tabular}
@ -651,7 +650,7 @@ Stack Overflow & the layered read-scalability deviation & cache-friendly read do
\begin{frame}{DORA metrics: the delivery layer -- and the coupling finding}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
\item The four DORA metrics measure whether the delivery-relevant promises of a structure are being kept: \textbf{deployment frequency} and \textbf{lead time for changes} (tempo); \textbf{change failure rate} and \textbf{failed-deployment recovery time} (stability)
\item The four DORA (DevOps Research and Assessment) metrics measure whether the delivery-relevant promises of a structure are being kept: \textbf{deployment frequency} and \textbf{lead time for changes} (tempo); \textbf{change failure rate} and \textbf{failed-deployment recovery time} (stability)
\item Central empirical finding: elite performers lead on \emph{all four} -- \textbf{tempo and stability are not a trade-off}
\item The strongest single result in the field supports coupling as the leading dimension of this entire theory: ``loosely coupled architectures and teams are the strongest predictor of continuous delivery'' -- in the 2017 analysis, testability and deployability contributed more to continuous delivery than test and deployment automation itself
\item High performance is possible with all kinds of systems -- including mainframes -- provided systems and teams are loosely coupled: the label ``microservices'' is \emph{neither necessary nor sufficient}
@ -682,7 +681,7 @@ Stack Overflow & the layered read-scalability deviation & cache-friendly read do
\end{projektbox}
\vspace{0.1cm}
\small From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (M3, walking skeleton) begins.
\small From week 8 the exercise slot becomes a one-lesson (one-hour) standup/coaching session and the lecture grows to three lessons; Sprint 1 (milestone M3, walking skeleton) begins.
\end{frame}
\begin{frame}{Summary}

BIN
Folien/AISE502_Vorlesung_8_Folien.pdf
View File

Binary file not shown.

78
Folien/AISE502_Vorlesung_8_Folien.tex
View File

@ -136,10 +136,10 @@
\item \textbf{C1} -- Core banking / transaction systems: the double impossibility
\item \textbf{C2} -- Social media / content platforms: 50:1 and the fan-out
\item \textbf{C3} -- Back-office / workflow: the modal, unglamorous case
\item \textbf{C4} -- ERP / enterprise core: integration \emph{is} the product
\item \textbf{C4} -- ERP (enterprise resource planning) / enterprise core: integration \emph{is} the product
\item \textbf{C5} -- E-commerce: quality attributes with price tags
\item Five classes side by side -- five verdicts as previews for Part IV
\item This week's exercise: \textbf{the walking skeleton} (M3)
\item This week's exercise: \textbf{the walking skeleton} (milestone M3)
\end{enumerate}
\end{frame}
@ -153,7 +153,7 @@
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{Lecture 6 closed Part II}: the consolidated capability table, Maxims 3 and 4 (quantum count; partitioning beats distribution), ordinal reading only -- every cell a default hypothesis
\item \textbf{Lecture 6 opened Part III with C10}: Highs on D6/D7/D9/D10/D12, the binding scenarios, the verdict (hexagonal MM $+$ PF $+$ EDA) -- and the C1/C2 mirror pair in one frame: \emph{weights, not dimensions, define a class}
\item \textbf{Lecture 7 (Part IV)}: three cases, three stages; $\mathrm{fit}(a,p)$ formally -- ordinal, non-compensatory; the $7 \times 10$ grid read (MM primary or secondary in seven of ten); the measurement contract -- fitness functions and the four DORA metrics; A2 dossier and design-review gate passed: \emph{implementation is free}
\item \textbf{Lecture 7 (Part IV)}: three cases, three stages; $\mathrm{fit}(a,p)$ formally -- ordinal, non-compensatory; the $7 \times 10$ grid read (MM primary or secondary in seven of ten); the measurement contract -- fitness functions and the four DORA (DevOps Research and Assessment) metrics; A2 dossier and design-review gate passed: \emph{implementation is free}
\item \textbf{Method recall (Lectures 2--3)}: $R(a) = (w_1 \ldots w_{12};\, S(a);\, K(a))$ -- weights from the (H,\,H) leaves of the utility tree; shape gates; constraints knock out; every High is a veto trigger with the cap rule of the three-stage procedure
\item \textbf{Today}: the demand side in its full class rhythm for C1--C5 -- \emph{challenges $\to$ binding scenarios $\to$ profile $\to$ what real systems chose}; each closing verdict is a preview that Part IV recomputes
\item \textbf{Project}: the design phase is over -- the implementation phase opens with milestone M3, the walking skeleton (weeks 8--9)
@ -196,7 +196,7 @@
\begin{frame}{Method recall: where the weights come from (Lectures 2--3)}
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
\item \textcolor{codegray}{(Lecture 2)} A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are \emph{elicited}, not guessed (QAW, ATAM utility tree), each leaf rated (business importance, achievement difficulty) on \{H, M, L\}
\item \textcolor{codegray}{(Lecture 2)} A4 recalled: a quality attribute is decision-relevant only as a six-part scenario; ASRs are \emph{elicited}, not guessed (QAW -- Quality Attribute Workshop; the utility tree of ATAM, the Architecture Tradeoff Analysis Method), each leaf rated (business importance, achievement difficulty) on \{H, M, L\}
\item \textcolor{codegray}{(Lecture 2)} \textbf{The (H,\,H) leaves of a class's characteristic utility tree \emph{are} the High weights of $R(a)$}
\item \textbf{New in Part III}: a weight is a \textbf{compressed empirical claim} -- ``systems of this class recurrently produce (H,\,H) scenario leaves on this dimension'' -- and each class section makes it \textbf{auditable}: documented challenges (incidents, production numbers, statutory obligations) $\to$ two to three \emph{binding scenarios} with response measures, populating the (H,\,H) region
\item \textcolor{codegray}{(Lecture 3)} \textbf{H} -- veto power: $--$ on an H dimension caps the fit at $-$, $-$ caps it at $\circ$, unless a documented mitigation with production evidence exists; \textbf{M} -- measured, conflicts noted not vetoed, clustered Medium conflicts downgrade one step; \textbf{L} -- does not discriminate for this class; optimising it is waste
@ -211,21 +211,20 @@
\begin{frame}{Workload shape and hard constraints}
\footnotesize
\begin{itemize}\setlength\itemsep{0pt}
\item \textcolor{codegray}{(recall, Lecture 2)} $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core. Every shape has a quantitative signature with production numbers -- \emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}
\item \textcolor{codegray}{(recall, Lecture 2)} $S(a)$ -- interactive, continuous stream, scheduled batch, explicitly hybrid; the \emph{shape gate}: a pattern whose native shape does not match the dominant $S(a)$ cannot carry the class's core. Every shape has a quantitative signature -- \emph{a workload claim without a number is as unfalsifiable as a scalability requirement without one}
\item \textcolor{codegray}{(recall, Lecture 2)} $K(a)$ -- \textbf{knock-out filters, not weights}: a violating pattern or deployment form is excluded before any scoring and can never be averaged away
\item The regulatory inventory of this catalogue: BCBS~239, FINMA Circular 2023/1, DORA, PCI~DSS v4.0, the EU AI Act -- plus organisational facts (team size and skills, mandated platforms, budget)
\item Regulation is a first-class architectural requirement that \textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, logging obligations for AI components
\item The regulatory inventory of this catalogue: BCBS~239 (Basel risk-data rules), FINMA Circular 2023/1, DORA (here the EU Digital Operational Resilience Act, not the DevOps metrics), PCI~DSS v4.0 (card payments), the EU AI Act -- plus organisational facts (team size, skills, platforms, budget)
\item Regulation is a first-class requirement that \textbf{translates directly into structure}: immutable journals, scope zoning, data classification at module boundaries, AI logging obligations
\end{itemize}
\vspace{0.03cm}
\begin{keypoint}
\footnotesize An application class is an ASR bundle, not an industry label -- weights from the (H,\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \emph{several} classes at once -- a bank runs a C1 booking core, C3 back-office workflows, C6 overnight risk runs, C7 reporting and increasingly a C10 advisory layer -- so the fit matrix is read \textbf{per subsystem, never per company logo}: your project's inheritance diagram (Lecture 6: C10 inherits C6/C7/C3) is exactly that reading.
\footnotesize An application class is an ASR bundle, not an industry label -- weights from the (H,\,H) leaves, shape gates the core, constraints knock out before scoring. One organisation operates \emph{several} classes at once (a bank: C1 booking core, C3 workflows, C6 risk runs, C7 reporting, C10 advisory) -- so the fit matrix is read \textbf{per subsystem, never per company logo}.
\end{keypoint}
\end{frame}
\begin{frame}{A map of the ten classes}
\begin{center}
\resizebox{!}{4.75cm}{%
\resizebox{!}{4.55cm}{%
\begin{tikzpicture}[
x=1cm, y=1cm,
classnode/.style={rectangle, draw, rounded corners=3pt, minimum width=2.6cm, minimum height=0.72cm, align=center, font=\small\sffamily, line width=0.6pt},
@ -275,7 +274,8 @@
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
\item C1 and C2 at opposite ends of the consistency axis within the same band -- the didactic \textbf{mirror pair}; C10 the only class whose \emph{shape} is constitutively hybrid
\item Today's five (thick frames) all sit in the interactive band -- read them along the axis: C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual
\item Today's five (thick frames) all sit in the interactive band -- read them along the axis: C1/C4 strict ACID (atomic, all-or-nothing transactions), C3 ACID-leaning, C5 split by subsystem, C2 eventual
\item Map labels: ERP $=$ enterprise resource planning; DSS/BI $=$ decision support / business intelligence; IoT $=$ Internet of Things
\end{itemize}
\end{frame}
@ -328,7 +328,7 @@
\begin{itemize}\setlength\itemsep{0pt}
\item \textbf{Sums.} Swiss Interbank Clearing settles on average roughly CHF~226 billion per day, peaks above CHF~386 billion -- a double-posted or lost booking is a balance-sheet event: D4 and D6 first. Every payment is a write surrounded by reads (cover checks, sanctions screening, fraud scoring): \emph{write-critical} -- but the \emph{concurrency} of writes against shared accounts, not their raw rate, stresses D4
\item \textbf{Speed spread.} Batch clearing hours; instant payments under 10\,s; card authorisation 1--2\,s; exchange trading microseconds -- latency means something different in each regime, hence D3 \textbf{Medium with a footnote}, not High
\item SIC5 instant-payment infrastructure: dimensioned for peaks in the order of 2{,}000 payments/s (clustered in-memory replicated state machine). VisaNet: \emph{capacity} above 65{,}000 transaction messages/s, average load orders of magnitude below -- capacity dimensioning vs.\ normal load: D2 is \emph{planned, not elastic}
\item SIC5 (fifth-generation Swiss Interbank Clearing) instant-payment infrastructure: dimensioned for peaks in the order of 2{,}000 payments/s (clustered in-memory replicated state machine). VisaNet: \emph{capacity} above 65{,}000 transaction messages/s, average load orders of magnitude below -- capacity dimensioning vs.\ normal load: D2 is \emph{planned, not elastic}
\item Load constant with deterministic peaks (end of day, end of month, salary runs); unavailability a loss event on national infrastructure, with regulator-defined disruption tolerances -- D5
\item \textbf{Time.} Reuters 2017: 220 billion lines of COBOL in production, 43\,\% of US banking systems COBOL-based -- ossification is the documented failure mode: D7 a High \emph{requirement} precisely because it is so often unmet. Change rate bimodal: booking core rarely, periphery (channels, onboarding, products) constantly. Data structured, records small, retention extreme -- ten years and more
\end{itemize}
@ -344,7 +344,7 @@ Three scenarios compress these challenges into the (H,\,H) region of the C1 util
\end{itemize}
\vspace{0.1cm}
$K(\text{C1})$ -- \textbf{the densest constraint set in the catalogue:} BCBS~239 (risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1~January 2024: ICT risk, protection of \emph{critical data}, business continuity with disruption tolerances); DORA (EU 2022/2554, applicable 17~January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR throughout.
$K(\text{C1})$ -- \textbf{the densest constraint set in the catalogue:} BCBS~239 (risk-data aggregation and reporting: integration and lineage); FINMA Circular 2023/1 (in force 1~January 2024: ICT -- information and communication technology -- risk, protection of \emph{critical data}, business continuity with disruption tolerances); DORA, the Digital Operational Resilience Act (EU 2022/2554, applicable 17~January 2025: ICT risk, incident reporting, resilience testing, third-party register); GDPR (data protection) throughout.
\end{frame}
@ -364,7 +364,7 @@ D4 Consistency \& integrity & \textbf{H} & a lost or double-posted booking creat
D5 Availability \& isolation & \textbf{H} & payment rails are national infrastructure; outages are loss events \\
D6 Security \& auditability & \textbf{H} & the immutable audit journal is a statutory obligation \\
D7 Evolvability & \textbf{H} & decades-long lifetimes; ossification is the failure mode \\
D8 Simplicity \& TTM & L & time-to-market traded for integrity without hesitation \\
D8 Simplicity \& time-to-market & L & time-to-market traded for integrity without hesitation \\
D9 Testability \& deployability & \textbf{H} & reconciliation and trail reconstruction verifiable by construction \\
D10 Operating cost & L & run cost traded for integrity as willingly as D8 \\
D11 Team scaling & M & binds only at neobank organisational scale -- the Monzo condition \\
@ -384,19 +384,19 @@ Constraints $K(a)$ & \multicolumn{2}{l}{BCBS 239; FINMA 2023/1; DORA; ACID core;
\footnotesize
Two documented production systems show this profile does \emph{not} determine a single pattern:
\begin{itemize}\setlength\itemsep{0pt}
\item \textbf{LMAX} (retail trading): six million orders/s on a \emph{single} JVM thread -- in-memory, event-sourced, deterministic sequential core, lock-free ring buffers. Serialisable \emph{by construction} (the strongest answer to the D4 veto); journal replay answers D6 and D9; surrenders D2 -- weighted only Medium
\item \textbf{Monzo} (UK digital bank): ca.\ 2{,}800 Go microservices (ca.\ 1{,}600 in 2020), viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, the MS column's strength; the $--$ on simplicity and cost paid deliberately; the D4 risk of sagas in the money path mitigated by homogeneity and central tooling
\item \textbf{Apache Fineract} (the 34-module single deployable of week 4), read from the demand side: a modular monolith behind a REST facade -- one ACID quantum serves the D4 veto, domain modules absorb the peripheral change rate (D7), the weak cell ($-$ on D5: one process as blast radius) mitigated by hot-standby replication. A standing counter-example to ``banking at scale implies microservices''
\item \textbf{LMAX} (retail trading): six million orders/s on a \emph{single} JVM (Java virtual machine) thread -- in-memory, event-sourced, deterministic sequential core. Serialisable \emph{by construction} (the strongest answer to the D4 veto); journal replay answers D6 and D9; surrenders D2 -- weighted only Medium
\item \textbf{Monzo} (UK digital bank): ca.\ 2{,}800 Go microservices, viable only through extreme homogeneity -- one language, one monorepo, central migration automation. Binding dimension D11, the MS column's strength; the $--$ on simplicity and cost paid deliberately; the saga risk on D4 mitigated by homogeneity and central tooling
\item \textbf{Apache Fineract} (week 4), read from the demand side: a modular monolith behind a REST facade (a web API) -- one ACID quantum serves the D4 veto, domain modules absorb the peripheral change rate (D7), the weak cell ($-$ on D5: one process as blast radius) mitigated by hot-standby replication. A standing counter-example to ``banking at scale implies microservices''
\end{itemize}
\begin{keypoint}
\footnotesize $R(a)$ alone does not force one pattern -- it defines the feasible set, constraints decide within it. C1's veto dimensions D4/D5/D6/D7/D9 eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do \emph{not} rank the survivors -- the LMAX/Monzo pair is evidence \textbf{for} the theory, not against it.
\footnotesize $R(a)$ defines the feasible set; constraints decide within it. C1's vetoes (D4/D5/D6/D7/D9) eliminate structures that cannot carry an ACID, journaled, decades-lived core; they do \emph{not} rank the survivors -- the LMAX/Monzo pair is evidence \textbf{for} the theory, not against it.
\end{keypoint}
\end{frame}
\begin{frame}{C1 -- AI lens and the verdict}
\begin{ailinse}[Fraud scoring at the edge of the ledger (Axis B)]
\footnotesize AI enters C1 at the periphery, never in the booking path: fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \emph{before} a posting is committed; increasingly LLM-based components for case triage and customer communication. D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \textbf{The rule ``agents propose, deterministic services decide and book'' originates in this class.}
\footnotesize AI enters C1 at the periphery, never in the booking path: fraud and sanctions scoring are ML classification components (millisecond latency, deterministic after training) consulted \emph{before} a posting is committed; increasingly LLM (large language model) based components for case triage and customer communication. D12 is Medium precisely because of this placement: the deterministic core must be isolatable from the probabilistic edge -- a ports-and-adapters discipline. A fraud model that could abort or mutate a posting mid-transaction would violate the D4 veto. \textbf{The rule ``agents propose, deterministic services decide and book'' originates in this class.}
\end{ailinse}
\vspace{0.15cm}
@ -446,13 +446,13 @@ Two documented production systems show this profile does \emph{not} determine a
\footnotesize
The (H,\,H) leaves of the C2 utility tree -- A4 in action, each with its response measure:
\begin{itemize}\setlength\itemsep{1pt}
\item \textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \textbf{p99 server-side latency below 200\,ms} -- the regime precomputed timelines and edge caches exist to meet. \textcolor{codegray}{(D1, D3.)}
\item \textbf{S1 (feed latency).} A user opens the home feed at global peak; the feed renders with \textbf{p99 (99th-percentile) server-side latency below 200\,ms} -- the regime precomputed timelines and edge caches exist to meet. \textcolor{codegray}{(D1, D3.)}
\item \textbf{S2 (fan-out delivery).} A user posts in normal operation; the post becomes visible to followers \textbf{within 5 seconds for the vast majority of accounts} -- Twitter's stated target, missed by design for extreme-follower accounts and compensated by hybrid fan-out. D2's amplification reading -- and a \emph{licence} on D4: seconds of staleness are within contract.
\item \textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \textbf{SLO attainment maintained and the blast radius of any single component failure below a declared bound}. \textcolor{codegray}{(The D5 scenario.)}
\item \textbf{S3 (availability under viral spikes).} An external event multiplies traffic within minutes; the platform keeps serving feeds with \textbf{SLO (service level objective) attainment maintained and the blast radius of any single component failure below a declared bound}. \textcolor{codegray}{(The D5 scenario.)}
\end{itemize}
\vspace{0.1cm}
$K(\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data).
$K(\text{C2})$ is comparatively light but not empty: the EU Digital Services Act (DSA: content-moderation, transparency and systemic-risk duties); GDPR (profiling, personal data).
\vspace{0.05cm}
Neither forces a consistency model -- which is precisely why this class can trade consistency away: the mirror image of C1, where regulation forbids exactly that trade. $K$ knocks out little; \textbf{the discrimination work is done by the weights, not the constraints.}
@ -474,11 +474,11 @@ D4 Consistency \& integrity & L & a feed seconds stale is invisible; eventual by
D5 Availability \& isolation & \textbf{H} & an unavailable feed is the defect; spikes arrive within minutes \\
D6 Security \& auditability & M & DSA and GDPR duties matter but do not shape the topology \\
D7 Evolvability & \textbf{H} & permanent A/B experiments; features live weeks, platform decades \\
D8 Simplicity \& TTM & M & simplicity welcome but outbid by feature velocity at scale \\
D8 Simplicity \& time-to-market & M & simplicity welcome but outbid by feature velocity at scale \\
D9 Testability \& deployability & \textbf{H} & ca.\ 100 deployments per day need cheap, safe releases \\
D10 Operating cost & M & fleet cost matters but never vetoes the read path \\
D11 Team scaling & \textbf{H} & hundreds of feature teams must deploy independently \\
D12 AI integrability & M & ranking and moderation are ML components off the p99 path \\
D12 AI integrability & M & ranking and moderation are ML (machine-learning) components off the p99 path \\
\midrule
Shape $S(a)$ & \multicolumn{2}{l}{interactive read-heavy} \\
Constraints $K(a)$ & \multicolumn{2}{l}{DSA; GDPR} \\
@ -494,7 +494,7 @@ Constraints $K(a)$ & \multicolumn{2}{l}{DSA; GDPR} \\
\item It exploits exactly the cell the L and MM columns share: stateless replication of the application tier scales \emph{reads} far -- so D1 High is servable from a monolith. \textbf{A monolith is a potential organisational problem, not a read-scaling problem}
\item A2 bites on D11: one release train throttles hundreds of teams -- why \textbf{Twitter/X} migrated from a Rails monolith to JVM services as organisation and load grew, and why its fan-out is an \emph{event flow} at heart: fan-out-on-write is publish/subscribe, the EDA column's home turf ($++$ on D1, D2 and D7's attach-new-consumers reading)
\item The MS column serves the same three Highs -- independent scaling of feed, media and graph services (D1), independent team deployments (D9, D11) -- at the documented price of $--$ on D8 and D10, accepted at this scale
\item \textbf{Mastodon} (open-source reference): Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, Node.js streaming API, federated via ActivityPub. The entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source: \emph{Mastodon is the secondary recommendation running in public}
\item \textbf{Mastodon} (open-source reference): Rails monolith with Sidekiq job queues, PostgreSQL (single writer, read replicas), Redis as feed cache and queue backend, Node.js streaming API (application programming interface), federated via ActivityPub. The entire fan-out mechanic -- one Sidekiq job per follower feed -- is inspectable in source: \emph{Mastodon is the secondary recommendation running in public}
\end{itemize}
\end{frame}
@ -542,7 +542,7 @@ Constraints $K(a)$ & \multicolumn{2}{l}{DSA; GDPR} \\
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{Reorganisation.} The dominant challenge is not technical: the \emph{organisation} keeps changing under the software. Maintenance and enhancement consume roughly 40--80\,\% (typically about 60\,\%) of life-cycle cost, mostly for adapting to reorganisations and process changes rather than repair -- the single strongest demand, on D7. Lifetimes 10--20 years and routinely beyond plan: the fortieth process change is not rhetorical
\item \textbf{Budget.} Small internal teams against internal cost centres; every franc spent on platform machinery is a franc unavailable for the next reorganisation -- a standing demand on D8 and D10, and a standing veto against premium structures
\item \textbf{Workload.} Almost no pressure: CRUD-dominated, moderately read-heavy (80/20 rule of thumb), office-hours load, gigabytes to a few terabytes of structured data -- D1, D2, D5 do not bind; a single relational ACID database almost always suffices; integration demand, however, is high
\item \textbf{Workload.} Almost no pressure: CRUD-dominated (create/read/update/delete forms over data), moderately read-heavy (80/20 rule of thumb), office-hours load, gigabytes to a few terabytes of structured data -- D1, D2, D5 do not bind; a single relational ACID database almost always suffices; integration demand, however, is high
\item \textbf{Witnesses.} Internal control systems demand enforced dual control and a complete audit trail per case -- D4 (transactional case state) and D6
\end{itemize}
\end{frame}
@ -573,18 +573,18 @@ $K(\text{C3})$: GDPR for employee data; statutory retention duties (Switzerland:
D1 Read scalability & L & dozens to thousands of internal users at office-hours load \\
D2 Write scal.\ \& elasticity & L & two requests per second at the July peak -- nothing to elasticise \\
D3 Latency & M & 1--2\,s form turnaround suffices, but not unboundedly more \\
D4 Consistency \& integrity & \textbf{H} & case state transactional; one skipped approval is an ICS finding \\
D4 Consistency \& integrity & \textbf{H} & case state transactional; one skipped approval is an ICS (internal control system) finding \\
D5 Availability \& isolation & L & hours of downtime are tolerable; the work waits \\
D6 Security \& auditability & \textbf{H} & four-eyes enforcement and a tamper-evident trail per case \\
D7 Evolvability & \textbf{H} & ca.\ 60\,\% of life-cycle cost is evolution, driven by reorganisations \\
D8 Simplicity \& TTM & \textbf{H} & small teams, internal budgets: simplest adequate structure wins \\
D8 Simplicity \& time-to-market & \textbf{H} & small teams, internal budgets: simplest adequate structure wins \\
D9 Testability \& deployability & M & releases weekly, not hourly; regression scope modest \\
D10 Operating cost & \textbf{H} & the budget belongs to the next reorganisation, not platform staff \\
D11 Team scaling & L & one team, often part-time \\
D12 AI integrability & L & document extraction decorates the intake edge; core untouched \\
\midrule
Shape $S(a)$ & \multicolumn{2}{l}{interactive} \\
Constraints $K(a)$ & \multicolumn{2}{l}{Retention law (e.g.\ OR 958\emph{f}); internal control systems; GDPR} \\
Constraints $K(a)$ & \multicolumn{2}{l}{Retention law (Swiss Code of Obligations, Art.\ 958\emph{f}); internal controls; GDPR} \\
\bottomrule
\end{tabular}
\end{center}
@ -659,9 +659,9 @@ The modal industrial answer: a three-tier or modular-monolith application over o
\footnotesize
\begin{itemize}\setlength\itemsep{1pt}
\item \textbf{Cross-module atomicity.} An order confirmation must commit order, stock reservation and ledger posting together, with zero half-completed postings, ever -- the hardest possible demand on D4, coupled directly to D6: financial-reporting law demands an unbroken, tamper-evident chain from source document to ledger entry. Eventual consistency \emph{between ledger and inventory} is not merely inconvenient -- it contradicts the audit obligation itself
\item \textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC generation to end-2027 (optionally 2030) because customers could not complete their migrations. ERP life cycles of 20--30 years are the normal case; replacement projects run for years
\item \textbf{Time.} SAP R/3 appeared in 1992; SAP had to extend mainstream maintenance for the ECC (ERP Central Component) generation to end-2027 (optionally 2030) because customers could not complete their migrations. ERP life cycles of 20--30 years are the normal case; replacement projects run for years
\item Under that horizon \emph{customising pressure is permanent} -- every enterprise adapts the system to itself -- so the central requirement is a disciplined extension mechanism (modules and add-ons rather than core modification): D7, with the operative sub-requirement that \textbf{extensions survive releases}. Change-rate signature inverse to load: core processes stable, customisations churn
\item \textbf{Rhythm, not volume.} Mixed workload: an OLTP core with deterministic batch peaks (month-end and year-end close, MRP runs, payroll); interactive latency of 1--2\,s suffices (D3 Medium); the batch window is a hard boundary; load is almost never the problem -- D1 and D2 Low; planned maintenance windows are an accepted norm, which caps D5 at Medium. Data medium to large, highly structured, very long retention
\item \textbf{Rhythm, not volume.} Mixed workload: an OLTP (online transaction processing) core with deterministic batch peaks (month-end and year-end close, MRP -- material requirements planning -- runs, payroll); interactive latency of 1--2\,s suffices (D3 Medium); the batch window is a hard boundary; load is almost never the problem -- D1 and D2 Low; planned maintenance windows are an accepted norm, which caps D5 at Medium. Data medium to large, highly structured, very long retention
\end{itemize}
\end{frame}
@ -675,7 +675,7 @@ The (H,\,H) leaves of the C4 utility tree -- A4 in action:
\end{itemize}
\vspace{0.1cm}
$K(\text{C4})$: financial-reporting law (Swiss CO, HGB, IFRS); audit-proof archiving duties (GoBD in Germany, GeB\"uV in Switzerland); GDPR for the HR module; SOX control requirements for US-listed groups.
$K(\text{C4})$: financial-reporting law (Swiss Code of Obligations, the German Commercial Code HGB, the International Financial Reporting Standards IFRS); audit-proof archiving duties (GoBD in Germany, GeB\"uV in Switzerland); GDPR for the HR module; SOX (Sarbanes--Oxley) control requirements for US-listed groups.
\end{frame}
@ -695,7 +695,7 @@ D4 Consistency \& integrity & \textbf{H} & cross-module ACID postings order $\to
D5 Availability \& isolation & M & planned maintenance windows are an accepted ERP norm \\
D6 Security \& auditability & \textbf{H} & unbroken, tamper-evident chain from source document to ledger \\
D7 Evolvability & \textbf{H} & 20--30-year lifetimes; extensions must survive releases \\
D8 Simplicity \& TTM & M & nobody expects an ERP overnight, but complexity still costs \\
D8 Simplicity \& time-to-market & M & nobody expects an ERP overnight, but complexity still costs \\
D9 Testability \& deployability & M & release trains; extension contracts verified before rollout \\
D10 Operating cost & M & material, but never the deciding dimension \\
D11 Team scaling & M & several module teams coordinate inside one release \\
@ -714,11 +714,11 @@ Constraints $K(a)$ & \multicolumn{2}{l}{GoBD/GeB\"uV; SOX; IFRS audit chains} \\
\begin{frame}{C4 -- what real systems chose, and why}
\footnotesize
\begin{itemize}\setlength\itemsep{2pt}
\item \textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM data model, extended by inheritance. \textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs
\item \textbf{Odoo}: a modular Python monolith over PostgreSQL -- every business domain a module over one shared ORM (object-relational mapping) data model, extended by inheritance. \textbf{ERPNext} (Frappe; Python, MariaDB): metadata-driven -- DocTypes generate schema, forms and REST APIs
\item Both: strict module boundaries, one deployment, one database, shared transactions -- \emph{the modular monolith in its purest industrial form}
\item Read against the MM column: one ACID quantum answers the D4 veto; domain modules and a disciplined extension mechanism answer D7 -- exactly S3; the $-$ on D5 is absorbed because the class weights D5 only Medium: \textbf{a rare case where a pattern's weak cell meets a class that does not care}
\item A2 starkest in the opposite direction: decomposing an ERP into independently deployable services turns cross-module atomicity into distributed sagas -- MS's $--$ on D4 meets the class's hardest High: \textbf{the structurally strongest anti-fit in the whole grid}; community attempts to cut such systems into microservices have remained marginal -- the near-absence of viable microservice ERPs after a decade of microservices enthusiasm is itself empirical evidence
\item Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI, banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window
\item Mitigation runs through the edges: hexagonal ports at the integration peripheries (EDI -- electronic data interchange -- banking, tax services) keep customising out of the core; period-end closing, MRP and payroll are canonical PF runs inside the batch window
\end{itemize}
\end{frame}
@ -779,13 +779,13 @@ Constraints $K(a)$ & \multicolumn{2}{l}{GoBD/GeB\"uV; SOX; IFRS audit chains} \\
\footnotesize
The (H,\,H) leaves of the C5 utility tree -- A4 in action:
\begin{itemize}\setlength\itemsep{1pt}
\item \textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\times$ normal load; browsing and checkout continue with \textbf{p95 checkout latency within budget and zero uncompensated oversells at 10$\times$ baseline in the pre-peak load test}. \textcolor{codegray}{(D2, D5, D9.)}
\item \textbf{S1 (peak elasticity).} Black-Friday traffic arrives at 10--50$\times$ normal load; browsing and checkout continue with \textbf{p95 (95th-percentile) checkout latency within budget and zero uncompensated oversells at 10$\times$ baseline in the pre-peak load test}. \textcolor{codegray}{(D2, D5, D9.)}
\item \textbf{S2 (page latency).} A customer opens a product page in normal operation; it renders \textbf{in under 1--2\,s, with API calls under 100--300\,ms} -- the budgets behind the revenue calibrations. \textcolor{codegray}{(D1/D3.)}
\item \textbf{S3 (payment-scope containment).} A security assessor audits the cardholder-data environment; the audit scope is demonstrably \textbf{confined to the tokenised payment subsystem, with third-party scripts on checkout pages inventoried and controlled} -- PCI~DSS v4.0 read as a scenario. \textcolor{codegray}{(The D6 scenario.)}
\end{itemize}
\vspace{0.1cm}
$K(\text{C5})$: PCI~DSS v4.0 governs cardholder data -- v3.2.1 retired 31~March 2024; future-dated requirements mandatory since 31~March 2025, including MFA for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2 (payment initiation, strong customer authentication); GDPR for customer data.
$K(\text{C5})$: PCI~DSS v4.0 governs cardholder data -- v3.2.1 retired 31~March 2024; future-dated requirements mandatory since 31~March 2025, including MFA (multi-factor authentication) for all access to the cardholder-data environment and control of third-party scripts on checkout pages. PSD2, the EU Payment Services Directive (payment initiation, strong customer authentication -- SCA); GDPR for customer data.
\vspace{0.05cm}
Direct architectural implication: \textbf{payment-scope minimisation} through tokenisation and outsourcing -- the audit scope is a function of the structure, so the structure is chosen to shrink it: \emph{regulation acting on D6 as a structural force}.
@ -807,7 +807,7 @@ D4 Consistency \& integrity & M & hybrid by definition: catalogue eventual, chec
D5 Availability \& isolation & \textbf{H} & downtime converts to revenue loss at documented rates \\
D6 Security \& auditability & \textbf{H} & PCI DSS v4.0 makes payment-scope minimisation structural \\
D7 Evolvability & \textbf{H} & promotions, checkout experiments, provider churn arrive weekly \\
D8 Simplicity \& TTM & M & speed to market matters, but not at the checkout's expense \\
D8 Simplicity \& time-to-market & M & speed to market matters, but not at the checkout's expense \\
D9 Testability \& deployability & \textbf{H} & load tests at 10$\times$ baseline gate the season \\
D10 Operating cost & M & fleet cost matters; the revenue stakes dominate it \\
D11 Team scaling & M & organisation-size dependent: Shopify versus Amazon \\
@ -868,7 +868,7 @@ D4 Consistency \& integrity & \textbf{H} & L & \textbf{H} & \textbf{H} & M \\
D5 Availability \& isolation & \textbf{H} & \textbf{H} & L & M & \textbf{H} \\
D6 Security \& auditability & \textbf{H} & M & \textbf{H} & \textbf{H} & \textbf{H} \\
D7 Evolvability & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} & \textbf{H} \\
D8 Simplicity \& TTM & L & M & \textbf{H} & M & M \\
D8 Simplicity \& time-to-market & L & M & \textbf{H} & M & M \\
D9 Testability \& deployability & \textbf{H} & \textbf{H} & M & M & \textbf{H} \\
D10 Operating cost & L & M & \textbf{H} & M & M \\
D11 Team scaling & M & \textbf{H} & L & M & M \\