Architektur: Entscheiden, wenn beide Lösungen gut sind
Seit einer Stunde diskutiert ihr dieselbe Frage. Das Kundenportal soll den Status eines Auftrags schneller anzeigen. Bisher werden die Daten nachts übernommen. Im Raum liegen zwei Vorschläge: den bestehenden Import häufiger ausführen oder Änderungen künftig als Ereignisse übertragen.
Die Kollegin aus der Entwicklung will auf Events setzen. Der Kollege aus dem Betrieb möchte den vorhandenen Import erweitern. Beide kennen ihr Fach. Beide können ihren Vorschlag begründen. Mit jedem Argument wird deutlicher, dass hier zwei unterschiedliche Vorstellungen davon aufeinandertreffen, was eine gute Lösung ausmacht.
An diesem gedanklichen Beispiel lässt sich zeigen, wie eine Architekturentscheidung vorankommt: Ihr klärt das konkrete Ziel, prüft die Optionen dagegen und benennt die Nachteile, die ihr bewusst akzeptiert. Ein Architecture Decision Record, kurz ADR, hält diese Begründung so fest, dass sie später wieder nutzbar wird.
„Schneller“ reicht für die Entscheidung noch nicht
Im Ticket steht „zeitnaher Status“. Die Event-Lösung verspricht kurze Verzögerungen. Der häufigere Import scheint mit weniger neuer Infrastruktur auszukommen. Solange offenbleibt, wie aktuell die Daten sein müssen, könnt ihr beide Vorschläge mit gutem Grund bevorzugen.
Ihr fragt nach. Für den vorgesehenen Anwendungsfall soll eine Statusänderung innerhalb von 15 Minuten sichtbar sein. Die erste Ausbaustufe betrifft eine begrenzte Kundengruppe. Weitere Informationen dürfen weiterhin nachts ankommen. Außerdem muss das Portal erkennen lassen, wenn sein Datenstand veraltet ist.
Damit wird der Vergleich konkreter. Ein inkrementeller Import könnte alle zehn Minuten die noch nicht übernommenen Änderungen lesen. Ob das reicht, hängt von Laufzeit, Verzögerungen und Last auf dem Quellsystem ab. Ein Zehn-Minuten-Takt allein garantiert noch keine Aktualität innerhalb von 15 Minuten.
Die Event-Variante muss ebenfalls mehr zeigen als einen schnellen Normalfall. Wie werden ausgefallene Übertragungen nachgeholt? Was passiert mit doppelten oder verspäteten Ereignissen? Wer betreibt die zusätzliche Strecke? Das sind prüfbare Fragen für beide Entwürfe.
Jede Option bekommt ihre eigenen Kosten zurück
Die Diskussion verändert sich, sobald ihr Vorteile und Folgelasten gemeinsam betrachtet. Der Import kann vorhandene Betriebskenntnisse nutzen. Häufigere Abfragen belasten aber möglicherweise das Quellsystem; ein Zeitplan bleibt außerdem gröber als eine direkte Änderungsübermittlung.
Eine Ereignisstrecke kann kurze Reaktionszeiten ermöglichen und weitere Abnehmer versorgen. Dafür braucht sie unter anderem einen verlässlichen Umgang mit Zustellung, Verarbeitung und Wiederanlauf. Welche dieser Fähigkeiten ihr bereits habt, entscheidet mit über den Aufwand.
Das ist eine Trade-off Analysis im konkreten Arbeitsalltag: Ihr untersucht, welche Eigenschaften ihr mit welcher Entscheidung gewinnt und welche Lasten ihr dafür übernehmt. Die Gewichtung folgt dem Vorhaben. Eine beeindruckende Liste abstrakter Qualitätsmerkmale würde euch noch keine Priorität geben.
Im Beispiel braucht ihr zunächst belastbare Aktualität für einen begrenzten Fall. Neue Abnehmer sind denkbar, aber noch nicht vereinbart. Deshalb wäre es verfrüht, ihren möglichen Nutzen als bereits gesicherten Vorteil einzurechnen. Genauso wenig dürft ihr den Import nur deshalb als günstig behandeln, weil seine bisherige Betriebsarbeit in keinem neuen Angebot auftaucht.
Der Rückweg besteht aus mehr als einem Revert
Jemand schlägt vor, einfach mit einer Variante anzufangen. Zurück könne man immer noch. Für den Code stimmt das vielleicht. Für das Verhalten des gesamten Systems muss es genauer betrachtet werden.
Wenn das Portal seinen Nutzern künftig eine bestimmte Aktualität zusagt, ändert sich deren Erwartung. Wenn weitere Prozesse die häufigeren Daten verwenden, entstehen neue Abhängigkeiten. Und wenn ihr während der Umstellung zwei Wege gleichzeitig schreibt, braucht ihr eine Regel, welche Information bei einem Widerspruch gilt.
Reversibilität hängt auch davon ab, was andere inzwischen auf der Entscheidung aufgebaut haben. Ein begrenzter Pilot kann den Rückweg einfacher halten: klare Teilnehmer, eine maßgebliche Datenquelle, bekannte Abschaltbedingungen und ein Verhalten des Portals für veraltete Daten. Das muss vor dem Start geklärt sein.
Wenn ihr noch nicht wisst, welche Prozesse heute von einem Datenbestand abhängen, führt der Weg zunächst über die Untersuchung der bestehenden Software. Eine Abwägung wird belastbarer, wenn ihre Annahmen über den Bestand überprüft werden können.
Ein kurzer ADR bewahrt den Grund
Michael Nygard beschreibt Architecture Decision Records als kurze Aufzeichnungen wichtiger Architekturentscheidungen. Kontext, Entscheidung, Status und Konsequenzen halten fest, warum eine Richtung gewählt wurde. Dazu gehören auch Nachteile. Der Eintrag kann bereits als Vorschlag entstehen und die Diskussion strukturieren.
Für unser Beispiel könnte ein ausgefüllter Entwurf so lauten:
ADR: Auftragsstatus im Pilot durch inkrementellen Import aktualisieren. Status: vorgeschlagen. Das Portal benötigt für eine begrenzte Kundengruppe einen höchstens 15 Minuten alten Status. Der nächtliche Import besteht bereits; eine betriebsbereite Ereignisstrecke gibt es noch nicht.
Wir schlagen einen Import alle zehn Minuten vor. Vor der Freigabe prüfen Entwicklung und Betrieb gemeinsam, ob Wartezeit und Verarbeitung unter der vereinbarten Last innerhalb der Aktualitätsgrenze bleiben. Das Portal weist veraltete Daten aus. Die Quelldaten bleiben maßgeblich; parallele Schreibwege werden im Pilot nicht eingeführt.
Wir akzeptieren zusätzliche Abfragelast und eine zeitlich gröbere Übertragung. Der Pilot darf bei Überlastung abgeschaltet werden; das Portal zeigt dann den älteren Datenstand mit entsprechendem Hinweis. Der Tech Lead verantwortet die erneute Bewertung, sobald die Aktualitätsgrenze nicht eingehalten wird, die Kundengruppe wesentlich wächst oder ein Anwendungsfall sekundenaktuelle Daten erfordert. Nach erfüllten Freigabebedingungen und gemeinsamer Entscheidung wechseln wir den Status auf „angenommen“.
Das Dokument trifft keine Entscheidung an eurer Stelle. Es macht sichtbar, worüber ihr tatsächlich entscheidet. Insbesondere verhindert der benannte Pilotumfang, dass eine lokale Lösung still zur Architekturvorgabe für alle künftigen Fälle wird.
Eine spätere Änderung muss den alten Streit nicht wiederholen
Wenn Entwicklung, Betrieb und fachliche Verantwortung denselben Fall unterschiedlich beurteilen, passt dazu THINK FIRST Team Intensive. Dort arbeitet ein internes Kernteam begleitet am eigenen Unternehmensfall, um Zusammenhänge und Annahmen in einem gemeinsam prüfbaren Modell sichtbar zu machen. Die fachliche Entscheidung bleibt beim Team.
Angenommen, später soll ein weiterer Prozess auf Statusänderungen innerhalb weniger Sekunden reagieren. Dann hat sich eine entscheidende Anforderung verändert. Ihr könnt den ADR öffnen und genau diese Annahme neu bewerten. Der bisherige Entwurf war für einen anderen Rahmen gedacht.
Vielleicht entscheidet ihr euch jetzt für die Ereignisstrecke. Die neue Entscheidung kann die alte ablösen und auf sie verweisen. So bleibt erkennbar, welche Gründe früher galten und was sich verändert hat.
Am Ende des ersten Gesprächs müssen deshalb auch nicht alle dieselbe technische Vorliebe haben. Es reicht, dass ihr die gewählte Richtung, ihre Bedingungen und ihre Kosten gemeinsam verantworten könnt. Beim nächsten Gespräch habt ihr einen konkreten Ausgangspunkt.