Eine technische Architekturpräsentation sollte drei Fragen nacheinander beantworten: Wo ist das System eingebettet? Wie läuft eine wichtige Anfrage durch das System? Warum ist der vorgeschlagene Ansatz den Alternativen vorzuziehen? Am Ende steht die Entscheidung, die Sie benötigen. Ein Komponentendiagramm allein erklärt weder das Verhalten noch die Abwägung.
Das folgende Beispiel beschreibt den Bestellservice eines fiktiven Händlers. Das Team erwägt eine Warteschlange zwischen der Annahme einer Bestellung und ihrer Abwicklung. Die Präsentation soll Entwicklung und Betrieb bei der Entscheidung über einen Pilotversuch helfen; sie ist kein Entwurf für ein reales Produktivsystem.
Sobald Diagramme und Vergleich vorliegen, können Sie die Architekturgliederung mit Presenti in bearbeitbare Folien umwandeln. Geben Sie die technische Begründung mit ein. So kann der erste Entwurf einen vorhandenen Gedankengang ordnen, statt ein System zu erfinden.
Benennen Sie die Änderung, der das Publikum zustimmen soll
Formulieren Sie die Entscheidung, bevor Sie eine Folie erstellen: „Einen Pilotversuch zur asynchronen Abwicklung angenommener Bestellungen freigeben; die Zahlungsautorisierung bleibt im bisherigen Ablauf.“ Grenzen Sie die Diskussion ein: Die Integration des Zahlungsdienstleisters, ein Datenbankwechsel und die vollständige Neugestaltung des Checkouts gehören nicht dazu.
Dieser Satz bestimmt, welche Details in die Präsentation gehören. Die Betriebsleitung muss verstehen, wie ein verzögerter Abwicklungsauftrag sichtbar wird. Die Entwicklungsleitung braucht Antworten zu Wiederholungsversuchen und Duplikaten. Beide benötigen keinen Rundgang durch sämtliche Dienste des Unternehmens. Ist das erwartete Nutzerverhalten noch umstritten, klären Sie es in einer Präsentation der Produktanforderungen, bevor Sie in dieser Besprechung eine Architektur auswählen lassen.
Beginnen Sie mit den Nachbarn des Systems
Zeigen Sie in einer Kontextansicht den Kunden, die Checkout-Anwendung, den Bestellservice, den Zahlungsdienstleister und den Abwicklungsservice. Beschriften Sie Beziehungen mit ihrem Zweck, statt nur einen Pfeil zu zeichnen. „Autorisiert die Zahlung“ sagt mehr als „API“. Kennzeichnen Sie den Bestellservice als Gegenstand der Diskussion und platzieren Sie externe Systeme außerhalb dieser Grenze.
Die C4-Anleitung zum Systemkontext empfiehlt diese Gesamtansicht des Systems, seiner Nutzer und der angeschlossenen Systeme, bevor Details eingeführt werden. Sie müssen nicht alle C4-Diagramme übernehmen, um von dieser Trennung der Ansichten zu profitieren.
Verfolgen Sie eine Bestellung von der Annahme bis zur Abwicklung
Ein nummerierter Ablauf zeigt, was sich durch die vorgeschlagene Warteschlange ändert. Die folgende Reihenfolge gehört zum fiktiven Händlerbeispiel. Verwenden Sie dieselben Nummern im Diagramm, damit Sie auf einen Schritt verweisen können, ohne erst das passende Kästchen zu suchen.
| Schritt | Interaktion | Was das Publikum verstehen sollte |
|---|---|---|
| 1 | Der Checkout sendet eine Bestellanfrage an den Bestellservice | Die Anfrage besitzt eine Bestell-ID, die im gesamten Ablauf verwendet werden kann |
| 2 | Der Bestellservice bestätigt die Zahlungsautorisierung | Eine abgelehnte Zahlung erzeugt keinen Abwicklungsauftrag |
| 3 | Der Bestellservice speichert die angenommene Bestellung und ein noch zu veröffentlichendes Ereignis | Der Entwurf muss einen Ausfall zwischen dem Speichern der Bestellung und dem Veröffentlichen des Ereignisses berücksichtigen |
| 4 | Ein Publisher sendet das ausstehende Ereignis an die Warteschlange | Die Veröffentlichung kann wiederholt werden; das Ereignis braucht eine stabile Kennung |
| 5 | Der Abwicklungsservice empfängt das Ereignis und speichert seinen Bearbeitungsstatus | Ein erneut zugestelltes Ereignis darf keine zweite Sendung auslösen |
| 6 | Der Betrieb sieht den Auftragsstatus oder eine Meldung über einen fehlgeschlagenen Auftrag | Die Warteschlange verändert neben dem Anfragepfad auch Überwachung und Wiederherstellung |
Ein dynamisches C4-Diagramm kann die geordnete Interaktion zur Laufzeit für einen bestimmten Anwendungsfall darstellen. Setzen Sie es gezielt ein: Hier sind der Fehlerpfad und die Wiederholungsversuche interessant, nicht jeder erfolgreiche Aufruf.
Beschriften Sie dieses Beispiel nicht mit „exactly once“ oder „keine verlorenen Bestellungen“. Solche Aussagen erfordern Implementierungsdetails und Tests, die diese Präsentation nicht liefert. Zeigen Sie stattdessen die offenen Entwurfsfragen: Wie werden ausstehende Ereignisse wiederhergestellt? Wie lange bleiben fehlgeschlagene Aufträge erhalten? Wer ist für die erneute Verarbeitung verantwortlich?
Vergleichen Sie die Varianten anhand derselben Fragen
Stellen Sie nicht einfach einen Absatz mit Vorteilen neben einen Absatz mit Nachteilen. Verwenden Sie für beide Varianten dieselben Kriterien und machen Sie den jeweiligen Aufwand sichtbar.
| Kriterium | Direkter Aufruf des Abwicklungsservice | Abwicklung über eine Warteschlange |
|---|---|---|
| Antwort an den Kunden | Die Annahme hängt vom Verhalten des Aufrufs an den Abwicklungsservice ab | Die Annahme lässt sich von der späteren Verarbeitung trennen |
| Wiederherstellung nach Fehlern | Wiederholungsversuche bleiben im aufrufenden Pfad | Auftragsstatus, erneute Verarbeitung und Duplikatbehandlung sind erforderlich |
| Betriebsaufwand | Weniger beteiligte Teile in diesem Ablauf | Für Warteschlangenzustand, fehlgeschlagene Aufträge und Verarbeitungsverzögerung werden Verantwortliche benötigt |
| Migration | Kein neuer Nachrichtenpfad | Pilotversuch und Rückkehr zum bisherigen Ablauf sind nötig |
Die Tabelle beschreibt Entwurfsüberlegungen, keine gemessene Leistung. Ergänzen Sie reale Latenz- oder Fehlerdaten nur mit Angaben zu Umgebung, Zeitraum, Stichprobe und Quelle. Ohne diese Daten ist ein begrenzter Pilotversuch die sachliche Empfehlung – keine behauptete Verbesserung.
Fassen Sie die Argumentation in sechs Folien zusammen
- Entscheidung und Umfang: der vorgeschlagene Pilotversuch und seine Ausschlüsse.
- Kontext: der Bestellservice und seine direkten Nachbarn.
- Aktuelles Problem: der beobachtete Vorfall, die Verzögerung oder die betriebliche Einschränkung, die den Vorschlag ausgelöst hat.
- Vorgeschlagener Ablauf: die sechs Interaktionen und ihre Fehlerstellen.
- Varianten: dieselben vier Vergleichskriterien für beide Ansätze.
- Pilotentscheidung: Verantwortlicher, Rückkehr zum bisherigen Ablauf, Tests und Termin für die Go-/No-Go-Entscheidung.
Im Beispiel könnte die letzte Folie das Plattformteam auffordern, vor der Pilotentscheidung einen Publisher-Ausfall, eine doppelte Zustellung und einen Ausfall des Abwicklungsservice zu testen. Jeder Test braucht ein erwartetes Ergebnis und eine Person, die es beurteilt. So entsteht ein konkretes Besprechungsergebnis, ohne vorzugeben, dass die Präsentation selbst die Architekturfrage entscheidet. Nach Abschluss dieser Tests verbindet eine Präsentation zur Release-Bereitschaft die Ergebnisse mit dem konkreten Release-Kandidaten, offenen Blockern und der Person, die zur Go/No-Go-Entscheidung befugt ist.
Erstellen Sie den Entwurf mit sechs Folien in Presenti aus Ihrem eigenen Ablauf, Variantenvergleich und den Pilotbedingungen. Konfiguration, Protokolle und vollständige Testergebnisse gehören in einen Anhang oder ein verlinktes Entwurfsdokument. Dort lassen sie sich prüfen, ohne den Hauptgedanken zu überladen.
