ETL, ESB, EAI, EDI, SOA, APIM. Die Abkürzungsflut rund um den Datentransfer ist groß, und viele dieser Begriffe beschreiben Dinge, die sich überschneiden. Manche beziehen sich auf ähnliche Konzepte, andere fügen sich nahtlos zusammen, wieder andere überschneiden sich nur teilweise. Das macht es leicht, eine technische Abkürzung zu einer Kaufentscheidung zu machen.
In diesem Interview erläutert Édouard Cante, Chief Product Officer bei SoftProject, seine Sicht auf den Unterschied zwischen ETL und ESB – und welche Konsequenzen dies seiner Meinung nach für Unternehmen hat. Ist dies angesichts der tatsächlichen Anforderungen der Unternehmen überhaupt die richtige Diskussion?
In einem früheren Artikel sind wir zu dem Schluss gekommen, dass ESB und API-Management zwei Seiten derselben Medaille sind. Gilt das auch für ESB und ETL?
Édouard Cante: Nein, aber ihre jeweiligen Anwendungsbereiche überschneiden sich teilweise: Beide beziehen sich auf den Datentransport und die Datentransformation innerhalb eines Informationssystems. Angesichts ihrer Beschaffenheit könnte man zu dem Schluss kommen, dass je nach Art des Datenflusses eine Entscheidung getroffen werden muss. Dies war beiESB und APIM nicht der Fall, da sie sich gegenseitig ergänzen.
Der historische Unterschied liegt in erster Linie in der architektonischen Dimension. Die spezifischen Merkmale von ETL und ESB sind für Laien im Bereich Datenmanagement nicht ohne Weiteres erkennbar. Zudem hat sich die Landschaft in den letzten Jahren verändert.
Historisch gesehen – und vielleicht etwas vereinfacht ausgedrückt – eignet sich ETL besonders für die Verarbeitung großer Datenmengen, bei denen die Leistung im Vordergrund steht, die Anzahl der Datenaustausche jedoch nicht allzu hoch ist. ETL verarbeitet Daten als Ganzes, also in großen Mengen. Wenn Sie beispielsweise den Gesamtumsatz nach Kunden aufgeschlüsselt haben möchten, aggregiert ETL alle Zeilen und wendet einen Prozess auf alle gleichzeitig an. Dieser setbasierte Ansatz wird insbesondere in den Bereichen Business Intelligence und Data Warehousing eingesetzt. Im Gegensatz dazu ist ESB besonders effektiv bei der Verarbeitung einer großen Anzahl hochfrequenter Datenaustausche mit jeweils begrenztem Datenvolumen, die zudem einen algorithmischen Aspekt beinhalten. Es spielt zweifellos eine Rolle bei der Aufhebung von Datensilos und der Unterstützung einer serviceorientierten Architektur, indem es als sicherer Austauschbus über das gesamte Informationssystem hinweg fungiert.
„Um es anhand extremer Beispiele zusammenzufassen: ETL wird verwendet, um Data Warehouses aus Systemen wie ERP und CRM aufzubauen. ESB ist für Unternehmen gedacht, die beispielsweise über eine Schnittstelle Kostenvoranschläge, Aufträge und Kundendaten aus ihrem CRM bereitstellen und anderen Anwendungen ermöglichen möchten, diese Daten über eine Verbindung zum Anwendungsbus abzurufen.“
Édouard Cante, Chief Product Officer bei SoftProject
Ich bin jedoch fest davon überzeugt, dass diese historischen Unterschiede mittlerweile an eine zu starke Vereinfachung grenzen. Kann heute wirklich noch jemand behaupten, er kaufe ein ETL-System ausschließlich für BI-Zwecke?
Warum glauben Sie, dass die Unterscheidung zwischen ESB und ETL nicht mehr zutrifft?
Édouard Cante: Ein weiterer häufig angeführter Unterschied besteht darin, dass ETL eine „Pull“-Technologie ist, die bedarfsgesteuert arbeitet, während ESB eine „Push“-Technologie ist, die Nachrichten generiert. Aber ist es aus Kundensicht überhaupt sinnvoll, nur zu „ziehen“ oder nur zu „schieben“? Wenn ein Unternehmen ein ETL-System implementiert hat und dann „schieben“ muss, lässt sich dies nicht in jede einzelne Anwendung separat integrieren. Das erfordert spezifische Entwicklungen und verdeutlicht das Problem, das dieser Unterscheidung zugrunde liegt.
Zwar war die Trennung von ESB und ETL vor zehn Jahren noch sinnvoll, doch bin ich fest davon überzeugt, dass dies aus geschäftlicher Sicht heute nicht mehr zutrifft. Unterschiedliche Konzepte müssen nicht zwangsläufig unterschiedliche Lösungen nach sich ziehen. Die IT-Abteilung vor die Wahl zu stellen, zwischen zwei verschiedenen Tools zu wählen, je nachdem, ob sie Daten bereitstellen oder mit ihnen interagieren möchte, bedeutet, das Problem aus dem falschen Blickwinkel anzugehen. Die geschäftlichen Anforderungen dürfen nicht durch technische Faktoren eingeschränkt werden.
„Für die meisten Unternehmen ergibt sich kein ROI, wenn sie einerseits ein reines ETL-System und andererseits ein reines ESB-System installieren.“
Édouard Cante, Chief Product Officer bei SoftProject
Schaffen Sie eine vertrauenswürdige Datenbasis, um KI-gestützte Automatisierung und zuverlässige Entscheidungsfindung zu ermöglichen. Laden Sie das Whitepaper herunter und erfahren Sie, wie Sie Data Governance als strategische Kompetenz etablieren – und so skalierbare Automatisierung und KI nutzen können.
Wie hat sich der Markt seit dem Aufkommen der ETL- und ESB-Konzepte entwickelt?
Édouard Cante: Ursprünglich gab es tatsächlich einige technologische Unterschiede. Die Märkte haben sich aufgespalten und getrennt voneinander entwickelt. Einige ETL-Anbieter haben in den Bereich der ESBs vorgedrungen, um Marktanteile zu gewinnen, und umgekehrt. Gleichzeitig haben Marketingargumente die Anforderungen anhand der Technologie in verschiedene Bereiche unterteilt, um die jeweilige Positionierung zu untermauern. ESB-Softwareanbieter haben zudem versucht, sich als Puristen zu profilieren.
„Der Kampf wurde vor allem auf technologischer Ebene geführt und nicht im Hinblick auf die tatsächlichen Anforderungen. Das ist ein Fehler!“
Édouard Cante, Chief Product Officer bei SoftProject
Aus Sicht des Kunden verschwammen dadurch die Grenzen, was zu vereinfachenden Sichtweisen führte. Es herrscht ein weit verbreitetes Missverständnis darüber, was ein ESB ist und welches Potenzial er birgt. Ein ESB wurde manchmal als reiner Datentransporter zusammengefasst, wobei seine Rolle bei der Organisation des gesamten Datenverkehrs völlig außer Acht gelassen wurde – ein Punkt, den wir auch in unserem Artikel über ESB, Middleware und Microservices beleuchten. Das Ergebnis ist, dass viele Projekte aufgrund dieser dogmatischen Ansätze gescheitert sind.
Ich habe ein Beispiel bei einem Einzelhändler gesehen, bei dem das Projekt mit einer theoretischen Darstellung des Datenverkehrs in einem beeindruckenden Diagramm begann, um für eine 100-prozentige ESB-Lösung zu argumentieren. Als das Projekt schließlich anlief, stieß diese extreme Position jedoch auf die harte Realität, dass einige Anwendungen den ESB nicht in Echtzeit nutzen konnten. Das Projekt war ein völliger Misserfolg.
Wenn es also ein Fehler ist, ETL und ESB als sich gegenseitig ausschließend zu betrachten, worin liegt dann das eigentliche Problem?
Édouard Cante: Das eigentliche Problem besteht darin, die Dinge aus einer anderen Perspektive zu betrachten. Gerade weil das Marketing die Wahl zwischen „ESB oder ETL“ forciert, kommt es zu diesen Fehlschlägen! Diese Dichotomie macht in den meisten Fällen keinen Sinn mehr.
Die IT-Abteilung sieht sich gezwungen, zwischen zwei Tools zu wählen, obwohl sie eigentlich beide benötigt: In den meisten Fällen möchte sie Datensilos aufbrechen und die Daten zwischen den verschiedenen Anwendungen im Informationssystem zirkulieren lassen, Business-Intelligence-Analysen erstellen und die Daten in einem MDM-System zentralisieren. Wenn sie jedes Konzept einer anderen Lösung zuordnet, muss sie von den geschäftlichen Anforderungen abweichen, ohne dass dies für sie selbst einen Vorteil bringt.
„Sie sollten vielmehr miteinander verbunden werden. Die Lösung sollte den geschäftlichen Anforderungen entsprechen und nicht irgendeinem technologischen Dogma.“
Édouard Cante, Chief Product Officer bei SoftProject
Diese Herausforderung stellt sich sogar in Anwendergruppen, die zwar über gewisse Kenntnisse im Umgang mit den Tools, nicht jedoch mit den Konzepten verfügen. Die Anwender haben dann nur eine eingeschränkte Sicht auf das Datenflussmanagement als solches. Erst durch das Verständnis der Konzepte können die Anwender ihre Kenntnisse vertiefen und verschiedene Tools leichter anwenden.
Wenn es nicht um die Frage „ETL oder ESB“ geht, welche Fragen sollten dann gestellt werden, um Systeme erfolgreich neu zu gestalten?
Édouard Cante: Zunächst einmal muss man die Realität akzeptieren und sich damit auseinandersetzen. Es ist zwar wichtig, Prozesse zu erfassen und einen Schritt zurückzutreten, um einen Überblick zu gewinnen, doch eine theoretische Sichtweise nach dem Motto „Alles wird SOA“ oder „Alles wird über APIs kommunizieren“ reicht nicht aus. Eine Zukunftsvision ist zwar schön und gut, aber in der Realität müssen Anwendungen schon jetzt in der Lage sein, miteinander zu kommunizieren!
Die IT-Tools müssen sich an die Anforderungen des Unternehmens anpassen – und nicht umgekehrt. Das Ziel ist es, die Zusammenarbeit innerhalb des Unternehmens zu vereinheitlichen.
„Der Streit zwischen ETL und ESB ist sinnlos. Wenn die Anforderungen der IT-Abteilung erfüllt werden sollen, dürfen diese Bereiche nicht länger voneinander getrennt bleiben. Die Unterscheidung liegt nun zwischen Datentransport und -transformation einerseits und der Datennutzung andererseits.“
Édouard Cante, Chief Product Officer bei SoftProject
Wenn es einen Unterschied geben muss, würde ich ihn auf einer anderen Ebene ansiedeln. Wir können unterscheiden Lösungen zur Datentransformationunterscheiden, die einen sicheren Datenverkehr gewährleisten und Daten für leistungsstarke Datenaufbereitungstools für bestimmte Rollen wie Data Scientists, BI usw. bereitstellen.
Die Geschäftsbereiche verfügen somit über hochfunktionale, speziell für sie entwickelte Tools, während der Datenmanager weiterhin die zentrale Rolle bei der Sicherstellung der Qualität, Aufbereitung und Verfügbarkeit der Daten einnimmt. Es sind diese Tools zur Datenaufbereitung, die den Markt verändern. Eigenständige Geschäftsbereiche sind durchaus sinnvoll, ohne dass sie sich in den Datenfluss einmischen müssen. Der Datenverkehr muss die entscheidenden Herausforderungen hinsichtlich Leistung und Rechtmäßigkeit bewältigen.
„Der Datenverkehr sollte als Ganzes betrachtet werden, unabhängig davon, mit welcher Methode die Daten für einen bestimmten geschäftlichen Bedarf übertragen werden. Der eigentliche Unterschied bei den technischen Werkzeugen liegt heute zwischen der Datentransformation und der Datenaufbereitung.“
Édouard Cante, Chief Product Officer bei SoftProject
Ich bin daher fest davon überzeugt, dass es notwendig ist, sowohl die aktuellen Standards zu erfüllen als auch die berühmten Altsysteme zu berücksichtigen, auf denen jedes Informationssystem nach wie vor läuft. Kunden, die ETL-/ESB-/EAI-Lösungen einsetzen, müssen diese mit diesen Anwendungen nutzen – sie haben keine andere Wahl. Als Softwarehersteller müssen wir dies daher ebenfalls tun. Wir müssen die Werkzeugkiste sein , die es den Kunden ermöglicht, Daten zu bewegen.
Was bedeutet das für die SoftProject-Plattform?
Édouard Cante: Wir haben dem Unterschied zwischen ESB und ETL nie große Bedeutung beigemessen, da unsere Kunden ihre Probleme nicht so wahrnehmen. Unser Ziel ist es, mit einer modularen Plattform, die diese Konzepte rund um geschäftliche Herausforderungen und Menschen vereint, eine umfassende Lösung für die Herausforderungen des IS-Re-Engineering anzubieten.
Die Integrationsschicht der SoftProject-Plattform verarbeitet beide Muster auf einer gemeinsamen Grundlage: geplante Massenladungen und ereignisgesteuerte Datenaustausche – mit über 200 vorgefertigten Adaptern, visueller Datentransformation und einem offenen, ausfallsicheren Bus. Wenn diese Daten einen tatsächlichen Prozess steuern sollen, modelliert und führt X4 BPMS diesen in BPMN 2.0 auf derselben Plattform aus, während Phoenix für Governance und Kontrolle über die gesamte Ausführung sorgt.
Auch im Bereich Governance gilt dieselbe Logik. dataspot. deckt das Metadatenmanagement und die Datenherkunft ab, MyDataCatalogue sorgt dafür, dass die Datenbestände auffindbar sind, und das Stammdatenmanagement liefert Ihnen einen einzigen verlässlichen Datensatz statt fünf plausibler – ein Problem, das wir im Abschnitt „Single Customer View“ näher beleuchten.
Es gibt zwar einige Extremfälle, in denen ein Ultra-ETL-System erforderlich ist, doch in der Praxis sind diese selten.
Weiterführende Literatur: Interoperabilität und Datenflüsse · Implementierung eines ESB · Auswahl Ihrer Datenplattform · Whitepaper und Leitfäden
Edouard Cante ist als Chief Product Officer für die strategische Ausrichtung und Weiterentwicklung des Produktportfolios von SoftProject verantwortlich. Mit seinem fundierten Marktverständnis und seiner hohen Innovationskraft treibt er kundenorientierte Lösungen voran und sichert die langfristige Wettbewerbsfähigkeit des Unternehmens.
Häufig gestellte Fragen: ESB vs. ETL:
Was ist der Unterschied zwischen ESB und ETL?
ETL extrahiert Daten, wandelt sie um und lädt sie im Batch-Verfahren – große Datenmengen, eine begrenzte Anzahl geplanter Datenaustausche. Ein Enterprise Service Bus wickelt viele kleine, hochfrequente Datenaustausche zwischen Anwendungen ab, die in der Regel ereignisgesteuert sind und mit einer Verarbeitungslogik verbunden sind. Beide übertragen und wandeln Daten um; sie unterscheiden sich in der Arbeitseinheit, nicht im Zweck.
Brauche ich sowohl ein ESB- als auch ein ETL-Tool?
Sie benötigen beide Funktionen. Ob dafür zwei Produkte erforderlich sind, ist eine andere Frage – und für die meisten Unternehmen lautet die Antwort „nein“. Der Betrieb eines reinen ETL-Systems neben einem reinen ESB-System verursacht in der Regel zusätzliche Lizenzkosten, erfordert zwei unterschiedliche Kompetenzbereiche und führt zu einer Integrationslücke zwischen beiden Systemen, ohne dass dadurch eine Anforderung erfüllt wird, die eine einzelne Plattform nicht abdecken könnte.
Ist ETL „Pull“ und ESB „Push“?
Das ist zwar das Standardverhalten beider Varianten, aber es handelt sich dabei nicht um eine Einschränkung, bei deren Planung man Abstriche machen sollte. Unternehmen, die sich auf ein Muster festlegen, benötigen irgendwann das andere, und die nachträgliche Anpassung von Anwendung zu Anwendung ist genau die individuelle Entwicklung, die eine Integrationsschicht eigentlich vermeiden sollte.
Inwiefern hängt ein ESB mit dem API-Management zusammen?
Sie ergänzen sich eher, als dass sie miteinander konkurrieren. Der ESB koordiniert Dienste innerhalb Ihres Informationssystems; das API-Management regelt, wie diese Dienste nach außen hin bereitgestellt und genutzt werden – Zugriffskontrolle, Nutzungsüberwachung, Versionierung und Standardisierung.
