Architektur- und Integrationsentscheidungen

Eine Architekturentscheidung braucht einen konkreten Gegenstand

Die Talbahn vergleicht zwei Integrationsangebote für ihre Diagnoseanwendung. Angebot A bündelt mehrere Funktionen auf einer Plattform; Angebot B verteilt sie auf verschiedene Komponenten. Keines ist allein deshalb besser. Die Architekturentscheidung betrifft den benötigten Austausch, dessen Grenzen und seine Veränderungen im Lebenszyklus.

Ein Architekturentscheid hält fest, welche Alternative gewählt wird und weshalb. Dazu gehören Annahmen, Folgen und offene Punkte. Eine Schnittstellenverantwortung benennt, wer das Verhalten auf einer Grenze spezifiziert, implementiert und bei Störungen untersucht. Diese Verantwortung bleibt auch dann nötig, wenn beide Seiten vom selben Lieferanten stammen.

Vom Use Case zum Vergleich

Zuerst übernimmt die Talbahn die Partner und Zustände aus 2.22. Dann zeichnet sie die Anwendung, Client-Funktionen, Gateways, Dienstplattform und Transportanteile ein. Für jede Alternative werden dieselben Fragen beantwortet. Dabei bleibt das anwendbare Anwendungsprofil eine Vorgabe; eine dort festgelegte Kopplungsart ist keine frei austauschbare Designoption. [S06; S10; S42]

Ein durchgearbeitetes Beispiel

Angebot A hat eine gemeinsame Betriebsorganisation und weniger organisatorische Übergaben. Die Talbahn sieht darin einen möglichen Vorteil bei der Störungsführung. Gleichzeitig muss sie prüfen, ob ein Plattformupdate Sprache und Diagnose gemeinsam betrifft. Angebot B erlaubt möglicherweise getrennte Änderungszyklen, bringt aber zusätzliche Schnittstellenkoordination mit sich. Beides sind zu prüfende Folgen der gewählten Umsetzung, keine allgemeinen Herstellerurteile.

Die Entscheidung lautet deshalb nicht «mehr Komponenten sind sicherer». Sie lautet beispielsweise: «Wir wählen die angebotene Trennung, weil unabhängige Diagnoseupdates im Versuch nachgewiesen sind und die zusätzliche Schnittstellenverantwortung vertraglich und betrieblich zugeordnet ist.» Ohne diesen Nachweis wäre der vermeintliche Vorteil eine Annahme.

Woran die Entscheidung später überprüft wird

Die Fallakte enthält einen konkreten Änderungsfall: Die streckenseitige Diagnoseanwendung wird ersetzt. Geprüft werden Registrierung, bestehende und neue Sitzungen, Adresszuordnung, Berechtigungen und Fehlerrückmeldungen. Eine erfolgreiche API-Anfrage allein beweist nicht den vollständigen Austausch. Ein Rollback beschreibt die kontrollierte Rückkehr zur vorherigen freigegebenen Kombination, falls festgelegte Kriterien verletzt werden.

Prüfe dein Verständnis

Ein Anbieter verspricht Austauschbarkeit mit der Begründung «offene Schnittstelle». Welche zusätzlichen Angaben machen das Versprechen prüfbar?

Musterantwort

Erforderlich sind konkreter Schnittstellenstand, unterstützte Optionen, Zustands- und Fehlerverhalten, Verantwortlichkeiten und ein Austauschversuch in der benannten Kombination. Offene Dokumentation erleichtert Integration, beweist aber nicht jede Austauschkonstellation. Ein Rückkehrverfahren begrenzt das Risiko eines fehlgeschlagenen Wechsels.

Das nimmst du mit

Architekturqualität zeigt sich am begründeten Umgang mit Funktionen, Abhängigkeiten und Änderungen. Eine plausible Zeichnung ist der Anfang einer Entscheidung, nicht ihr Nachweis.

Deine Talbahn-Fallakte

Schreibe einen Architekturentscheid mit Anlass, zwei Alternativen, gewählter Lösung, Begründung, Nachweis und verbleibender Annahme.