API-first statt Insellösungen: ERP, Shop, CRM und KI sauber verbinden

1. Ausgangslage: die gewachsene Punkt-zu-Punkt-Landschaft

Die Systemlandschaft eines typischen Mittelständlers ist selten geplant worden — sie ist entstanden. Zuerst kam das ERP, dann der Shop, dann ein CRM für den Vertrieb, dann ein Versanddienstleister mit eigenem Portal, dann ein Buchhaltungssystem, dann ein Werkzeug für Newsletter. Jedes System wurde für sich ausgewählt und war für sich betrachtet die richtige Entscheidung. Verbunden wurden sie hinterher, jeweils genau dann, wenn ein konkreter Schmerz zu groß wurde.

Das Ergebnis ist ein Geflecht direkter Verbindungen: Der Shop schreibt Bestellungen ins ERP, das ERP schickt Rechnungen an die Buchhaltung, ein Skript synchronisiert Kunden ins CRM, ein Export erzeugt nachts eine CSV-Datei für den Versanddienstleister. Mathematisch sind bein Systemen bis zu n(n−1)/2 Verbindungen möglich — bei acht Systemen also 28. Real sind es meist zehn bis fünfzehn, und schon das reicht für den entscheidenden Effekt: Niemand hat mehr den Überblick, welche Daten wohin fließen.

Die Symptome sind überall gleich. Ein Kunde existiert dreimal, mit drei unterschiedlichen Adressen. Eine Preisänderung im ERP kommt im Shop erst am nächsten Tag an, manchmal gar nicht. Ein Skript, das seit 2019 läuft, hat der damalige Praktikant geschrieben, und seit dessen Weggang traut sich niemand, es anzufassen. Fällt eine Verbindung aus, merkt es niemand, bis ein Kunde anruft.

Die naheliegende Reaktion — jede kaputte Verbindung einzeln reparieren — verschlimmert die Lage, weil sie das Muster fortschreibt. Der Ausweg beginnt mit einer anderen Frage: nicht „wie verbinde ich A mit B?“, sondern „wo liegt die Wahrheit über ein Datenobjekt, und wie kommt sie zu allen, die sie brauchen?“

2. Was API-first konkret bedeutet

API-first wird häufig als Technologieentscheidung missverstanden. Tatsächlich ist es zuerst eine Reihenfolgeentscheidung: Die Schnittstelle wird spezifiziert, bevor sie gebaut wird, und jede Funktion eines Systems ist programmatisch erreichbar — nicht nur über die Oberfläche. Für die Praxis im Mittelstand folgen daraus vier konkrete Konsequenzen.

Jedes Datenobjekt hat genau ein führendes System

Diese Festlegung ist der Kern und wird trotzdem in der Mehrzahl der Projekte nie schriftlich getroffen. Sie erfolgt nicht pro System, sondern pro Datenfeld. Üblich und bewährt: Die Kundenstammdaten und Zahlungskonditionen führt das ERP, weil sie dort rechtlich relevant sind. Kontakthistorie und Vertriebsstatus führt das CRM. Produktbeschreibungen und Bilder führt das PIM oder der Shop. Bestände führt das ERP, immer.

Ohne diese Festlegung entstehen zirkuläre Überschreibungen: Das CRM aktualisiert die Adresse im ERP, der nächtliche ERP-Export überschreibt sie im CRM zurück, und beim nächsten Durchlauf beginnt das Spiel von vorn. Solche Schleifen sind der häufigste Grund für Datenqualität, der niemand mehr traut.

Verträge statt Absprachen

Eine Schnittstelle ist ein Vertrag zwischen zwei Systemen — und Verträge gehören schriftlich fixiert, maschinenlesbar und versioniert. In der Praxis heißt das: eine OpenAPI-Spezifikation für HTTP-Schnittstellen, ein JSON Schema für Nachrichtenformate, beides im Repository neben dem Code. Der Nutzen zeigt sich nicht am Tag der Erstellung, sondern zwei Jahre später, wenn ein Feld ergänzt werden soll und niemand mehr weiß, wer alles davon liest.

Ereignisse statt Zustandsabfragen

Wenn ein Quellsystem melden kann, dass sich etwas geändert hat, sollte man es melden lassen, statt alle fünf Minuten nachzufragen. Ereignisbasierte Integration reduziert Last und Latenz erheblich. In der Realität kommt man trotzdem nicht ohne Polling aus: als Rückfallebene für verlorene Ereignisse und für den nächtlichen Vollabgleich, der stille Abweichungen aufdeckt. Die belastbare Architektur kombiniert beides.

Portabilität als Entwurfsziel

Jedes System in der Landschaft wird irgendwann ersetzt. Wenn die Integrationslogik in herstellerspezifischen Konfigurationsoberflächen liegt, wird jeder Wechsel zum Neubau. Liegt sie in exportierbaren Formaten — n8n-Workflows als JSON, Transformationen als lesbarer Code, Zuordnungen in einer eigenen Datenbanktabelle — ist ein Systemwechsel Arbeit, aber kein Projekt von vorn.

3. Referenzarchitektur: Hub statt Spinnennetz

Statt jedes System mit jedem zu verbinden, spricht jedes System mit genau einer Stelle: einer Integrationsschicht, die Übersetzung, Fehlerbehandlung und Protokollierung zentral übernimmt. Aus n(n−1)/2 Verbindungen werden n Anbindungen.

Diese Schicht besteht aus vier klar getrennten Aufgaben. Die Anbindung holt Daten aus dem Quellsystem oder nimmt dessen Ereignisse entgegen und normalisiert sie in ein internes Format. Die Übersetzung bildet dieses Format auf das Zielmodell ab — hier liegt die Fachlogik, hier gehören Tests hin. Die Zustellung schreibt ins Zielsystem, mit Idempotenzprüfung und Wiederholungslogik. Die Beobachtungprotokolliert jeden Vorgang, alarmiert bei Fehlerhäufung und hält eine Warteschlange für Nachrichten bereit, die endgültig gescheitert sind.

Der letzte Punkt macht in der Praxis den größeren Teil des Aufwands aus. Der Erfolgsfall ist an einem Tag gebaut. Was Wochen kostet, ist die Frage, was passieren soll, wenn das Zielsystem zwölf Minuten nicht erreichbar ist, wenn ein Datensatz ein Pflichtfeld nicht enthält oder wenn dieselbe Nachricht zweimal ankommt.

// Zustellung mit Idempotenz und begrenztem Wiederholungsversuch
async function zustellen(nachricht) {
  const key = nachricht.idempotenzSchluessel; // z. B. "shop:bestellung:100234"

  if (await protokoll.bereitsVerarbeitet(key)) {
    return { status: 'uebersprungen', key };
  }

  for (let versuch = 1; versuch <= 4; versuch++) {
    try {
      const ergebnis = await erp.bestellungAnlegen(nachricht.daten, { idempotencyKey: key });
      await protokoll.erfolg(key, ergebnis.belegnummer);
      await mapping.speichern('bestellung', nachricht.quellId, ergebnis.belegnummer);
      return { status: 'ok', key };
    } catch (fehler) {
      if (!istVoruebergehend(fehler) || versuch === 4) {
        // Fachlicher Fehler oder Versuche erschöpft: sichtbar parken, nicht verwerfen
        await deadLetter.ablegen({ key, nachricht, fehler: fehler.message });
        await alarm.melden('zustellung_fehlgeschlagen', key);
        return { status: 'fehler', key };
      }
      await warte(2 ** versuch * 1000); // exponentiell: 2s, 4s, 8s
    }
  }
}

Zwei Details in diesem Muster sind entscheidend. Erstens wird zwischen vorübergehenden und fachlichen Fehlern unterschieden: Ein Verbindungsabbruch rechtfertigt einen weiteren Versuch, ein fehlendes Pflichtfeld nicht — dort würde jeder Wiederholungsversuch nur denselben Fehler erzeugen. Zweitens wird eine gescheiterte Nachricht geparkt, nicht verworfen. Eine Dead Letter Queue, die jemand regelmäßig ansieht, ist der Unterschied zwischen einer Integration, der man vertraut, und einer, bei der man nie sicher ist, ob alles angekommen ist.

Ergänzt wird die Zustellung um eine eigene Mapping-Tabelle: Sie hält fest, welche Kennung im Quellsystem welcher Kennung im Zielsystem entspricht. Diese Zuordnung gehört in die Integrationsschicht — nicht in ein Freitextfeld des Zielsystems, wo sie beim nächsten Datenimport verloren geht.

4. Legacy-ERP anbinden, wenn es keine API gibt

Der häufigste Einwand in Integrationsprojekten lautet: „Unser ERP kann das nicht.“ In den wenigsten Fällen stimmt das. Es gibt in der Regel vier gangbare Wege, in absteigender Attraktivität.

Der beste Weg ist eine vorhandene, wenn auch unmoderne Schnittstelle: SOAP, ein RFC-Baustein, ein herstellerspezifischer Konnektor. Unmodern ist kein Problem — eine SOAP-Schnittstelle hinter einer sauberen internen Abstraktion funktioniert genauso zuverlässig wie REST, sie ist nur unbequemer zu schreiben.

Der zweitbeste Weg ist eine lesende Datenbankverbindung, idealerweise auf eine Replik statt auf die Produktivdatenbank. Damit lassen sich Bestände, Preise und Stammdaten zuverlässig auslesen. Für schreibende Zugriffe ist dieser Weg dagegen ausgeschlossen: Ein direkter Insert umgeht die Geschäftslogik des ERP — Nummernkreise, Validierungen, Buchungslogik — und erzeugt Datensätze, die formal existieren, aber fachlich unvollständig sind. Der Schaden zeigt sich meist erst Monate später beim Jahresabschluss.

Der dritte Weg ist der Dateiaustausch: CSV oder XML in einem überwachten Verzeichnis oder per SFTP. Das wirkt altmodisch und ist trotzdem oft die pragmatischste Lösung, solange drei Bedingungen erfüllt sind — jede Datei trägt einen eindeutigen Namen mit Zeitstempel, verarbeitete Dateien werden in ein Archivverzeichnis verschoben statt gelöscht, und das Ausbleiben einer erwarteten Datei löst einen Alarm aus. Genau der letzte Punkt fehlt in nahezu jeder gewachsenen Dateischnittstelle.

Der letzte Weg ist eine Oberflächenautomatisierung, die Eingaben simuliert. Sie ist fragil, bricht bei jedem Update und sollte nur als befristete Überbrückung eingesetzt werden — mit einem festen Datum, an dem sie ersetzt wird.

5. Vergleich: Punkt-zu-Punkt, iPaaS, eigene Middleware

Die Tabelle legt einen Mittelweg nahe, der sich in der Praxis bewährt hat: eine selbst betriebene n8n-Instanz als Integrationsschicht, ergänzt um eigene Dienste dort, wo die Fachlogik zu komplex für einen Workflow wird. Man behält die Nachvollziehbarkeit einer grafischen Oberfläche für die einfachen achtzig Prozent und die volle Freiheit für die schwierigen zwanzig — bei planbaren, volumenunabhängigen Kosten.

6. Die teuersten Integrationsfehler

Kein führendes System festgelegt. Der teuerste Fehler überhaupt, weil er sich erst nach Monaten in unsauberen Daten zeigt und dann kaum noch rückwirkend zu bereinigen ist. Die Festlegung kostet eine Sitzung mit den Fachbereichen und eine Tabelle mit drei Spalten: Datenfeld, führendes System, Begründung.

Fehler still verwerfen. Ein try/catch, das den Fehler protokolliert und weitermacht, wirkt robust und ist das Gegenteil davon. Nach sechs Monaten fehlen dreihundert Bestellungen im ERP und niemand weiß, welche. Fehler gehören in eine sichtbare Warteschlange mit benannter Zuständigkeit.

Zugangsdaten im Workflow. API-Schlüssel, die direkt in einer Workflow-Definition stehen, landen im Export, im Backup und in der Versionshistorie. Sie gehören in einen Secret-Speicher und werden zur Laufzeit referenziert.

Keine Trennung von Test und Produktion. Wer Schnittstellen direkt am Produktivsystem entwickelt, verschickt früher oder später Testbestellungen an echte Kunden. Eine Testumgebung ist bei Integrationsprojekten kein Luxus, sondern Grundausstattung.

Vollabgleich statt Delta. Ein nächtlicher Abgleich, der alle 80.000 Artikel überträgt, funktioniert bei 8.000 gut und bricht bei 80.000 zusammen. Deltas über Zeitstempel oder Änderungszähler sind von Anfang an kaum aufwendiger — nachträglich eingebaut dagegen schon.

Keine Dokumentation der Zuständigkeit. Wenn um 22 Uhr eine Schnittstelle steht, muss ohne Suche klar sein, wer angerufen wird. Eine Seite pro Integration mit Zweck, Auslöser, Fehlerverhalten und Ansprechpartner ist die wirksamste Dokumentation, die es gibt.

7. Roadmap: Migration ohne Stillstand

1. Bestandsaufnahme (Woche 1–2)Alle bestehenden Datenflüsse erfassen — auch die Skripte, von denen die IT nichts weiß. Pro Fluss notieren: Quelle, Ziel, Auslöser, Häufigkeit, Verantwortung. Das Ergebnis ist meist unangenehm und immer aufschlussreich.
2. Datenhoheit festlegen (Woche 2)Pro Datenobjekt und relevantem Feld das führende System bestimmen, gemeinsam mit den Fachbereichen. Schriftlich, im Repository, mit Datum. Diese Tabelle ist das wichtigste Ergebnis des gesamten Projekts.
3. Integrationsschicht aufbauen (Woche 3–5)Die Schicht mit Protokollierung, Wiederholungslogik, Idempotenzprüfung und Dead Letter Queue aufsetzen — zunächst für genau eine, gut verstandene Verbindung.
4. Erste Verbindung umziehen (Woche 5–7)Eine bestehende Punkt-zu-Punkt-Verbindung über die neue Schicht führen, im Parallelbetrieb mit Abgleich der Ergebnisse. Erst nach fehlerfreiem Parallelbetrieb die alte Verbindung abschalten — und tatsächlich abschalten, nicht nur deaktivieren.
5. Restliche Verbindungen nach Risiko (ab Woche 8)In der Reihenfolge ihrer Störanfälligkeit migrieren, nicht in der Reihenfolge ihrer Einfachheit. Jede Migration bringt die Dokumentationsseite und den Eintrag in der Alarmierung mit.

8. Fazit und Quick-Check

Integration ist unspektakuläre Arbeit, und genau deshalb wird sie unterschätzt. Sie erzeugt keine sichtbaren Oberflächen und keine Vorführeffekte. Was sie erzeugt, ist die Voraussetzung für alles andere: Ohne verlässlichen, dokumentierten Zugriff auf die eigenen Daten scheitern auch KI-Projekte, Shop-Relaunches und Auswertungen — nicht an ihrer eigenen Komplexität, sondern daran, dass die Daten nicht dort sind, wo sie gebraucht werden, oder niemand ihnen traut.

Der wirtschaftliche Kern ist die Wiederverwendung. Die erste Schnittstelle trägt den Aufbau der Schicht und ist entsprechend teuer. Ab der dritten sinkt der Aufwand deutlich, weil Fehlerbehandlung, Protokollierung und Betrieb bereits stehen. Wer diese Kurve kennt, bewertet das erste Angebot anders — und trifft die Aufbauentscheidung nicht nach dem Preis der ersten Verbindung.

Wer hier mehr als zweimal verneinen muss, hat kein Werkzeugproblem, sondern ein Strukturproblem — und das lässt sich schrittweise lösen, ohne den Betrieb anzuhalten.

Häufige Fragen

Fachglossar

API-first

Entwurfsprinzip, bei dem die Schnittstelle eines Systems zuerst spezifiziert und dann implementiert wird. Jede Funktion ist damit programmatisch erreichbar, nicht nur über die Oberfläche — Voraussetzung dafür, dass Systeme später ohne Umwege zusammenarbeiten.

iPaaS

Integration Platform as a Service — gehostete Plattform mit fertigen Konnektoren zu verbreiteten Systemen. Schnell einsatzbereit, dafür mit laufenden volumenabhängigen Kosten und Datenhaltung beim Anbieter.

Idempotenzschlüssel

Eindeutige Kennung einer Nachricht, anhand derer ein Zielsystem erkennt, ob es diesen Vorgang bereits verarbeitet hat. Verhindert Doppelbuchungen bei Wiederholungsversuchen nach Netzwerkfehlern.

Dead Letter Queue

Warteschlange für Nachrichten, die nach mehreren Versuchen nicht verarbeitet werden konnten. Sie verhindert, dass ein einzelner fehlerhafter Datensatz die gesamte Verarbeitung blockiert, und macht Fehler sichtbar statt sie zu verwerfen.

System of Record

Das für ein bestimmtes Datenfeld verbindlich führende System. Alle anderen Systeme halten davon nur Kopien. Ohne diese Festlegung entstehen zirkuläre Überschreibungen zwischen Systemen.

Anti-Corruption Layer

Übersetzungsschicht zwischen dem Datenmodell eines Altsystems und dem der eigenen Anwendung. Verhindert, dass die Eigenheiten des Altsystems in alle neuen Systeme durchsickern und dort dauerhaft festwachsen.