1010 lines
64 KiB
TeX
1010 lines
64 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 10 slides, typeset with the official FHGR beamer theme
|
|
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
|
|
% Slide content is unchanged; only the presentation layer is the FHGR template.
|
|
% ============================================================================
|
|
\documentclass[aspectratio=169]{beamer}
|
|
|
|
\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}
|
|
|
|
% ============================================
|
|
% PACKAGES
|
|
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
|
|
% listings, hyperref, environ and xparse -- only the extras are needed here.
|
|
% ============================================
|
|
\usepackage[british]{babel}
|
|
\usepackage{booktabs}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{tcolorbox}
|
|
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}
|
|
|
|
% ============================================
|
|
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
|
|
% The names used throughout the slides are kept, so no slide text changes;
|
|
% they now resolve to the FHGR brand colours defined by the theme.
|
|
% ============================================
|
|
\colorlet{bankblue}{blue} % FHGR blue (4B92A4)
|
|
\colorlet{bankgreen}{green} % FHGR green (817E65)
|
|
\colorlet{bankred}{red} % FHGR red (C60219)
|
|
\colorlet{codegray}{gray} % FHGR gray (595959)
|
|
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
|
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
|
|
|
% Attribution labels in English (theme default is German)
|
|
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
|
|
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}
|
|
|
|
% ============================================
|
|
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
|
|
% ============================================
|
|
\newtcolorbox{keypoint}{
|
|
colback=bankblue!7!white,
|
|
colframe=bankblue,
|
|
title=Key Concept,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{examplebox}[1][]{
|
|
colback=bankgreen!10!white,
|
|
colframe=bankgreen,
|
|
title={Example: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{definitionbox}[1][]{
|
|
colback=linen!40!white,
|
|
colframe=camel!85!black,
|
|
title={Definition: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{thinkbox}{
|
|
colback=lightGray!35!white,
|
|
colframe=darkGray,
|
|
title=Discussion,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{hinweisbox}{
|
|
colback=bankred!5!white,
|
|
colframe=bankred,
|
|
title=Important Note,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{ailinse}[1][]{
|
|
colback=aiviolet!7!white,
|
|
colframe=aiviolet,
|
|
title={AI Lens: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{projektbox}{
|
|
colback=bankblue!4!white,
|
|
colframe=bankblue!70!black,
|
|
title=Project Link: Portfolio Intelligence Platform,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
% ============================================
|
|
% TITLE METADATA
|
|
% ============================================
|
|
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
|
|
\subtitle{Lecture 10: The Fit II -- Hybrids, Evolution Paths, and the Decision Procedure\\[0.4ex]{\small Script: Part IV, Sections 35--36 and 33}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\shortname{AISE502}
|
|
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
|
|
|
\begin{document}
|
|
|
|
% ============================================
|
|
% TITLE SLIDE
|
|
% ============================================
|
|
\FHGRTitlePage
|
|
|
|
% ============================================
|
|
% AGENDA
|
|
% ============================================
|
|
\begin{frame}{Agenda}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item \textbf{Hybrids and evolution paths} -- fit as a function of time
|
|
\item The \textbf{eight-step decision procedure}
|
|
\item The reference run: \textbf{ADR-007} -- compare it with your A2
|
|
\item The \textbf{ten matrix rows} in detail
|
|
\item This week's exercise: \textbf{the deterministic core (M4)}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Both operands are now yours}: $C(p)$ for seven patterns (Part II, weeks 4--6) and $R(a)$ for ten classes (Part III: C10 in week 6, C1--C5 in week 8, C6--C9 in week 9)
|
|
\item \textbf{Lecture 7} (Part IV, first lecture): three cases, three stages -- knock-out and shape gate, veto with documented mitigation, holistic ordinal reading; $\mathrm{fit}(a,p)$ formally; why not a weighted sum; cell semantics; the $7 \times 10$ grid read by column and by row; the measurement contract introduced
|
|
\item \textbf{Lectures 8--9}: all ten class profiles -- challenges $\to$ binding scenarios $\to$ weights $\to$ what real systems chose
|
|
\item \textbf{Your project}: A2 (ADR $+$ C4 $+$ measurement contract) passed the design-review gate in week 7; the walking skeleton runs end-to-end (M3); \textbf{M4 -- the deterministic core -- starts this week}
|
|
\item \textbf{Today, three moves}: (1) what the matrix cannot say -- hybrids and fit as a function of time; (2) the eight-step procedure and the reference run ADR-007, to hold against your own A2; (3) the ten rows cell by cell -- the same evidence, now matched
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% HYBRIDS AND EVOLUTION PATHS
|
|
% ============================================
|
|
\section{Hybrids and Evolution Paths}
|
|
|
|
\begin{frame}{Hybrids and evolution paths -- four episodes you already know}
|
|
\emph{\textcolor{bankblue}{What happens when a fit that was right stops being right?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize You know all four episodes (Lectures 1, 4, 5, 6 and the support points of Lecture 7) -- the new reading is the sentence after them:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{2018, Segment}: more than 140 per-destination services a small team could no longer test or operate -- consolidated into one deployable
|
|
\item \textbf{2023, Amazon Prime Video}: monitoring workflow moved from serverless orchestration into a single process -- infrastructure cost cut by over $90\,\%$
|
|
\item \textbf{Shopify}: the opposite of extraction -- stay a monolith, enforce module boundaries with Packwerk, shard whole-monolith pods
|
|
\item The classical \textbf{outward} move -- growing the new structure around a legacy core -- has carried its own name since 2004: the \textbf{Strangler Fig}
|
|
\item \textbf{None of these corrects a \emph{wrong} initial decision}: each is a fit that \emph{was} right decaying as profile, organisation, or measured load drifted -- \textbf{Assumption A5 in production}
|
|
\item Two instruments for exactly that situation, taught as rules rather than footnotes: \textbf{hybrids} (different patterns where one no longer serves all subsystems) and \textbf{evolution paths} (documented, repeatable repairs between patterns)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Hybrids are the normal case -- and the unit of evaluation}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textbf{Eight of the ten primary recommendations of \S 33 are compositions -- among them:}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\begin{tabular}{@{}p{0.9cm}p{5.0cm}@{}}
|
|
\toprule
|
|
\textbf{Class} & \textbf{Composition} \\
|
|
\midrule
|
|
C1, C5 & a consistent core with event-driven edges \\
|
|
C7 & a pipeline feeding a serving layer \\
|
|
C8 & a log with stream processors \\
|
|
C9 & a monolith with a specialised push layer \\
|
|
C10 & a hexagonal core with pipelines and orchestration \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item only \textbf{C4} (pure MM) and \textbf{C6} (pure PF) come close to a single-pattern answer -- and even they carry subordinate pipelines and glue
|
|
\item \textcolor{codegray}{(Lecture 7)} a cell rates the \emph{dominant structure of the core} (bold $=$ primary); the composition lives in the row rationale, never in the cell value
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.50\textwidth}
|
|
\begin{keypoint}
|
|
\footnotesize The unit of fit evaluation is the \textbf{subsystem with its own architecture quantum} -- its own unit of deployment, scaling, and failure. Applying the matrix to a whole enterprise in one stroke is a \textbf{category error the theory explicitly forbids}: the question is never ``is this company a microservices company?'' but ``what is the dominant structure of \emph{this} subsystem's core, and which patterns serve its edges?''. The composition must be \textbf{recorded} -- a C4-model container diagram is the natural notation, since the seven patterns differ most visibly at container level.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{bankblue}{\textbf{Project link:}} your A2 C4 container diagram should be that record -- check that it shows which patterns own which container.
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Fit is a function of time -- Lehman's laws and MonolithFirst}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Lehman's laws} guarantee the drift the four episodes displayed: a system embedded in the real world must \textbf{continually change or become progressively less useful}, and its \textbf{complexity increases unless work is invested to reduce it}
|
|
\item Hence a fit established at design time \emph{decays} (Assumption A5) -- and every recommendation must carry a \textbf{migration strategy}; three documented strategies span the space
|
|
\item \textbf{MonolithFirst} \textcolor{codegray}{(recap: Lecture 7, \S 34 column reading -- MM primary or secondary in seven of ten classes; Lecture 4's choose-when line)}: stable service boundaries cannot be cut before the domain is understood, so do not start with microservices even if you expect to need them
|
|
\item New here: the matrix encodes this as the MM column's default dominance -- Lecture 7's ``unfashionable default''; the evolution path encodes it as the \textbf{sanctioned starting state}
|
|
\item \textcolor{codegray}{(Strategies two and three -- Strangler Fig and sacrificial architecture -- on the next frame)}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Fit is a function of time -- Strangler Fig both ways, sacrificial architecture}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Strangler Fig.} Grow the new structure around the old, intercepting and capturing function by function -- the migration stays \emph{incremental and stoppable at any point}
|
|
\item The pattern works in \textbf{both directions}: \emph{outward} -- extracting services from a monolith along verified module boundaries; \emph{inward} -- the Segment and Prime Video consolidations that opened the section
|
|
\item A \textbf{third direction}, Uber's DOMA \textcolor{codegray}{(Lecture 5)}: beyond roughly 2{,}200 services, a \emph{second} structuring level (about 70 domains with gateways) had to be re-introduced -- convergence back towards macro-modules
|
|
\item \textbf{Sacrificial architecture.} Consciously accept that the current structure will be replaced in a few years while keeping internal quality high
|
|
\item Especially legitimate for AI-native components whose model and tool landscape turns over in months \textcolor{codegray}{(AI Lens, three frames on)}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The documented evolution paths -- a state diagram}
|
|
\begin{center}
|
|
\resizebox{0.9\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
sysbox/.style={rectangle, draw, rounded corners=4pt, minimum width=3.2cm, minimum height=1.1cm, align=center, font=\small\sffamily, line width=0.8pt},
|
|
core/.style={sysbox, fill=bankblue!20, draw=bankblue, font=\small\sffamily\bfseries},
|
|
comp/.style={sysbox, fill=bankgreen!15, draw=bankgreen},
|
|
extern/.style={sysbox, fill=gray!15, draw=gray!60!black},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
|
|
lbl/.style={font=\footnotesize\sffamily, align=center}
|
|
]
|
|
\node[extern] (L) at (0,0) {L\\Layered monolith};
|
|
\node[core] (MM) at (7.6,0) {MM\\Modular monolith};
|
|
\node[comp] (MS) at (15.2,0) {MS\\Microservices};
|
|
\node[extern] (SL) at (0,-3.2) {SL\\Serverless orchestration};
|
|
\node[comp] (DOM) at (15.2,-3.2) {Domain-bundled\\services (DOMA)};
|
|
|
|
\draw[arr] (L) -- node[lbl, above=1pt] {enforce domain boundaries\\(Packwerk, ArchUnit, Modulith)} (MM);
|
|
\draw[arr] (MM) -- node[lbl, above=1pt] {Strangler-Fig extraction\\when D11 measurably binds} (MS);
|
|
\draw[arr] (MS.south west) to[bend left=22] node[lbl, below=3pt] {consolidation (Segment 2018)} (MM.south east);
|
|
\draw[arr] (MS) -- node[lbl, right=3pt] {re-bundle into $\sim$70 domains\\(Uber DOMA 2020)} (DOM);
|
|
\draw[arr] (SL.east) -| node[lbl, above=2pt, pos=0.22] {process consolidation\\(Prime Video 2023, $-90\,\%$ cost)} (MM.south);
|
|
\draw[arr, dashed] (L.north) to[out=55, in=125, looseness=1.1] node[lbl, above=2pt] {sacrificial rebuild (planned replacement)} (MM.north);
|
|
\end{tikzpicture}}%
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize \emph{The modular monolith is both the sanctioned starting state (MonolithFirst) and the documented consolidation target.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Maxim 5 -- buy options on tomorrow's profile}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Maxim 5.} Choose the pattern for the requirements profile you can \emph{verify today}; buy \emph{options} on the profile you expect tomorrow -- via module boundaries, ports, and a strangler-ready seam, \textbf{not via speculative distribution}. Every arrow in the evolution diagram is cheaper to traverse when the boundaries it needs were bought in advance as \textbf{modules and ports} rather than as \textbf{processes}.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.2cm}
|
|
\footnotesize
|
|
\textbf{Reading against the diagram:}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item L $\to$ MM \emph{buys} the boundaries
|
|
\item MM $\to$ MS \emph{spends} them -- only when D11 \emph{measurably} binds
|
|
\item the inward arrows (Segment, Prime Video) are cheaper when the seams already exist as modules and ports
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{bankblue}{\textbf{Project link:}} your Spring-Modulith-verified modules and the LLM gateway port are exactly such options (ADR-007, later today).
|
|
\end{frame}
|
|
|
|
\begin{frame}{AI Lens: sacrificial architecture for AI-native components}
|
|
\begin{ailinse}[Axis B]
|
|
\footnotesize LLM providers deprecate models on windows of \textbf{months, not years}, and the agent-framework landscape turns over even faster. For the AI layer of a C10 system, sacrificial architecture is therefore \textbf{not an admission of failure but the rational default}: design the AI subsystem \emph{to be replaced} -- behind a port, with an \textbf{eval harness as the acceptance gate for its successor} -- while the \textbf{deterministic core is designed to last}. The port boundary converts a provider deprecation from an \emph{architecture revision} (the steep part of the cost-of-change curve, \S 37 next week) into an \emph{adapter task}.
|
|
\end{ailinse}
|
|
|
|
\vspace{0.25cm}
|
|
\begin{projektbox}
|
|
\footnotesize The AI layer you build in weeks 12--13 is \textbf{sacrificial by design}; the deterministic core you build this week (M4) is the part \textbf{designed to last}.
|
|
\end{projektbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE DECISION PROCEDURE
|
|
% ============================================
|
|
\section{The Decision Procedure}
|
|
|
|
\begin{frame}{From a pre-filtered shortlist to a defensible decision}
|
|
\emph{\textcolor{bankblue}{How does a pre-filtered shortlist become a defensible decision?}}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize \textbf{The matrix pre-filters; it does not decide.} The teachable, auditable procedure compresses the SEI method family into \textbf{eight steps}, each with a defined \emph{artefact} and a defined \emph{measurement}, and continues into the life cycle per Assumption A5.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\begin{tabular}{@{}p{5.2cm}p{7.6cm}@{}}
|
|
\toprule
|
|
\textbf{Step} & \textbf{Artefact / measurement} \\
|
|
\midrule
|
|
(i) Identify the ASRs & ASR list, class hypothesis \\
|
|
(ii) Quality attribute scenarios & six-part scenarios with response measures \\
|
|
(iii) Utility tree & $(H,H)$ leaves $=$ the weights of $R(a)$ \\
|
|
(iv) Pre-filter via the matrix & shortlist of two to three candidates or compositions \\
|
|
(v) Trade-off analysis (ATAM-light) & sensitivity and trade-off points, risks, weight variation \\
|
|
(vi) Decide and record as ADR & MADR record with drivers and options \\
|
|
(vii) Measurement contract & fitness functions with thresholds \\
|
|
(viii) Measure in operation & DORA and QA measures continually, Lehman indicators quarterly \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\footnotesize (i)--(iii) the \textbf{demand side} $\cdot$ (iv)--(vi) the \textbf{match under governance} $\cdot$ (vii)--(viii) the \textbf{genuinely new obligations} -- detailed on the next three frames.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Steps (i)--(iii): the demand side -- ASRs, scenarios, utility tree}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{(i) Identify the ASRs.} Mine business goals, stakeholder interviews, and the regulatory frame -- \emph{not} the requirements document alone, which empirically under-specifies architecturally significant requirements
|
|
\item Classify the system as an instance (or blend) of the ten application classes -- a \textbf{hypothesis about its ASR bundle} to inherit and then correct
|
|
\item \textbf{(ii) Formulate quality attribute scenarios with response measures.} Six parts each; \textbf{no scenario without a number}
|
|
\item An unfalsifiable requirement cannot discriminate between patterns (Assumption A4)
|
|
\item \textbf{(iii) Prioritise in a utility tree.} Rate each leaf on (business importance, achievement difficulty) $\in \{H,M,L\}^2$
|
|
\item The $(H,H)$ leaves \emph{are} the weights of $R(a)$ -- this is where the matrix weights come from, so they are \textbf{derivable, not arbitrary}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{codegray}{You did exactly this in weeks 2--3 (A1); the formal mapping follows in three frames.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Steps (iv)--(v): pre-filter via the matrix, then ATAM-light}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item \textbf{(iv) Pre-filter candidate patterns via the matrix.} Knock-out constraints and shape gate first, then the veto rule (the three stages of Lecture 7). Output: \textbf{two to three candidate patterns or compositions}, including the hybrid options named in the relevant class row
|
|
\item \textbf{(v) Trade-off analysis (ATAM-light).} Walk the $(H,H)$ scenarios against each candidate's tactic bundle; classify each point found as \emph{risk} or \emph{non-risk}
|
|
\item Where money decides, extend with \textbf{CBAM} utility-response curves -- what is $99.99\,\%$ availability \emph{worth}, versus $99.9\,\%$?
|
|
\item \textcolor{codegray}{Lecture 3's rule, now mandatory at step (v):} \textbf{sensitivity analysis} -- vary the weights plausibly; if the recommendation flips, you have found a genuine trade-off point that deserves \textbf{stakeholder negotiation, not a formula}
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{definitionbox}[Sensitivity point / trade-off point]
|
|
\footnotesize \textbf{Sensitivity point}: one decision, large effect on \emph{one} attribute. \textbf{Trade-off point}: one decision, opposing effects on \emph{several} attributes.
|
|
\end{definitionbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Steps (vi)--(viii): record, contract, measure -- and keep the paths open}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{(vi) Decide and record as an ADR} \textcolor{codegray}{(Lecture 3's format: context, decision, consequences including the negative ones; superseded, never edited)}, now as step (vi). The one new element: the MADR fields ``decision drivers / considered options'' \textbf{carry the utility-tree weights and the matrix row into the record} -- ISO/IEC/IEEE 42010 Clause 6.10 fulfilled by construction, architectural knowledge vaporisation countered
|
|
\item \textbf{(vii) Define the measurement contract.} Every ADR ends with the fitness functions that would \emph{falsify} it -- with thresholds (\S 37, next week)
|
|
\item \textbf{(viii) Measure in operation and keep evolution paths open.} The DORA metrics and the quality-attribute-specific measures run \emph{continually}; Lehman indicators (growth, complexity trend, debt stock) run \emph{quarterly}
|
|
\item When measurements falsify the decision, the sanctioned responses are the \textbf{documented evolution paths} of \S 35 (the arrows of the state diagram); a revised decision is a \textbf{new ADR that supersedes} -- never silently overwrites -- the old one
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Note how much of this you have already done -- and Maxim 6}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.95}%
|
|
\begin{tabular}{@{}p{1.6cm}p{7.2cm}p{4.2cm}@{}}
|
|
\toprule
|
|
\textbf{Steps} & \textbf{Where you did it} & \textbf{Your project} \\
|
|
\midrule
|
|
(i)--(iii) & the pipeline Part III ran ten times (challenges $\to$ binding scenarios $\to$ utility-tree weights) -- inherited work, corrected against elicited scenarios & A1, weeks 2--3 \\
|
|
(iv)--(vi) & the three cases of Lecture 7 performed \emph{under governance} -- same gate, veto, ordinal reading; sensitivity analysis escalated to stakeholders, outcome recorded & the match and ADR, weeks 6--7 \\
|
|
(vii)--(viii) & the genuinely new obligations -- the remainder of Part IV (next week) & A2 measurement contract $=$ a first pass at (vii); from M4 on, CI gates generate the first data the contract measures; (viii) proper begins once the system is operated \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Maxim 6} (restated from Part I). An architecture decision without a response measure is an \emph{opinion}; with a response measure and a fitness function it is a \emph{testable hypothesis}. The eight steps exist to manufacture exactly that transformation -- from stakeholder concern to falsifiable, monitored commitment.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE REFERENCE RUN: ADR-007
|
|
% ============================================
|
|
\section{The Reference Run: ADR-007}
|
|
|
|
\begin{frame}{The reference run -- step (i): ASRs and classification}
|
|
\emph{\textcolor{bankblue}{You ran this procedure yourselves in weeks 6--7; here is the reference run to hold your A2 against.}}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (i)]
|
|
\footnotesize \textbf{(i) ASRs.} The platform analyses client portfolios and generates advisory answers with LLM support. Stakeholder interviews and the regulatory frame yield the ASR bundle:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{grounded answers with provenance}
|
|
\item \textbf{complete per-step audit logging} (EU AI Act duties may attach)
|
|
\item \textbf{per-request cost control}
|
|
\item \textbf{provider-migration robustness}
|
|
\item an \textbf{extreme change rate} for prompts and models
|
|
\end{itemize}
|
|
\textbf{Classification:} an instance of \textbf{C10}, inheriting C6/C7 traits (index and eval pipelines) and C3 traits (deterministic services) -- the inheritance diagram of week 6, now as the step-(i) hypothesis.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textcolor{bankblue}{\textbf{Check against your A2:}} which of these five ASRs does your dossier name -- and which did you find that this list lacks?
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference run -- step (ii): the binding scenario, six parts and a number}
|
|
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (ii)]
|
|
\footnotesize \textbf{(ii) Scenarios.} The binding scenario: a customer (\textbf{source}) submits a request for which the LLM generates a factually wrong recommendation (\textbf{stimulus}) in normal operation (\textbf{environment}) of the advisory platform (\textbf{artifact}); the deterministic validation layer blocks the answer and escalates to a human (\textbf{response}); detection rate $\geq 99\,\%$ at $< 2$\,s added latency (\textbf{response measure}).
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Companion scenarios} fix three more numbers:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{cost budget}: token cost per request $\leq$ CHF~0.40 at p95
|
|
\item \textbf{latency budget}: advisory answer $< 20$\,s end-to-end
|
|
\item \textbf{migration scenario}: provider deprecation absorbed within \textbf{one sprint}, \textbf{zero domain-code changes}
|
|
\end{itemize}
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textbf{No scenario without a number} -- each of these becomes a fitness function in step (vii). \textcolor{codegray}{(S1 and S2 of Lecture 6 carry the same numbers; the migration scenario adds two response measures S3 did not fix.)}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference run -- steps (iii) and (iv): utility tree and matrix shortlist}
|
|
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- steps (iii)--(iv)]
|
|
\footnotesize \textbf{(iii) Utility tree.} The $(H,H)$ leaves land on D6 (auditability), D7 (evolvability under model churn), D9 (testability, operationalised as eval pass rate), D10 (cost per request), D12 (AI integrability) -- \textbf{reproducing the High weights of the C10 column}, as the theory predicts.
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{(iv) Matrix shortlist.} The C10 row yields MM $++$ and HX $++$ as core candidates, with EDA $+$ (job/audit spine) and PF $+$ (ingestion and eval pipelines) as named edge patterns; L is excluded by \textbf{veto}, MS and SL are \textbf{capped at $\circ$}.
|
|
|
|
\vspace{0.05cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}lccccccc@{}}
|
|
\toprule
|
|
& \textbf{L} & \textbf{MM} & \textbf{HX} & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
|
|
\midrule
|
|
C10 AI-native analysis / advisory & $-$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $+$ & $+$ & $\circ$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.05cm}
|
|
\textbf{Shortlist: (a)} hexagonal modular monolith with pipelines and an async job spine; \textbf{(b)} the same core with a fuller EDA backbone.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize Two candidates, both compositions -- the hybrid options named in the class row, exactly as step (iv) prescribes.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference run -- step (v): ATAM-light, sensitivity and trade-off points}
|
|
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform (class C10) -- step (v)]
|
|
\footnotesize \textbf{(v) ATAM-light.} Walking the $(H,H)$ scenarios against both candidates identifies
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item one dominant \textbf{sensitivity point}: the placement of the \textbf{LLM gateway}, on which auditability, cost telemetry, and migration cost all hinge
|
|
\item one genuine \textbf{trade-off point}: LLM \textbf{context length} (answer quality up; cost and latency down)
|
|
\end{itemize}
|
|
\vspace{0.05cm}
|
|
\textbf{Weight variation test:} flips nothing between (a) and (b) for the core; it \emph{does} flip the job-spine choice when audit-log completeness is weighted maximally -- recorded as a \textbf{risk to be retired by a spike}.
|
|
|
|
\vspace{0.05cm}
|
|
\textbf{CBAM reasoning settles the spine:} the fuller EDA backbone buys availability the class only weights \textbf{Medium}, at an operations cost the class weights \textbf{High} -- candidate \textbf{(a) wins}.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize \textcolor{codegray}{Against the C10 profile of Lecture 6: D5 $=$ M, D10 $=$ H -- CBAM here is a weight comparison, not a curve.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The reference run -- steps (vi)--(viii): ADR, contract, operation, paths}
|
|
\begin{examplebox}[Decision run for the Portfolio Intelligence Platform -- steps (vi)--(viii)]
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{(vi) ADR.} Recorded as \textbf{ADR-007}: decision drivers $=$ the utility-tree weights; considered options $=$ the matrix shortlist -- \emph{one matrix row, narrated}
|
|
\item \textbf{(vii) Measurement contract.} ADR-007 ends with the fitness functions of the contract table (\S 37) -- module-boundary verification, determinism-boundary rule, latency and token budgets, eval pass rate, reconciliation, chaos drills -- each with threshold and cadence
|
|
\item \textbf{(viii) Operation.} DORA four keys per deployable unit; the eval harness gates every prompt and model change; Lehman indicators quarterly
|
|
\item \textbf{Declared evolution paths}, each a new, superseding ADR: extract the ingestion pipeline to its own quantum if batch load grows; replace the LLM adapter on deprecation (sacrificial by design); escalate to an EDA spine if audit volume demands it
|
|
\end{itemize}
|
|
\end{examplebox}
|
|
|
|
\footnotesize More than paperwork: the \textbf{considered options carry the matrix reasoning} (auditable), the \textbf{final section carries the contract} (falsifiable); the gateway rule it relies on is subsequently fixed in \textbf{ADR-011} \textcolor{codegray}{(Lecture 3)}.
|
|
\end{frame}
|
|
|
|
\begin{frame}{ADR-007 (1/3): context and decision drivers}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.10\textwidth}
|
|
\scriptsize\color{codegray}
|
|
\vspace{1.05cm}
|
|
step (i)
|
|
|
|
\vspace{1.85cm}
|
|
step (iii)
|
|
\end{column}
|
|
\begin{column}{0.88\textwidth}
|
|
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
|
\scriptsize\ttfamily
|
|
\textbf{ADR-007: Hexagonal modular monolith with LLM gateway}\\[2pt]
|
|
Status: accepted (2026-10-12) | supersedes: ADR-003\\[4pt]
|
|
\textbf{Context and problem statement:} The Portfolio Intelligence Platform (class C10) must deliver grounded advisory answers with full audit logging (EU AI Act), per-request cost control, and robustness against LLM provider deprecation. Change rate of prompts/models is extreme; the deterministic services (data access, portfolio computation, audit) have classical back-office profiles.\\[4pt]
|
|
\textbf{Decision drivers (utility-tree (H,H) leaves):}\\
|
|
* D6 auditability: every agent step reconstructable\\
|
|
* D7 evolvability under model churn\\
|
|
* D9 testability = eval pass rate >= 95\% in CI\\
|
|
* D10 token cost per request <= CHF 0.40 (p95)\\
|
|
* D12 AI integrability: queue, port, measurement point
|
|
\end{tcolorbox}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{ADR-007 (2/3): considered options and decision}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.10\textwidth}
|
|
\scriptsize\color{codegray}
|
|
\vspace{0.5cm}
|
|
step (iv)
|
|
|
|
\vspace{1.3cm}
|
|
steps (v)/(vi)
|
|
\end{column}
|
|
\begin{column}{0.88\textwidth}
|
|
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
|
\scriptsize\ttfamily
|
|
\textbf{Considered options (matrix shortlist, Table fit-c10):}\\
|
|
1. Hexagonal modular monolith + PF pipelines + async jobs (++)\\
|
|
2. Same core + full EDA backbone for jobs/audit (+)\\
|
|
3. Microservices per capability (o)\\
|
|
4. Layered monolith (-, veto D7)\\[4pt]
|
|
\textbf{Decision:} Option 1. Deterministic core as Spring-Modulith-verified modules; all LLM access via one gateway port (adapter owns prompts, schema validation, retries, cost telemetry); ingestion/eval as versioned pipelines; agent workflow orchestrated, not autonomous: \textbf{agents propose, deterministic services decide and book}.
|
|
\end{tcolorbox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize The options block is the record form of the step-(iv) shortlist: the ASCII ratings (++, +, o, -) are the C10 row; the one exclusion names its veto (L: veto D7), MS is capped at o, not vetoed -- exactly the step-(iv) reading.
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{ADR-007 (3/3): consequences and measurement contract}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.10\textwidth}
|
|
\scriptsize\color{codegray}
|
|
\vspace{0.5cm}
|
|
step (vi)
|
|
|
|
\vspace{1.05cm}
|
|
steps (vii)/(viii)
|
|
\end{column}
|
|
\begin{column}{0.88\textwidth}
|
|
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
|
\scriptsize\ttfamily
|
|
\textbf{Consequences:}\\
|
|
+ Provider deprecation = adapter task, not architecture revision\\
|
|
+ Single measurement point for cost, latency, audit\\
|
|
- Release coordination across modules (accepted, 2 teams)\\
|
|
- Async job spine limited; EDA escalation path documented\\[4pt]
|
|
\textbf{Measurement contract (falsifies this ADR):}\\
|
|
* ArchUnit/Modulith verify: 0 undeclared cross-module deps\\
|
|
* Static rule: no domain service imports the LLM gateway except via the declared port (0 violations)\\
|
|
* p95 advisory answer < 20 s (CI gate + production SLO)\\
|
|
* Eval harness pass rate >= 95\% on golden set; 0 ontology-violating outputs shipped\\
|
|
* Token cost per request <= CHF 0.40 at p95 (continual)\\
|
|
* Daily reconciliation booked vs. journaled: 0 discrepancies\\
|
|
* DORA four keys per deployable unit; review quarterly
|
|
\end{tcolorbox}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
\small \textbf{Hold your A2 against the reference run:}
|
|
\begin{enumerate}\setlength\itemsep{4pt}
|
|
\item Do your \textbf{considered options} name the matrix row and the vetoes behind each exclusion -- or only the winner?
|
|
\item Which of the \textbf{seven ADR-007 fitness functions} does your measurement contract carry, with a threshold and a cadence? Which is missing?
|
|
\item Your \textbf{step (v)}: what was your sensitivity point, what your trade-off point -- and did any weight variation flip a choice?
|
|
\item Which \textbf{evolution path} did you declare -- and is the seam for it bought as a module or port, or would it require a process boundary?
|
|
\end{enumerate}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE TEN ROWS IN DETAIL
|
|
% ============================================
|
|
\section{The Ten Rows in Detail}
|
|
|
|
\begin{frame}{The ten rows in detail -- how to read a row rationale}
|
|
\emph{\textcolor{bankblue}{Every cell of the grid is a verdict -- where is the computation behind it?}}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item For each class the row rationale records the \textbf{stage-by-stage computation} behind every cell -- per cell: which gate or knock-out fired, which \textbf{veto} (the High-weight dimension on which the veto rule fired), which documented \textbf{mitigation} (tactic or hybrid composition) lifted the cap -- plus the primary and secondary recommendation and the \textbf{central trade-off} the class forces
|
|
\item \textbf{Nothing in this section is new evidence: it is the same evidence, now matched} -- the production systems and numbers live in Part III's ``what real systems chose'' and are back-referenced, not re-narrated
|
|
\item Rows C6, C1 and C2 were computed as the three cases of Lecture 7 -- the tables now complete them cell by cell
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize \textcolor{codegray}{(Lecture 7)} A cell answers one question only -- \emph{how well does this pattern serve as the dominant structure of this class's core?} -- edges routinely use patterns whose cell reads $\circ$ or $-$.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The $7 \times 10$ grid, for reference}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.9}%
|
|
\vspace{-0.2cm}
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{4.8cm}ccccccc@{}}
|
|
\toprule
|
|
\textbf{Application class} & \textbf{L} & \textbf{MM} & \textbf{HX}$^{\dagger}$ & \textbf{MS} & \textbf{EDA} & \textbf{PF} & \textbf{SL} \\
|
|
\midrule
|
|
C1 Core banking / transactions & $\circ$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $-$ & $\circ$ & $-$ \\
|
|
C2 Social media / content platform & $\circ$ & $+$ & $\circ$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $\circ$ \\
|
|
C3 Back-office / workflow & $+$ & {\boldmath$++$} & $+$ & $--$ & $-$ & $\circ$ & $\circ$ \\
|
|
C4 ERP / enterprise core system & $\circ$ & {\boldmath$++$} & $+$ & $--$ & $-$ & $\circ$ & $--$ \\
|
|
C5 E-commerce platform & $-$ & {\boldmath$++$} & $+$ & $+$ & $+$ & $\circ$ & $+$ \\
|
|
C6 Simulation / batch compute & $--$ & $\circ$ & $\circ$ & $--$ & $\circ$ & {\boldmath$++$} & $\circ$ \\
|
|
C7 Decision support / BI analytics & $+$ & $+$ & $\circ$ & $-$ & $\circ$ & {\boldmath$++$} & $+$ \\
|
|
C8 Real-time / IoT streaming & $--$ & $-$ & $\circ$ & $+$ & {\boldmath$++$} & $+$ & $-$ \\
|
|
C9 Collaboration / messaging & $\circ$ & $+$ & $\circ$ & $+$ & {\boldmath$++$} & $-$ & $--$ \\
|
|
C10 AI-native analysis / advisory & $-$ & {\boldmath$++$} & {\boldmath$++$} & $\circ$ & $+$ & $+$ & $\circ$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
$^{\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''. The HX column is never negative. Bold $=$ the cells underlying the primary recommendation.
|
|
\end{frame}
|
|
|
|
\begin{frame}{C1 -- core banking: the canonical hybrid, ACID core and EDA edges}
|
|
\footnotesize \textcolor{codegray}{Case 2 of Lecture 7 computed the contested pair MM vs.\ MS; the table completes the remaining cells.}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $\circ$ & a single ACID database satisfies the consistency veto, but technical layering fails decades-long evolvability (veto D7) and the change-isolation needs of a banking core \\
|
|
MM & {\boldmath$++$} & cross-module ACID plus enforced domain boundaries match the consistency veto and the peripheral change rate (veto D5; mitigation: hot-standby replication) -- Fineract in production \\
|
|
HX & {\boldmath$++$} & ports isolate a long-lived booking core from volatile channels, providers, and AI scoring adapters; the core becomes hermetically testable -- the standard bank-backend discipline \\
|
|
MS & $\circ$ & sagas replace ACID in the money path (veto D4; mitigation only under the Monzo condition: organisational scale plus extreme homogeneity); premium paid in platform staff, no gain at typical team sizes \\
|
|
EDA & $-$ & eventual consistency vetoed in the booking core (veto D4: High vs.\ $--$, uncapped as dominant structure); as an \emph{edge} pattern the immutable event journal is the natural regulatory audit trail \\
|
|
PF & $\circ$ & shape gate -- end-of-day clearing, statements, and risk runs are genuine batch pipelines, but the pattern cannot carry the interactive account core \\
|
|
SL & $-$ & stateful sequential ordering, strict guarantees, auditable long-lived state vs.\ ephemeral stateless functions (veto D4; weak on all remaining High-weight dimensions) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: hexagonal modular monolith for the booking core -- central trade-off: consistency vs.\ scalability, resolved by \emph{placing} patterns: ACID core, EDA edges.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C2 -- social media / content platform: the mirror image of C1}
|
|
\footnotesize \textcolor{codegray}{Case 3 of Lecture 7 ran this row's Stage-3 finale between MS and EDA; the table records the full row.}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $\circ$ & Instagram proves a layered monolith scales reads via stateless replication, but single-quantum releases and technical partitioning throttle High-weighted feature velocity (veto D7, D11) \\
|
|
MM & $+$ & Instagram-style scaling plus domain-cut change isolation (veto D5; mitigation: replicated instances); the honest ceiling is release coordination once team count passes roughly five \\
|
|
HX & $\circ$ & adds testability, but the binding constraints (read fan-out, team scaling) live elsewhere, and feed paths carry little long-lived domain logic \\
|
|
MS & {\boldmath$++$} & independent scaling of feed, media, graph services plus independent team deployments match D1, D7, D11 at once (veto D3; mitigation: edge caching, precomputed timelines); the $--$ on cost and simplicity accepted at this scale \\
|
|
EDA & {\boldmath$++$} & fan-out-on-write \emph{is} an event flow -- the Twitter timeline architecture; new consumers attach without touching producers (veto D9; mitigation: schema/contract tests plus progressive delivery) \\
|
|
PF & $\circ$ & shape gate -- feed precomputation, ranking-model training, media processing are pipelines beside the serving path, never the interactive product core \\
|
|
SL & $\circ$ & viral spikes suit elastic functions (veto D3: cold starts), yet sustained baseline load makes per-execution pricing structurally expensive \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: EDA $+$ microservices hybrid at organisational scale -- central trade-off: read scalability and team scaling vs.\ simplicity and cost; the exact mirror of C1.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C3 -- back-office / workflow: day-one simplicity vs.\ multi-decade evolvability}
|
|
\footnotesize \textcolor{codegray}{Lecture 3's Discussion predicted this row: L $+$, MM $++$, MS $--$.}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $+$ & CRUD over one ACID store at office-hours load is the native habitat (High D8 rewards simplicity); the $-$ on High-weighted evolvability is the legacy-rot risk (veto D7; mitigation only for small, stable scope -- scoping, hence $+$ not $++$) \\
|
|
MM & {\boldmath$++$} & the same run cost with domain boundaries that pay off over the 10--20-year evolution horizon dominating this class's cost -- the Pareto choice when process change is frequent \\
|
|
HX & $+$ & worth the indirection where long-lived process logic meets volatile integrations -- LDAP, ERP, DMS, workflow engine as adapter (veto D8; mitigation: ports only at the integration seams) \\
|
|
MS & $--$ & the premium buys scaling and team autonomy this class does not need, at simplicity and run costs \textbf{vetoed twice} (veto D8, D10) \\
|
|
EDA & $-$ & asynchronous choreography destroys the traceable, sequential process semantics (four-eyes principle, audit trail) the class is built around (veto D8: $--$ on High); a workflow engine, not a broker, is the fit \\
|
|
PF & $\circ$ & shape gate -- nightly reporting jobs and imports are pipelines at the edge of an interactive forms-over-data core \\
|
|
SL & $\circ$ & sporadic office-hours load fits scale-to-zero economics, but the operational skill investment rarely amortises for internal IT \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: modular monolith with externalised process logic (a Camunda-class workflow engine behind a port) -- central trade-off: day-one simplicity vs.\ multi-decade evolvability.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C4 -- ERP core: the strongest anti-fit in the grid}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $\circ$ & one schema, one transaction scope fits the integration mandate, but technical layers offer no discipline against permanent customising pressure (veto D7; no scoping mitigation -- ERP scope is never small) \\
|
|
MM & {\boldmath$++$} & modules over a shared ACID data model with a disciplined extension mechanism is \emph{literally} Odoo/ERPNext; \textbf{no veto fires} -- the $-$ on D5 is Medium-weight (planned maintenance windows are an accepted ERP norm) \\
|
|
HX & $+$ & ports pay off at the integration peripheries (EDI, banking, tax services) and keep customising out of the core -- the survival condition for 20--30-year life cycles \\
|
|
MS & $--$ & cross-module ACID postings (order $\to$ stock $\to$ ledger) are the product's value and become distributed sagas (veto D4) -- \textbf{structurally the strongest anti-fit in the grid} \\
|
|
EDA & $-$ & eventual consistency between ledger and inventory contradicts the class's defining integrity guarantee (veto D4); events serve only outbound integration \\
|
|
PF & $\circ$ & shape gate -- period-end closing, MRP, payroll runs are canonical scheduled pipelines inside the batch window: a subordinate, well-fitting component \\
|
|
SL & $--$ & long transactions, batch windows, stateful sessions, a monolithic data model contradict short-lived stateless functions on every axis (veto D4, plus the sustained-load cost inversion) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: modular monolith -- central trade-off: one integrated data model vs.\ independent module scaling and deployment, resolved by module boundaries \emph{inside} one transactional quantum.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C5 -- e-commerce: seasonal elasticity vs.\ checkout consistency}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $-$ & a small shop is served honestly, but the single write path is what the defining 10--50$\times$ seasonal peaks break (veto D2: $--$ on High, no mitigation within the pattern); full-regression releases fail D9 \\
|
|
MM & {\boldmath$++$} & Shopify's Packwerk-enforced modular Rails core carries roughly 280 million requests per minute while preserving checkout ACID (veto D2; mitigation: pod-sharded replication; veto D5; mitigation: replicated pods) \\
|
|
HX & $+$ & ports around payment, logistics, tax, and search providers localise very high integration churn -- and shrink the PCI audit scope \\
|
|
MS & $+$ & Amazon's founding case shows the fit at organisational scale (veto D3; mitigation: caching, edge delivery); below that scale the platform premium ($--$ on Medium D10) eats margin -- $++$ only when D11 measurably binds \\
|
|
EDA & $+$ & order flows, inventory updates, saga-based checkout choreography are event-shaped at the edges of an ACID checkout (veto D9; mitigation: contract tests, progressive delivery) \\
|
|
PF & $\circ$ & shape gate -- catalogue feeds, search indexing, recommendation training are supporting pipelines, not the storefront \\
|
|
SL & $+$ & flash-sale spikes are the textbook elastic-load case (veto D3; mitigation: provisioned concurrency, edge runtimes); sustained catalogue traffic and checkout latency SLOs keep it from primary status \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: modular monolith with a hybrid consistency profile inside (catalogue eventual, checkout ACID) and event-driven edges -- central trade-off: seasonal elasticity vs.\ checkout consistency.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C6 -- simulation / batch compute: a row decided at Stage 1}
|
|
\footnotesize \textcolor{codegray}{Case 1 of Lecture 7 computed this row almost entirely at Stage 1; the table records the per-cell residue.}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $--$ & shape gate plus veto D2 -- an interactive serving pattern has no answer to makespan, checkpointing, or CPU-hour cost: a category error \\
|
|
MM & $\circ$ & numeric kernels are monolithic \emph{code} (OpenFOAM-style), but the architecture class around them is the pipeline; the module system contributes nothing to throughput (cap via D2) \\
|
|
HX & $\circ$ & ports around solvers and data sources buy testability of orchestration code; the compute core and the binding cost dimension are untouched \\
|
|
MS & $--$ & distributing a tightly coupled numeric dataflow across service boundaries multiplies communication cost (veto D10) -- the general form of the Prime Video lesson at HPC scale \\
|
|
EDA & $\circ$ & a replayable log is useful glue for job status, but continuous event semantics add machinery where a scheduler and a DAG already express the control flow (cap via D9) \\
|
|
PF & {\boldmath$++$} & immutable inputs $\to$ deterministic stages $\to$ versioned outputs under Slurm/Airflow/Spark is the dominant form, reproducibility by construction \\
|
|
SL & $\circ$ & embarrassingly parallel bursts (Monte-Carlo fan-out) fit FaaS elasticity, but data-heavy inter-stage communication through storage recreates the Prime Video cost trap (split D10 resolves against it) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: pipes-and-filters on HPC/batch infrastructure -- central trade-off: elastic scale-out vs.\ data affinity; in Amdahl's regime, consolidate, do not distribute.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C7 -- BI analytics: a pipeline feeding a serving tier}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $+$ & the serving tier is honestly a thin layered application delegating heavy reads to the warehouse -- Metabase ships as one JAR for exactly this reason \\
|
|
MM & $+$ & the same fit with cleaner seams between semantic model, query, and visualisation concerns as the tool estate grows \\
|
|
HX & $\circ$ & adapter isolation of warehouse dialects helps tool vendors more than in-house BI teams; the dominant contracts are data schemas, not code ports \\
|
|
MS & $-$ & splitting a read-only analytical product into services adds network and platform cost against no High-weight dimension (veto D10: $--$ on High) \\
|
|
EDA & $\circ$ & streaming ingestion earns its broker-operations complexity only when the freshness contract measurably tightens below the batch window \\
|
|
PF & {\boldmath$++$} & the modern data stack \emph{is} an ELT pipeline -- sources $\to$ DAGs $\to$ warehouse $\to$ serving -- with lineage and refresh contracts as audit artefacts (D1 delegated to the output store) \\
|
|
SL & $+$ & scheduled, spiky transformation jobs fit pay-per-run functions (the $++$ side of the split D10), though warehouse-native scheduling often does the same more cheaply \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: pipes-and-filters (ELT) feeding a layered serving tier -- central trade-off: data freshness vs.\ cost and simplicity; the ADR to write is the freshness contract.} \textcolor{codegray}{(Tightening freshness towards real time drags the class into C8 economics.)}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C8 -- real-time streaming: a log with stream processors}
|
|
\footnotesize \textcolor{codegray}{The documented Uber stack: Kafka $+$ Flink $+$ OLAP serving (Fu and Soman 2021).}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $--$ & shape gate plus veto D2 -- a synchronous request/response monolith cannot sustain continuous ingest at the world's production rate with backpressure \\
|
|
MM & $-$ & modularity helps the codebase, but the single quantum caps sustained ingest and fault isolation (veto D2, D5) and cannot provide the durable, partitioned, replayable transport the class is defined by \\
|
|
HX & $\circ$ & ports isolate processing logic from broker APIs (easing Kafka-to-Pulsar-style migrations); the binding constraints are throughput semantics, not dependency direction \\
|
|
MS & $+$ & stream processors deploy naturally as long-running services aligned with the dataflow (D3 kept out of a request/response path) -- provided boundaries follow the flow, exactly where Segment's per-destination cut failed \\
|
|
EDA & {\boldmath$++$} & a durable, partitioned, replayable log with decoupled producers and consumers is the class's defining structure -- Kafka's origin story \\
|
|
PF & $+$ & stream processing is pipes-and-filters over a log -- the batch form's latency veto ($--$ on High-weighted D3) is lifted by its documented streaming incarnation with exactly-once checkpointing \\
|
|
SL & $-$ & per-event invocation at sustained millions of events per second is dominated economically ($--$ side of the split D10) and latency-wise (cold starts, veto D3) by long-running stream processors \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: EDA (log-centric broker topology) with streaming pipes-and-filters as the processing layer -- central trade-off: delivery semantics vs.\ operational complexity and cost.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C9 -- collaboration / messaging: monolithic core, specialised push layer}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $\circ$ & fine for small installations, but millions of long-lived stateful connections are a resource profile the pattern never modelled (cap via D5) \\
|
|
MM & $+$ & no veto beyond D5 (mitigation: replicated instances); the single-binary-by-design fit is the Mattermost case \\
|
|
HX & $\circ$ & helps swap storage and push providers (Discord's MongoDB $\to$ Cassandra $\to$ ScyllaDB path); the crux -- connection fan-out -- is orthogonal to dependency direction \\
|
|
MS & $+$ & Discord's per-attribute specialisation (BEAM gateways, Rust data services) shows targeted services exactly where tail latency demands them (veto D3; mitigation: specialised low-latency services) \\
|
|
EDA & {\boldmath$++$} & gate passed on the push path -- the class's binding fan-out delivery scenario; no veto on the High set; the pattern--domain coincidence Part III records for the push layer \\
|
|
PF & $-$ & shape gate plus veto D3 ($--$ on High) -- interactive bidirectional message flows are the opposite of unidirectional batch transformation (history exports aside) \\
|
|
SL & $--$ & structural knock-out -- long-lived WebSocket connection state is the canonical anti-case for short-lived stateless functions \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: monolithic persistence and business core with a specialised event-driven push layer (Slack: PHP/Hack core plus the Flannel edge cache) -- central trade-off: real-time fan-out at global scale vs.\ deployability and simplicity.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- your class: the row extended to all seven candidates}
|
|
\footnotesize \textcolor{codegray}{Week 3's mini-match ran L, MM, MS against the five High weights; the table extends the row to all seven.}
|
|
\vspace{-0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{0.85}%
|
|
\begin{tabular}{@{}p{0.95cm}cp{10.9cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern} & \textbf{Fit} & \textbf{Rationale} \\
|
|
\midrule
|
|
L & $-$ & technical layers give the non-deterministic component no boundary, no queue, and no measurement point -- the three things it needs most (veto D7; $-$ on High-weighted D9) \\
|
|
MM & {\boldmath$++$} & a domain-cut monolith hosts the deterministic services (data access, computation, audit) cheaply and gives the AI subsystem a hard, CI-verifiable module boundary (D5 $-$ Medium; replication) \\
|
|
HX & {\boldmath$++$} & the LLM is an adapter on a port -- swappable on deprecation, mockable, guarded by contract validation: the anti-corruption layer for a component that would otherwise corrupt the domain \\
|
|
MS & $\circ$ & blast-radius control is welcome, but synchronous chains multiply seconds-scale LLM latency and failure rates; D10's veto targets per-request AI cost, a gateway concern: $--$ relaxes to $\circ$ \\
|
|
EDA & $+$ & queues absorb LLM latency, rate limits, and outages and create batching points for cost control -- the default for non-interactive AI work (veto D9; mitigation: the eval harness) \\
|
|
PF & $+$ & ingestion $\to$ chunking $\to$ embedding $\to$ index, and the eval harness itself, are pipelines with versioned data contracts; $+$ not $++$: the advisory surface is no pipeline (Medium D3) \\
|
|
SL & $\circ$ & event-glue around batch APIs fits (spiky advisory load hits the $++$ side of the split D10); platform timeouts against minutes-long LLM/solver runs and opaque per-call cost stacking do not \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\vspace{-0.05cm}
|
|
\footnotesize \textbf{Primary: hexagonal modular monolith core with pipelines and an orchestrated agent workflow -- the verdict and the determinism boundary on the next frame.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{C10 -- the verdict: a designed hybrid, and the determinism boundary}
|
|
\begin{keypoint}
|
|
\footnotesize \textbf{Primary recommendation:} a hexagonal modular monolith -- deterministic core, AI adapters at ports, an LLM gateway as the single measurement point -- plus pipes-and-filters for ingestion and evals and an orchestrated agent workflow for the AI layer. \textbf{This is a \emph{designed hybrid}, and saying so explicitly is part of the theory.} \textbf{Secondary:} EDA for the AI job and audit spine. \textbf{Central trade-off: agent autonomy and capability vs.\ cost, latency, and testability} -- governed by a token-cost budget and a p95 latency budget per use case as CI-gated fitness functions (\S 37), and by the determinism boundary: \textbf{LLM agents propose; deterministic services decide and book} (Part V).
|
|
\end{keypoint}
|
|
|
|
\vspace{0.25cm}
|
|
\begin{projektbox}
|
|
\footnotesize ADR-007's decision section is this verdict in one paragraph. This week's M4 work builds the part that \emph{decides and books} -- the \texttt{Performance}, \texttt{Risk}, and \texttt{Optimization} services -- and pins it with exact tests \textbf{before any agent output is trusted}.
|
|
\end{projektbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Ten rows, ten trade-offs (1/2): C1--C5}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{tabular}{@{}p{0.8cm}p{4.4cm}p{3.5cm}p{3.8cm}@{}}
|
|
\toprule
|
|
\textbf{Class} & \textbf{Primary (secondary)} & \textbf{Central trade-off} & \textbf{Deciding measurement} \\
|
|
\midrule
|
|
C1 & HX-MM core (EDA edges, PF batch; MS at the Monzo condition) & consistency vs.\ scalability & reconciliation fitness functions at the consistency boundary \\
|
|
C2 & EDA $+$ MS hybrid (MM until scale is measured -- Mastodon) & read scalability, team scaling vs.\ simplicity, cost & deployments per developer per day as teams multiply \\
|
|
C3 & MM $+$ workflow engine behind a port (L for small, stable scope) & day-one simplicity vs.\ multi-decade evolvability & change dispersion per process change \\
|
|
C4 & MM (HX inside for extensions; L only for very small scope) & integrated data model vs.\ independent module scaling and deployment & a resolution, not a metric: module boundaries inside one transactional quantum \\
|
|
C5 & MM, hybrid consistency inside $+$ EDA edges (MS at organisational scale) & seasonal elasticity vs.\ checkout consistency & p95 checkout latency; zero uncompensated oversells at 10$\times$ baseline \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Ten rows, ten trade-offs (2/2): C6--C10}
|
|
\begin{center}
|
|
\scriptsize
|
|
\renewcommand{\arraystretch}{1.0}%
|
|
\begin{tabular}{@{}p{0.8cm}p{4.4cm}p{3.5cm}p{3.8cm}@{}}
|
|
\toprule
|
|
\textbf{Class} & \textbf{Primary (secondary)} & \textbf{Central trade-off} & \textbf{Deciding measurement} \\
|
|
\midrule
|
|
C6 & PF on HPC/batch (SL fan-out for communication-light bursts) & elastic scale-out vs.\ data affinity & cost per simulation; communication share of runtime \\
|
|
C7 & PF (ELT) $+$ layered serving tier (EDA ingestion where freshness demands) & data freshness vs.\ cost and simplicity & refresh-window adherence; p95 dashboard latency \\
|
|
C8 & EDA log $+$ streaming PF (MS processors where ownership demands) & delivery semantics vs.\ operational complexity, cost & consumer lag, watermark delay, duplicate rate under chaos \\
|
|
C9 & monolithic core $+$ EDA push layer (MM alone for self-hosted) & global real-time fan-out vs.\ deployability, simplicity & concurrent connections (push layer premature below $\sim 10^5$) \\
|
|
C10 & HX-MM core $+$ PF $+$ orchestrated agents (EDA job/audit spine) & agent autonomy vs.\ cost, latency, testability & token-cost and p95 latency budgets per use case, CI-gated \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The recurring resolution: consistent core, asynchronous edges}
|
|
\begin{keypoint}
|
|
\footnotesize Every cell of the ten rows is traceable to the same mechanics: $R(a)$ against $C(p)$, a \textbf{veto} where a High weight meets a deep deficit, and a \textbf{documented mitigation} wherever a cap was lifted. The recurring resolution across the rows is \textbf{consistent core, asynchronous edges} -- hybrids arise by \emph{placing} patterns in different subsystems, never by averaging their scores.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.3cm}
|
|
\footnotesize
|
|
\textbf{Loop closed:}
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item eight of ten primary recommendations are compositions (the opening of today's first block)
|
|
\item the unit of evaluation is the subsystem with its own quantum
|
|
\item the composition is recorded in the C4 container diagram
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% CLOSING
|
|
% ============================================
|
|
\section{Closing}
|
|
|
|
\begin{frame}{This week's exercise: the deterministic core (M4)}
|
|
\begin{projektbox}
|
|
\footnotesize Milestone \textbf{M4 -- Deterministic Core and Resilience} (weeks 10--11) begins; the exercise slot is coaching (1 lesson).
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item Implement the \texttt{Performance}, \texttt{Risk}, and \texttt{Optimization} services and test them \textbf{fully against the reference vectors} -- exact tests, not approximate ones
|
|
\item Pin the deterministic services with tests \emph{before} you trust any agent output
|
|
\item Keep the deterministic core \textbf{free of LLM calls} -- this is the line that is graded (ADR-007's determinism boundary: agents propose, deterministic services decide and book)
|
|
\item Commit after the milestone; record architectural decisions as ADRs as you go -- a revised decision is a new, superseding ADR
|
|
\end{enumerate}
|
|
\end{projektbox}
|
|
|
|
\vspace{0.1cm}
|
|
\small Next week completes M4: resilience on all external calls and graceful degradation verified.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Summary}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Hybrids are the normal case}: eight of ten primary recommendations are compositions; the unit of fit evaluation is the subsystem with its own quantum -- recorded as a C4 container diagram
|
|
\item \textbf{Fit is a function of time} (Lehman, A5): MonolithFirst, Strangler Fig in both directions, sacrificial architecture -- MM is start state and consolidation target
|
|
\item \textbf{Maxim 5}: choose for the profile you can verify today; buy options on tomorrow's via modules, ports, a strangler-ready seam -- not via speculative distribution
|
|
\item \textbf{Eight steps}: ASRs $\to$ scenarios with numbers $\to$ utility tree $\to$ matrix shortlist $\to$ ATAM-light $\to$ ADR $\to$ measurement contract $\to$ measure and keep paths open; (vii)--(viii) are the new obligations
|
|
\item \textbf{Maxim 6}: without a response measure a decision is an opinion; with a response measure and a fitness function it is a testable hypothesis
|
|
\item \textbf{ADR-007}: one matrix row narrated -- options carry the matrix reasoning (auditable), the final section carries the contract (falsifiable)
|
|
\item \textbf{The ten rows}: every cell traceable to $R(a)$ against $C(p)$, veto and documented mitigation; the recurring resolution is \emph{consistent core, asynchronous edges}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 11 -- Part IV closes: the measurement contract in depth}}
|
|
\begin{itemize}\small
|
|
\item fitness-function taxonomy in CI/CD
|
|
\item the four DORA metrics and the coupling finding
|
|
\item the four-layer cascade and the C10 reference contract
|
|
\item the cost of change: Boehm vs.\ Menzies
|
|
\item Conway's law and Team Topologies as the third fit dimension
|
|
\item AI Lens on both axes; your project's contract
|
|
\item limits of the theory applied to itself; Maxim 9
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part IV, Sections 35--36 and 33
|
|
\item ahead: Part IV, Sections 37--39
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Exercise / deliverable}}
|
|
\begin{itemize}\small
|
|
\item coaching; resilience on all external calls (timeout, retry, circuit breaker, fallback); graceful degradation
|
|
\item \textbf{milestone: deterministic core fully tested and resilient (M4 complete)}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% END
|
|
% ============================================
|
|
\FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex]
|
|
{\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex]
|
|
Fachhochschule Graub\"unden, Chur\\[2.4ex]
|
|
{\small AISE502 -- AI in Software Engineering II}}}}]
|
|
|
|
\end{document}
|