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

Ihr ERP ist 15 Jahre alt. Es funktioniert, es bildet Ihre Kernprozesse ab – 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-Bestände. Das Legacy-System liefert dagegen Batch-Exporte, CSV-Dateien und nächtliche SFTP-Transfers.

Der Reflex vieler Organisationen: alles neu bauen. Das kostet Millionen, dauert Jahre und scheitert häufig. Die bessere Antwort ist API-First: Das System nicht ersetzen, sondern kontrolliert öffnen – schrittweise, sicher und messbar.

Dieser Artikel zeigt, wie Sie Ihre Legacy-Systeme mit einer API-First-Strategie integrationsfähig machen, welche Patterns (Anti-Corruption Layer, API Gateway, BFF) wann passen und wie Sie den Business-Case gegenüber der Geschäftsführung aufbauen.

Für wen dieser Artikel relevant ist: CTOs, Enterprise-Architekten und IT-Leiter im Mittelstand, die vor der Aufgabe stehen, ERP-, CRM- oder Fachsysteme für Mobile, Partner oder neue digitale Produkte zu öffnen.

Warum API-First der Hebel für inkrementelle Modernisierung ist

Das Grundproblem: Isolation statt Integration

Legacy-Systeme sind nicht schlecht. Sie sind stabil, bewährt und tragen jahrelang akkumuliertes Geschäftswissen. Ihr eigentliches Problem ist Isolation: Sie wurden für eine Zeit gebaut, in der Systeme für sich standen und Integration Datei-Austausch oder manuelle Übertragung bedeutete.

Heute erwarten Kunden, Partner und Fachbereiche Echtzeit-Zugriff auf Daten und Prozesse. Ein isoliertes System wird – unabhängig davon, wie stabil es läuft – zum Engpass für jede digitale Initiative.

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 belastbare Zahlen. Hier die typischen Größenordnungen für ein Mittelstandsunternehmen (Richtwerte, die Sie für Ihr Haus konkretisieren sollten):

Kosten der Nicht-Modernisierung:

• Manuelle Datenübertragung zwischen Systemen: 2-3 FTE, ca. €180.000/Jahr
• Fehlerhafte Daten durch Medienbrüche: €50.000-€120.000/Jahr (Retouren, Fehllieferungen, Nacharbeit)
• Entgangene Geschäftschancen durch fehlende Partner-Integration: schwer quantifizierbar, aber real
• Time-to-Market für neue digitale Produkte: sechs bis zwölf Monate statt vier bis acht Wochen

Investition in eine API-First-Strategie:

• Initial-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 meist 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

Fazit: APIs sind eine strategische Entscheidung, keine technische

API-First ist kein Hype. 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 neue Systeme vor Altlasten. Das API Gateway gibt Ihnen Kontrolle, Sicherheit und Übersicht. Saubere Versionierung und Governance halten die APIs langfristig stabil und wartbar.

Das Entscheidende: 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.

Konkrete erste Schritte:

1. Wählen Sie einen API-Use-Case mit hohem Business-Value und niedriger Komplexität – typisch: Produktkatalog, Kundendaten-Lookup oder Statusabfragen.
2. Setzen Sie ein Cloud-natives API-Gateway auf (Azure APIM im Consumption-Tier oder AWS API Gateway reichen zum Start).
3. Bauen Sie den ersten Anti-Corruption Layer mit sauberem Domänenmodell – kein direkter Durchgriff auf Legacy-Feldnamen.
4. Definieren Sie den OpenAPI-Contract, bevor die Implementierung beginnt.

Ihr Legacy-System hat jahrelang gute Dienste geleistet. Mit API-First kann es das weiter tun – als Teil eines integrierten Ökosystems. Wenn der Tag kommt, an dem Sie es tatsächlich ersetzen, haben Sie die härteste Arbeit bereits erledigt: Alle Konsumenten sprechen mit der API, nicht mit dem System dahinter.

Nächste Schritte

• Passende Landing Page: .NET & Legacy Migration Services
• Für CTOs im Mittelstand: CTO-Sparring: Zweitmeinung zu Ihrer Integrationsstrategie
• Verwandter Artikel: Legacy-Modernisierung mit dem Strangler-Fig-Pattern
• Verwandter Artikel: Legacy-ERP-Integration mit Azure Functions: Lessons Learned
• Gespräch vereinbaren: 60-Min-Strategiegespräch zur API-Strategie