Altsysteme über eine moderne API nutzbar machen, ohne sie sofort zu ersetzen.

Ein Unternehmen möchte ein neues Portal, eine mobile Anwendung, moderne Landingpages oder einen KI-gestützten Prozess entwickeln. Die benötigten Daten liegen jedoch in einem älteren CRM, einer branchenspezifischen Fachsoftware, SharePoint, Dateien und weiteren Systemen, die keine geeigneten modernen Schnittstellen bieten.

Der naheliegende Schluss lautet oft: Zuerst müssen alle Altsysteme ersetzt werden. Das kann richtig sein – ist aber häufig weder kurzfristig realistisch noch für den ersten digitalen Service erforderlich.

Eine Integrations- und Datenschicht kann die vorhandenen Systeme entkoppeln. Sie übernimmt Daten, normalisiert sie, ergänzt Fachlogik und stellt sie über moderne, kontrollierte Schnittstellen bereit.

Altsystem heißt nicht wertloses System

Ein bestehendes System kann:

• fachlich gut funktionieren,
• wichtige historische Daten enthalten,
• tief in operative Prozesse eingebunden sein,
• von Mitarbeitern sicher bedient werden,
• aber technisch schwer integrierbar sein.

Die Frage ist deshalb nicht nur, ob die Technologie alt ist. Entscheidend ist:

• Welche Aufgabe erfüllt das System?
• Welche Daten werden benötigt?
• Wie zuverlässig sind diese Daten?
• Welche Änderungen müssen zurückgeschrieben werden?
• Welche Risiken und Kosten hätte eine Ablösung?
• Welche neuen Produkte sollen entstehen?

Ein System kann als Quelle zunächst sinnvoll weiterarbeiten, auch wenn neue Verbraucher nicht mehr direkt darauf zugreifen.

Eine Anti-Corruption Layer zwischen Alt und Neu

Neue Anwendungen sollten nicht das Datenmodell und die Eigenheiten jedes Altsystems übernehmen.

Beispiel:

Legacy CRM:        Feld OBJ_STATUS = 17
Immobiliensoftware: Status = "active_listing"
SharePoint-Liste:   Vermarktung = "Ja"
        ↓ Integrationsschicht normalisiert
        ↓
Kanonischer Status: available

Diese Schicht übersetzt technische und fachliche Besonderheiten in ein gemeinsames Modell. In der Softwarearchitektur wird eine solche Grenze häufig als Anti-Corruption Layer verstanden: Das neue System wird vor den uneinheitlichen Modellen der Quellen geschützt.

Datenübernahme oder Echtzeitabfrage?

Es gibt zwei grundlegende Muster.

Direkte Laufzeitabfrage

Die moderne API ruft Daten bei jeder Anfrage aus dem Altsystem ab.

Vorteile:

• unmittelbar aktuelle Daten,
• weniger lokale Replikation.

Nachteile:

• neue Anwendung hängt von Verfügbarkeit und Antwortzeit des Altsystems ab,
• hohe Last kann die Quelle überfordern,
• Normalisierung erfolgt bei jeder Anfrage,
• komplexe Abfragen über mehrere Systeme sind langsam.

Kontrollierte Replikation

Daten werden regelmäßig oder ereignisbasiert in eine moderne Datenschicht übernommen.

Vorteile:

• schnelle und stabile APIs,
• gemeinsames Modell über mehrere Quellen,
• Suchindizes und komplexe Abfragen,
• Entkopplung vom Laufzeitverhalten der Quelle,
• historische Nachvollziehbarkeit möglich.

Nachteile:

• Daten besitzen eine definierte Verzögerung,
• Synchronisation und Konfliktbehandlung werden notwendig.

Häufig ist ein hybrides Modell sinnvoll: Stammdaten werden repliziert, einzelne kritische Werte bei Bedarf aktuell abgefragt.

Das kanonische Modell folgt dem neuen Produkt

Die Integrationsplattform sollte nicht versuchen, jede Tabelle der Altsysteme vollständig zu spiegeln. Ihr Modell richtet sich nach den neuen Nutzungsszenarien.

Beispiel Immobilienservice:

Property
- identity
- address
- type
- marketing_status
- public_description
- price_information
- media
- availability
- responsible_contact
- source_references

Jede Quelle liefert einen Teil. Herkunft, Aktualität und Zugriffsrechte werden mitgeführt.

Dadurch entsteht ein nutzbares Datenprodukt statt eines schwer verständlichen Datenbankabzugs.

Herkunft und Priorität

Wenn mehrere Systeme dieselbe Information liefern, muss eine Regel entscheiden.

Mögliche Kriterien:

• fachlich führende Quelle,
• Freigabestatus,
• Aktualität,
• Vollständigkeit,
• Markt oder Mandant,
• manuelle Bestätigung.

Für jeden relevanten Wert sollte nachvollziehbar bleiben:

• aus welcher Quelle er stammt,
• wann er übernommen wurde,
• welche Regel ihn ausgewählt hat,
• welche alternativen Werte existieren.

Diese Provenienz ist entscheidend für Support und Fehleranalyse.

REST, GraphQL und Suchindex erfüllen verschiedene Aufgaben

REST API

Geeignet für klare Ressourcen und stabile Integrationsverträge.

Beispiele:

• einzelnes Objekt abrufen,
• Anfrage anlegen,
• Status aktualisieren,
• Dokument erzeugen.

GraphQL API

Geeignet, wenn unterschiedliche Frontends oder Partner flexibel verschiedene Datenbeziehungen benötigen.

Ein Portal kann genau die Felder laden, die für seine Ansicht erforderlich sind, ohne zahlreiche spezialisierte Endpunkte.

Suchindex

Geeignet für:

• Volltextsuche,
• Filter,
• Facetten,
• Sortierung,
• große Ergebnismengen,
• Geo- oder Ähnlichkeitssuche.

Der Suchindex ist eine abgeleitete Projektion und nicht automatisch die führende Datenquelle.

Eine Plattform kann alle drei Bereitstellungen aus demselben kanonischen Modell erzeugen.

Öffentliche und geschützte Daten trennen

Dasselbe Objekt kann öffentliche und vertrauliche Felder besitzen.

Beispiel:

Öffentlich:

• Titel,
• Kurzbeschreibung,
• Lage auf grober Ebene,
• öffentliche Bilder,
• Angebotsstatus.

Geschützt:

• genaue Adresse,
• interne Notizen,
• Eigentümerdaten,
• vertrauliche Dokumente,
• interne Kalkulation.

Die Trennung sollte nicht allein durch verschiedene Frontends erfolgen. API-Schema, Berechtigungen und Datenprojektionen müssen verhindern, dass geschützte Felder überhaupt unberechtigt ausgeliefert werden.

Mögliche Modelle:

• getrennte öffentliche und interne Endpunkte,
• feldbasierte Berechtigungen,
• rollenbezogene Datenprojektionen,
• signierte zeitlich begrenzte Dokumentzugriffe.

Schreibprozesse kontrollieren

Sobald neue Anwendungen nicht nur lesen, sondern Anfragen, Änderungen oder Konfigurationen zurückschreiben, wird die Integration transaktional.

Zu klären ist:

• Welches System nimmt den Vorgang verbindlich an?
• Wie wird eine externe Anfrage eindeutig identifiziert?
• Was passiert bei doppeltem Absenden?
• Wie wird der Status zurückgemeldet?
• Welche Validierung erfolgt vor der Übergabe?
• Was passiert, wenn das Zielsystem nicht erreichbar ist?

Idempotency Keys, Warteschlangen und explizite Prozesszustände verhindern doppelte Vorgänge und unsichtbare Verluste.

Caching und Datenalter

Neue Websites und Portale erwarten schnelle Antworten. Caches sind sinnvoll, benötigen aber Regeln:

• Welche Daten dürfen gecacht werden?
• Wie lange?
• Wie werden Änderungen invalidiert?
• Darf bei Quellausfall ein alter Wert angezeigt werden?
• Wie wird das Alter sichtbar?

Öffentliche Beschreibungen können länger gecacht werden als Preise, Verfügbarkeit oder vertrauliche Statusinformationen.

Legacy-Fehler nicht verstecken

Die Integrationsschicht sollte Quellprobleme nicht nur still kompensieren. Sie muss sichtbar machen:

• fehlende Daten,
• unbekannte Statuswerte,
• widersprüchliche Quellen,
• ausgefallene Importe,
• veraltete Datensätze,
• nicht zustellbare Rückschreibungen.

Ein Quality Dashboard und Alerts helfen, die Quelllandschaft schrittweise zu verbessern.

Die Integrationsschicht als Migrationspfad

Eine moderne Daten- und API-Schicht kann später die Ablösung einzelner Systeme erleichtern.

Neue Anwendungen sprechen bereits mit dem kanonischen Modell. Wird ein Quellsystem ersetzt, ändert sich primär der Konnektor – nicht jedes Portal und jede Landingpage.

Das bedeutet nicht, dass jede Integrationsschicht automatisch dauerhafte Zielarchitektur ist. Sie schafft aber eine kontrollierte Grenze, an der Systeme schrittweise modernisiert werden können.