Systemlandschaften wachsen selten nach Plan. Ein CSV-Export hier, ein nächtlicher Datenbankabgleich dort, dazu ein Skript, das seit Jahren läuft und dessen Autor das Unternehmen verlassen hat — so entsteht über die Zeit ein Geflecht aus Direktverbindungen, das jede Änderung zum Risiko macht. Eine API-Strategie ist die Antwort darauf. Sie muss weder akademisch noch umfangreich sein: Es geht um wenige, verbindliche Entscheidungen, wie Systeme miteinander sprechen.
Das Problem mit Punkt-zu-Punkt-Integrationen
Bei n Systemen mit direkten Verbindungen wächst die Zahl möglicher Schnittstellen quadratisch — und mit ihr der Pflegeaufwand. Ein typisches Bild aus einer Bestandsaufnahme: 14 Integrationen zwischen ERP, Webshop, Lagerverwaltung und Buchhaltung, davon 9 als nächtliche Dateiübertragungen mit jeweils eigener Fehlerbehandlung, eigenem Format und eigener Zuständigkeit. Fällt eine Übertragung aus, bemerkt man es oft erst am fehlenden Ergebnis — im geschilderten Fall etwa daran, dass der Webshop einen Vormittag lang veraltete Lagerbestände anzeigte. Jeder Systemwechsel — etwa ein neuer Webshop — bedeutet zudem, mehrere dieser Verbindungen gleichzeitig neu zu bauen. Die Kosten dieses Wildwuchses tauchen in keiner Rechnung auf; sie verstecken sich in verlängerten Projektlaufzeiten und in der Vorsicht, mit der jede Änderung angefasst wird.
Standards zuerst: wenige Regeln, konsequent angewendet
Der Kern einer API-Strategie passt auf zwei Seiten. Bewährt haben sich: HTTP-basierte REST-Schnittstellen mit JSON als Standardformat, eine maschinenlesbare Beschreibung jeder Schnittstelle per OpenAPI, einheitliche Authentifizierung (etwa OAuth 2.0 mit kurzlebigen Tokens statt geteilter Passwörter) und einheitliche Fehlercodes. Ebenso wichtig ist die Festlegung, was nicht mehr gebaut wird: keine neuen Direktzugriffe auf fremde Datenbanken, keine unversionierten Formate, keine Schnittstellen ohne Dokumentation. Solche Leitplanken klingen banal — ihre konsequente Anwendung unterscheidet gewachsene Landschaften von gepflegten. Wichtig ist außerdem eine klare Verantwortung: Jede Schnittstelle hat einen benannten Eigentümer, der Änderungen freigibt und Anfragen beantwortet. Schnittstellen ohne Eigentümer veralten unbemerkt und werden zum Risiko.
Versionierung: Verträge zwischen Systemen ernst nehmen
Eine Schnittstelle ist ein Vertrag: Wer sie nutzt, verlässt sich auf ihr Verhalten. Änderungen brauchen deshalb Regeln. Praktikabel ist eine einfache Versionierung im Pfad (etwa /v1/, /v2/) mit der Zusage, dass innerhalb einer Version nur abwärtskompatible Erweiterungen erfolgen — neue Felder ja, entfernte oder umbenannte Felder nein. Alte Versionen erhalten ein angekündigtes Abschaltdatum mit ausreichender Frist — üblich sind sechs bis zwölf Monate, abhängig davon, wie viele Konsumenten betroffen sind. Damit das funktioniert, muss bekannt sein, wer eine Schnittstelle überhaupt nutzt; ein einfaches Verzeichnis der Konsumenten je API gehört deshalb zur Grundausstattung. Dieses Vorgehen kostet Disziplin, erspart aber die gefürchteten Kettenreaktionen, bei denen eine kleine Änderung im ERP drei nachgelagerte Systeme bricht.
Sicherheit und Betrieb von Anfang an mitdenken
Schnittstellen sind Zugänge zu Unternehmensdaten und verdienen dieselbe Sorgfalt wie Benutzerkonten: Jede API erhält eine eigene Kennung je nutzendem System (keine geteilten Schlüssel), Berechtigungen nach dem Minimalprinzip und ein Zugriffsprotokoll. Für den Betrieb gilt: Eine Schnittstelle ohne Monitoring ist eine tickende Störung. Mindeststandard sind Erreichbarkeits- und Fehlerraten-Alarme sowie Ratenbegrenzungen, damit ein fehlerhafter Konsument nicht das ganze System lahmlegt. Bei dem eingangs erwähnten Unternehmen reduzierte eine zentrale Integrationsschicht mit diesen Standards die Zeit für die Anbindung eines neuen Systems von durchschnittlich sechs Wochen auf unter zwei — weil Authentifizierung, Logging und Fehlerbehandlung nicht mehr je Schnittstelle neu erfunden werden.
Fazit: Integrationsfähigkeit ist ein Wettbewerbsvorteil
Ob neuer Webshop, neues Lagersystem oder die Anbindung eines Großkunden per EDI: Unternehmen mit klarer API-Strategie setzen solche Vorhaben in Wochen um, andere in Quartalen. Der Einstieg ist bewusst unspektakulär: eine Inventur der bestehenden Verbindungen, die Definition der eigenen Standards und die Regel, dass jede neue oder ohnehin anzufassende Schnittstelle nach diesen Standards gebaut wird. So wandert die Landschaft Schritt für Schritt in den Zielzustand, ohne dass ein riskantes Großprojekt nötig wäre. Wie wir Schnittstellen konzipieren, entwickeln und in den Betrieb überführen, lesen Sie unter Dienstleistungen; für eine Einschätzung Ihrer Systemlandschaft sprechen Sie uns gern an.
