Kommentar von Kai Waehner, Confluent So vereinfacht Kafka die Integration und Modernisierung von Anwendungen

In Unternehmen bilden geschäftskritische Anwendungen das Rückgrat vieler Geschäftsprozesse. Diese operativen Systeme generieren kontinuierlich große Datenmengen, die zur Steuerung von Prozessen, Anwendungen und Services genutzt werden können. In der Praxis sind diese Anwendungsdaten jedoch häufig über eine Vielzahl von Systemen verteilt und in Silos eingeschlossen. Hinzu kommt, dass sich die Daten oft nur schwer aus den zugrunde liegenden Anwendungsdatenbanken oder aus den SaaS-Diensten extrahieren lassen, in denen sie gespeichert sind.

Einzelne Data Engineers oder Softwareentwickler bauen daher häufig maßgeschneiderte, Batch-basierte Daten-Pipelines für oft nur einen spezifischen Anwendungsfall. Das führt jedoch schnell zu Fragmentierung, doppelten Datenbeständen und Inkonsistenzen zwischen verschiedenen Anwendungssilos und Daten-Pipelines, was wiederum den Austausch sowie die Wiederverwendung der Daten erschwert.

Daten, die nur für eine einzige Anwendung zugänglich sind, sind wesentlich schwieriger wiederzuverwenden als Daten, die unternehmensweit verfügbar sind. Werden Daten hingegen geteilt, können sie zu wiederverwendbaren Bausteinen für neue oder verbesserte Anwendungen, Services und Produkte werden. Das ermöglicht fundiertere Entscheidungen, optimiert Geschäftsprozesse und hilft außerdem, Sicherheitsrisiken zu reduzieren.

Streaming & KI von Confluent

Confluent richtet seine Plattform auf KI-Dienste aus

Dazu müssen Anwendungsdaten auf eine zentrale, gemeinsame und offene Plattform gebracht werden, die folgende Anforderungen erfüllt:

• Datenquellen und -ziele werden voneinander entkoppelt, wodurch die Komplexität reduziert wird.

• Gemeinsam genutzte Daten werden gespeichert, sodass sie von bestehenden und neuen Anwendungen leicht wiederverwendet werden können.

• Daten können als Events zur Steuerung des Verhaltens von Anwendungen genutzt werden.

• Gemeinsam genutzte Daten werden mit bestehenden Datenquellen aus Anwendungen integriert.

• Je nach Anwendungsfall ist der Zugriff sowohl auf Echtzeit-Streams als auch auf historische Batch-Daten möglich.

• Die schnelle Wiederverwendung von Daten wird durch einfache und wiederholbare Anwendungsfälle für die gemeinsame Datennutzung gefördert.

Kafka als zentrale, gemeinsame, offene Plattform

Datenarchitekten suchen daher nach gemeinsam nutzbaren, echtzeitfähigen, Event-getrieben und offenen Datenplattformen, die sich in der Praxis bewährt haben und idealerweise auf Open-Source-Technologien oder offenen Protokollen basieren.

Apache Kafka entkoppelt Datenquellen von Zielsystemen und reduziert so die Komplexität herkömmlicher Punkt-zu-Punkt-Integrationen. Producer veröffentlichen Events in Topics, ohne die Consumer zu kennen. Consumer wiederum abonnieren diese Topics unabhängig voneinander. Dadurch entstehen keine direkten Abhängigkeiten zwischen Anwendungen – und bestehende Systeme müssen nicht angepasst werden. Topics werden so zu zentralen Bausteinen für Event-getriebene Anwendungen und Analysen.

Dank des Event-basierten Publish-Subscribe-Modells von Kafka können Teams Datenströme erweitern oder verändern, ohne Quellsysteme oder bestehende Pipelines anzupassen. Im Gegensatz dazu arbeiten REST-APIs meist synchron und erfordern eine engere Integration mit den jeweiligen Anwendungen. Das kann Entwicklungszeiten verlängern und zusätzliche Risiken schaffen.

Kommentar von Falko Germar-Schwarz, Factor House

Kafka im Multi-Cluster-Betrieb – wo Governance und Monitoring an Grenzen stoßen

Als Open-Source-Technologie mit einem großen Ökosystem an Konnektoren und Tools ermöglicht Kafka eine unternehmensweite Standardisierung. Teams und Anwendungen können Daten einfacher teilen und wiederverwenden, und das mit deutlich weniger individuellen Integrationen und ohne starke Abhängigkeit von einzelnen Anbietern.

Kafka speichert Daten dauerhaft in unveränderlichen Logs. Dadurch werden flüchtige Ereignisse zu wiederverwendbaren Bausteinen, auf die sowohl bestehende als auch zukünftige Anwendungen zugreifen können. Über konfigurierbare Aufbewahrungszeiten können Topics entweder die komplette Historie oder nur bestimmte Zeitfenster speichern. Das ermöglicht beispielsweise das erneute Abspielen von Datenströmen oder Events, um neue Systeme anzubinden oder nach Störungen schnell wiederherzustellen.

Auch bestehende ERP-Systeme profitieren von Kafka. Über Kafka Connect lassen sich etwa Auftragsereignisse als Datenströme verfügbar machen – etwa für Analysen, Betrugserkennung oder neue KI-Services, ohne die Daten erneut aus den Quellsystemen extrahieren zu müssen. Diese gemeinsame, persistente Datenebene durchbricht Datensilos und macht Anwendungsdaten zu einem wertvollen Gut, das sich breit teilen und wiederverwenden lässt.

Kafka ermöglicht sowohl Echtzeit-Streaming als auch den Zugriff auf historische Batch-Daten und verbessert zugleich die Wiederverwendbarkeit von Daten durch einfache, wiederholbare Anwendungsfälle. Echtzeit-Consumer versorgen beispielsweise Dashboards oder Alarmsysteme mit aktuellen Informationen. Gleichzeitig kann Kafka Daten in offene Lakehouse-Architekturen wie Apache Iceberg überführen, um Reporting und Analysen zu unterstützen. Diese Architektur sorgt vor allem für Datenkonsistenz über verschiedene Systeme hinweg. Anwendungen können dieselben Events unabhängig voneinander in Echtzeit, als Batch-Verarbeitung oder über API-basierte Abfragen nutzen und greifen dabei stets auf denselben Datenstand zu.

Agent-Orchestrierung und Anomalieerkennung

Confluent erweitert „Confluent Intelligence“

Je schneller Daten wiederverwendet werden können, desto schneller lassen sich neue Projekte umsetzen. Typische Einstiegsszenarien, wie die Synchronisierung einer Datenbank mit einem Suchindex oder die Weiterleitung von Protokolldaten an Sicherheitstools, lassen sich mit vorgefertigten Konnektoren schnell umsetzen. Diese risikoarmen, wirkungsvollen Muster lassen sich gut skalieren, senken Integrationskosten und beschleunigen Innovationen (auch für KI), ohne dass eine umfassende Modernisierung der Infrastruktur oder tiefgreifende Änderungen an bestehenden Anwendungen erforderlich sind.

Kafka bei der Anwendungsintegration einsetzen

Datenarchitekten setzen Kafka für die Integration, Modernisierung und Weiterentwicklung von Anwendungen ein. Einige Unternehmen verwenden dafür ein einfaches Muster, das als Entity Builder bekannt ist.

Eine Entität repräsentiert ein „Objekt“ innerhalb einer fachlichen Domäne, beispielsweise einen Kunden, eine Bestellung, ein Produkt, einen Mitarbeitenden, eine Abteilung oder eine Rechnung. Sie ist eindeutig identifizierbar, hat definierte Attribute und existiert im System entweder unabhängig oder in Abhängigkeit von anderen Entitäten. Geschäftsprozesse bauen auf diesen Entitäten sowie auf ihren Beziehungen und Eigenschaften auf.

Anwendungen speichern Entitäten und ihre Beziehungen in Datenbanken. Nach Unternehmensübernahmen oder bei der Einführung neuer SaaS-Anwendungen sind identische Entitäten, wie z. B. ein Kunde, oft über mehrere Systeme verteilt, sodass eine vollständige Zusammenführung dieser Anwendungen oft nicht praktikabel ist. Stattdessen spezialisieren Architekten einzelne Anwendungen für bestimmte Prozesse oder Dienste und verwenden Kafka, um ein zentrales Protokoll zu erstellen, das zur Nutzung gemeinsamer Entitäten verwendet werden kann.

Handelt es sich bei der Entität beispielsweise um einen „Kunden“, speichert jede Anwendung ihre entsprechenden Kundendatensätze in einem Topic und berücksichtigt dabei auch alle Änderungen an diesen Datensätzen. Diese Änderungen können an einen einfachen Event-getriebenen Microservice weitergeleitet oder in einen bestehenden Monolithen integriert oder dort erweitert werden. Idealerweise wurde im Vorfeld eine grundlegende Datenmodellierung durchgeführt, damit Geschäftsbereiche, Data Engineers und Software-Entwickler ein gemeinsames Verständnis davon haben, was ein „Kunde“ ist und welche Attribute in den jeweiligen Anwendungen relevant sind. Um zu starten und einen Mehrwert zu erzielen, ist jedoch kein umfangreiches Datenmodell erforderlich.

Datenmodellierung als Grundlage der Datennutzung

Zunächst liegt der Fokus auf einfachen Anwendungsfällen. Die Verantwortlichen der beteiligten Anwendungen entwickeln gemeinsam ein Datenmodell, das auf einem einheitlichen Verständnis der Entität „Kunde” basiert. Dazu definieren sie klar, was unter einem Kunden zu verstehen ist. Was zunächst trivial erscheinen mag, wird schnell technisch komplex. Deshalb ist es wichtig, diese Definition möglichst präzise zu dokumentieren, bevor mit der eigentlichen Systemarchitektur begonnen wird.

GreenOps: Nachhaltigkeit in Datenarchitekturen

Wenn Datenströme plötzlich Stromfresser sind

Nicht alle Anwendungsmanager sind offen für eine gemeinsame Datennutzung. Wenn sich hier keine Einigung erzielen lässt, kann es sinnvoll sein, eine Führungskraft einzubeziehen, die die geschäftlichen Vorteile erkennt und das Thema vorantreibt. Der geschäftliche Vorteil, Daten über eine Kafka-Plattform gemeinsam zu nutzen, der liefert hierfür überzeugende Argumente.

Im Bereich Finanzdienstleistungen gibt es beispielsweise separate Anwendungen für Bankgeschäfte, Kreditkarten, Investitionen und Zahlungsverkehr. Um besser zu verstehen, was die Entität „Kunde“ in diesen unterschiedlichen Anwendungen bedeutet, kann ein Datenmodellierungsprozess die folgenden Fragen stellen:

• Welche Kundenidentifikatoren, wie Sozialversicherungsnummer, Geburtsdatum oder Passnummer, werden in den verschiedenen Anwendungen verwendet und sind eindeutig einer einzelnen Person zugeordnet?

• Welche Informationen zu diesen Identifikatoren eignen sich, um einen gemeinsamen Primärschlüssel zu bilden, über den sich Kundendaten aus unterschiedlichen Anwendungen zusammenführen lassen?

• Welche Attribute sind außerhalb der jeweiligen Anwendung besonders relevant und sollten denormalisiert und mit der Kundenentität geteilt werden?

• Welche zusätzlichen Kundeninformationen erhöhen den Geschäftswert der jeweiligen Anwendung?

• Welche gemeinsam genutzten Informationen müssen aus Gründen des Datenschutzes, der Sicherheit oder der Compliance besonders geschützt werden?

• Abgeleitete oder aggregierte Kennzahlen und Dimensionen müssen einheitlich berechnet und definiert werden.

Sobald ein gemeinsames Datenmodell und ein einheitliches Verständnis der Entität „Kunde” vorhanden sind, können in jeder Anwendung Kafka-Topics auf Basis dieses Modells generiert werden. Die daraus resultierenden Ströme können dann miteinander verknüpft werden, beispielsweise indem zwei oder mehr Ströme aus verschiedenen Systemen über Kunden-IDs zusammengeführt und auf die für den jeweiligen Anwendungsfall relevanten Attribute reduziert werden. Dieses Vorgehen zeigt, wie der Datenmodellierungsprozess zugleich die materialisierten Ansichten (Materialized Views) berücksichtigt, die nachgelagerte Anwendungen benötigen. Gleichzeitig verdeutlicht es die Stärke einer Event-getriebenen Datenintegration: Durch frei verfügbare und kontinuierlich aktualisierte Daten lassen sich neue Anwendungsfälle deutlich einfacher realisieren.

Einfache Entwicklung von Anwendungen mit inkrementellen Änderungen

Für die Entität „Kunde” können Änderungen wie eine neue Adresse, angepasste Salden oder neue Zahlungen identifiziert und als Events an einen Microservice weitergeleitet werden, der diese Änderungen verarbeitet. So lassen sich beispielsweise Adressaktualisierungen an andere Anwendungen verteilen, Angebote auf Basis neuer Informationen generieren oder Compliance-relevante Prozesse anstoßen. Dieser Ansatz ermöglicht einen praktischen Einstieg.

Nach Abschluss eines Projekts sollte eine strukturierte Bewertung durchgeführt werden. Im Mittelpunkt stehen dabei Fragen wie: Welche Aspekte haben sich bewährt, wo gab es Schwierigkeiten? Lassen sich wiederkehrende Anforderungen erkennen, die aufgrund von Lücken im Ereignismodell oder im Datenprodukt nicht erfüllt werden konnten? Welche technischen Herausforderungen traten während der Umsetzung auf? Hat das ausgewählte Datenprodukt die Anforderungen erfüllt? Wurden Ereignisse so kontextualisiert, dass sie den Nutzungsmustern der Verbraucher entsprechen? Und welche weitere Entität könnte als Datenstrom bereitgestellt werden, um zusätzlichen Mehrwert zu schaffen – ähnlich wie im Beispiel die Entität „Kunde“?

Dieser Ansatz zur Öffnung und gemeinsamen Nutzung von Daten vermeidet tiefgreifende Änderungen an bestehenden Monolithen wie Altsystemen oder deren Datenmodellen. Diese Systeme können weiterhin für den operativen Betrieb genutzt werden, während die Modernisierung schrittweise um sie herum erfolgt.

Gleichzeitig ermöglicht dieser Ansatz, event-getriebene Anwendungen sofort aufzubauen, während ein Datenaustausch in Echtzeit zwischen Anwendungen möglich wird.

Fazit

Die Integration neuer Daten in bestehende, ausgereifte Anwendungen war schon immer eine Herausforderung. Kafka bietet hierfür geeignete Mechanismen und stützt sich auf Bausteine, die den Schwerpunkt auf Datenaustausch, Wiederverwendbarkeit und konsistente Daten über verschiedene Systeme hinweg legen. Allein schon der Austausch von Event-Daten über Kafka schafft einen geschäftlichen Mehrwert, ohne dass kostspielige oder komplexe Änderungen an bestehenden Anwendungen erforderlich sind. Auf dieser Grundlage kann die Datenarchitektur in großen Unternehmen schrittweise modernisiert und auf wiederverwendbaren Datenbausteinen aufgebaut werden.

(ID:50880506)