API-First-Strategie: Legacy-Systeme öffnen, ohne sie neu zu bauen

Ihr ERP-System ist 15 Jahre alt. Es funktioniert. Es bildet geschäftskritische Prozesse ab, die über Jahre gewachsen sind. Aber: Es kann nicht mit der Außenwelt sprechen. Der Vertrieb will eine mobile App. Partner fordern digitale Schnittstellen. Die neue E-Commerce-Plattform braucht Echtzeit-Bestandsdaten. Und Ihr Legacy-System? Kennt nur Batch-Exporte, CSV-Dateien und nächtliche SFTP-Transfers.

Die klassische Reaktion: "Wir müssen alles neu bauen." Das kostet Millionen, dauert Jahre und scheitert in über 60% der Fälle. Die bessere Antwort: API-First. Nicht das System ersetzen – sondern es öffnen. Kontrolliert, sicher, schrittweise.

In diesem Artikel zeige ich Ihnen als Enterprise-Architekt, wie Sie mit einer API-First-Strategie Ihre Legacy-Systeme integrationsfähig machen – ohne Big-Bang-Risiko, mit messbarem ROI und einem klaren Fahrplan für Ihre Stakeholder.

Warum API-First der Schlüssel zur inkrementellen Modernisierung ist

Das Grundproblem: Isolation durch fehlende Schnittstellen

Legacy-Systeme sind nicht per se schlecht. Sie sind stabil, bewährt und enthalten jahrelang akkumuliertes Geschäftswissen. Ihr Problem ist ein anderes: Sie sind isoliert. Sie wurden in einer Zeit gebaut, in der Systeme für sich allein standen. Integration bedeutete manuelle Datenübertragung oder bestenfalls Datei-basierte Batch-Verarbeitung.

Heute erwarten Kunden, Partner und interne Abteilungen Echtzeit-Zugriff auf Daten und Prozesse. Ein isoliertes System – egal wie stabil – wird zum Engpass.

API-First als Philosophie, nicht als Technologie

API-First bedeutet nicht, einfach eine REST-Schnittstelle vor ein altes System zu schrauben. Es ist eine strategische Entscheidung: Jede neue Funktionalität, jede Integration, jede Erweiterung wird zuerst als API gedacht. Die API ist das Produkt – nicht die Benutzeroberfläche, nicht die Datenbank, nicht das Backend.

Für Legacy-Systeme heißt das konkret:

• Keine Direktzugriffe auf die Datenbank – stattdessen definierte API-Endpunkte
• Keine Point-to-Point-Integrationen – stattdessen ein zentrales API-Gateway
• Keine impliziten Schnittstellen – stattdessen dokumentierte, versionierte Contracts
• Keine Abhängigkeit von internen Datenstrukturen – stattdessen stabile, entkoppelte Datenmodelle

Der Business Case: Warum sich API-First rechnet

IT-Entscheider brauchen Zahlen. Hier sind sie:

Kosten der Nicht-Modernisierung (typisches Mittelstandsunternehmen):

• Manuelle Datenübertragung zwischen Systemen: 2-3 FTE, ca. €180.000/Jahr
• Fehlerhafte Daten durch Medienbrüche: ca. €50.000-€120.000/Jahr (Retouren, Fehllieferungen, Nacharbeit)
• Verlorene Geschäftschancen durch fehlende Partnerintegration: schwer quantifizierbar, aber real
• Langsame Time-to-Market für neue digitale Produkte: 6-12 Monate statt 4-8 Wochen

Investition in eine API-First-Strategie:

• Initiales Setup (API Gateway, Anti-Corruption Layer, erste APIs): €80.000-€150.000
• Laufende Betriebskosten: €2.000-€5.000/Monat
• Amortisation: typisch 8-14 Monate

Das Verhältnis ist eindeutig: Die Kosten des Nichtstuns übersteigen die Investition innerhalb des ersten Jahres.

Der Anti-Corruption Layer: Die Brücke zwischen Alt und Neu

Was ist ein Anti-Corruption Layer?

Der Anti-Corruption Layer (ACL) ist ein Konzept aus dem Domain-Driven Design. Er fungiert als Übersetzungsschicht zwischen einem Legacy-System und der modernen API-Welt. Sein Zweck: Die Eigenheiten, Altlasten und Inkonsistenzen des Legacy-Systems dürfen nicht in die neuen Systeme "durchsickern".

Stellen Sie sich den ACL vor wie einen Dolmetscher zwischen zwei Welten: Das Legacy-System spricht seine eigene Sprache (proprietäre Datenformate, kryptische Feldnamen, historisch gewachsene Geschäftslogik). Die neue API-Welt spricht eine moderne, klar definierte Sprache. Der ACL übersetzt zwischen beiden – in beide Richtungen.

ACL in der Praxis: Ein konkretes Beispiel

Ein mittelständischer Maschinenbauer hat ein SAP R/3-System aus dem Jahr 2008. Die Kundendaten sind über mehrere Tabellen verteilt, Feldnamen sind kryptisch (KNA1, KNVV, KNVP), und die Geschäftslogik für Kundenklassifizierung steckt in ABAP-Code, den niemand mehr vollständig versteht.

Ohne ACL müsste jedes neue System diese Komplexität kennen und nachbilden. Jede Änderung am SAP-System würde alle angebundenen Systeme betreffen.

Mit ACL sieht die Architektur anders aus:

[SAP R/3] → [Anti-Corruption Layer] → [Customer API v1]
                                           ↓
                    ┌──────────────────────┼──────────────────────┐
                    ↓                      ↓                      ↓
              [Mobile App]         [Partner Portal]         [E-Commerce]

Der ACL transformiert die SAP-Datenstrukturen in ein sauberes, modernes Domänenmodell:

SAP-Struktur (Legacy):              API-Modell (Modern):
─────────────────────               ────────────────────
KNA1-KUNNR: "0000012345"     →     customerId: "C-12345"
KNA1-NAME1: "MÜLLER GMBH"    →     company.name: "Müller GmbH"
KNA1-LAND1: "DE"              →     address.country: "Germany"
KNA1-ORT01: "STUTTGART"       →     address.city: "Stuttgart"
KNVV-VKORG: "1000"           →     salesOrganization: "DACH"
KNVV-KDGRP: "Z1"             →     customerGroup: "Premium"

Entwurfsprinzipien für den ACL

1. Unidirektionale Abhängigkeit: Der ACL kennt das Legacy-System. Das Legacy-System kennt den ACL nicht. Änderungen am Legacy-System erfordern Anpassungen im ACL – aber nicht in den konsumierenden Systemen.

2. Fachliche Übersetzung, nicht nur technische: Der ACL übersetzt nicht nur Datenformate, sondern auch Geschäftskonzepte. Wenn das Legacy-System "Debitor" sagt und die neue Welt "Customer" meint, ist das eine fachliche Transformation.

3. Fehlerisolierung: Wenn das Legacy-System langsam antwortet oder Fehler wirft, fängt der ACL das ab. Die API-Konsumenten sehen definierte Fehlercodes und Timeouts – nicht kryptische SAP-Fehlermeldungen.

4. Caching-Strategie: Nicht jeder API-Call muss das Legacy-System in Echtzeit befragen. Der ACL implementiert intelligentes Caching: Stammdaten werden stündlich synchronisiert, Bestandsdaten alle 5 Minuten, Preise in Echtzeit.

API Gateway Patterns: Die zentrale Steuerungsebene

Warum ein API Gateway unverzichtbar ist

Ein API Gateway ist der zentrale Eintrittspunkt für alle API-Aufrufe. Es übernimmt Querschnittsfunktionen, die Sie nicht in jeder einzelnen API implementieren wollen:

• Authentifizierung und Autorisierung – Wer darf was?
• Rate Limiting – Schutz vor Überlastung
• Request Routing – Weiterleitung an den richtigen Backend-Service
• Protokolltransformation – REST nach SOAP, JSON nach XML
• Monitoring und Logging – Wer hat wann was aufgerufen?
• Caching – Entlastung der Backend-Systeme

Gateway-Patterns für Legacy-Integration

Pattern 1: Facade Gateway

Das einfachste Pattern. Das Gateway bietet eine moderne REST-API nach außen und übersetzt Anfragen in das Legacy-Protokoll (z.B. SOAP, RFC, BAPI).

Einsatz: Wenn das Legacy-System bereits Schnittstellen hat, diese aber nicht modern genug sind. Typisch bei SAP-Systemen mit BAPI/RFC-Schnittstellen oder älteren SOAP-Webservices.

Pattern 2: Aggregation Gateway

Das Gateway kombiniert Daten aus mehreren Backend-Systemen zu einer einheitlichen Antwort. Ein Mobile-App-Client fragt einmal an und bekommt Kundendaten aus dem CRM, Bestandsdaten aus dem ERP und Lieferstatus aus dem WMS – in einer Response.

Einsatz: Wenn Daten über mehrere Legacy-Systeme verteilt sind und Konsumenten eine einheitliche Sicht brauchen.

Pattern 3: Backend-for-Frontend (BFF)

Für jeden Konsumenten-Typ (Mobile App, Web-Portal, Partner-API) wird ein eigenes Backend erstellt, das genau die Daten und Formate liefert, die dieser Konsument braucht. Das BFF kommuniziert seinerseits mit den Backend-APIs.

Einsatz: Wenn verschiedene Konsumenten sehr unterschiedliche Anforderungen an Datenformat, Granularität und Performance haben.

Tooling-Entscheidung: Build vs. Buy

Für das API Gateway haben Sie drei Optionen:

Meine Empfehlung für den Mittelstand: Starten Sie mit einem Cloud-nativen Gateway (z.B. Azure API Management im Consumption Tier). Die Einstiegskosten sind gering, die Lernkurve flach, und Sie können später skalieren.

Versionierung und Governance: APIs langfristig stabil halten

API-Versionierung richtig umsetzen

APIs ändern sich. Das ist unvermeidlich. Entscheidend ist, wie sie sich ändern. Eine saubere Versionierungsstrategie schützt Ihre Konsumenten vor Breaking Changes und gibt Ihnen Freiheit für Weiterentwicklung.

URL-basierte Versionierung (empfohlen für die meisten Szenarien):

GET /api/v1/customers/12345
GET /api/v2/customers/12345

Vorteile: Explizit, leicht verständlich, einfach zu routen im API Gateway. Nachteile: URLs ändern sich bei Major-Versionen.

Header-basierte Versionierung:

GET /api/customers/12345
Accept: application/vnd.company.v2+json

Vorteile: Saubere URLs. Nachteile: Weniger sichtbar, schwerer zu debuggen.

Governance: Wer entscheidet was?

API-Governance ist kein bürokratischer Overhead – sie ist Qualitätssicherung für Ihre digitalen Schnittstellen. Definieren Sie klare Regeln:

1. API Design Guidelines: Einheitliche Naming-Conventions, Fehlerformate, Paginierung, Filterung. Dokumentieren Sie diese in einem lebendigen Styleguide, nicht in einem 200-Seiten-PDF, das niemand liest.

2. Review-Prozess: Jede neue API oder Breaking Change durchläuft ein Review durch das Architecture Board. Nicht als Gatekeeper, sondern als Qualitätssicherung.

3. Lifecycle Management: Jede API-Version hat ein definiertes End-of-Life-Datum. Konsumenten werden 6 Monate vor Abschaltung informiert. Alte Versionen werden nicht ewig gewartet.

4. API-Katalog: Ein zentraler, durchsuchbarer Katalog aller verfügbaren APIs – mit Dokumentation, Beispielen, SLAs und Ansprechpartnern. Tools wie Backstage oder ein einfaches Developer Portal im API Gateway erfüllen diesen Zweck.

Contract-First-Entwicklung

Definieren Sie den API-Contract (OpenAPI/Swagger) bevor Sie implementieren. Der Contract ist die Diskussionsgrundlage zwischen API-Provider und API-Konsument. Erst wenn beide Seiten einverstanden sind, wird gebaut.

Vorteile:

• Frontend- und Backend-Teams können parallel arbeiten
• Mock-Server auf Basis des Contracts ermöglichen frühes Testen
• Automatische Code-Generierung (Client-SDKs, Server-Stubs) spart Entwicklungszeit
• Der Contract ist die Single Source of Truth – nicht der Code, nicht die Dokumentation

Sicherheit: OAuth2, API Keys und Zero-Trust

Authentifizierung und Autorisierung

Legacy-Systeme haben oft einfache Sicherheitsmodelle: Benutzername/Passwort, vielleicht ein VPN. Das reicht für eine moderne API-Landschaft nicht aus.

API Keys – für einfache, serverbasierte Integrationen:

• Jeder Konsument erhält einen eigenen API Key
• Der Key identifiziert den Konsumenten und ermöglicht Rate Limiting
• API Keys sind kein Ersatz für Authentifizierung – sie identifizieren, aber authentifizieren nicht im engeren Sinne
• Rotation alle 90 Tage, sofortige Deaktivierung bei Kompromittierung

OAuth2 / OpenID Connect – für komplexere Szenarien:

• Client Credentials Flow für Service-to-Service-Kommunikation
• Authorization Code Flow mit PKCE für Mobile Apps und SPAs
• Scopes definieren granulare Berechtigungen (z.B. customers:read, orders:write)
• Token-Laufzeiten: Access Token 15-60 Minuten, Refresh Token 24 Stunden

Meine Empfehlung: Starten Sie mit API Keys für interne und Partner-Integrationen. Sobald Sie externe Konsumenten oder Endbenutzer-Szenarien haben, führen Sie OAuth2 ein. Nutzen Sie einen etablierten Identity Provider (Azure AD, Keycloak, Auth0) – bauen Sie keine eigene Authentifizierungslösung.

Sicherheit auf Transport- und Netzwerkebene

• TLS 1.3 als Minimum für alle API-Kommunikation
• Mutual TLS (mTLS) für besonders sensible Service-to-Service-Verbindungen
• IP-Whitelisting als zusätzliche Schutzschicht für Partner-APIs
• WAF (Web Application Firewall) vor dem API Gateway zum Schutz gegen OWASP Top 10
• Input-Validierung an jedem API-Endpunkt – vertrauen Sie keinem Input, auch nicht von internen Systemen

Datenschutz und Compliance

Besonders relevant für Unternehmen im DACH-Raum:

• DSGVO: Personenbezogene Daten in API-Responses minimieren (Data Minimization). Logging darf keine personenbezogenen Daten enthalten oder muss diese pseudonymisieren.
• Audit Trail: Jeder API-Zugriff auf sensible Daten wird protokolliert – wer, wann, was, von wo.
• Data Residency: API Gateway und Datenverarbeitung in der EU. Bei Cloud-Diensten auf die Region achten.

Monitoring, SLAs und Betrieb

Was Sie messen müssen

APIs ohne Monitoring sind wie ein Auto ohne Armaturenbrett. Sie fahren blind. Definieren Sie von Anfang an die richtigen Metriken:

Technische Metriken:

• Latenz: P50, P95, P99 Response-Zeiten pro Endpunkt
• Fehlerrate: Anteil der 4xx- und 5xx-Responses
• Durchsatz: Requests pro Sekunde, pro Konsument
• Verfügbarkeit: Uptime in Prozent, gemessen End-to-End

Business-Metriken:

• API-Adoption: Wie viele Konsumenten nutzen welche APIs?
• Integration-Velocity: Wie schnell werden neue Partner angebunden?
• Error-Impact: Welche API-Fehler haben welchen Business-Impact?

SLAs definieren und einhalten

Definieren Sie für jede API klare Service Level Agreements:

Wichtig: Ihre API-SLAs können nicht besser sein als die SLAs Ihrer Backend-Systeme. Wenn Ihr Legacy-ERP eine Verfügbarkeit von 98% hat, kann Ihre API darüber nicht 99.9% garantieren – es sei denn, Sie implementieren Caching und Fallback-Mechanismen im ACL.

Alerting und Incident Response

• Proaktives Alerting: Warnungen bei steigender Latenz oder Fehlerrate, bevor Konsumenten es merken
• Runbooks: Dokumentierte Handlungsanweisungen für häufige API-Probleme
• Status Page: Eine öffentliche (oder Partner-zugängliche) Statusseite für Ihre APIs
• Post-Mortem-Kultur: Nach jedem Incident eine blameless Retrospektive – Was ist passiert? Wie verhindern wir es?

Konkrete Anwendungsfälle: API-First in der Praxis

Anwendungsfall 1: ERP-Anbindung für E-Commerce

Ausgangslage: Ein mittelständischer Industriezulieferer mit SAP ECC 6.0 möchte einen B2B-Webshop launchen. Das ERP enthält 45.000 Artikel mit Preisen, Beständen und technischen Daten.

Lösung:

• Anti-Corruption Layer liest Artikeldaten via SAP BAPI und transformiert sie in ein modernes Produktmodell
• Product API liefert Katalogdaten, Preise (kundenspezifisch) und Echtzeit-Bestände
• Order API nimmt Bestellungen entgegen und schreibt sie als Aufträge ins SAP
• Event-basierte Synchronisation: Bestandsänderungen im SAP triggern Updates in der Product API

Ergebnis: Time-to-Market für den Webshop: 4 Monate statt geschätzter 14 Monate bei Direktintegration. Bestellfehler durch Medienbrüche: von 8% auf 0.3% reduziert.

Anwendungsfall 2: Mobile App für den Außendienst

Ausgangslage: 120 Außendienstmitarbeiter eines Versicherungsunternehmens arbeiten mit einem 12 Jahre alten CRM-System, das nur über einen Fat Client im VPN erreichbar ist. Kundentermine werden auf Papier vorbereitet. Angebote dauern 3-5 Tage.

Lösung:

• Backend-for-Frontend (BFF) für die Mobile App, optimiert für mobile Netzwerke und Offline-Fähigkeit
• Customer API mit aggregierten Kundendaten aus CRM, Policen-System und Schaden-System
• Quote API für Echtzeit-Angebotserstellung mit Regelwerk aus dem Legacy-Tarifsystem
• Document API für digitale Unterschrift und Dokumentenablage

Ergebnis: Angebotserstellung von 3-5 Tagen auf 15 Minuten. Abschlussquote um 23% gestiegen. Außendienst-Zufriedenheit deutlich verbessert, Recruiting-Vorteil gegenüber Wettbewerbern.

Anwendungsfall 3: Partner-Integration im Ökosystem

Ausgangslage: Ein Logistikunternehmen möchte seine Tracking-Daten Geschäftskunden programmatisch zur Verfügung stellen. Bisher: manuelle Excel-Reports per E-Mail, einmal täglich.

Lösung:

• Partner API mit Self-Service-Onboarding über ein Developer Portal
• Webhook-basierte Echtzeit-Benachrichtigungen bei Statusänderungen
• Sandbox-Umgebung für Partner-Entwickler zum Testen
• Granulare API Keys pro Partner mit individuellen Rate Limits und Berechtigungen

Ergebnis: 35 Partner in 6 Monaten angebunden (vorher: 2-3 manuelle Integrationen pro Jahr). Kundenbindung signifikant gestiegen. Neues Geschäftsmodell: Premium-API-Zugang als kostenpflichtiger Service generiert zusätzlichen Umsatz.

ROI-Kalkulation: Den Business Case aufbauen

Kostenmodell für eine API-First-Initiative

Einmalige Kosten (Jahr 1):

Laufende Kosten (pro Jahr):

Einsparungen und Mehrwert

Direkte Einsparungen:

• Reduktion manueller Datenübertragung: €80.000-€150.000/Jahr
• Weniger Fehler durch Medienbrüche: €30.000-€80.000/Jahr
• Schnellere Partner-Anbindung: €50.000-€100.000/Jahr (Opportunitätskosten)

Indirekte Wertschöpfung:

• Schnellere Time-to-Market für digitale Produkte
• Neue Geschäftsmodelle durch API-Monetarisierung
• Bessere Datenqualität durch zentrale, konsistente Schnittstellen
• Reduktion technischer Schulden durch Entkopplung

Typischer ROI: 150-300% über 3 Jahre. Break-even nach 8-14 Monaten.

Argumentationshilfe für den Vorstand

Vermeiden Sie technische Details. Sprechen Sie die Sprache des Business:

• "Wir reduzieren die Integrationszeit für neue Partner von 6 Monaten auf 2 Wochen."
• "Unsere Fehlerquote bei Bestellungen sinkt von 8% auf unter 1%."
• "Wir ermöglichen 3 neue digitale Produkte pro Jahr, ohne das Kernsystem anzufassen."
• "Die Investition amortisiert sich in unter 12 Monaten."
• "Wir reduzieren unser Risiko: Wenn wir das ERP in 5 Jahren ersetzen, müssen wir nicht alle Integrationen neu bauen."

Fahrplan: API-First in 4 Phasen einführen

Phase 1: Foundation (Monat 1-3)

• API Gateway aufsetzen und konfigurieren
• Sicherheitsinfrastruktur implementieren (API Keys, TLS, WAF)
• Erste API identifizieren (wählen Sie einen Use Case mit hohem Wert und niedriger Komplexität)
• Anti-Corruption Layer für die erste API bauen
• Monitoring und Alerting einrichten
• API Design Guidelines dokumentieren

Phase 2: Erste Wertschöpfung (Monat 3-6)

• Erste API in Production bringen und mit realem Konsumenten verbinden
• Erfahrungen sammeln und Architektur validieren
• Zweite und dritte API nach dem bewährten Muster bauen
• Developer Portal aufsetzen
• SLAs definieren und messen

Phase 3: Skalierung (Monat 6-12)

• API-Katalog erweitern (5-10 APIs)
• Partner-Onboarding über Self-Service ermöglichen
• Event-basierte APIs ergänzen (Webhooks, Event Streaming)
• Automatisierte API-Tests in die CI/CD-Pipeline integrieren
• Governance-Prozesse etablieren

Phase 4: Optimierung und Monetarisierung (ab Monat 12)

• API-Nutzung analysieren und optimieren
• Neue Geschäftsmodelle auf Basis der APIs entwickeln
• Legacy-System schrittweise ablösen (das System hinter dem ACL ist austauschbar)
• API-Plattform als strategischen Wettbewerbsvorteil positionieren

Weiterführende Artikel:

• Architektur-Review: Ihre Systemlandschaft bewerten
• Event-Driven Architecture im Mittelstand
• Enterprise Data Hub: Von Datensilos zur Plattform
• Unsere Integrations-Beratung
• Kontaktieren Sie uns

Fazit: APIs sind keine technische Entscheidung, sondern eine strategische

API-First ist kein Hype und kein Selbstzweck. Es ist die pragmatischste Strategie, um Legacy-Systeme zukunftsfähig zu machen, ohne sie in einem riskanten Big-Bang-Projekt neu zu bauen.

Der Anti-Corruption Layer schützt Ihre neuen Systeme vor den Altlasten. Das API Gateway gibt Ihnen Kontrolle, Sicherheit und Übersicht. Saubere Versionierung und Governance stellen sicher, dass Ihre APIs langfristig stabil und wartbar bleiben.

Das Wichtigste: Sie müssen nicht alles auf einmal machen. Starten Sie mit einer API, einem Use Case, einem Konsumenten. Beweisen Sie den Wert. Skalieren Sie dann.

Ihr Legacy-System hat Ihnen jahrelang gute Dienste geleistet. Mit einer API-First-Strategie kann es das weiterhin tun – nur eben nicht mehr allein, sondern als Teil eines modernen, integrierten Ökosystems. Und wenn der Tag kommt, an dem Sie das Legacy-System tatsächlich ersetzen, haben Sie die härteste Arbeit bereits erledigt: Alle Konsumenten sprechen mit der API, nicht mit dem System dahinter. Der Austausch geschieht hinter dem ACL – unsichtbar für alle Beteiligten.

Das ist die wahre Stärke von API-First: Es macht die Zukunft möglich, ohne die Gegenwart zu riskieren.