Was ist IBM Event Automation und wie steuert es Ihre Kafka-Landschaft?

Die meisten Kafka-Landschaften starten sauber und enden unübersichtlich. Aus einer Handvoll Topics werden im Laufe der Zeit Hunderte, verteilt auf unterschiedliche Teams, uneinheitlich dokumentiert oder gar nicht, ohne verlässliche Möglichkeit zu wissen, wer in ein Topic publiziert, wer daraus konsumiert oder ob sich das Schema gefahrlos ändern lässt. Genau dieses Problem löst IBM Event Automation: nicht indem es Kafka ersetzt, sondern indem es eine Governance- und Auffindbarkeits-Schicht darüber legt.

Dieser Leitfaden erklärt, was IBM Event Automation ist, warum Kafka-Governance mit wachsender Grösse notwendig wird, wie die Komponenten der Plattform zusammenspielen und wie sie sich in Confluent oder einen anderen Kafka-kompatiblen Cluster einfügt, den Sie bereits betreiben.

Das Problem: Kafka-Topics ohne Governance

Ein Kafka-Cluster ohne Governance-Schicht wirkt bei den ersten paar Dutzend Topics unproblematisch. Jemand weiss, was in jedem Topic steht, wer es besitzt und wer daraus konsumiert, weil das Team klein genug ist, um dieses Wissen informell zu halten. Das funktioniert nicht mehr, sobald irgendwo zwischen fünfzig und einigen Hundert Topics erreicht sind, was die meisten mittelgrossen und grossen Kafka-Landschaften innerhalb weniger Jahre einholt.

Ab diesem Punkt können neue Consumer nicht mehr erkennen, was ein Topic enthält, ohne nachzufragen. Producer ändern ein Schema, ohne zu wissen, wer dadurch etwas kaputt macht. Doppelte Topics entstehen, weil die Person, die die Daten brauchte, nicht wusste, dass sie bereits an anderer Stelle existierten. Sicherheitsteams können grundlegende Fragen dazu, wer worauf Zugriff hat, nicht beantworten. Nichts davon ist ein Kafka-Problem. Kafka tut genau das, wofür es entwickelt wurde: Datensätze zuverlässig mit niedriger Latenz zu bewegen. Auffindbarkeit, Ownership und Zugriffskontrolle waren nie Teil dieses Designs, und sie entstehen nicht von selbst, wenn die Landschaft wächst.

Der Workaround, zu dem die meisten Teams zuerst greifen, ist eine Tabelle oder eine Wiki-Seite mit Topics und deren Owner. Das funktioniert eine Weile, gerät dann aber innerhalb eines Quartals hinter den Cluster zurück, weil nichts erzwingt, dass es mit dem, was tatsächlich läuft, synchron bleibt. Bis jemand bemerkt, dass die Dokumentation falsch ist, ist sie es meist schon seit Monaten, und das Team hat leise aufgehört, ihr zu vertrauen. Damit ist die Landschaft wieder am Ausgangspunkt: stillschweigendes Wissen, gehalten von wem auch immer am längsten dabei ist.

Was ist IBM Event Automation?

IBM Event Automation ist IBMs Plattform für die Verwaltung einer ereignisgesteuerten Landschaft auf Basis von Kafka. Sie setzt auf Kafka auf, statt es zu ersetzen, und ergänzt Governance-, Katalog- und Verarbeitungsfunktionen, die reines Kafka nicht bietet. Die Plattform bringt die Disziplin des API-Managements, bekannt aus Tools wie API Connect, auf Event-Streams: Topics dokumentieren, den Zugriff darauf kontrollieren und sie über einen Self-Service-Katalog auffindbar machen.

Ausserdem enthält die Plattform eine No-Code-Stream-Processing-Schicht zum Aufbau von Event-Flows ohne Programmieraufwand, die wir ausführlicher in unserem Begleitartikel zu No-Code-Stream-Processing mit IBM Event Automation behandeln. Dieser Artikel konzentriert sich auf die Governance-Seite: wie Event Automation aus einer unverwalteten Menge von Kafka-Topics eine auffindbare, zugriffskontrollierte Event-Landschaft macht.

Der Name steht für drei eigenständige, aber integrierte Produkte, und das lohnt sich von Anfang an präzise zu benennen, weil Organisationen häufig eine Komponente einführen, ohne die anderen zu übernehmen. Ein Team, das ausschliesslich ein Governance-Problem hat, muss sich mit Stream Processing gar nicht befassen, und ein Team, das nur No-Code-Flows möchte, muss nicht zuerst jedes Topic katalogisieren. Die Komponenten sind so konzipiert, dass sie unabhängig voneinander eingeführt werden können, je nachdem, welches Problem am dringendsten ist.

Kernfunktionen von IBM Event Automation

Die Governance-Funktionen von Event Automation zielen darauf ab, Kafka-Topics wie verwaltete, dokumentierte Produkte zu behandeln, statt wie unbeschriftete Leitungen.

• Topics in einem durchsuchbaren Event-Katalog veröffentlichen, mit angehängter AsyncAPI-Dokumentation
• Zugriffskontrolle durchsetzen, sodass Consumer den Zugriff auf ein Topic beantragen und erst nach Genehmigung erhalten, statt sich frei zu verbinden
• Nachverfolgen, wer in welches Topic publiziert und wer daraus konsumiert, sodass vor einer Schemaänderung eine Auswirkungsanalyse möglich ist
• Self-Service-Auffindbarkeit bereitstellen, sodass Teams bestehende Topics finden und deren Zugriff beantragen können, statt Duplikate anzulegen
• Kafka-Cluster-Zustand, Nachrichtenfluss und Consumer-Lag über eine einheitliche Betriebssicht überwachen

Kernkomponenten von Event Automation

IBM Event Automation besteht aus drei Komponenten, die unabhängig voneinander oder gemeinsam eingeführt werden können, je nachdem, was in einer Organisation bereits vorhanden ist.

Event Streams

Event Streams ist IBMs Kafka-Distribution und bündelt Apache Kafka mit produktionsreifem Tooling: Nachrichten durchsuchen, Workload-Balancing, eine schema registry und Cluster-Monitoring. Organisationen, die Kafka bereits anderswo betreiben, etwa mit Confluent, müssen Event Streams nicht einführen, um den Rest der Plattform zu nutzen.

Event Endpoint Management

Event Endpoint Management ist die Governance-Schicht und die Komponente, die am unmittelbarsten für die Lösung des zu Beginn dieses Artikels beschriebenen Problems zuständig ist. Sie veröffentlicht Kafka-Topics in einem Self-Service-Katalog, der mit AsyncAPI dokumentiert ist, wendet Zugriffskontrollen an und lässt Consumer den Zugriff über einen gesteuerten Workflow statt über ein Ad-hoc-Gespräch beantragen.

Event Processing

Event Processing ist die No-Code-Stream-Processing-Schicht, die auf Apache Flink basiert, aber über einen visuellen Designer statt über Code bedient wird. Sie ist die Komponente, die wir ausführlich in unserem Begleitartikel behandeln; wir erwähnen sie hier, weil sich Topics mit Governance und Katalogeintrag auch am sichersten in einen Processing-Flow einspeisen lassen, da deren Inhalt und Owner bereits bekannt sind.

Warum Kafka-Governance wichtig ist

Governance ist keine Compliance-Checkbox, die nachträglich an Kafka angeflanscht wird. Sie verändert, was operativ möglich ist. Ein dokumentiertes, zugriffskontrolliertes Topic lässt sich mit Zuversicht ändern, weil der Owner weiss, wer davon abhängt. Ein undokumentiertes Topic nicht, weil eine Schemaänderung stillschweigend drei Consumer brechen kann, an die sich niemand mehr erinnert.

Governance entscheidet auch darüber, ob die Kafka-Einführung sich weiter verstärkt oder ins Stocken gerät. Teams, die bestehende Topics finden und wiederverwenden können, kommen schneller voran und vermeiden doppelte Pipelines. Teams, die das nicht können, bauen tendenziell neu, was bereits existiert, weil das Finden mehr kostet als das Neubauen. In grossem Massstab wird diese Duplizierung zu einer eigenen operativen Last, mit mehreren Topics, die nahezu identische Daten führen und auseinanderdriften.

Es gibt zudem eine Sicherheitsdimension, die oft erst nach einem Vorfall sichtbar wird. Ohne Zugriffskontrolle auf Topic-Ebene lautet die Antwort auf die Frage „Wer kann diesen Stream lesen?" häufig „Wer auch immer Netzwerkzugriff auf den Cluster hat", was für einen Stream mit Finanz- oder Kundendaten selten die beabsichtigte Richtlinie ist. Zugriffskontrolle nachträglich einzuführen, nachdem ein Cluster unkontrolliert gewachsen ist, ist möglich, aber deutlich schwieriger, als sie von Anfang an bei der Topic-Erstellung einzubauen.

Wie IBM Event Automation das Problem von Kafka-Topics ohne Governance löst

Event Endpoint Management löst das Problem ungesteuerter Topics direkt, indem es jedes Topic als Produkt mit Owner, Dokumentation und Zugriffsrichtlinie behandelt, statt als anonymen Stream, den jeder abonnieren kann.

Möchte ein Team aus einem Topic konsumieren, findet es dieses im Katalog, liest die AsyncAPI-Dokumentation, um Schema und Semantik zu verstehen, und beantragt den Zugriff über die Plattform. Der Topic-Owner genehmigt oder lehnt diese Anfrage ab, und die Freigabe wird nachverfolgt. Ist eine Schemaänderung geplant, sieht der Owner genau, wer das Topic konsumiert, und kann sich vor der Änderung melden, statt erst danach zu erfahren, dass etwas kaputtgegangen ist.

Das erfordert weder eine Datenmigration noch eine Änderung daran, wie Producer und Consumer in Kafka schreiben. Die Governance-Schicht steht neben dem bestehenden Cluster und katalogisiert, was bereits vorhanden ist.

Wie IBM Event Automation mit Confluent/Kafka zusammenarbeitet

Die Governance- und Processing-Komponenten von Event Automation sind nicht auf IBMs eigene Event-Streams-Distribution beschränkt. Event Endpoint Management und Event Processing lassen sich über Standard-Kafka-Protokolle mit jedem Kafka-kompatiblen Cluster verbinden, einschliesslich Confluent Platform oder Confluent Cloud. Das ist relevant für Organisationen, die bereits auf Confluent standardisiert haben und ihre Kafka-Distribution nicht migrieren möchten, nur um eine Governance-Schicht hinzuzufügen.

In der Praxis bedeutet das: Eine Organisation kann ihren bestehenden Confluent-Cluster als System of Record für Event-Daten beibehalten und Event Endpoint Management ausschliesslich für den Katalog, die Dokumentation und die Zugriffskontrolle einführen, die es darüber hinzufügt. Die Kafka-Schicht und die Governance-Schicht sind bewusst voneinander entkoppelt.

Das ist auch relevant für Organisationen, die Kafka über mehr als eine Distribution hinweg betreiben, was nach einer Fusion oder Übernahme häufig vorkommt, oder einfach, weil unterschiedliche Teams im Laufe der Zeit unterschiedliche Entscheidungen getroffen haben. Ein einziger Event-Endpoint-Management-Katalog kann mehrere zugrunde liegende Kafka-Cluster umfassen und gibt der Organisation damit eine zentrale Stelle, um Event-Daten zu finden und deren Zugriff zu beantragen, unabhängig davon, auf welchem Cluster sie tatsächlich liegen.

Typische Anwendungsfälle

• Eine bestehende Kafka-Landschaft katalogisieren, die über den Punkt hinausgewachsen ist, an dem informelles Wissen ausreicht
• Nachgelagerten Teams Self-Service-Zugriff auf Event-Daten geben, ohne dass Engineering bei jeder Anfrage direkt involviert sein muss
• Zugriffskontrolle für sensible Event-Streams durchsetzen, etwa solche mit Finanztransaktionen oder personenbezogenen Daten
• Die Entstehung doppelter Topics reduzieren, indem bestehende Topics auffindbar gemacht werden, bevor ein Team ein neues baut
• Eine solide Governance-Grundlage schaffen, bevor No-Code- oder individuelles Stream Processing darauf aufgesetzt wird

Überlegungen zur Implementierung

Die Einführung der Governance-Schicht von Event Automation funktioniert am besten als stufenweises Vorgehen statt als einmaliges Migrationsereignis. Alle bestehenden Topics auf einmal zu katalogisieren, bevor Ownership und Dokumentation geklärt sind, ergibt einen Katalog, dem niemand vertraut. Effektiver ist es, mit einer Teilmenge besonders wichtiger oder besonders riskanter Topics zu beginnen, dort Ownership und Dokumentation richtig aufzusetzen und von dort aus zu erweitern.

Auch Ownership muss bewusst zugewiesen werden. Ein Topic ohne klaren, verantwortlichen Owner im Katalog ist nicht besser gesteuert als ein Topic ohne Katalogeintrag. Organisationen, die diesen Schritt überspringen, landen bei einem Katalog, der Topics auflistet, aber nicht beantworten kann, wer dafür verantwortlich ist, was den Zweck verfehlt.

Und schliesslich sollten Zugriffsrichtlinien widerspiegeln, wie die Organisation tatsächlich arbeitet, statt einheitlich eine standardmässig offene oder standardmässig gesperrte Einstellung anzuwenden. Sensible Finanz- oder Kundendaten-Streams brauchen in der Regel Genehmigungs-Workflows, interne operative Kennzahlen oft nicht. Jedes Topic gleich zu behandeln, in welche Richtung auch immer, schafft entweder unnötige Reibung oder unnötige Exposition.

Wie Mimacom unterstützen kann

Mimacom unterstützt Unternehmen dabei, Governance in Kafka-Landschaften zu bringen, die aus der informellen Verwaltung herausgewachsen sind, egal ob auf Basis von IBM Event Streams, Confluent oder einer anderen Kafka-Distribution. Wir bewerten den aktuellen Stand der Topics, der Ownership und der Dokumentation einer Organisation und implementieren anschliessend Event Endpoint Management mit einem Zugriffskontrollmodell, das zur tatsächlichen Arbeitsweise des Unternehmens passt. Wird zusätzlich eine No-Code- oder individuelle Processing-Schicht benötigt, unterstützen wir bei der Entscheidung, was in Event Processing gehört und was einen dedizierten Engineering-Ansatz braucht.

FAQs

Ersetzt IBM Event Automation Kafka?

Nein. Event Automation ergänzt einen bestehenden Kafka-Cluster um Governance-, Katalog- und Processing-Funktionen. Es ersetzt Kafka selbst nicht und lässt sich gegen IBMs eigene Event-Streams-Distribution, Confluent oder einen anderen Kafka-kompatiblen Cluster betreiben.

Kann IBM Event Automation einen Confluent-Kafka-Cluster steuern?

Ja. Event Endpoint Management und Event Processing verbinden sich über Standardprotokolle mit jedem Kafka-kompatiblen Cluster, einschliesslich Confluent Platform und Confluent Cloud. Die Einführung der Governance-Schicht erfordert keine Migration weg von Confluent.

Was dokumentiert ein Event-Katalog konkret?

Jedes Topic im Katalog wird mit AsyncAPI dokumentiert, einschliesslich Schema, Beschreibung und Ownership. Consumer nutzen diese Dokumentation, um den Inhalt eines Topics zu verstehen, bevor sie Zugriff beantragen, und Owner nutzen sie, um bei der Planung von Änderungen nachzuvollziehen, wer vom Topic abhängt.

Ordnung in eine ereignisgesteuerte Landschaft bringen

Eine ungesteuerte Kafka-Landschaft scheitert nicht auf einen Schlag. Sie verschlechtert sich schrittweise, durch doppelte Topics, undokumentierte Schemas und Änderungen, die Consumer brechen, an die sich niemand mehr erinnert. Die Governance-Schicht von IBM Event Automation setzt genau dort an und macht aus einer Menge anonymer Topics einen Katalog dokumentierter, zugriffskontrollierter Event-Produkte, ohne dass der zugrunde liegende Kafka-Cluster verändert werden muss.

Am meisten profitieren die Organisationen, die Governance als fortlaufende Disziplin verstehen, mit klarer Ownership und bewussten Zugriffsrichtlinien, statt als einmalige Katalogisierungsübung.