iPaaS oder Eigenentwicklung: Middleware richtig wählen

Build-or-Buy ist eine der ältesten Fragen der IT und im Integrationsumfeld besonders folgenreich. Buy heißt hier: Eine Integrationsplattform als Service (iPaaS) stellt fertige Konnektoren für gängige Systeme bereit, dazu grafische Mapping-Werkzeuge, Ablaufsteuerung, Protokollierung und Betrieb. Sie konfigurieren, statt zu programmieren, und zahlen dafür eine laufende Gebühr. Build heißt: Eine eigene Middleware wird entwickelt, die genau Ihre Datenmodelle, Sonderfälle und Prozesse abbildet -- als Code, der Ihnen gehört und den Sie beliebig verändern dürfen.

Keine der beiden Antworten ist grundsätzlich richtig. Die Grundentscheidung hängt davon ab, wie viele Systeme zusammenspielen, wie eigentümlich Ihre Prozesse sind, wie wichtig Datenhoheit ist und wie schnell die erste Version stehen muss. Ein Handelsunternehmen mit Standardabläufen fährt mit einem Konnektor-Baukasten oft schneller; ein Betrieb mit tiefer Fertigungslogik, komplexen Preisregeln oder regulatorischen Anforderungen braucht häufig maßgeschneiderte Middleware. Weil sich Systemlandschaften mit der Zeit verändern, lohnt es, die Entscheidung nicht nur für heute, sondern für die nächsten Jahre zu treffen. Wer etwa früh eine Kundendaten-Synchronisation ins CRM plant, sollte diesen Fluss von Beginn an mitdenken.

Eine maßgeschneiderte Middleware lohnt sich dort, wo der Standard nicht ausreicht. Das ist der Fall, wenn Ihre Geschäftslogik eigentümlich ist -- etwa bei kundenindividuellen Preisen, komplexen Stücklisten, Chargen- und Seriennummern oder mehrstufigen Genehmigungen. Auch wenn Datenhoheit aus rechtlichen oder strategischen Gründen entscheidend ist, spricht viel für eine eigene Lösung, weil Daten und Verarbeitung vollständig in Ihrer Umgebung bleiben. Und schließlich dann, wenn Sie ein System anbinden müssen, für das kein fertiger Konnektor existiert.

Eigenentwicklung heißt nicht, jedes Rad neu zu erfinden. Bewährte offene Bausteine für Warteschlangen, Ereignisverarbeitung und Protokollierung bilden das Fundament, auf dem die individuellen Konnektoren und Transformationen aufsetzen. Der Aufwand liegt höher als beim Zusammenklicken eines Baukastens, dafür bildet die Lösung Ihre Prozesse exakt ab und lässt sich beliebig weiterentwickeln. Aus über 50 Integrationsprojekten (Projekterfahrung) zeigt sich: Das dritte anzubindende System kommt meist früher als geplant, weshalb sich eine tragfähige Architektur früh auszahlt.

Datenhoheit entscheidet mit über die Architektur. Bei einer Eigenentwicklung bleiben Nutzdaten und Verarbeitungslogik in Ihrer Infrastruktur; Sie bestimmen den Speicherort, die Aufbewahrung und die Zugriffe. Bei iPaaS passieren die Daten die Plattform eines Anbieters -- häufig personenbezogene Daten aus Bestellungen, Kunden und Rechnungen. Der Verarbeitungsort, die Auftragsverarbeitung und mögliche Drittlandtransfers gehören deshalb vor der Auswahl geprüft, nicht danach. Wer etwa Kundendaten sauber in SAP und ein CRM spiegelt, sollte den Weg dieser Daten lückenlos kennen.

Ein pragmatischer Umgang mit Lock-in besteht darin, ihn bewusst zu begrenzen statt zu ignorieren. Bei iPaaS heißt das: Exportwege für Konfiguration und Verlaufsdaten sichern, Datenmodelle dokumentieren und die Abhängigkeit von einzelnen proprietären Funktionen gering halten. Bei Eigenentwicklung heißt es: Standards statt Sonderwege verwenden, Konnektoren modular schneiden und die Lösung so dokumentieren, dass sie auch in zwei Jahren und von einem anderen Team verständlich bleibt. Beide Male gilt: Wer den Ausstieg mitdenkt, verhandelt und arbeitet freier.

In der Praxis ist die Entscheidung selten schwarz-weiß. Viele tragfähige Integrationsprojekte kombinieren beide Wege: Standardisierte, unkritische Datenflüsse laufen über iPaaS-Konnektoren, während geschäftskritische oder eigentümliche Prozesse als maßgeschneiderte Module entstehen. So verbinden Sie die kurze Time-to-Live des Baukastens mit der Passgenauigkeit und Datenhoheit der Eigenentwicklung. Die Kunst liegt darin, jeden Datenfluss dem richtigen Werkzeug zuzuordnen.

Die Zuordnung folgt drei Kriterien: Wie eigentümlich ist der Prozess, wie sensibel sind die Daten, und wie oft ändert sich die Schnittstelle? Standardnahe, unkritische Flüsse mit stabiler Schnittstelle sind gute Kandidaten für den Baukasten. Eigentümliche, sensible oder sich häufig ändernde Flüsse sind besser als eigenes Modul aufgehoben. Diese Trennlinie lässt sich zudem verschieben: Was heute als iPaaS-Fluss startet, kann später in eine eigene Komponente wandern, wenn Volumen, Kosten oder Anforderungen es nahelegen.