API, iPaaS oder Middleware: Was passt zu welchem Prozess?

Wenn zwei Systeme miteinander sprechen sollen, gibt es selten nur einen Weg. Man kann die Schnittstellen direkt miteinander verbinden. Man kann eine Integrationsplattform dazwischenschalten. Man kann eine eigene, schlanke Middleware bauen. Und in manchen Fällen ist ein nächtlicher Dateiabgleich die vernünftigste Lösung, so unspektakulär das klingt.

Die Frage „API, iPaaS oder Middleware" wird in der Praxis oft nach Gewohnheit beantwortet: Wer eine Plattform im Haus hat, nimmt die Plattform. Wer entwickeln kann, entwickelt. Beides kann richtig sein und beides kann teuer werden. Dieser Beitrag beschreibt, woran Sie die Entscheidung tatsächlich festmachen sollten.

Die vier Grundmuster

Direkte API-Verbindung. Ihr System A ruft die Schnittstelle von System B auf, oder ein kleiner Dienst tut es im Auftrag beider. Keine zusätzliche Plattform, keine zusätzliche Lizenz. Der Weg ist kurz und gut nachvollziehbar.

Integrationsplattform (iPaaS). Ein Anbieterdienst stellt fertige Konnektoren für gängige Systeme bereit, dazu eine visuelle Oberfläche, in der Abläufe zusammengesteckt werden. Sie kaufen Geschwindigkeit im Aufbau und Standardlösungen für wiederkehrende Probleme wie Wiederholung nach Fehlern.

Eigene Middleware, also eine Integrationsschicht. Ein eigener Dienst nimmt Daten entgegen, prüft sie, übersetzt sie in das Zielformat, legt sie bei Bedarf in eine Warteschlange und stellt sie zu. Sie haben volle Kontrolle über Logik, Protokollierung und Fehlerverhalten.

Batch- oder dateibasierter Abgleich. Daten werden in Intervallen exportiert, übertragen und importiert. Wirkt aus der Zeit gefallen, ist aber bei Systemen ohne brauchbare Schnittstelle oder bei sehr großen Datenmengen häufig die stabilste Variante.

Ein fünftes Muster taucht in größeren Landschaften auf: ereignisgetriebene Architektur, bei der Systeme Ereignisse veröffentlichen und andere darauf reagieren. Für den typischen Mittelständler mit zwei bis fünf Systemen ist das meist Überbau, für Landschaften mit vielen Abnehmern derselben Information aber sinnvoll.

Die fünf Fragen, die die Entscheidung tragen

1. Wie viele Systeme und Verbindungen sind beteiligt?

Bei zwei Systemen und einer Handvoll Datenobjekte ist eine direkte Verbindung fast immer der ehrlichste Weg. Ab etwa vier bis fünf Systemen kippt das Bild: Punkt-zu-Punkt-Verbindungen wachsen schnell an, und jede einzelne muss gepflegt, überwacht und beim Anbieterwechsel angefasst werden. Dann lohnt sich eine zentrale Stelle, egal ob als Plattform oder als eigene Schicht.

2. Wie hoch ist das Volumen, und wie preist der Anbieter?

Integrationsplattformen rechnen häufig nach Vorgängen, Aufgaben oder Ausführungen ab. Bei einigen hundert Vorgängen im Monat ist das unerheblich. Bei hunderttausenden Zeilen aus einem Onlineshop verändert dasselbe Preismodell die Wirtschaftlichkeit vollständig. Rechnen Sie deshalb nicht mit dem heutigen Volumen, sondern mit dem Volumen, das Sie in zwei Jahren erwarten, und prüfen Sie, ab welchem Punkt die Kurve steil wird.

3. Wie komplex ist die Übersetzungslogik?

Solange Felder eins zu eins zugeordnet werden, spielt eine Plattform ihre Stärken aus. Sobald Regeln dazukommen, wird es unübersichtlich: Preisstaffeln, Sonderfälle je Kundengruppe, Zusammenführen mehrerer Quellen zu einem Datensatz, Nachschlagen in einer dritten Tabelle. Solche Logik lässt sich in visuellen Werkzeugen zwar abbilden, aber schlecht lesen, schlecht testen und schlecht versionieren. Ab einem gewissen Punkt ist geschriebener, dokumentierter Code besser wartbar als ein Diagramm mit sechzig Kästchen.

4. Wie viel darf schiefgehen?

Diese Frage entscheidet mehr als jede andere. Fragen Sie für jeden Ablauf: Was passiert, wenn die Übertragung heute für vier Stunden ausfällt? Bei einem Kennzahlenbericht ist die Antwort meist ein Achselzucken. Bei einer Auftragsübergabe bedeutet sie verlorene Ware, verärgerte Kunden oder eine falsche Rechnung.

Je geringer die Fehlertoleranz, desto mehr brauchen Sie:

• Warteschlange, damit nichts verloren geht, wenn das Zielsystem nicht antwortet
• Wiederholungslogik mit wachsenden Abständen, damit ein überlastetes System nicht zusätzlich bedrängt wird
• Idempotenz, also eindeutige Schlüssel, damit eine wiederholte Übertragung keinen zweiten Auftrag erzeugt
• Toter Briefkasten, in dem hängengebliebene Vorgänge landen und sichtbar bleiben
• Benachrichtigung, damit ein Mensch von der Störung erfährt, bevor der Kunde anruft

Plattformen bringen einiges davon mit. Ob es für Ihren Fall ausreicht, sollten Sie prüfen und nicht annehmen.

5. Wer betreibt das Ganze in zwei Jahren?

Jede Integration ist ein dauerhaftes Bauwerk. Schnittstellen ändern sich, Zugangsschlüssel laufen ab, Grenzwerte werden angepasst, Anbieter stellen Versionen ab. Fragen Sie deshalb vorab: Wer bemerkt eine Änderung, wer passt an, und wie schnell? Wenn es dafür keine Antwort gibt, ist die einfachste Lösung die richtige, unabhängig von ihrer technischen Eleganz.

Was Sie über die technischen Grundbegriffe wissen sollten

Für die Entscheidung müssen Sie nicht entwickeln können, aber vier Begriffe sollten Sie einordnen können, weil sie in jedem Angebot auftauchen.

Authentifizierung. Jede Schnittstelle will wissen, wer da anfragt. Das reicht von einfachen Schlüsseln bis zu Verfahren mit ablaufenden Zugangstoken. Wichtig für Sie: Wo liegen diese Zugangsdaten, wer darf sie sehen, und was passiert, wenn sie ablaufen? Abgelaufene Zugänge sind die häufigste Ursache stiller Ausfälle.

Grenzwerte, oft Rate Limits genannt. Fast jede Schnittstelle begrenzt, wie viele Anfragen pro Zeiteinheit erlaubt sind. Wer das ignoriert, bekommt beim ersten größeren Import Ablehnungen und im schlimmsten Fall eine temporäre Sperre. Eine tragfähige Integration kennt die Grenzwerte des Zielsystems und hält sich daran, statt sie auszureizen.

Wiederholung und Idempotenz. Netzwerke sind unzuverlässig. Eine Antwort kann verloren gehen, obwohl der Vorgang beim Empfänger angekommen ist. Wird dann wiederholt, entsteht ohne eindeutigen Schlüssel ein Duplikat. Deshalb gehört zu jeder Übertragung eine Kennung, an der das Zielsystem erkennt: Das kenne ich schon.

Ereignis statt Abfrage. Manche Systeme melden Änderungen aktiv, per Webhook. Andere müssen regelmäßig gefragt werden. Aktive Meldungen sind schneller und sparsamer, brauchen aber eine erreichbare Gegenstelle und einen Plan für den Fall, dass eine Meldung verloren geht.

Diese vier Punkte sind der Kern dessen, was eine belastbare von einer improvisierten Verbindung unterscheidet. Ausführlicher beschrieben ist das auf der Seite zur API-Integration.

Eine ehrliche Gegenüberstellung

Direkte API-Verbindung passt bei zwei Systemen, klarer Logik und überschaubarem Volumen. Vorteil: wenig bewegliche Teile, keine zusätzliche Abhängigkeit. Nachteil: wächst schlecht in die Breite.

iPaaS passt, wenn gängige Systeme verbunden werden sollen, die Logik nah am Standard liegt und Geschwindigkeit zählt. Vorteil: schnell produktiv, viel Fertiges. Nachteil: laufende Kosten am Volumen, begrenzte Tiefe bei Sonderlogik, Abhängigkeit vom Anbieter und dessen Preisänderungen.

Eigene Middleware passt bei komplexer Logik, hohen Volumina, strengen Anforderungen an Nachvollziehbarkeit oder wenn Sie Abhängigkeiten bewusst klein halten wollen. Vorteil: volle Kontrolle, keine mengenabhängigen Lizenzkosten. Nachteil: höherer Aufbauaufwand und die Pflicht, den Betrieb ernst zu nehmen.

Batch passt, wenn ein System keine brauchbare Schnittstelle hat oder große Datenmengen zu festen Zeiten bewegt werden. Vorteil: robust und einfach zu prüfen. Nachteil: nie aktuell, und Fehler fallen erst im nächsten Lauf auf.

Ein Hinweis aus der Praxis: Diese Muster schließen sich nicht aus. Es ist völlig legitim, den Auftragsfluss über eine eigene Schicht zu führen, weil dort nichts verloren gehen darf, und gleichzeitig eine Plattform für unkritische Randabläufe zu nutzen.

Wie Sie zu einer belastbaren Entscheidung kommen

1. Prozesse auflisten, die überhaupt eine Verbindung brauchen, und je Prozess Richtung und Häufigkeit notieren.
2. Fehlertoleranz je Prozess einstufen: unkritisch, ärgerlich, geschäftskritisch.
3. Schnittstellen prüfen: Existiert eine? Was kann sie, welche Grenzwerte, welche Authentifizierung, welche Datenmodelle? Diese Prüfung ist der Punkt, an dem sich Annahmen von Tatsachen trennen.
4. Volumen hochrechnen und gegen Preismodelle halten.
5. Betriebsmodell festlegen, bevor gebaut wird: Wer überwacht, wer reagiert, in welcher Zeit?
6. Erst dann Architektur entscheiden und mit einem Ablauf beginnen, der end-to-end produktiv geht.

Diese Reihenfolge klingt selbstverständlich und wird trotzdem regelmäßig umgedreht. Wenn die Werkzeugentscheidung vor der Prozessklärung steht, wird der Prozess an das Werkzeug angepasst, und das merkt man dem Ergebnis an.

Häufige Fragen

Ist eine Integrationsplattform nicht immer günstiger als Eigenentwicklung?

Beim Aufbau häufig ja, im Betrieb nicht zwangsläufig. Entscheidend sind Volumen und Preismodell. Rechnen Sie beide Varianten über einen Zeitraum von drei Jahren durch, inklusive Anpassungen und Betrieb, nicht nur bis zum Go-live.

Was ist mit No-Code-Werkzeugen?

Sie sind ein legitimer Teil der Werkzeugkiste, besonders für einfache, unkritische Abläufe und für schnelle Erprobung. Für Abläufe, an denen Umsatz oder Buchhaltung hängen, sollten Sie prüfen, ob Nachvollziehbarkeit, Fehlerbehandlung und Versionierung dem gerecht werden.

Wie vermeide ich Abhängigkeit von einem Anbieter?

Drei Hebel: Dokumentieren Sie die fachliche Logik unabhängig vom Werkzeug, halten Sie Zugänge und Hosting in Ihren eigenen Konten, und achten Sie darauf, dass Konfiguration und Code exportierbar sind. Dann ist ein Wechsel Arbeit, aber kein Neuanfang.

Wir haben eine bestehende Verbindung, die ständig ausfällt. Neu bauen?

Nicht zwingend. Häufig fehlen nur Warteschlange, Wiederholung und Überwachung. Eine Bestandsaufnahme der tatsächlichen Fehlerbilder ist der sinnvollere erste Schritt als ein Neubau aus dem Bauch heraus.

Wie Sie zu einer tragfähigen Entscheidung kommen

Die Wahl zwischen API, iPaaS und Middleware ist keine Glaubensfrage. Sie ergibt sich aus Volumen, Logik, Fehlertoleranz und der Frage, wer das Ergebnis später betreut. Wer diese vier Punkte klärt, kommt fast immer zu einer Antwort, die sich auch in zwei Jahren noch verteidigen lässt.

Wie ein Integrationsvorhaben von der Analyse bis zum Betrieb abläuft, lesen Sie auf der Übersicht zur Software-Implementierung. Wenn Sie einen konkreten Prozess im Kopf haben, klären wir im Erstgespräch, welcher Weg dafür trägt — lassen Sie Ihre Systemlandschaft einordnen.