Wer ein Legacy-System an neues Produkt anbinden will, sollte zuerst die Kopplung begrenzen statt reflexhaft mehr Werkzeuge einzukaufen. Die eigentliche Entscheidung fällt früher, als viele Teams annehmen: Schreibrechte, Datenhoheit und Störungsfolgen legen den Integrationspfad meist schon fest. Gibt es nur lesenden Zugriff auf eine stabile Schnittstelle und bleibt ein Ausfall fachlich verkraftbar, kann direkte Anbindung reichen. Sobald mehrere Systeme schreiben, Fehler manuell geklärt werden müssen oder das Legacy-System unzuverlässig reagiert, ist ein Adapter oder eine Integrationsschicht fast immer die bessere Kaufentscheidung.
Direkte Kopplung ist vertretbar, wenn das neue Produkt Daten nur konsumiert und das Legacy-System fachlich führend bleibt. Ein Adapter wird nötig, wenn Formate, Fehlerbilder oder Protokolle übersetzt werden müssen. Eine breitere Integrationsschicht lohnt sich, wenn mehrere Flüsse, Schreibrechte, Wiederanläufe und Betriebsverantwortung zusammenkommen. Wenn zu Beginn niemand sauber sagen kann, wer Dubletten, Teilfehler und nächtliche Incidents übernimmt, liegt das Problem selten an der Plattform. Es fehlt an Betriebsreife.
Genau dort werden Beschaffungen unnötig teuer. Teams kaufen Middleware, obwohl in Wahrheit Zuständigkeiten, Datenführerschaft und Release-Abhängigkeiten ungeklärt sind. Davon hängt ab, ob das neue Produkt wirklich schneller wird oder nur moderner aussieht.
Wann direkte Anbindung reicht und wann sie kippt
Direkte Anbindung ist nicht falsch. Sie wird nur regelmäßig zu großzügig freigegeben. Tragfähig ist sie vor allem dann, wenn ein neues Produkt über eine dokumentierte Schnittstelle liest, das Legacy-Team Änderungen planbar freigibt und ein Ausfall keinen kritischen Prozess stoppt.
Fehlt einer dieser Punkte, steigen die Folgekosten schnell. Dann hängt das neue Produkt nicht nur an einer API oder Datenbank, sondern an stillen Regeln des Altbestands: Batch-Fenstern, Sondercodes, historisch gewachsenen Feldbedeutungen oder Freigaben einzelner Personen. Solche Abhängigkeiten stehen selten auf der Architekturfolie, tauchen im Betrieb aber fast immer auf.
Besonders heikel sind Schreibzugriffe. Ein neues Produkt, das direkt auf Legacy-Tabellen schreibt, spart am Anfang vielleicht Zeit. Später kostet es Beweglichkeit, weil jede Änderung am Datenmodell, an Triggern oder an Freigabeprozessen zwei Systeme gleichzeitig betrifft. Direkter Schreibzugriff auf Legacy-Tabellen ist in den meisten Vorhaben ein Warnsignal. Es gibt Ausnahmen, etwa in klar kontrollierten Übergangsszenarien mit stabiler Eigentümerschaft. Als Standard taugt es nicht.
Die bessere Prüffrage lautet deshalb: Welches System ist pro Datenobjekt führend, wer darf verbindlich schreiben und welche Antwortzeit ist fachlich wirklich nötig? Wenn diese drei Punkte nur mit Annahmen beantwortet werden, ist direkte Kopplung meist keine schlanke Lösung, sondern vertagte Architekturarbeit.
Manchmal ist selbst ein guter Adapter nur noch ein Puffer vor der eigentlichen Entscheidung. Wenn der Altbestand fachlich kaum verstanden wird, Änderungen über Einzelpersonen laufen oder jede neue Anbindung Sonderlogik erzeugt, sollte die Grundsatzfrage früher auf den Tisch. Dann hilft der Blick auf Refaktorisierung oder Neuschreiben, weil davon abhängt, ob die Integrationsgrenze dauerhaft gedacht ist oder nur als Übergang dient.
Welches Integrationsmuster zum Altbestand passt
Nicht jedes Legacy-System verlangt dieselbe Antwort. Genau hier scheitern viele Vorhaben: Ein einziges Muster wird auf sehr unterschiedliche Altlandschaften gedrückt. Wer ein Legacy-System integrieren will, sollte zuerst den Typ des Altbestands benennen und erst danach über Plattformen sprechen.
Datenbankzentrierte Systeme
Bei datenbankzentrierten Altverfahren wirkt direkter Zugriff oft verlockend, weil Tabellen sichtbar und schnell erreichbar sind. Das Problem ist selten SQL selbst. Das Problem ist die Annahme, dass Tabellen bereits ein sauberes Fachmodell darstellen. In gewachsenen Systemen steckt Geschäftslogik oft in Triggern, Stored Procedures, Statusfeldern oder impliziten Feldkombinationen.
Lesender Zugriff kann funktionieren, wenn das Schema stabil ist und keine versteckte Logik im Weg steht. Sobald das neue Produkt schreiben, reservieren oder Zustände fachlich interpretieren muss, gehört ein Adapter-Service dazwischen. Er kapselt das Schema, übersetzt technische Felder in fachliche Objekte und schützt das neue Produkt vor internen Strukturänderungen.
Datei-, Batch- und SFTP-Strecken
Wenn der Altbestand nur periodisch liefert, sollte das neue Produkt keine Echtzeit simulieren. In solchen Umgebungen ist asynchrone Datenintegration meist die vernünftigere Grundform. Dateien werden angenommen, validiert, versioniert und bei Fehlern in einen klaren Prüfpfad verschoben.
Entscheidend sind hier Idempotenz, Abgleich und Wiederanlauf. Ein Import muss denselben Lauf erneut verarbeiten können, ohne Dubletten zu erzeugen. Ein Abgleich muss zeigen, welche Datensätze erwartet, verarbeitet oder verworfen wurden. Und ein Wiederanlauf darf nicht davon abhängen, dass nachts jemand manuell Dateien umbenennt.
SOAP und ältere Service-Schnittstellen
SOAP ist kein Ausschlusskriterium. Viele stabile Kernsysteme liefern darüber seit Jahren verlässlich. Problematisch werden starre Verträge, große XML-Nachrichten, unklare Fehlermeldungen und schwankende Antwortzeiten. Ein Adapter, der intern SOAP spricht und nach außen eine produktnahe API anbietet, ist oft die sauberste Lösung.
Dann liegen Timeouts, Mapping, Versionierung und Caching an einer Stelle. Das neue Produkt muss weder XML-Eigenheiten noch alte Fehlercodes kennen. Diese Trennung senkt spätere Umbaukosten deutlich.
Mainframe und transaktionale Kernverfahren
Mainframe-Anbindung verlangt meist weniger Architekturromantik und mehr Betriebsdisziplin. Häufig gibt es feste Zeitfenster, begrenzte Parallelität und hohe fachliche Kritikalität. Hier gewinnt selten die eleganteste Lösung. Es gewinnt die robusteste.
Eine dünne Integrationsschicht mit Lastbegrenzung, sauberer Fehlerklassifikation und klaren Verträgen ist oft sinnvoller als ein großer zentraler Umbau. Für schrittweise Ablösung bleibt das Strangler-Fig-Muster eine brauchbare Referenz, wie es auch in der Microsoft-Architekturdokumentation beschrieben wird: Zugriffe werden kontrolliert umgeleitet, Altpfade nach und nach stillgelegt.
| Legacy-Typ | Sinnvolles Muster | Direkte Anbindung nur wenn | Hauptrisiko |
|---|---|---|---|
| Datenbank | Adapter vor dem Schema | nur lesend, stabiles Schema, keine versteckte Logik | Schemaänderungen brechen das neue Produkt |
| Batch oder Datei | Asynchroner Import mit Abgleich | nicht für interaktive Kernprozesse | stille Datenfehler und Dubletten |
| SOAP | Adapter mit Mapping und Timeout-Steuerung | kleiner Umfang, stabile Verträge | enge Kopplung an alte Fehler- und Datenmodelle |
| Mainframe | Dünne Integrationsschicht mit Lastschutz | nur sehr begrenzter lesender Zugriff | Überlastung und schwer beherrschbare Teilfehler |
Synchron oder asynchron: hier entstehen die echten Betriebskosten
Viele Teams diskutieren zu früh über Endpunkte und zu spät über Betriebsfolgen. Dabei ist die Wahl zwischen synchron und asynchron oft die teuerste Architekturentscheidung im ganzen Vorhaben. Echtzeit ist nur dann gerechtfertigt, wenn der Nutzer oder der Prozess ohne unmittelbare Antwort nicht weiterkommt.
Synchron passt bei Preisprüfung, Verfügbarkeitscheck, Authentifizierung oder Reservierung mit sofortiger Rückmeldung. Asynchron passt bei Statusangleichung, Dokumentbereitstellung, Stammdatenänderungen oder Importläufen. Der Unterschied ist nicht akademisch. Er entscheidet darüber, ob Lastspitzen, Timeouts und Legacy-Ausfälle direkt im Nutzerfluss landen oder kontrolliert abgefedert werden.
Die verbreitete Echtzeit-Fixierung bei Legacy-Anbindungen ist in vielen Unternehmen kein technischer Bedarf, sondern ein Beschaffungssymptom. Wenn in frühen Gesprächen jede Fachanforderung plötzlich „in Echtzeit“ sein soll, obwohl der Prozess seit Jahren mit Stunden- oder Tagesversatz lebt, wird oft nicht besser integriert, sondern nur teurer eingekauft.
