% !TEX encoding = UTF-8 Unicode
% ============================================================================
% AISE502 -- AI in Software Engineering II
% Lecture 1 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 1: Architecture as a Decision Problem\\[0.4ex]{\small Script: Part I, Sections 1--2}}
\author{Dr.\ Florian Herzog}
\shortname{AISE502}
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}

\begin{document}

% ============================================
% TITLE SLIDE
% ============================================
\FHGRTitlePage

% ============================================
% AGENDA
% ============================================
\begin{frame}{Agenda}
\begin{enumerate}
    \item The module: aims, assessment, semester plan, project
    \item Four production systems -- two facts
    \item The decision problem
    \item What software architecture is (and is not)
    \item The framework at a glance
    \item The two AI axes of this module
    \item Six load-bearing assumptions (A1--A6)
    \item From questions to dimensions
\end{enumerate}
\end{frame}

% ============================================
% SECTION 1: THE MODULE
% ============================================
\section{The Module}

\begin{frame}{The module in one question}
\begin{keypoint}
\emph{How do I design, justify, and operate the structure of a software system so that it meets its quality attributes and remains maintainable for years -- even when individual components (AI) are non-deterministic, fallible, and expensive?}
\end{keypoint}

\vspace{0.4cm}
This module makes that question \textbf{decidable} -- with a framework of five elements:
\begin{itemize}
    \item a \textbf{demand side} (what the application requires),
    \item a \textbf{supply side} (what a structure can deliver),
    \item a \textbf{matching rule}, a \textbf{decision record}, and a \textbf{measurement contract}.
\end{itemize}

\vspace{0.2cm}
\textcolor{codegray}{\small Lectures in German -- all materials, the script, and the exam in English.}
\end{frame}

\begin{frame}{Learning objectives}
After this module you can \dots
\begin{itemize}
    \item explain why architecture selection is a \textbf{matching problem} -- no pattern is good or bad in itself
    \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 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}

\begin{frame}{Assessment}
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\begin{block}{Project (50\,\%)}
\begin{itemize}
    \item Portfolio Intelligence Platform (group work, all semester)
    \item Requirements dossier (A1, week 3)
    \item Architecture dossier: ADR $+$ measurement contract (A2, week 7)
    \item Implementation (weeks 8--13)
    \item Final presentation with \textbf{architecture defence} (week 14)
\end{itemize}
\end{block}
\end{column}
\begin{column}{0.48\textwidth}
\begin{block}{Written examination (50\,\%)}
\begin{itemize}
    \item End of semester, 60 minutes
    \item \textbf{Open book:} script and own notes, on paper
    \item \textbf{Closed internet}
    \item Focus: architecture reasoning -- profiles, matching, trade-offs
\end{itemize}
\end{block}
\end{column}
\end{columns}
\end{frame}

\begin{frame}{The semester at a glance}
\small
\begin{center}
\begin{tabular}{@{}p{1.5cm}p{4.3cm}p{4.2cm}p{2.7cm}@{}}
\toprule
\textbf{Weeks} & \textbf{Lectures} & \textbf{Exercise / project} & \textbf{Deliverables} \\
\midrule
1--3 & Part I: the framework -- dimensions, scenarios, weights & Kickoff; requirements workshops & \textbf{A1} (week 3) \\
4--7 & Part II: seven patterns; the match & Architecture study; the match; design & \textbf{A2 $+$ design gate} (week 7) \\
8--13 & Parts III--V: classes, fit at scale, the AI dimension & Implementation sprints $+$ coaching & Milestones (weeks 9/11/13) \\
14 & Synthesis, exam preparation & \textbf{Presentations $+$ defence} & \textbf{A3} \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.2cm}
\textbf{Design phase} (weeks 1--7): 2 lessons lecture $+$ 2 exercise -- design first, code later.\\
\textbf{Implementation phase} (weeks 8--13): 3 lessons lecture $+$ 1 coaching.
\end{frame}

\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.
\end{projektbox}

\vspace{0.2cm}
\textbf{This week (kickoff exercise):}
\begin{itemize}
    \item form teams; set up repository and tooling (including agentic coding tools)
    \item build domain understanding; sketch a first ontology
    \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{Four Production Systems -- Two Facts}

\begin{frame}{Discussion}
\begin{thinkbox}
\begin{itemize}
    \item Which software architectures can you name -- and which is the \emph{best} one?
    \item Is a monolith outdated? Are microservices the professional default?
    \item Netflix and Amazon run microservices. Should your two-person startup?
    \item How would you even \emph{decide} -- and how would you defend the decision a year later?
\end{itemize}
\end{thinkbox}
\end{frame}

\begin{frame}{Four production systems, four structures}
\footnotesize
\begin{center}
\begin{tabular}{@{}p{2.2cm}p{4.5cm}p{6.4cm}@{}}
\toprule
\textbf{System} & \textbf{Structure} & \textbf{Documented outcome} \\
\midrule
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\,\%$ \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.2cm}
\textcolor{codegray}{\scriptsize Sources: Craver 2016; Sewell 2024; Noonan 2018; Kolny 2023 -- each described by the system's own engineers.}
\end{frame}

\begin{frame}{Reading the four cases}
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\textcolor{bankgreen}{\textbf{Same problem, opposite structures}}
\begin{itemize}
    \item Monzo and Stack Overflow both serve millions of users, interactively, at high availability
    \item one does it with $\sim 2{,}800$ deployment units -- the other with essentially \textbf{one}
\end{itemize}
\end{column}
\begin{column}{0.48\textwidth}
\textcolor{bankred}{\textbf{Fashionable structure, expensive failure}}
\begin{itemize}
    \item Prime Video: distributed boundaries in the middle of a tightly coupled data flow
    \item Segment: services cut along \emph{configuration instances}, not domain seams
\end{itemize}
\end{column}
\end{columns}

\vspace{0.4cm}
\begin{hinweisbox}
Neither fact proves monoliths good or microservices bad. Each failure was a \textbf{mismatch} between a workload and a structure -- not a bad pattern.
\end{hinweisbox}
\end{frame}

\begin{frame}{Two facts -- and the maxim they force}
\textbf{Fact 1: Structures differ radically for similar-looking problems.}\\
\textcolor{codegray}{\small The grade portal and Instagram share the same load question -- at different magnitudes.}

\vspace{0.3cm}
\textbf{Fact 2: No structure dominates.}\\
\textcolor{codegray}{\small For every pattern there is a documented context where it failed expensively -- and one where its unfashionable opposite succeeded at scale (Instagram, Shopify).}

\vspace{0.4cm}
\begin{keypoint}
\textbf{Maxim 1.} Patterns are neither good nor bad; only the \textbf{fit} between a requirements profile and a capability profile is.
\end{keypoint}

\vspace{0.3cm}
The decision problem: choose among \textbf{non-dominated} alternatives whose value depends on the \textbf{match} -- knowing the choice is \textbf{expensive to reverse}.
\end{frame}

% ============================================
% SECTION 3: WHAT ARCHITECTURE IS
% ============================================
\section{What Software Architecture Is}

\begin{frame}{What is ``software architecture''?}
The term has a documented tendency to mean \emph{everything and therefore nothing} (Fowler 2003).

\vspace{0.3cm}
\begin{definitionbox}[Software architecture (ISO/IEC/IEEE 42010:2022)]
``Fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes.''
\end{definitionbox}

\vspace{0.3cm}
The standard also creates one \textbf{obligation} this module builds on directly:\\
a conformant architecture description \textbf{must record architecture decisions \emph{and their rationale}} (Clause 6.10).
\end{frame}

\begin{frame}{Four definition families -- each contributes one element}
\footnotesize
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{1. Normative (ISO 42010)}}
\begin{itemize}\setlength\itemsep{1pt}
    \item shared vocabulary: stakeholders, concerns, views
    \item obligation: record decisions $+$ rationale
\end{itemize}

\vspace{0.1cm}
\textcolor{bankblue}{\textbf{2. Decision-centric (Booch)}}
\begin{itemize}\setlength\itemsep{1pt}
    \item the \emph{significant} decisions -- significance $=$ \textbf{cost of change}
    \item lost decision knowledge (\emph{knowledge vaporization}) $\to$ erosion
\end{itemize}
\end{column}
\begin{column}{0.48\textwidth}
\textcolor{bankblue}{\textbf{3. Social (Fowler/Johnson)}}
\begin{itemize}\setlength\itemsep{1pt}
    \item the experts' \emph{shared understanding}; ``the important stuff''
    \item perceived \textbf{irreversibility} is the core -- architects work to \emph{remove} it
\end{itemize}

\vspace{0.1cm}
\textcolor{bankblue}{\textbf{4. Structural-analytic (SEI)}}
\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}
\end{itemize}
\end{column}
\end{columns}

\vspace{0.05cm}
\begin{keypoint}
Distilled: \emph{architecture is the set of hard-to-reverse structural decisions that determine the quality behaviour of a system.}
\end{keypoint}
\end{frame}

\begin{frame}{Architecture -- design -- implementation: a cost-of-change boundary}
\begin{center}
\footnotesize
\begin{tabular}{@{}llll@{}}
\toprule
\textbf{Level} & \textbf{Example decision} & \textbf{Reversal cost} & \\
\midrule
\textcolor{bankred}{Architecture} & monolith vs.\ microservices & months (a migration) & hard to reverse \\
\textcolor{bankblue}{Design} & choice of logging library & days (behind an interface) & revisable \\
\textcolor{bankgreen}{Implementation} & a variable name & seconds & trivial \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.3cm}
\begin{itemize}
    \item The boundary is \textbf{gradual and context-dependent}: a database choice is architectural without a persistence abstraction -- closer to design in a hexagonal system
    \item That is the point: \textbf{good architecture pushes decisions from irreversible towards reversible}
\end{itemize}
\end{frame}

\begin{frame}{Two refusals -- enforced throughout the module}
\begin{columns}[T]
\begin{column}{0.48\textwidth}
\textcolor{bankred}{\textbf{No fashion}}
\begin{itemize}
    \item the dominance claim behind every hype cycle is falsified by the four production cases
    \item no pattern is chosen because it is modern
\end{itemize}
\end{column}
\begin{column}{0.48\textwidth}
\textcolor{bankred}{\textbf{No taste}}
\begin{itemize}
    \item a claim that cannot be measured or falsified has no place in an architectural decision
    \item ``elegant'' is not an argument -- a response measure is
\end{itemize}
\end{column}
\end{columns}

\vspace{0.4cm}
\begin{hinweisbox}
Every judgement in this module must trace to a \textbf{measurable} property of a \textbf{documented} context.
\end{hinweisbox}
\end{frame}

% ============================================
% SECTION 4: THE FRAMEWORK
% ============================================
\section{The Framework at a Glance}

\begin{frame}{The framework: five elements}
\begin{definitionbox}[Architecture--application fit]
\footnotesize
\begin{enumerate}
    \item \textbf{Requirements profile} $R(a) = \bigl(w_1, \dots, w_{12};\; S(a);\; K(a)\bigr)$ -- priority weights (High/Medium/Low), workload shape, hard constraints: the \emph{demand side}
    \item \textbf{Capability profile} $C(p) = \bigl(c_1, \dots, c_{12};\; S(p)\bigr)$ -- ordinal ratings $\{++, +, \circ, -, --\}$ plus native workload shape: the \emph{supply side}
    \item \textbf{Fit} $\mathrm{fit}(a,p)$ -- an ordinal, \emph{non-compensatory} match, computed by rules, not arithmetic
    \item \textbf{Architecture Decision Record (ADR)} -- the permanent, auditable record of decision $+$ rationale
    \item \textbf{Measurement contract} -- fitness functions and thresholds under which the decision is continuously tested
\end{enumerate}
\end{definitionbox}

\vspace{0.1cm}
\small Both profiles range over the \textbf{same twelve dimensions} -- introduced today, completed next week.
\end{frame}

\begin{frame}{The framework as a pipeline -- and the map of the script}
\begin{center}
\resizebox{0.94\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},
    core/.style={sysbox, fill=bankblue!20, draw=bankblue},
    comp/.style={sysbox, fill=bankgreen!15, draw=bankgreen},
    meas/.style={sysbox, fill=violet!15, draw=aiviolet},
    arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
    farr/.style={-{Stealth[length=2.5mm]}, thick, dashed, bankred}
]
    \node[core] (klass) {Application class\\ \scriptsize (Part III)};
    \node[core, right=0.9cm of klass] (profil) {Requirements profile $R(a)$\\ \scriptsize scenarios, utility tree};
    \node[core, right=0.9cm of profil] (match) {Matching $\mathrm{fit}(a,p)$\\ \scriptsize against $C(p)$ (Parts II, IV)};
    \node[comp, below=1.4cm of match] (adr) {Architecture decision\\ \scriptsize ADR with rationale};
    \node[meas, left=0.9cm of adr] (fitness) {Measurement contract\\ \scriptsize fitness functions in CI/CD};
    \node[meas, left=0.9cm of fitness] (ops) {Operation\\ \scriptsize DORA, SLOs, Lehman trends};
    \draw[arr] (klass) -- (profil);
    \draw[arr] (profil) -- (match);
    \draw[arr] (match) -- (adr);
    \draw[arr] (adr) -- (fitness);
    \draw[arr] (fitness) -- (ops);
    \draw[farr] (ops.north) -- node[midway, right=2pt, font=\scriptsize\sffamily, text=bankred, align=left] {profile drift (A5):\\ re-measure, evolve, supersede} (klass.south);
\end{tikzpicture}%
}
\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.
\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.
\end{itemize}
\end{ailinse}

\vspace{0.3cm}
\begin{itemize}
    \item Both axes are treated systematically in Part V of the script
    \item Until then, \textcolor{aiviolet}{\textbf{AI Lens}} boxes flag where each axis touches the classical material
    \item Your project lives on \textbf{both} axes: you build an AI-native system, using AI tools
\end{itemize}
\end{frame}

% ============================================
% SECTION 5: SIX ASSUMPTIONS
% ============================================
\section{Six Load-Bearing Assumptions}

\begin{frame}{Six load-bearing assumptions}
The framework rests on six assumptions -- each anchored in established literature, each justifying \textbf{one element} of the framework.

\vspace{0.3cm}
\begin{center}
\small
\begin{tabular}{@{}llp{5.4cm}@{}}
\toprule
& \textbf{Assumption (short)} & \textbf{Justifies} \\
\midrule
A1 & architecture $=$ hard-to-reverse decisions & the ADR (element 4) \\
A2 & everything is a trade-off & the matching problem (element 3) \\
A3 & quality attributes drive architecture & the twelve dimensions \\
A4 & requirements $=$ measurable scenarios & the demand-side method (element 1) \\
A5 & a decision is a tested hypothesis & the measurement contract (element 5) \\
A6 & AI extends the space, not the method & D12 $+$ eval harness -- nothing else \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.2cm}
\textcolor{codegray}{\small The next three slides give each assumption its evidence.}
\end{frame}

\begin{frame}{A1 -- Decisions. \quad A2 -- Trade-offs.}
\small
\textbf{A1 -- Architecture is the set of significant, hard-to-reverse design decisions.}
\begin{itemize}\setlength\itemsep{1pt}
    \item significance measured by \textbf{cost of change}; ``decisions you wish you could get right early''
    \item lost decision knowledge is a documented cause of erosion $\to$ every decision becomes an \textbf{ADR}
\end{itemize}

\vspace{0.25cm}
\textbf{A2 -- Everything in software architecture is a trade-off} \textcolor{codegray}{(First Law, Richards \& Ford)}
\begin{itemize}\setlength\itemsep{1pt}
    \item \dots and if you think you have found something that is not, \emph{you have not yet identified the trade-off}
    \item the star ratings show it: microservices lead overall yet one star on cost and simplicity; layered is the exact mirror -- \textbf{dominance does not occur} $\to$ a matching problem exists
    \item corollary: a proposal claiming \emph{only benefits} is incomplete \emph{by assumption}
\end{itemize}
\end{frame}

\begin{frame}{A3 -- Quality attributes. \quad A4 -- Scenarios.}
\small
\textbf{A3 -- Quality attributes, not functionality, drive architecture.}
\begin{itemize}\setlength\itemsep{1pt}
    \item functionality is largely \textbf{structure-neutral}; structure determines \emph{how well}: performance, availability, modifiability, security
    \item non-functional properties can rarely be refactored in afterwards
    \item $\to$ the coordinate system consists of quality attributes -- never feature lists
\end{itemize}

\vspace{0.25cm}
\textbf{A4 -- Requirements are architecturally usable only as measurable scenarios.}
\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)
\end{itemize}
\end{frame}

\begin{frame}{A5 -- A tested hypothesis. \quad A6 -- AI absorbed.}
\small
\textbf{A5 -- An architecture decision is a hypothesis, continuously tested over the life cycle.}
\begin{itemize}\setlength\itemsep{1pt}
    \item Lehman: change continually or decay; maintenance $\approx 40$--$80\,\%$ of life-cycle cost $\to$ design-time fit \textbf{decays}
    \item re-measure: fitness functions in CI/CD, the four DORA metrics; change \emph{within} an architecture is cheap -- change \emph{of} it stays steep (Segment, Prime Video)
\end{itemize}

\vspace{0.3cm}
\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}
\end{itemize}
\end{frame}

\begin{frame}{Maxim 2}
\begin{keypoint}
\textbf{Maxim 2.} Because everything is a trade-off (A2) and quality drives structure (A3), architecture selection is \textbf{matching}; because decisions are costly to reverse (A1) and decay over time (A5), the match must be \textbf{documented} and \textbf{continuously measured}.
\end{keypoint}

\vspace{0.4cm}
\begin{center}
\large
demand $\;\to\;$ supply $\;\to\;$ match $\;\to\;$ record $\;\to\;$ test
\end{center}

\vspace{0.3cm}
\centering\small\textcolor{codegray}{This chain is the red line of the whole script -- every part instantiates one link at scale.}
\end{frame}

% ============================================
% SECTION 6: FROM QUESTIONS TO DIMENSIONS
% ============================================
\section{From Questions to Dimensions}

\begin{frame}{Imagine you are on the on-call rota \dots}
Forget frameworks for a moment. You are responsible -- personally -- for a system real people use. These questions \emph{will} find you:

\vspace{0.2cm}
\small
\begin{itemize}\setlength\itemsep{3pt}
    \item \emph{The grade-release portal: what happens at 08:00 on publication day, when the whole semester refreshes the same page at once?}
    \item \emph{An e-banking transfer: can the same payment ever be booked twice -- or disappear halfway?}
    \item \emph{One component crashes at noon: does the whole application go dark, or does one widget show a spinner while everything else keeps working?}
    \item \emph{The regulator calls: ``prove to us, step by step, what happened to this one transaction.'' How long does that take you?}
    \item \emph{A new feature request arrives: how many places in the code must change -- one module, or seventeen?}
\end{itemize}
\end{frame}

\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{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?}
\end{itemize}

\vspace{0.2cm}
\begin{hinweisbox}
Every one of these questions has ended budgets, products, or careers.
\end{hinweisbox}
\end{frame}

\begin{frame}{Three observations turn the list into a method}
\begin{enumerate}\setlength\itemsep{3pt}
    \item \textbf{The questions recur} -- across wildly different systems: the grade portal and Instagram share the first question, merely at different magnitudes.
    \item \textbf{None of them asks \emph{what} the system does} -- functionality is structure-neutral (A3); every question is about \emph{how well}, \emph{at what cost}, \emph{under which failure}.
    \item \textbf{Each can be answered with a number} -- requests per second, double bookings per million, per cent of functionality lost, hours to an audit trail, modules touched per feature, cost per request \dots
\end{enumerate}

\vspace{0.2cm}
\begin{keypoint}
The twelve profile dimensions D1--D12 are exactly this: the recurring questions -- \textbf{grouped, named, and equipped with defined measures}. Nothing more mysterious than that.
\end{keypoint}
\end{frame}

\begin{frame}{The twelve dimensions: five groups (preview)}
\small
\begin{center}
\begin{tabular}{@{}llp{6.6cm}@{}}
\toprule
\textbf{Group} & \textbf{Dimensions} & \textbf{The underlying question} \\
\midrule
Load and speed & D1, D2, D3 & does the structure survive its own success? \\
Correctness and trust & D4, D5, D6 & can it be trusted -- with money, uptime, history? \\
Change and delivery & D7, D8, D9 & what does the \emph{next} change cost? \\
Economics and organisation & D10, D11 & what does it cost to run -- and can teams work in parallel? \\
The new dimension & D12 & how cheaply can it host a slow, fallible, per-call-priced AI component? \\
\bottomrule
\end{tabular}
\end{center}

\vspace{0.15cm}
\begin{itemize}
    \item Next week: all twelve, one by one -- each with its question, its vocabulary, and its \textbf{measurement instrument}
    \item Both profiles -- demand $R(a)$ and supply $C(p)$ -- will be vectors over \emph{these} twelve dimensions
\end{itemize}
\end{frame}

\begin{frame}{Discussion}
\begin{thinkbox}
Pick an app you use daily.
\begin{itemize}
    \item Which \textbf{three dimensions} dominate it?
    \item On which dimension would its operator accept a \emph{bad} rating without losing sleep?
    \item Compare with your neighbour -- where you disagree, you have found a \textbf{weight} discussion. Next week's utility tree resolves exactly that.
\end{itemize}
\end{thinkbox}
\end{frame}

% ============================================
% SUMMARY
% ============================================
\section{Summary}

\begin{frame}{Summary}
\small
\begin{enumerate}\setlength\itemsep{2pt}
    \item Four production systems: structures differ radically, none dominates -- failures were \textbf{mismatches}
    \item \textbf{Maxim 1:} patterns are neither good nor bad; only the \emph{fit} is
    \item Architecture $=$ the \textbf{hard-to-reverse structural decisions} that determine quality behaviour
    \item The framework: $R(a)$ (demand) $\to$ $C(p)$ (supply) $\to$ $\mathrm{fit}(a,p)$ $\to$ \textbf{ADR} $\to$ \textbf{measurement contract}
    \item AI enters twice: \textbf{Axis A} (tool in the process), \textbf{Axis B} (component in the system)
    \item Six assumptions A1--A6 carry the framework; the twelve dimensions are \textbf{recurring engineering questions} -- grouped, named, measurable
    \item \textbf{Maxim 2:} match, then document, then measure
\end{enumerate}
\end{frame}

\begin{frame}{Next week}
\begin{columns}[T]
\begin{column}{0.55\textwidth}
\textcolor{bankblue}{\textbf{Lecture 2 -- the twelve dimensions, completed}}
\begin{itemize}
    \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 the utility tree: from scenarios to \textbf{weights}
\end{itemize}
\end{column}
\begin{column}{0.42\textwidth}
\textcolor{bankblue}{\textbf{Reading}}
\begin{itemize}
    \item this week: script Part I, Sections 1--2
    \item ahead: Part I, Section 3
\end{itemize}

\vspace{0.3cm}
\textcolor{bankblue}{\textbf{Exercise}}
\begin{itemize}
    \item kickoff: teams, repo, domain, ontology sketch, raw stakeholder wishes
\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}