Warum die Verbindung von Anwendungen nicht damit beginnt, möglichst viele Daten auszutauschen.
Am Montagmorgen gibt die Konstruktion eine überarbeitete Zeichnung frei. Revision C einer Baugruppe ist fertig und technisch geprüft.
Der Einkauf arbeitet jedoch noch mit der Stückliste vom Freitag. In der Fertigung ist bereits ein Auftrag auf Grundlage der vorherigen Version geplant.
Als die Frage aufkommt, welche Version nun gilt, beginnt die Suche: eine E-Mail mit der neuen Zeichnung, eine exportierte Excel-Tabelle, ein Eintrag im ERP und eine Rückfrage an die Konstruktion.
Keines der Systeme ist ausgefallen. Die Informationen sind vorhanden. Jeder arbeitet mit dem Stand, der für seinen Bereich zunächst nachvollziehbar erscheint.
Was fehlt, ist eine verbindliche Antwort darauf, wann aus einer technischen Änderung eine Entscheidung für Einkauf und Fertigung wird.
Die Excel-Tabelle ist nicht das eigentliche Problem.
Solche Übergaben entstehen häufig dort, wo unterschiedliche Anwendungen einen gemeinsamen Geschäftsablauf unterstützen.
Die Konstruktion verwaltet Zeichnungen und technische Revisionen. Der Einkauf benötigt Artikel, Lieferanten und Bestellinformationen. Die Fertigung plant Aufträge und Ressourcen.
Zwischen diesen Bereichen werden Daten exportiert, ergänzt, weitergeleitet und gelegentlich erneut erfasst.
Die naheliegende Reaktion lautet: Wir müssen diese Systeme endlich automatisiert miteinander verbinden.
Doch damit ist noch nicht geklärt, welche Information übertragen werden soll und welche Bedeutung sie im nächsten System besitzt.
Eine neue Zeichnung bedeutet nicht zwangsläufig, dass bereits ausgelöste Bestellungen geändert werden dürfen. Eine technisch freigegebene Stückliste ist nicht automatisch für jeden laufenden Fertigungsauftrag gültig.
Wer nur den Datentransfer automatisiert, kann ungeklärte Entscheidungen schneller verbreiten.
Nicht jedes System braucht dieselbe Wahrheit.
In der Softwarearchitektur beschreibt Martin Fowler mit Bounded Contexts, warum unterschiedliche fachliche Bereiche eigene, in sich konsistente Datenmodelle benötigen können.
Ein Begriff kann dabei je nach Kontext etwas anderes bedeuten.
„Freigegeben“ heißt in der Konstruktion möglicherweise, dass eine technische Revision geprüft wurde. Im Einkauf kann eine Freigabe dagegen bedeuten, dass eine Bestellung verbindlich ausgelöst werden darf.
Beide Zustände können korrekt sein, ohne dass sie dieselbe Entscheidung beschreiben.
Deshalb besteht gute Systemarchitektur nicht zwangsläufig darin, sämtliche Daten in einer zentralen Anwendung zusammenzuführen.
Entscheidend ist, welches System für welche Information maßgeblich ist und wer die dazugehörige Entscheidung verantwortet.
In unserem Beispiel könnte die Konstruktion für den freigegebenen technischen Stand verantwortlich sein, während das ERP Bestellungen und Fertigungsaufträge verwaltet. Das wäre eine bewusst festzulegende Architekturentscheidung, keine automatische Eigenschaft dieser Produkte.
Eine klare Grenze verbindet, statt zu trennen.
Damit die Übergabe funktioniert, braucht sie mehr als eine Datei oder einen API-Aufruf.
Die Information muss ihren fachlichen Zusammenhang behalten: Welche Revision wurde freigegeben? Für welche Aufträge gilt sie? Ab wann? Wer entscheidet, wenn bereits Material bestellt wurde?
Erst wenn diese Fragen geklärt sind, lässt sich der technische Übergang zuverlässig gestalten.
Bei unterschiedlichen Datenmodellen kann eine Übersetzungsschicht sinnvoll sein. Microsoft beschreibt dafür das Anti-Corruption-Layer-Muster: Eine definierte Schnittstelle übersetzt zwischen fachlichen Modellen, ohne dass ein System die internen Annahmen des anderen übernehmen muss.
Das bedeutet nicht, für jede Übergabe einen zusätzlichen Dienst einzuführen. Auch ein kontrollierter Export oder eine bewusst manuelle Freigabe kann richtig sein, wenn Zuständigkeiten, Gültigkeit und Fehlerwege eindeutig geregelt sind.
Die Qualität einer Grenze zeigt sich nicht daran, wie unsichtbar sie geworden ist.
Sie zeigt sich daran, ob eine Information ihre Bedeutung behält, wenn sie den Verantwortungsbereich wechselt.
Automatisierung ersetzt keine Entscheidung.
Zurück zur neuen Zeichnungsrevision.
Die Änderung betrifft möglicherweise Bauteile, die bereits bestellt oder gefertigt wurden. Ob bestehende Aufträge angepasst werden, muss anhand ihrer Auswirkungen entschieden werden.
Eine Schnittstelle kann die neue Revision bereitstellen. Sie kann betroffene Vorgänge identifizieren und eine Prüfung anstoßen.
Ob eine laufende Bestellung geändert werden darf, bleibt jedoch eine fachliche Entscheidung, solange dafür keine verbindlichen Regeln und Zuständigkeiten definiert sind.
Darin liegt der Unterschied zwischen einer bloßen Integration und einer durchdachten Systemarchitektur.
Die eine bewegt Informationen. Die andere gestaltet, wie aus Informationen verlässliche Entscheidungen und nachvollziehbare Abläufe werden.
Gute Architektur macht Übergaben überflüssig, die niemand verantwortet.
Nicht jede E-Mail muss verschwinden. Nicht jeder Prozess muss vollautomatisch ablaufen.
Aber es sollte erkennbar sein, wo ein System verantwortlich ist, wo diese Verantwortung endet und unter welchen Bedingungen sie an den nächsten Bereich übergeht.
Dann entsteht aus einzelnen Anwendungen eine zusammenhängende Systemlandschaft, ohne ihre notwendigen fachlichen Grenzen aufzulösen.
Das Ziel ist nicht, dass alle Systeme alles wissen. Sondern dass jede Information dort verbindlich ist, wo sie gebraucht wird – und keine Entscheidung zwischen den Systemen verloren geht.
Quellen und Vertiefung
- Martin Fowler — Bounded Context — Fachliche Modelle, Kontextgrenzen und die Beziehungen zwischen ihnen.
- Microsoft Learn — Anti-Corruption Layer Pattern — Übersetzung unterschiedlicher Datenmodelle und Semantik zwischen Systemen.
- Microsoft Learn — Saga Pattern — Umgang mit mehrstufigen Vorgängen, Teilfehlern und nicht ohne Weiteres umkehrbaren Entscheidungen.
Die beschriebenen Architekturprinzipien beruhen auf dokumentierten Entwürfen und daraus abgeleiteten Überlegungen.
