Anforderungen und Architekturtreiber

Anforderungen und Architekturtreiber

0:00 Im ersten Modul haben wir festgehalten, dass Architektur aus begründeten Entscheidungen besteht. Jetzt geht es um die Grundlage dieser Begründungen. Denn eine Entscheidung braucht Kriterien, und die kommen nicht aus der Technik, sondern aus den Anforderungen. Die Kunst dabei ist das Aussortieren: Von hundert Anforderungen verändern vielleicht fünf den Bauplan. Die anderen fünfundneunzig werden in einer bestehenden Struktur umgesetzt.

0:25 Wer diese fünf nicht findet, entwirft ins Blaue — und wer alle hundert für strukturwirksam hält, entwirft für jeden Fall und damit für keinen.

Anforderungen und Architekturtreiber

0:33 Wir gehen den Weg in drei Schritten. Zuerst schauen wir, was eine Anforderung überhaupt strukturwirksam macht und woher solche Treiber kommen. Dann nehmen wir uns die Qualitätsattribute vor — und zwar mit einem Schwerpunkt darauf, wie man sie so formuliert, dass sie überhaupt etwas entscheiden können. Am Ende steht eine Übung, in der Sie das für unser Referenzsystem Kartenwerk durchspielen. Deren Ergebnis begleitet uns durch den Rest des Seminars.

Von der fachlichen Anforderung zur technischen Struktur

0:59 Beginnen wir mit der Sortierarbeit. Was unterscheidet eine Anforderung, die Ihren Bauplan verändert, von einer, die nur Arbeit macht? Die Antwort ist einfacher als gedacht — und wird trotzdem selten gestellt. Es lohnt sich, das an einem Bild festzumachen. Stellen Sie sich ein Haus vor. Ob im Wohnzimmer Parkett oder Fliesen liegen, ist eine Entscheidung — aber keine, die den Grundriss betrifft.

1:23 Ob im Erdgeschoss eine Werkstatt mit schwerer Maschine steht, dagegen schon: Das entscheidet über Fundament und Deckenlast. Genauso hier. Die allermeisten funktionalen Anforderungen sind Fliesen. Der Bauplan ändert sich bei Qualitätsanforderungen, bei harten Einschränkungen und bei Geschäftszielen, die Folgen für Schnitt, Verteilung oder Betrieb haben.

1:44 Genau diese heißen Architekturtreiber. Achten Sie auf die erste Zeile. Ein Ticket stornieren zu können, ist fachlich wichtig, für den Kunden vielleicht das Wichtigste überhaupt — und trotzdem ohne Strukturwirkung. Das ist der Punkt, an dem Diskussionen kippen, weil „nicht strukturwirksam" wie „unwichtig" klingt. Es heißt nur: Das bauen wir in dem, was wir ohnehin haben.

2:07 Der Test dafür ist eine einzige Frage, und ich empfehle, sie wörtlich zu stellen: Was am Bauplan würde anders aussehen, wenn diese Anforderung wegfiele? Kommt darauf keine Antwort, ist es keine treibende Anforderung. Die interessante Beobachtung an dieser Liste: Nur die erste Quelle steht üblicherweise in einem Anforderungsdokument.

2:27 Die anderen drei findet man im Gespräch — und oft gegen Widerstand. Dass zwei Teams an verschiedenen Standorten sitzen, dass es im Haus keine Kubernetes-Erfahrung gibt, dass ein Bestandssystem aus politischen Gründen nicht angefasst werden darf: Solche Dinge gelten als Rahmenbedingungen, nicht als Anforderungen. Für Ihre Architektur sind sie aber genau das. Sie schließen Optionen aus, und zwar zuverlässiger als jedes Qualitätsziel.

2:53 Diese Unterscheidung schützt Sie vor einer sehr häufigen Selbsttäuschung. Links steht Komplexität, die aus der Sache kommt — Preisregeln, Kontingente, Stornofristen. Die können Sie nicht wegentwerfen, nur beherrschbar schneiden. Rechts steht Komplexität, die Sie selbst hineingebracht haben: Verteilung, Caches, ereignisgetriebene Kopplung.

3:13 Und der entscheidende Satz steht in der Fußzeile: Technische Komplexität ist immer eine Entscheidung. Damit ist sie begründungspflichtig. Wenn jemand sagt, das System sei eben komplex, lohnt sich die Rückfrage, welche Hälfte gemeint ist. Der erste Punkt ist der verbreitetste und der folgenreichste. „Das System soll performant und sicher sein" steht in jedem zweiten Lastenheft — und entscheidet nichts, weil niemand dagegen verstoßen kann.

3:40 Eine Anforderung, die man nicht verletzen kann, ist keine. Der dritte Punkt ist der teuerste: Wenn Zielkonflikte nicht bewusst entschieden werden, entscheidet sie später der Betrieb, unter Zeitdruck und mit den Mitteln, die dann gerade da sind. Das ist selten die Lösung, die man mit Ruhe gewählt hätte.

Qualitätsattribute moderner Webanwendungen

3:57 Damit zu den Qualitätsattributen selbst. Sie kennen die Liste vermutlich — Performance, Skalierbarkeit, Sicherheit, Wartbarkeit. Interessant ist nicht die Liste, sondern die Frage, wie man daraus etwas macht, an dem sich eine Entscheidung tatsächlich messen lässt. Vergleichen Sie die beiden Formulierungen auf dieser Folie. „Kartenwerk soll schnell sein" klingt nach einer Anforderung, ist aber nur eine Stimmung.

4:22 Der zweite Satz nennt einen Auslöser, eine Umgebung und eine messbare Antwort — und plötzlich haben Sie etwas, das eine Entscheidung entscheiden kann. Sie können damit eine Architekturvariante durchrechnen, Sie können eine Messung dagegen laufen lassen, und Sie können am Ende feststellen, dass Sie das Ziel verfehlt haben.

4:39 Genau das ist der Unterschied zwischen einem Wunsch und einer Anforderung: Man kann daran scheitern. Diese fünf Säulen stammen aus dem Well-Architected Framework, und ich empfehle sie ausdrücklich als Prüfraster — aber nicht als Rangfolge. Der Nutzen liegt in der Vollständigkeit: Wenn Sie eine Entwurfsentscheidung durch alle fünf Brillen anschauen, fällt Ihnen zuverlässig die Seite auf, an die Sie nicht gedacht haben.

5:03 Meistens ist das die Kostenseite oder die operative Seite. Beachten Sie auch, dass zu jeder Säule ausdrücklich Abwägungen gehören — das Framework behauptet selbst nicht, dass sich alle fünf gleichzeitig maximieren lassen. Lesen Sie diese Tabelle bitte von rechts nach links. Die rechte Spalte ist das Eigentliche: Sie zeigt, dass jedes Qualitätsziel einen konkreten Hebel im Entwurf hat.

5:26 Skalierbarkeit heißt Zustandslosigkeit und Partitionierung — das ist keine Betriebseinstellung, das entscheiden Sie im Code. Beobachtbarkeit heißt Instrumentierung und Korrelation, und die kann man nicht nachrüsten, ohne überall anzufassen. Am interessantesten ist die Zeile zur Barrierefreiheit: Sie hängt unter anderem an der Rendering-Entscheidung, also an einem Thema, das die meisten Teams rein technisch diskutieren.

5:50 Darum geht es in Modul vier. Das ist der Punkt, an dem Architektur unbequem wird. Jede dieser vier Zeilen beschreibt einen Zielkonflikt, den Sie nicht auflösen, sondern nur entscheiden können. Mehr Redundanz kostet Geld. Strenge Konsistenz kostet Verfügbarkeit, sobald das Netz zwischen zwei Teilen wegbricht — darauf kommen wir bei den Datenarchitekturen ausführlich zurück.

6:13 Und die letzte Zeile ist die, die am häufigsten ignoriert wird: Lieferfähigkeit lebt von Einfachheit. Jede zusätzliche Fähigkeit, die Sie ins System holen, bezahlen Sie mit Tempo — nicht einmalig, sondern dauerhaft. Der erste Stolperstein ist der Klassiker aus jedem Workshop: Am Ende sind alle Attribute hoch priorisiert.

6:32 Das fühlt sich nach Sorgfalt an und ist das Gegenteil davon — eine Priorisierung, die nichts zurückstellt, ist keine. Deshalb ist die Übung gleich so aufgebaut, dass Sie sich auf drei festlegen müssen. Der letzte Punkt verdient auch Aufmerksamkeit: Kosten und Nachhaltigkeit werden als Betriebsthemen behandelt, obwohl sie fast vollständig aus Entwurfsentscheidungen folgen.

6:54 Was Ihr System dauerhaft verbraucht, haben Sie am Reißbrett festgelegt.

Praxisübung

6:58 Jetzt sind Sie dran. Wir nehmen Kartenwerk und arbeiten heraus, was dieses System wirklich treibt — und wo sich die Ziele gegenseitig im Weg stehen. Nehmen Sie diese Übung ernster, als ihr Umfang vermuten lässt. Was hier entsteht, ist die Grundlage für jede Entscheidung an beiden Seminartagen. Wenn Sie in Modul acht zwischen modularem Monolithen und Diensten abwägen, greifen Sie auf diese Prioritäten zurück. Wenn Sie in Modul sieben über Konsistenz entscheiden, ebenso.

7:27 Eine Architektur ohne priorisierte Qualitätsziele ist beliebig — man kann sie weder begründen noch widerlegen. Die Obergrenze von sechs Treibern ist die eigentliche Schwierigkeit, und sie ist Absicht. Sie werden zwanzig Punkte finden, die alle berechtigt sind, und müssen begründen, welche davon den Bauplan verändern. Nutzen Sie die Prüffrage aus dem ersten Kapitel konsequent.

7:51 Und formulieren Sie jedes Szenario mit Auslöser, Umgebung und Antwort — auch dann, wenn Sie die Zahl schätzen müssen. Eine geschätzte Zahl kann man später korrigieren; ein Adjektiv nicht. Die Zielkonflikte am Ende sind kein Anhängsel, sondern das eigentliche Ergebnis. Zwei dieser Punkte möchte ich hervorheben. Eine Zahl ohne Lastannahme ist wertlos — eine Sekunde Antwortzeit bei zehn Nutzern und bei zwanzigtausend sind zwei völlig verschiedene Anforderungen.

8:18 Und der dritte Punkt beschreibt, was mit den meisten Priorisierungen geschieht: Sie werden erstellt, präsentiert und danach nie wieder herangezogen. Die Gegenprobe dafür ist einfach. Wenn Ihre nächste Architekturentscheidung sich nicht auf eines dieser Ziele beruft, war die Priorisierung Dekoration.