Wie bindet man ein Legacy-System an ein neues Produkt an?

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.

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.

Aus Projekten mit gewachsenen Kernsystemen kenne ich ein wiederkehrendes Muster: Die erste Diskussion dreht sich um Protokolle, die erste Produktionsstörung fast immer um Zuständigkeiten, Wiederanläufe und unklare Fachrückmeldungen. Kritisch wird es im Incident-Handling: Wer entscheidet bei Teilfehlern über Wiederholung, wer eskaliert bei Rückstau, und ab wann landet ein Fall in manueller Nacharbeit statt in einer weiteren technischen Schleife? Genau dort scheitern Integrationen im Betrieb, obwohl die Schnittstelle auf dem Papier sauber aussieht.

Bei einem regionalen Versicherer musste ein neues Serviceportal Statusabfragen und Adressänderungen gegen ein älteres Kernsystem abwickeln. Statusabfragen liefen synchron über einen Adapter mit kurzem Cache und klaren Timeouts, weil Nutzer aktiv auf Rückmeldung warteten. Adressänderungen wurden asynchron angenommen, mit Nachrichten-ID, begrenzten Wiederholungen und fachlichem Abgleich über den Rückkanal. Der Konflikt entstand nicht an der API, sondern bei Supportübergaben: Das Portal-Team sah eine erfolgreiche Annahme, das Kernsystem-Team erst Stunden später einen fachlich abgelehnten Datensatz. Ohne klaren Eskalationsweg wäre daraus täglich manuelle Nacharbeit geworden.

Wer solche Flüsse plant, sollte nicht nur Antwortzeiten messen. Wichtiger sind Queue-Laufzeit, Anteil manueller Nachbearbeitung, Dublettenquote und Alter offener Nachrichten. Diese Kennzahlen zeigen, ob eine Integrationsform im Betrieb trägt oder nur in der Präsentation gut aussieht.

Betriebsmodell, Governance und Kaufkriterien

Die meisten Integrationsprobleme sind vor dem Start sichtbar. Man muss sie nur ernst nehmen. Für Auswahl und Umsetzung reichen wenige harte Prüfpunkte.

Erstens: Legacy-Eigenheiten gehören in Adapter, nicht ins neue Produkt. Wenn ein Anbieter oder internes Team Tabellenstrukturen, Dateiformate oder proprietäre Fehlermeldungen direkt in die neue Anwendung zieht, steigt das Risiko für Seiteneffekte und Freigabestau deutlich.

Zweitens: Das Fehlermodell muss explizit sein. Timeouts, Teilfehler, Retry-Grenzen, Dead-Letter-Pfade und manuelle Fallbacks müssen beschrieben sein. Fehlt das, ist die Lösung nicht produktionsreif, auch wenn die Demo funktioniert.

Drittens: Beobachtbarkeit ist kein Nachrüstpaket. Infrastruktur-Monitoring allein reicht nicht. Wer nur CPU, Speicher und Antwortzeiten sieht, erkennt fachliche Konflikte zu spät. Nötig sind auch Metriken für Dubletten, Rückstaus, offene Nachrichten und fehlgeschlagene Abgleiche.

Viertens: Betriebsverantwortung muss benannt sein. Wenn niemand sagen kann, wer nachts bei Queue-Stau, fehlerhaften Rückmeldungen oder Datenkonflikten reagiert, ist das Angebot architektonisch unvollständig. Integration ist kein reines Entwicklungsprojekt. Sie ist ein Betriebsmodell.

Fünftens: Der Rückbaupfad sollte sichtbar sein. Eine gute Integrationsschicht schützt nicht nur den Altbestand, sie erleichtert auch spätere Ablösung. Es muss erkennbar sein, welche Adapter dauerhaft gebraucht werden und welche verschwinden können, sobald neue Domänendienste Verantwortung übernehmen.

Bei personenbezogenen Daten wird Governance materiell. Für Vorhaben in Europa ist die Datenschutz-Grundverordnung ein echter Architekturtreiber, nicht nur ein Freigabethema. Datenminimierung, nachvollziehbare Protokollierung, klare Verantwortlichkeiten und umsetzbare Lösch- oder Berichtigungspfade über Systemgrenzen hinweg müssen in das Design hinein. Wer Daten unnötig spiegelt, baut sich nicht nur technische, sondern auch regulatorische Last auf. Die Anforderungen sind in der Datenschutz-Grundverordnung klar beschrieben.

Ein weiterer Marktpunkt wird oft unterschätzt: zentrale Integrationsplattformen. Ein Enterprise Service Bus kann in großen Organisationen mit vielen Teams und verbindlichen Standards sinnvoll sein. Für viele Vorhaben ist er als Startpunkt aber zu schwer. Erst wenige reale Flüsse verstehen, dann standardisieren. Andersherum endet es oft in teurer Zentralisierung ohne klaren Engpass.

Ich habe in Auswahlprozessen mehrfach gesehen, dass Anbieter mit großer Plattformgeschichte überzeugen, obwohl der eigentliche Engpass viel kleiner war: ein unsauberes Fehlermodell, fehlende Fachquittungen oder keine klare Trennung zwischen technischer Annahme und fachlicher Verarbeitung. Wer diese Punkte nicht vor Vertragsabschluss klärt, kauft oft Komplexität statt Risikoreduktion. Das ist eine unbequeme, aber in vielen Beschaffungen zutreffende Beobachtung.

Wenn aus der Anbindung ein mehrstufiges Transformationsprogramm wird, reicht Schnittstellenarbeit nicht mehr aus. Dann geht es um Migrationspfad, Betriebsmodell und Reihenfolge der Ablösung. In solchen Fällen gehört das Thema in einen breiteren Rahmen der Legacy-Modernisierung.

Wie man klein startet, ohne die falsche Grenze zu bauen

Der vernünftige Einstieg ist klein, aber nicht künstlich klein. Man startet mit einem geschäftlich relevanten Fluss, der echte Last, echte Fehler und echte Zuständigkeiten sichtbar macht. Ein Demo-Szenario ohne kritische Randbedingungen liefert kaum belastbare Erkenntnisse.

Die Reihenfolge sollte nüchtern bleiben. Erst wird das führende System pro Datenobjekt festgelegt. Danach folgt ein Integrationsvertrag mit Eingaben, Ausgaben, Fehlercodes, Idempotenzregeln und Versionierung. Dann wird Legacy-spezifische Logik in Adapter isoliert. Beobachtbarkeit kommt nicht später, sondern ab dem ersten produktiven Fluss.

Das neue Produkt spricht mit einem stabilen fachlichen Vertrag, nicht mit Tabellen, Batch-Eigenheiten oder proprietären Fehlermeldungen des Altbestands. Diese Grenze macht Betrieb beherrschbar und Entwicklung schneller. Fehlt sie, entsteht keine tragfähige Integrationsschicht, sondern nur eine modernere Verpackung derselben Abhängigkeit.

Kurz gesagt: Die falsche Grenze rächt sich schnell.

Cutover-Risiken werden regelmäßig unterschätzt. Sobald ein neuer Kanal produktiv geht, braucht es Regeln für Parallelbetrieb, Rollback, Datenabgleich und Supportwege. Wer nur den Happy Path plant, erlebt den ersten echten Incident als Architekturreview unter Produktionsdruck.

Ein belastbarer Pfad ist meist unspektakulär. Zuerst trennt man einen kritischen Schreibfluss vom direkten Legacy-Zugriff, etwa eine Adressänderung oder Auftragsaktualisierung. Danach läuft genau dieser Fluss einige Wochen mit Monitoring, Prüfpfad und fachlichem Abgleich stabil im Betrieb. Erst dann entscheidet man, welche Funktion wirklich aus dem Legacy-System herausgelöst wird. Wenn der Altbestand bereits Wachstum und Änderbarkeit blockiert, hilft auch der Blick auf Modernisierung ohne Big Bang.

Am Ende zählt eine operative Frage: Kann das neue Produkt schneller weiterentwickelt werden, ohne dass jede Änderung eine Legacy-Diskussion über Tabellen, Batch-Fenster oder alte Fehlercodes auslöst? Wenn die Antwort nein ist, wurde das Legacy-System zwar angebunden, aber nicht sauber entkoppelt.