Kaum ein Unternehmen arbeitet noch völlig eigenständig. Die Produktentwicklung erfolgt gemeinsam mit Zulieferern, die Auftragsabwicklung läuft über Logistikpartner, Servicedaten fließen von Händlern zurück, und die Kunden erwarten, all diese Informationen an einem Ort zu finden. Dieser Wandel – der mal als „erweitertes Unternehmen“, mal als „Zulieferer-Ökosysteme“ oder „vernetzte Betriebsabläufe“ bezeichnet wird – hat eine ganz konkrete Folge: Ihr Informationssystem muss sich öffnen.
Früher dienten Anwendungen dazu, Inhalte abzurufen. Heute sind sie der wichtigste Kanal, über den ein Unternehmen mit seinen Kunden, Mitarbeitern, Lieferanten und Partnern kommuniziert. Die Öffnung des Systems ist nicht mehr nur eine Entscheidung der IT-Abteilung, sondern eine Voraussetzung für die Geschäftstätigkeit.
Die meisten Unternehmen erkennen das an. Was ihnen jedoch Schwierigkeiten bereitet, ist die Entscheidung, wie sie sich öffnen sollen. Stabilität, Echtzeitverhalten, Skalierbarkeit, Standardisierung, Sicherheit, Governance, Überwachung – jede dieser Entscheidungen hängt davon ab, wie das Unternehmen wachsen will. Und zwei Technologien stehen im Mittelpunkt dieser Entscheidung: der Enterprise Service Bus und das API-Management.
ESB vs. API-Management: zwei Hälften einer Integrationsstrategie
Der Vergleich wird häufiger als eigentlich gerechtfertigt als Wettstreit dargestellt. ESB und API-Management sind keine konkurrierenden Antworten auf dieselbe Frage. Sie beantworten zwei unterschiedliche Fragen, die zufällig nebeneinander stehen:
- Wie kommunizieren die Dienste in meinem Informationssystem miteinander? Das ist die Aufgabe des ESB.
- Wie kann ich steuern, welche Daten ich nach außen hin offenlege? Das ist die Aufgabe des API-Managements.
Die Funktionen überschneiden sich so stark, dass man die beiden leicht verwechseln kann – beide leiten Nachrichten weiter, beide wandeln Nutzdaten um, beide protokollieren den Datenverkehr. Sie basieren jedoch auf unterschiedlichen Schwerpunkten, und wenn man das eine durch das andere ersetzt, entsteht in der Regel eine Architektur, die keine der beiden Aufgaben gut erfüllt.
Was ein ESB eigentlich macht
Ein Enterprise Service Bus ist der Mechanismus, der den Datenaustausch zwischen Quellen und Zielen in Ihrer gesamten Infrastruktur sichert und standardisiert. Sein Kern ist der Anwendungsbus: ein einziger Kanal, über den Anwendungen Daten veröffentlichen und abonnieren, anstatt sich direkt miteinander zu verbinden.
Der Wert liegt eher in der Struktur als in der Funktionalität. Ohne einen Bus bedeutet die Verbindung von n Systemen, dass Punkt-zu-Punkt-Verbindungen aufrechterhalten werden müssen, deren Anzahl mit dem Wachstum der Infrastruktur zunimmt. Mit einem Bus ist jedes System nur einmal angeschlossen. Formatkonvertierung, Routing-Regeln, Fehlerbehandlung und Wiederholungslogik sind an einem Ort zusammengefasst – und das ist auch der einzige Ort, an dem Sie nachsehen müssen, wenn etwas nicht funktioniert.
Falls Sie noch dabei sind, die zugrunde liegende Architektur abzuwägen, finden Sie in unserem Vergleich von ESB, Middleware und Microservices eine ausführlichere Darstellung der Vor- und Nachteile.
Was API-Management bietet
Das API-Management – APIM – regelt, wie APIs veröffentlicht, veröffentlicht, gesichert und überwacht werden. Es deckt den gesamten Lebenszyklus ab: die Konzeption einer Schnittstelle, deren Versionierung, die Steuerung, wer sie wie oft aufrufen darf, die Nachverfolgung der Nutzung sowie die Stilllegung, wenn der Zeitpunkt gekommen ist. Die meisten Plattformen verfügen über ein Entwicklerportal, über das interne wie externe Nutzer erkennen können, was verfügbar ist, und einsehen können, wie es genutzt wird.
Während es beim ESB um zuverlässige Datenübertragung geht, steht bei APIM die kontrollierte Offenlegung im Vordergrund. Es handelt sich um die Vertragsebene zwischen einem Dienstanbieter und einem Dienstnutzer – und um den Ort, an dem API-Governance-Richtlinien tatsächlich durchgesetzt und nicht nur dokumentiert werden.
Warum die beiden zusammengehören
Ein „Bus“ ohne API-Management kann Daten zwar effizient übertragen, bietet jedoch keinen einheitlichen Überblick darüber, wer außerhalb des Unternehmens welche Daten nutzen darf. API-Management ohne einen „Bus“ führt häufig dazu, dass anfällige, eng gekoppelte Endpunkte offengelegt werden, die bei jeder Änderung eines Backend-Systems ausfallen.
In Kombination übernimmt der ESB die interne Orchestrierung und schirmt die Nutzer von der Komplexität des Backends ab, während APIM die Grenzen definiert und überwacht. Gleiche Integrationsstrategie, zwei Ebenen.
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.
Acht Fragen, die Ihre Integrationsstrategie bestimmen
Sobald die Rollen klar sind, beginnt die eigentliche Arbeit: die Entscheidung, wie Ihre Integrationsstrategie aussehen soll. Hier gibt es keine Vorlage. Die richtige Antwort hängt davon ab, wie zentral der Datenaustausch für Ihr Geschäftsmodell ist und wie sich der Austausch mit Ihrem Ökosystem Ihrer Erwartung nach entwickeln wird. Geschäftliche Anforderungen stehen an erster Stelle; technische Einschränkungen folgen danach.
Diese acht Fragen bilden einen brauchbaren Ausgangspunkt.
1. Was geben Sie preis, wem gegenüber und warum?
Beginnen Sie mit dem Ziel, nicht mit dem Endpunkt. Ein Produktkatalog für Vertriebspartner, ein Service zur Abfrage des Schadensstatus für Versicherungsnehmer und eine Partner-API zur Preisermittlung stellen jeweils ganz unterschiedliche Anforderungen an Sicherheit, Verfügbarkeit und Versionsverwaltung.
2. Welche Anforderungen stellt Ihr Geschäftsmodell an die eingehenden und ausgehenden Datenströme?
Ordnen Sie die Abläufe dem Geschäftsmodell zu. Welche Dienste muss das Unternehmen tatsächlich anbieten oder in Anspruch nehmen, und in welchem Umfang? Hier stellen Sie fest, dass ein Dienst, den alle für nebensächlich hielten, die Hälfte Ihres Transaktionsaufkommens ausmacht.
3. Wie viel Sicherheit und Kontrolle sind erforderlich?
Authentifizierung, Autorisierung, Ratenbegrenzung, Prüfpfade, Datenaufbewahrungsort. Das Niveau richtet sich nach der Sensibilität der Daten und den rechtlichen Rahmenbedingungen, nicht danach, was die eingesetzten Tools am bequemsten machen.
4. Wie schnell muss die Integration skalierbar sein?
Zehn Partner im ersten Jahr und vierhundert im dritten Jahr – das ist eine grundlegend andere Architektur als eine stabile Gruppe von einem Dutzend. Fragen Sie nach dem erwarteten Durchsatz pro Dienst, nicht nur in der Summe.
5. Welchen Detaillierungsgrad wünschen Sie sich beim Öffnen von Diensten?
Wird jeder Nutzer denselben Zugang erhalten, oder wird es von Anfang an verschiedene Stufen geben – Premium-Kunden mit umfangreicheren Daten oder höheren Limits, alle anderen mit einem eingeschränkten Angebot? Die nachträgliche Einführung in ein einheitliches Modell ohne Stufen ist mühsam.
6. Wie ausgereift ist Ihr Ökosystem?
Ihre Strategie ist nur so skalierbar wie die Fähigkeit Ihrer Partner, Schritt zu halten. Wenn Lieferanten die Art und Weise, wie sie Daten bereitstellen, standardisieren müssen, bevor alles durchgängig funktioniert, muss dieser Aufwand in den Plan und in den Zeitplan einbezogen werden.
7. Müssen die Abläufe im Voraus mit den Partnern abgestimmt werden?
Bei einfachen Abläufen – wie beispielsweise der Veröffentlichung von Katalogdaten – ist dies in der Regel nicht der Fall. Bei allem, was einen mehrstufigen Austausch, einen gemeinsamen Status oder eine Verpflichtung beider Seiten beinhaltet, muss die Prozessdefinition an erster Stelle stehen. An dieser Stelle verwandelt sich ein Integrationsprojekt still und leise in ein Geschäftsprozessmanagement-Projekt.
8. Um welche Art der Datenweitergabe handelt es sich hierbei?
Handelt es sich bei der Beziehung um eine Partnerschaft, eine kommerzielle Dienstleistung oder ein kostenloses Service? Bei kostenpflichtigen APIs sind von Anfang an Nutzungsmessung, Abrechnungsintegration und Service-Levels erforderlich. Auch bei kostenlosen APIs sind Interoperabilitätsgarantien erforderlich, allerdings ist das Governance-Modell weniger aufwendig.
Von der Strategie zur Plattform: Worauf Sie achten sollten
Sobald die Strategie festgehalten ist, stellt sich die Frage, welche Technologie sie umsetzen kann. Einige Kriterien sind wichtiger als Funktionslisten.
Umfangreiche Anbindungsmöglichkeiten. Jedes Altsystem, das Sie nicht anbinden können, erfordert eine manuelle Umgehungslösung. Das X4 BPMS wird mit mehr als 200 vorgefertigten Adaptern und einem integrierten ESB ausgeliefert, wodurch der Großteil der Arbeit an maßgeschneiderten Konnektoren entfällt, die die Integrationsbudgets in die Höhe treiben.
Prozesse und Integration aus einer Hand. Viele Unternehmen betreiben ihren Bus und ihre Prozess-Engine als separate Systemlandschaften und verbringen dann Jahre damit, diese aufeinander abzustimmen. X4 BPMS modelliert Prozesse in BPMN 2.0 und führt sie auf derselben Plattform aus, über die auch die Daten übertragen werden. So werden ein für einen Partner bereitgestellter Service und der dahinterstehende Prozess als eine Einheit verwaltet.
Governance nicht nur bei der Konzeption, sondern auch bei der Ausführung. Phoenix erweitert dieses Bild um die Bereiche Unternehmensintegration und Ausführungs-Governance, einschließlich des API-Lebenszyklusmanagements – der Ebene, die Aufschluss darüber gibt, welche Schnittstellen existieren, wer sie nutzt und ob sie sich noch wie vorgesehen verhalten.
Transparenz. Integrationsfehler sind vor allem deshalb kostspielig, weil sie erst spät entdeckt werden. Der Process Monitor bietet den Betriebsteams einen Echtzeit-Überblick über laufende Datenaustausche, anstatt dass sie diese nachträglich anhand von Protokolldateien rekonstruieren müssen.
In unserem Überblick über nahtlose Integration und im Leitfaden zur Auswahl einer Datenintegrationsplattform gehen wir näher auf die Auswahlkriterien ein.
Drei Fehler, die die Einführung von ESB und APIM zum Scheitern bringen
Es als reine Tool-Entscheidung behandeln. Die Auswahl einer Plattform, bevor geklärt ist, was das Unternehmen bereitstellen möchte, führt zu einer kostspieligen, technisch ausgefeilten Lösung für die falsche Frage.
Backend-Systeme direkt offenlegen. Durch die Veröffentlichung einer API, die eine Datenbanktabelle abbildet, wird jeder Nutzer an Ihr internes Schema gebunden. Die nächste Migration wird dann zu einer Verhandlung mit allen, die diese API jemals aufgerufen haben.
Governance auf später verschieben. Konventionen zur Versionsverwaltung, Richtlinien zur Ausmusterung, Zuständigkeiten und Sicherheitsstandards lassen sich bei fünf APIs kostengünstig festlegen, bei achtzig APIs ist ihre Durchsetzung jedoch sehr aufwendig. Genau hier zeigt sich auch der Nutzen der Unternehmensarchitektur.
Die Integrationsstrategie sollte sich an den Unternehmenszielen orientieren
Aus geschäftlicher Sicht ist die Öffnung des Informationssystems eine echte Transformation. Aus IT-Sicht handelt es sich um etwas Bescheideneres und Präziseres: die Ausweitung eines bereits intern bestehenden serviceorientierten Ansatzes auf das gesamte Ökosystem. Das zugrunde liegende Prinzip hat sich seit zwanzig Jahren nicht geändert – man soll aufhören, Punkt-zu-Punkt-Verbindungen zwischen Anwendungen anzuhäufen.
Im Laufe des Prozesses müssen technische Entscheidungen getroffen werden. Fragen zur API-Versionierung, zur Token-Strategie, zur Platzierung in der DMZ und zur Gateway-Topologie müssen geklärt werden. Doch dies sind Entscheidungen, die erst später anstehen. Ausschlaggebend für Ihre Integrations- und Offenheitsstrategie sollte die zukünftige Ausrichtung des Unternehmens sein, und die Frage „ESB oder API-Management“ klärt sich von selbst, sobald dies klar ist: Sie benötigen beides, wobei jedes die Aufgaben übernimmt, für die es konzipiert wurde.
Édouard Cante ist als Chief Product Officer für die strategische Ausrichtung und Weiterentwicklung des Produktportfolios von SoftProject verantwortlich. Mit seinem ausgeprägten Marktverständnis und seiner hohen Innovationskraft treibt er kundenorientierte Lösungen voran und sichert die langfristige Wettbewerbsfähigkeit des Unternehmens.
Häufig gestellte Fragen zur einheitlichen Kundensicht
Was ist der Unterschied zwischen einem ESB und API-Management?
Ein ESB koordiniert und sichert den Datenaustausch zwischen den Systemen innerhalb Ihres Informationssystems und fungiert dabei als zentraler Anwendungsbus anstelle von Punkt-zu-Punkt-Verbindungen. Das API-Management regelt, wie APIs den Nutzern zur Verfügung gestellt werden – Veröffentlichung, Versionierung, Zugriffskontrolle, Überwachung und Stilllegung. Der ESB übernimmt den internen Datenaustausch; das API-Management sorgt für die kontrollierte externe Bereitstellung.
Kann API-Management einen ESB ersetzen?
Nein. Ein API-Gateway kann Aufrufe weiterleiten und sichern, ist jedoch nicht dafür ausgelegt, komplexe interne Abläufe zu koordinieren, Daten zwischen älteren Formaten zu konvertieren oder lang andauernde, zustandsbehaftete Datenaustausche zu verwalten. Der Ersatz eines Busses durch ein Gateway verlagert diese Logik in der Regel in die Anwendungen selbst – genau das ist das Kopplungsproblem, für dessen Lösung der Bus ursprünglich vorgesehen war.
Brauchen wir sowohl einen ESB als auch ein API-Management?
Die meisten Organisationen, die Dienste über ihre eigenen Grenzen hinaus bereitstellen, tun dies. Wenn Ihre Integration vollständig intern erfolgt, reicht möglicherweise ein Bus allein aus. Sobald Partner, Kunden oder externe Entwickler Ihre Dienste nutzen, benötigen Sie eine Governance-Ebene, die den Vertrag an der Grenze definiert und durchsetzt.
Wo sollte eine ESB-APIM-Strategie ansetzen?
Es geht um das Geschäftsmodell, nicht um die Architektur. Entscheiden Sie, was Sie offenlegen möchten, für wen und welche geschäftliche Beziehung dahintersteckt. Die technischen Anforderungen – Sicherheitsstufe, Skalierbarkeit, Granularität, Versionierung – ergeben sich aus diesen Antworten und nicht umgekehrt.
Was ist API-Governance?
Unter API-Governance versteht man die Gesamtheit der Regeln und Prozesse, die dafür sorgen, dass eine API-Landschaft auch bei zunehmendem Umfang einheitlich bleibt: Namens- und Versionskonventionen, Sicherheitsstandards, Zuständigkeiten, Dokumentationsanforderungen und Richtlinien zur Auslaufregelung. API-Management-Plattformen sind die Mechanismen, über die diese Regeln durchgesetzt werden.
