The page is unfortunately not available in this language. Here is the German version.

Das DataFlow Data Maturity Model: Wie Banken dank Apache Kafka Schritt für Schritt zum Daten-Ökosystem gelangen

Die Rolle von Daten in der heutigen Geschäftswelt hat sich tiefgreifend verändert. Was früher als statisches Gut betrachtet wurde, entwickelt sich zunehmend zu einem dynamischen und strategischen Werttreiber. Banken, die aufgrund ihrer regulatorischen Rahmenbedingungen und IT-Landschaften lange Zeit auf traditionelle Datenprozesse angewiesen waren, sehen sich heute einem Wandel gegenüber, der neue Technologien und Denkweisen erfordert. Mit dem Aufkommen von Daten-Streaming-Plattformen wie Apache Kafka eröffnen sich neue Möglichkeiten, nicht nur effizienter mit Daten umzugehen, sondern auch neue Geschäftsmodelle und Kundeninteraktionen zu schaffen. Die Frage ist nicht mehr, ob dieser Wandel notwendig ist, sondern wie er erfolgreich gestaltet werden kann. Dieses Whitepaper ist aus der Überzeugung entstanden, dass der Übergang zu einer datengetriebenen Organisation nicht nur technologisches Know-how, sondern auch eine klare strategische Ausrichtung verlangt. Es richtet sich an alle, die in ihrer Organisation datenbasierte Innovationen fördern und den Schritt in die Echtzeit-Welt gestalten wollen. Wir laden Sie ein, sich inspirieren zu lassen und wertvolle Impulse für Ihre eigene Datenstrategie zu gewinnen.

Einführung

Die Digitalisierung und der wachsende Bedarf an Echtzeitdaten haben die Art und Weise, wie Unternehmen ihre Daten verarbeiten und nutzen, radikal verändert. Besonders Banken, die traditionell auf stabile, aber langsame Datenarchitekturen setzen, stehen vor der Herausforderung, sich in einer Welt der Echtzeit-Datenströme zu entwickeln. In diesem Whitepaper erläutern wir, wie Apache Kafka–eine leistungsstarke Open-Source-Plattform für Daten-Streaming – Banken dabei unterstützt, den Übergang von traditionellen Batch-Verarbeit- ungen hin zu einer modernen, skalierbaren und flexiblen Echtzeit-Datenarchitektur zu meistern. Anhand eines fünfstufigen Reifemodells beleuchten wir den Weg einer Bank, die mit isolierten Datensilos beginnt und sich schliesslich zu einem umfassenden, vernetzten Flow-Ökosystem entwickelt. Dabei zeigen wir auf, welche organisatorischen und technischen Herausforderungen auf diesem Weg auftreten und wie Banken diese bewältigen können.

Data Maturity Model
Figure 1. Data Maturity Model

Batch-Verarbeitungen verarbeiten Daten gesammelt in zeitlichen Intervallen. Diese Methode stammt aus einer Zeit, in der Echtzeitdatenverarbeitung technisch nicht möglich war.

Level 0: Daten in Ruhe

In vielen Banken liegen die Daten in isolierten, statischen Datenbanken, die von den jeweiligen Abteilungen verwaltet werden. Eine Abteilung nutzt ein Core-Banking-System, während andere Systeme wie das E-Banking oder das CRM unabhängig voneinander operieren. Diese Systeme sind nicht in der Lage, in Echtzeit miteinander zu kommunizieren, was bedeutet, dass Daten oft nur in regelmässigen Batch-Prozessen ausgetauscht werden.

Beispiel

Ein Kunde einer Bank tätigt eine Transaktion über sein Core-Banking-System. Diese Information wird jedoch erst in der nächsten nächtlichen Batch-Verarbeitung in das E-Banking - System synchronisiert, wodurch der Kunde den aktualisierten Kontostand erst am nächsten Tag einsehen kann. Diese Verzögerungen entstehen durch die Strukturen der Banken, die auf klassische Messaging-Systeme wie ESB (Enterprise Service Bus) setzen.

Das führt zu

  1. Veraltete Daten: Informationen sind oft nicht aktuell sofort abgerufen werden. und können bei Bedarf nicht

  2. Inkonsistenzen: Daten sind zwischen den Systemen oft uneinheitlich.

  3. Langsame Reaktionszeiten: Veränderungen werden reflektiert, was den Kundenservice beeinträchtigt. nur

Leben im Gestern: Batch-Verarbeitung in einer Echtzeit-Welt
Figure 2. Leben im Gestern: Batch-Verarbeitung in einer Echtzeit-Welt

Der Enterprise Service Bus (ESB) dient als zentrale Verbindung, um verschiedene Systeme mitein- ander kommunizieren zu lassen. Er wurde ursprünglich entwickelt, um die Integration komplexer IT-Umgebungen zu erleichtern.

Level 1: Isolierte Datenströme

Der erste Schritt zur Modernisierung der Datenarchitektur ist die Einführung von Daten-Streaming-Technologien wie Apache Kafka. Banken beginnen, isolierte Echtzeit-Datenströme zwischen Systemen zu etablieren. Häufig geschieht dies ohne umfassende Strategie, sondern als punktuelle Lösung für spezifische Anwendungsfälle.

Beispiel

Die Bank setzt Kafka ein, um die Kommunikation zwischen dem Core-Banking- und dem E-Banking-System zu verbessern. Transaktionen werden nun in Echtzeit synchronisiert, sodass Kunden sofort ihren aktuellen Kontostand sehen können. Dies erfolgt durch die Einrichtung von Kafka-Producern und -Consumern, die die relevanten Datenströme zwischen den beiden Systemen abbilden.

Das führt zu

  1. Isolierten Anwendungen: Die Datenströme werden oft nur für bestimmte Abteilungen oder Systeme eingerichtet.

  2. Fehlender Strategie: Unternehmen nutzen Kafka nur für begrenzte Anwendungsfälle, ohne die Skalierbarkeit oder Integration in die gesamte Datenarchitektur zu berücksichtigen.

Leben in Silos: Einzelne Datenströme
Figure 3. Leben in Silos: Einzelne Datenströme, punktueller Mehrwert

Diese Grafik zeigt, wie Echtzeit-Datenströme zwischen isolierten Systemen, wie dem Core-Banking und einem weiteren isolierten System, über Apache Kafka fliessen. Diese Lösung verbessert zwar den Datenfluss für spezifische Anwendungsfälle, doch ohne übergreifende Integration bleibt das Potenzial begrenzt. Für langfristigen Mehrwert müssen die Datenströme skalierbar und auf die gesamte Datenarchitektur ausgeweitet werden, um eine flexible Systemlandschaft zu ermöglichen.

Das Core-Banking wickelt die Kerntransaktionen ab, wie Überweisungen oder Kredite, während E-Banking das Online-Portal für Kunden darstellt. Es ist oft älter und schwerer zu modernisieren als E-Banking-Systeme.

Level 2: Datenverarbeitung im Fluss

Nachdem die ersten Kafka-Use-Cases erfolgreich implementiert wurden, möchten weitere Abteilungen auch in Echtzeit kommunizieren. Nun profitieren nicht nur das Core-Banking und E-Banking, sondern auch andere Bereiche wie das Wealth-Management und das CRM-System von Echtzeitdaten. Durch die Verknüpfung dieser Systeme können weitere Abteilungen von den Vorteilen der Echtzeit-Daten profitieren.

Beispiel

Das Wealth-Management-System der Bank kann nun auf Echtzeit-Transaktionsdaten zugreifen, um das Anlageverhalten von Kunden zu analysieren. Auch die Marketingabteilung bekommt ihre benötigten Daten aus dem Wealth-Management-System und kann jetzt mit qualitativen Echtzeit-Kundendaten ihre Kampagnen planen.

Das führt zu . Isolierten Anwendungen: Die Integration mehrerer Systeme in Echtzeit erhöht die technische Komplexität. . Fehlender Strategie: Unterschiedliche Datenformate und -strukturen erschweren die gemeinsame Nutzung der Daten.

Vom Fluss zur Strategie: Echtzeitverarbeitung mit Struktur
Figure 4. Vom Fluss zur Strategie: Echtzeitverarbeitung mit Struktur

Wealth-Management umfasst Dienstleistungen, die darauf abzielen, das Vermögen von Kunden zu maximieren. Der Einsatz von Echtzeitdaten ermöglicht es, schneller auf Marktveränderungen zu reagieren und individuelle Anlagestrategien anzupassen.

Level 3: Flow Governance

Mit zunehmender Datenvernetzung wird die Einführung einer klaren Governance-Struktur unerlässlich. Banken müssen sicherstellen, dass Daten konsistent, sicher und regelkonform fliessen. Dies erfordert die Definition von Standards für Datenformate, Zugriffsrechte und Namenskonventionen. Ein Schema-Management und die Einführung von Datenverträgen ermöglichen es, Datenströme effizient zu verwalten und zu überwachen.

Beispiel

In einer Bank werden Daten zwischen den Systemen wie Core-Banking, E-Banking und CRM über Kafka in Echtzeit ausgetauscht. Um die Datenqualität und Sicherheit zu gewährleisten, werden klare Richtlinien für die Datenflüsse eingeführt, wie etwa: Verwendung von standardisierten Formaten wie Avro oder Protobuf. Nutzung einer Schema-Registry zur Verwaltung der Datenstrukturen. Definierte Zugriffsrechte für verschiedene Abteilungen, um sicherzustellen, dass nur autorisierte Systeme Zugriff auf bestimmte Datenströme haben.

Das führt zu . Aufbau einer einheitlichen Plattform: Die Einführung von Governance erfordert eine enge Zusammenarbeit zwischen Architektur- und Plattformteams. . Verantwortung für Datenqualität: Fachabteilungen müssen lernen, die Verantwortung für die von ihnen generierten Datenströme zu übernehmen.

Governance als Schlüssel: Ordnung in den Datenströmen
Figure 5. Governance als Schlüssel: Ordnung in den Datenströmen

Schema-Management stellt sicher, dass alle Systeme einheitlich auf Daten zugreifen können. Die Einführung von Schema-Registries war ein wichtiger Schritt zur Gewährleistung von Datenqualität in komplexen Umgebungen.

Level 4: Flow-Ökosystem

Der letzte Schritt auf dem Weg zur datengetriebenen Bank ist die Schaffung eines umfassenden Flow-Ökosystems. Daten werden nicht länger als Nebenprodukt betrachtet, sondern als strategisches Asset, das der gesamten Organisation zur Verfügung steht. Durch die Einführung eines Data Mesh wird eine dezentrale Datenarchitektur aufgebaut, in der Daten als Produkte behandelt werden, die von den verschiedenen Abteilungen erzeugt, verwaltet und genutzt werden können.

Beispiel

In der Bank wird ein Self-Service-Datenkatalog eingerichtet, über den verschiedene Abteilungen wie das Marketing oder das Wealth-Management Datenprodukte in Echtzeit entdecken und nutzen können, ohne die zentrale IT-Abteilung zu involvieren. Dies beschleunigt die Datennutzung und ermöglicht es den Abteilungen, schneller und effizienter auf relevante Daten zuzugreifen.

Das führt zu . Aufrechterhaltung der Datenqualität: Mit der Verteilung der Verantwortung auf mehrere Abteilungen muss die Bank sicherstellen, dass alle Teams einheitliche Standards befolgen. . Skalierung der Architektur: Das Flow-Ökosystem muss kontinuierlich erweitert und optimiert werden, um zukünftigen Anforderungen gerecht zu werden.

Vom Silo zum Netz: Data Mesh als Ökosystem für Datenflüsse
Figure 6. Vom Silo zum Netz: Data Mesh als Ökosystem für Datenflüsse

Zhamak Dehghani entwickelte das Konzept des Data Mesh im Jahr 2019. Es bietet einen neuen Ansatz zur Datenarchitektur, um die Skalierbarkeit in grossen Unternehmen zu verbessern.

Fazit

Die Transformation von Banken hin zu einer modernen, datengetriebenen Organisation ist ein komplexer, aber unvermeidlicher Prozess. In einer zunehmend digitalisierten Welt, in der Echtzeitdaten über Erfolg oder Misserfolg entscheiden können, müssen Banken ihre traditionellen Strukturen hinter sich lassen und auf flexible, skalierbare Datenarchitekturen setzen. Hierbei spielt Apache Kafka eine zentrale Rolle, da es als leistungsfähige Plattform für Daten-Streaming die kontinuierliche Verarbeitung grosser Datenmengen in Echtzeit ermöglicht.

Das in diesem Whitepaper vorgestellte fünfstufige Reifemodell verdeutlicht, dass dieser Wandel weit über die Einführung einer neuen Technologie hinausgeht. Es handelt sich um einen ganzheitlichen Ansatz, der sowohl technologische als auch organisatorische Aspekte berücksichtigt. Die Reise beginnt mit der Ablösung isolierter Datensilos und führt schrittweise zu einer vollintegrierten Datenlandschaft, in der Daten als wertvolle Assets betrachtet und genutzt werden.

Jede Phase dieses Prozesses bringt eigene Herausforderungen mit sich – von der Einführung erster isolierter Datenströme bis hin zur Etablierung eines umfassenden Flow-Ökosystems mit klar definierten Governance-Strukturen. Banken, die diesen Weg erfolgreich beschreiten, werden nicht nur ihre betriebliche Effizienz verbessern, sondern auch neue Geschäftsmodelle entwickeln können, die auf Echtzeitdaten basieren. Die schnelle Verfügbarkeit konsistenter und aktueller Daten schafft die Grundlage für bessere Kundeninteraktionen, präzisere Analysen und ein höheres Mass an Innovation.

Über Anatoly Zelenin
Hallo, ich bin Anatoly! Ich liebe es, bei Menschen das Funkeln in den Augen zu wecken. Als Apache Kafka Experte und Buchautor bringe ich seit über einem Jahrzehnt IT zum Leben - mit Leidenschaft statt Langeweile, mit Erlebnissen statt endlosen Folien.

Über Dirk Budke
Dirk Budke ist Head of Engineering bei mesoneer und dort für KI und Data Engineering zuständig.

Weiterlesen

article-image
Apache Kafka Clients richtig konfigurieren

Die Standardkonfigurationen von Kafka reichen für die Entwicklung, aber in der Produktion sind sie eine Schwachstelle. Dieser Leitfaden deckt die wesentlichen Einstellungen für Zuverlässigkeit, Performance und Betriebsstabilität ab.

Mehr lesen
article-image
Ausblick auf das Data Mesh: 4 Schritte für den Paradigmenwechsel

Das „Data Mesh“ ist in der IT-Szene ein echter Hype. Warum Unternehmen von einer dezentralisierten Datenarchitektur profitieren und wie Apache Kafka beim Etablieren dieser neuen Struktur hilft, erörtert dieser Artikel.

Mehr lesen