EAI und
Systemgrenzen

Enterprise Application Integration (EAI) bezeichnet die geplante Verbindung eigenständiger Anwendungen, damit ein durchgängiger Geschäftsprozess entsteht. Eine Anwendung bleibt dabei für ihre eigene Aufgabe verantwortlich. Das ERP verwaltet beispielsweise Artikel und Aufträge, ein Shop den Warenkorb, ein Dokumentenmanagementsystem die Dokumente und Orthanc medizinische Bilddaten. EAI schafft Regeln für den Austausch, ersetzt diese Systeme aber nicht.

Eine funktionierende Netzwerkverbindung genügt noch nicht. Integration braucht mehrere Ebenen von Interoperabilität: Technisch müssen sich Systeme erreichen. Syntaktisch müssen sie Formate wie JSON oder DICOM lesen können. Semantisch müssen sie unter einem Feld dasselbe verstehen. Organisatorisch muss geklärt sein, wer Fehler bearbeitet und wer Änderungen genehmigt. Zwei APIs können deshalb technisch perfekt kommunizieren und fachlich dennoch falsche Resultate erzeugen.

Der Nutzen von EAI liegt nicht nur in weniger Handarbeit. Gute Integration verkürzt Durchlaufzeiten, vermeidet Medienbrüche, verbessert Datenqualität und macht einen Prozess beobachtbar. Sie erzeugt jedoch auch Abhängigkeiten. Darum gehört zu jeder Schnittstelle ein fachlicher Zweck, ein Vertrag, ein Besitzer und ein Fehlerweg.

Eine Systemgrenze trennt Verantwortungen. Innerhalb der Grenze darf ein Team Datenmodell und Implementierung ändern. An der Grenze wird nur ein stabiler Vertrag zugesichert. Wer direkt in die Datenbank eines fremden Systems schreibt, umgeht dessen Regeln. Ein Update des Herstellers kann die Integration dann unbemerkt zerstören.

Für jedes wichtige Geschäftsobjekt braucht es ein führendes System. Im Handel kann WooCommerce den Checkout besitzen, während Odoo Artikelbestand und internen Auftrag führt. Die Shop-Bestellnummer bleibt eine externe Referenz im ERP. Im Spital verwaltet Orthanc die DICOM-Studie; ein Klinikinformationssystem kann Fall und Behandlung führen. Die lokale Orthanc-ID ist dann keine allgemeine Fallnummer. Eine DICOM StudyInstanceUID, eine Fall-ID und eine technische Event-ID haben verschiedene Bedeutungen und dürfen nicht vermischt werden.

Datenhoheit bedeutet nicht, dass nur ein System Daten sehen darf. Andere Systeme dürfen kontrollierte Kopien halten. Es muss aber feststehen, wer eine Korrektur vornehmen darf, wie Kopien aktualisiert werden und welche Verzögerung akzeptabel ist. Das verhindert den Streit zwischen zwei scheinbar gleichwertigen Wahrheiten.

Systeme können auf mehreren Achsen gekoppelt sein. Zeitliche Kopplung bedeutet, dass beide gleichzeitig verfügbar sein müssen. Strukturelle Kopplung entsteht, wenn ein Konsument jedes interne Feld des Anbieters kennt. Fachliche Kopplung entsteht, wenn Regeln über mehrere Systeme verteilt sind. Betriebliche Kopplung zeigt sich, wenn ein Fehler in einem System die gesamte Kette blockiert.

Eine Integrationsschicht reduziert Kopplung nur, wenn sie klare Verträge schafft. Werden alle Fachregeln, Datenkopien und Sonderfälle wahllos darin gesammelt, entsteht ein schwer wartbares „Zentralsystem“. Das Ziel ist nicht maximale Entkopplung, sondern eine bewusste, erklärbare Abhängigkeit.

1. Beginne mit dem Geschäftsprozess und seinen Verantwortlichen, nicht mit einem Produktnamen.
2. Bestimme pro Objekt ein führendes System und dokumentiere externe Referenzen.
3. Nutze die öffentliche API oder ein dokumentiertes Ereignis statt eines Datenbank-Durchgriffs.
4. Halte Fachlogik möglichst beim verantwortlichen Fachservice; Gateway und Queue übernehmen Querschnittsaufgaben.
5. Bewerte Kopplung, Fehlerfolgen, Datenklassifikation und Betriebskosten gemeinsam.
6. Wähle eine zentrale Integrationsplattform nur, wenn Wiederverwendung, Kontrolle oder Beobachtbarkeit den Zusatzbetrieb rechtfertigen.