API-First: Altsysteme verbinden, ohne sie zu ersetzen

Das ERP läuft seit 2014. Das Ticket-System wurde 2017 eingeführt. Die Kundenverwaltung lebt in einer Access-Datenbank, die niemand mehr anfassen will. Jedes System funktioniert für sich. Zusammen funktionieren sie nicht.

Die Reaktion vieler Systemhäuser: alles ersetzen. Neue Software, neue Lizenzen, Migrationsprojekt. Dauer: 12 bis 18 Monate. Kosten: sechsstellig. Risiko: hoch.

Es gibt einen anderen Weg.

Das Integrationsproblem

Altsysteme ohne Schnittstellen zwingen Mitarbeitende zu manuellen Workarounds. Daten werden aus einem System exportiert, in Excel bearbeitet und in ein anderes System importiert. Oder per Copy-Paste übertragen. Oder gar nicht — und stattdessen am Telefon erfragt.

Die Folge: Daten stecken in Silos. Kein System hat die vollständige Sicht. Entscheidungen basieren auf unvollständigen Informationen. Fehler durch Medienbrüche sind Alltag.

API-First: Das Architekturprinzip

API-First bedeutet: Zwischen die bestehenden Systeme wird eine Integrationsschicht gesetzt. Diese Schicht spricht mit jedem System in dessen Sprache und stellt die Daten über eine einheitliche REST- oder GraphQL-Schnittstelle bereit.

[ERP] ---> [Integrationsschicht] <--- [Ticket-System] | [Einheitliche API] | [Portal] [Dashboard] [Automatisierung]

Die Altsysteme bleiben unangetastet. Kein Migrationsprojekt. Kein Schulungsaufwand. Kein Risiko durch Systemwechsel.

Wie die Integrationsschicht funktioniert

Adapter pro System

Für jedes Altsystem wird ein Adapter geschrieben. Der Adapter kennt die Eigenheiten des Systems: Datenbankstruktur, Exportformate, Authentifizierung, Limitierungen. Er übersetzt zwischen der systemspezifischen Logik und der einheitlichen API.

Manche Systeme bieten eigene APIs — dann ist der Adapter dünn. Andere bieten nur Datenbankzugriff oder Dateiexporte — dann ist der Adapter dicker, aber das Prinzip bleibt gleich.

Datennormalisierung

Kundenstammdaten heißen im ERP "Debitor", im Ticket-System "Kontakt" und in der Kundenverwaltung "Firma". Die Integrationsschicht normalisiert diese Begriffe. Ein Datensatz, eine Struktur, ein Zugangspunkt.

Echtzeit vs. Batch

Nicht jede Verbindung muss in Echtzeit laufen. Lizenzdaten reichen als nächtlicher Abgleich. Ticket-Status braucht Echtzeit. Die Integrationsschicht unterstützt beides — je nach Anforderung des Datenflusses.

Was sich dadurch ändert

Für das Team

Ein Dashboard statt fünf Systeme. Kundendaten, Ticket-Status, Lizenzübersicht und Vertragslaufzeiten an einem Ort. Der tägliche Wechsel zwischen Anwendungen entfällt.

Für die Automatisierung

Automatisierungsworkflows brauchen eine API als Grundlage. Ohne Schnittstellen bleibt Automatisierung auf einzelne Systeme beschränkt. Mit der Integrationsschicht werden systemübergreifende Workflows möglich: Ein neuer Kunde wird im ERP angelegt, die Lizenzen im Vendor-Portal bestellt und das Onboarding-Ticket automatisch erstellt.

Für spätere Systemwechsel

Wenn Sie in zwei Jahren das ERP tatsächlich ersetzen, tauschen Sie nur den Adapter aus. Der Rest der Architektur bleibt stabil. Die Integrationsschicht entkoppelt Ihre Workflows von einzelnen Systemen.

Wann der Ansatz nicht passt

Wenn ein Altsystem instabil ist, Sicherheitslücken hat oder vom Hersteller nicht mehr unterstützt wird, ist Ersetzen die richtige Entscheidung. Die Integrationsschicht ist kein Argument dafür, marode Systeme am Leben zu halten. Sie ist ein Argument dafür, funktionsfähige Systeme nicht grundlos zu ersetzen.

Nächster Schritt

Lassen Sie uns in 30 Minuten prüfen, wie Self-Service Ihren 1st-Level-Support entlastet — unverbindlich und kostenfrei.

Gespräch vereinbaren →