Abschlussworkshop Eine Webarchitektur entwerfen

Abschlussworkshop Eine Webarchitektur entwerfen

0:00 Wir sind am Ende angekommen — und damit an dem Punkt, an dem aus zwölf Modulen eine Architektur werden soll. Bisher haben Sie in jedem Modul eine Entscheidung für Kartenwerk getroffen, jeweils isoliert. Jetzt kommt der schwierigere Teil: Passen diese Entscheidungen zusammen? Erfahrungsgemäß nicht vollständig, und genau das ist die Übung.

0:20 Eine Architektur ist mehr als die Summe guter Einzelentscheidungen — sie muss in sich widerspruchsfrei sein und sich jemandem erklären lassen.

Abschlussworkshop — Eine Webarchitektur entwerfen

0:28 Der Workshop läuft in drei Blöcken. Zuerst Kontext, Stakeholder und Systemgrenzen. Dann die Struktur: Frontend, Backend, Schnittstellen, Daten. Danach Betrieb, Sicherheit und die Frage nach KI-Komponenten. Am Ende präsentieren Sie Ihre Zielarchitektur mit einem Containerdiagramm und drei dokumentierten Entscheidungen — und wir werten gemeinsam aus.

0:50 Wenn Sie ein eigenes Anwendungsszenario mitgebracht haben, nehmen Sie gern das statt Kartenwerk.

Arbeitsschritte

0:57 Schauen wir uns zunächst an, wie Sie vorgehen. Zwölf Schritte in drei Blöcken — und die Reihenfolge ist nicht beliebig, sondern folgt dem roten Faden des ganzen Seminars. Achten Sie auf den letzten Satz: Die Entscheidungen der vorangegangenen Module werden hier nicht wiederholt, sondern zusammengeführt. Sie fangen also nicht bei null an.

1:17 Holen Sie Ihre Ergebnisse aus den Übungen hervor — die priorisierten Qualitätsziele aus Modul zwei, die Rendering-Entscheidung aus Modul vier, den Integrationsstil aus Modul sechs, die Datenverantwortung aus Modul sieben und die Variantenwahl aus Modul acht. Der Workshop besteht darin, sie zu verbinden und die Widersprüche aufzulösen.

1:36 Der erste Block ist der kürzeste und der wichtigste. Wer nutzt das System wozu, welche Stakeholder gibt es, welche drei Qualitätsziele zählen, wo verlaufen die Systemgrenzen. Und die Fußzeile nennt die härteste Regel dieses Workshops: Wenn Sie mehr als drei Qualitätsziele stehen lassen, entscheiden Sie später nichts, weil alles gleich wichtig ist.

1:56 Diese Beschränkung fühlt sich falsch an — sie ist aber genau das, was Ihre Architektur begründbar macht. Der zweite Block ist die eigentliche Konstruktionsarbeit. Rendering je Oberfläche, Backend-Struktur mit Abhängigkeitsregeln, Schnittstellen und Ereignisse mit Stil und Vertrag, Datenverantwortung, Konsistenzanforderung je Bestand.

2:16 Die Fußzeile ist der Prüfmaßstab, den Sie bei jeder einzelnen Festlegung anlegen sollten: Sie muss auf eines Ihrer drei Qualitätsziele zurückführbar sein. Wenn das nicht gelingt, ist die Festlegung nicht falsch — aber sie ist Geschmack, und Geschmack verteidigt sich schlecht. Der dritte Block bringt zusammen, was oft erst nach der Architektur bedacht wird: Bereitstellungsmodell und Compute, Vertrauensgrenzen und Mandantentrennung, Observability mit Signalen und Service Level Objectives.

2:44 Punkt vier ist der, bei dem ich Sie ausdrücklich ermutigen möchte, auch nein zu sagen. Die Fußzeile sagt es deutlich: Der Verzicht auf eine KI-Komponente ist ein vollwertiges Ergebnis, wenn er begründet ist. Nicht jedes System wird durch einen Assistenten besser. Zum Ergebnis: ein C4-Containerdiagramm, das jede ausführbare Einheit und jeden Datenspeicher zeigt, dazu drei ADRs mit Alternativen und Konsequenzen.

3:09 Und jede Entscheidung muss sich auf eines Ihrer priorisierten Qualitätsziele zurückführen lassen. Der Hinweis nennt noch etwas Praktisches: Das Diagramm trägt den Vortrag. Zwanzig Minuten, und Folien mit Aufzählungen ersetzen das Bild nicht. Wenn Sie Ihre Architektur an einem Diagramm erklären können, haben Sie sie verstanden.

3:30 Der erste Punkt ist der handwerkliche: Das Diagramm mischt Container und Komponenten. Bleiben Sie konsequent auf der Containerebene — alles, was läuft, und alles, was speichert. Der zweite ist der inhaltliche Klassiker: Die Qualitätsziele stehen auf Folie eins und tauchen danach nicht mehr auf. Und der letzte ist eine Falle bei den ADRs: Drei Einträge entstehen, aber alle beschreiben im Grunde dieselbe Entscheidung aus verschiedenen Blickwinkeln.

3:56 Wählen Sie drei wirklich verschiedene Weichen.

Gemeinsame Auswertung

3:59 Nach der Präsentation kommt der Teil, der oft am meisten bringt: die gemeinsame Auswertung. Und dabei geht es ausdrücklich nicht darum, eine Lösung zur richtigen zu erklären. Der erste Satz ist ernst gemeint: Richtigkeit gibt es hier nicht. Was es gibt, sind Begründbarkeit, Risiken und Reversibilität — und danach fragen wir.

4:19 Zwei Dinge interessieren uns besonders: Was macht diesen Entwurf teuer, und was lässt sich daran noch ändern? Damit sind wir wieder bei der Unterscheidung aus Modul eins zwischen reversiblen und schwer reversiblen Entscheidungen. Sie hat uns durch das ganze Seminar getragen und schließt es jetzt ab. Diese sechs Fragen nehmen Sie bitte mit — sie funktionieren bei jedem Architekturreview, nicht nur heute. Die rechte Spalte sagt, worauf jede zielt.

4:45 Und die Fußzeile benennt die beiden unbequemen: Welche Entscheidungen sind reversibel, und was sollte zunächst einfacher sein? Diese beiden treffen meistens dieselbe Entscheidung — nämlich die vorweggenommene Verteilung, die man später nur schwer zurücknimmt. Wenn eine Frage in der Auswertung weh tut, ist es fast immer eine dieser beiden.

5:06 Diese vier Merkmale sehe ich bei den überzeugendsten Ergebnissen immer wieder. Sie lassen Dinge bewusst weg und sagen, warum — das ist Souveränität, nicht Lücke. Sie benennen ihre größte Unsicherheit von selbst, statt zu hoffen, dass niemand fragt. Sie trennen, was jetzt gebaut wird, von dem, was später möglich bleibt. Und für jede Verteilungsentscheidung gibt es einen Betriebsverantwortlichen — denn jeder zusätzliche Dienst bedeutet, dass jemand nachts erreichbar ist.

5:34 Zum Schluss der praktische Ausblick. Ihre drei ADRs sind der Anfang eines Decision Log, nicht sein Ende. Die Fitness Functions aus Modul zwölf setzen die Regeln Ihres Entwurfs durch, sonst weichen sie über die Jahre auf. Das Containerdiagramm gehört neben den Code und wird mit ihm gepflegt. Und der letzte Punkt ist der, der am ehesten liegen bleibt: Die Annahmen aus der Auswertung werden zu Aufgaben mit Termin.

5:58 Eine ungeprüfte Annahme ist ein Risiko, das Sie noch nicht kennen.

Danke!

6:03 Damit sind wir am Ende. Wenn Sie aus diesen zwei Tagen eine Sache mitnehmen, dann bitte diese: Architektur ist kein Zustand, den man erreicht, sondern eine Tätigkeit, die man ausübt — und ihr Kern besteht darin, wenige Entscheidungen bewusst zu treffen und sie so festzuhalten, dass andere sie nachvollziehen können. Alle Materialien liegen in der Freigabe. Fragen zu Ihrer eigenen Architektur bespreche ich gern im Anschluss. Vielen Dank für Ihre Aufmerksamkeit und die guten Diskussionen.