Aktuelle Trends bei Datenarchitekturen im Bankensektor

Gestern, Heute und Morgen

Abonnieren Sie den kostenlosen Bank Blog Newsletter

Von der Antike über Renaissance zur Moderne. Der architektonische Wandel in Europa ist allgegenwärtig. Ein vergleichbarer Wandel findet derzeit in der Datenarchitektur statt. Der dezentrale Ansatz des neuartigen Data Mesh bietet Einblick in eine neue Epoche.

Data Mesh als neuer Ansatz für Datenarchitekturen im Banking

Data Mesh als neuer Ansatz für Datenarchitekturen im Banking.

Partner des Bank Blogs

Berg Lund & Company ist Partner des Bank Blogs

Der Bankensektor verarbeitet permanent enorme Datenmengen in Echtzeit unter dem ständigen Druck, zahlreiche Regularien zu erfüllen. Somit ist es nicht verwunderlich, dass die Finanzindustrie („FS”) einer der größten Arbeitgeber für Data Scientisten ist. Sie sind unter anderem zuständig für die Optimierung bestehender Services, der Entwicklung neuer Produkte und der Erarbeitung von Modellen zur korrekten Einschätzung von Risiken.

Ähnlich wie viele Großunternehmen haben auch die meisten Banken und Versicherungen in den 1990er Jahren eine monolithische und starre Datenarchitektur mit einem Data Warehouse in ihrem Zentrum aufgebaut. Laut einer PwC Studie vom Februar 2022  nutzen 84 Prozent der befragten Unternehmen ein Data Warehouse. Die Daten aus dem Data Warehouse werden weiterverarbeitet und in Reporting Tools und Dashboards aufgearbeitet. Auf dieser Basis können u.a. neue Strategien entwickelt und regulatorische Auflagen erfüllt werden.

Weiterentwicklung der Datenarchitektur

Im Laufe der letzten Jahrzehnte hat sich diese Art der Datenarchitektur aufgrund von externem und internem Druck weiterentwickelt. Die 2010er Jahre waren geprägt durch die Einführung von Data Lakes. Diese haben die Möglichkeit geschaffen, größere Datenmengen und verschiedenste Datentypen in einer höheren Geschwindigkeit zu verarbeiten. Data Warehouses und Data Lakes koexistieren mittlerweile in den meisten Banken und Versicherungen und bilden den grundlegenden Baustein einer Datenplattform. Diese Datenplattformen wurden aus Governance Gründen in den letzten Jahren um Datenkataloge erweitert und sollen die Grundlage für u.a. den Einsatz von Künstlicher Intelligenz und eine gezieltere Nutzung der gesammelten Daten erleichtern.

Dennoch liegen die meisten Unternehmen derzeit nach eigener Einschätzung weit hinter ihren Möglichkeiten. Datenbezogene Probleme sind so vielfältig und so alt wie einige Data Warehouses. In der PwC Studie befragte Fachkräfte bezeichnen ein fehlendes Verständnis für Daten und ihren Kontext sowie geringe Datenqualität als zwei der größten Probleme.

Probleme zentraler Datenarchitekturen und zentraler Datenteams

Die Ursachen für diese Probleme liegen oft in der zentralisierten Dateninfrastruktur und den damit einhergehenden zentralen Datenteams, welche für die Datenhaltung in den zentralen Data Warehouses und Data Lakes verantwortlich sind. Die zentrale Organisation der Datenteams hat zur Folge, dass trotz technischer Expertise meist nur wenig fachliches Verständnis für die Daten und deren Hintergrund aus den verschiedenen Unternehmensbereichen vorhanden ist. Außerdem mangelt es, auch aus diesem Grund, in vielen Fällen an einer klaren Ownership für die Daten aus den unterschiedlichen Bereichen, was letzten Endes in Summe oft zu der angeführten mangelhaften Datenqualität führt.

Hinzu kommt, dass zentrale Datenteams insbesondere vor dem Hintergrund rasant steigender Datenmengen und höherer Komplexität der Daten einen Bottleneck darstellen. Dies führt zu einer geringen Agilität, sodass die Durchführung von Wartungen, Anpassungen und sonstiger datenbezogenen Anfragen zur Aufrechterhaltung oder gar der Steigerung der Datenqualität oft mit langen Wartezeiten verbunden sind.

Data Mesh als mögliche Problemlösung

Vor diesem Hintergrund hat 2019 mit dem sogenannten Data Mesh eine neue Art der Datenarchitektur ein massives Momentum erlangt. Diese dezentrale Ausrichtung der Datenarchitektur basiert nicht auf technischen Neuerungen, sondern vielmehr auf der Anpassung der Datenarchitektur und der Datenteams auf die konzerneigene Struktur. Dies geschieht u.a. durch die Reallokation von Datenteams in die Nähe der jeweiligen Fachbereiche, um gemeinsam in sogenannten dezentralen Domänen zu arbeiten. Ebenfalls wird die Datenqualität durch ein klares Ownership für Datenprodukte und einen zentralen Datenkatalog gesteigert. Durch solche Formen der Reorganisation bietet der Data Mesh einige Antworten auf die immer weiter steigende Komplexität rund um das Thema Datenmanagement. Im weiteren Verlauf sollen das Data Mesh Konzept und dessen zentrale Bestandteile näher erläutert werden.

Dezentralisierung – Daten werden dezentral in Domänen erzeugt, verarbeitet und konsumiert

Mit einem Data Mesh gehen wichtige Grundelemente einher, die das Fundament für diese Art der Datenarchitektur bilden. Hierbei steht u.a. das Konzept der Dezentralisierung im Vordergrund.

Im Mittelpunkt des Dezentralisierungs-Gedankens finden sich sogenannte Datendomänen wieder. In einer Data Mesh Architektur definiert eine Bank basierend auf Geschäftsfunktionen Datendomänen, die ihre bereichsspezifischen Daten generieren, sammeln und auch vorrangig nutzen. Domänen Beispiele innerhalb einer Bank könnten dementsprechend Kredite, Versicherung, Leasing und Kunde sein. Innerhalb einer Domäne definiert ein Datenarchitekt das logische Datenmodell und die wichtigsten Datenobjekte. Ausschlaggebend ist in einem Data Mesh, dass die verschiedenen Datenobjekte einer Ownership bedürfen, sodass die Verantwortung für die Qualität und die Wiederverwendbarkeit der Daten gewährleistet werden kann. Aus diesem Grund werden sogenannte Datenprodukt-Owner innerhalb der Domänen festgelegt, denen diese Verantwortung zuteilwird.

Die Definition verschiedener Datendomänen trägt gemeinsam mit der damit einhergehenden Zuteilung der Verantwortlichkeit (Ownership) sowie der fachlichen Expertise innerhalb der Domänen dazu bei, qualitativ hochwertige Daten dezentral zu pflegen. Hierin liegt ein maßgeblicher Vorteil gegenüber starren, zentralen Ansätzen, bei denen klare Verantwortlichkeiten oft fehlen und die fachliche Expertise meist nicht so nahe an den Daten selbst liegt.

Datenprodukte – Bereitstellung wertvoller Informationen innerhalb des Unternehmens

Im Rahmen einer Data Mesh Architektur stellen die bereits erwähnten Datenprodukte einen weiteren Schlüsselfaktor dar. Auch wenn die Ownership für Daten dezentral in den jeweiligen Domänen liegt, können und sollen Daten in vielen Fällen dennoch von mehreren Domänen verwendet werden. Aus diesem Grund sind die jeweiligen Domänen dafür verantwortlich, ihre Daten auch für andere Datendomänen nutzbar zu machen und zu teilen, und zwar in Form von Datenprodukten.

Datenprodukte sind in sich geschlossene, geprüfte, qualitativ hochwertige Datenobjekte einer Domäne. Neben den enthaltenen Informationen selbst beinhalten Datenprodukte auch die Informationen zu Quellsystemen, durchgeführten Transformationsschritten an den Rohdaten sowie Nutzerrechten. Dies soll dazu beitragen, dass Datenprodukte nicht nur in der erzeugten Domäne selbst, sondern auch von Datenkonsumenten anderer Domänen bedenkenlos genutzt und ggf. für ihre eigenen Informationszwecke erweitert werden können.

Ein Beispiel für ein solches Datenprodukt stellen bspw. Kundenstammdaten aus dem CRM-System einer Sales-Datendomäne dar, welche interne und ggf. externe Daten Qualitäts-Checks durchlaufen haben. Ein solches Datenprodukt ist in diversen Datendomänen von Interesse und kann als Basis für weitere Analysen und Datenanreicherungen dienen. Weitere Datenprodukte könnten u.a. Diverse Kredite oder SCHUFA Daten sein.

Um eine hohe Qualität von Datenprodukten zu gewährleisten, müssen Anreize geschaffen werden. Eine Möglichkeit dafür besteht darin, die zuvor erwähnten Datenprodukt-Owner für die Qualität und den Wert der Daten zu belohnen, was beispielsweise am Ausmaß der Datenprodukt-Nutzung innerhalb des Unternehmens bemessen werden könnte. Somit haben Datenprodukt-Owner ein eigenes Interesse daran, hochwertige und auch in anderen Domänen nutzbare Datenprodukte zu schaffen.

Die Expertise der Datenprodukt-Owner ist vermehrt fachlicher als technischer Natur, weshalb in jeder Datendomäne ein ganzes Datenprodukt-Team agieren sollte.

Datenprodukt-Teams – Autonome, interdisziplinäre Teams

Datenprodukt-Teams sind in jeder Datendomäne angesiedelt und somit dezentralisiert – ein grundlegender Unterschied zu zentralisierten Data Warehouse- und Data Lake-Teams. Sie arbeiten autonom, um ihre Datenprodukte innerhalb der (vom Architekten der Datendomäne) festgelegten Leitplanken zu entwickeln.

Zwei Rollen innerhalb eines Datenprodukt-Teams wurden bereits genannt – der Architekt der Datendomäne sowie der bzw. die Datenprodukt-Owner, welche domänenspezifische, fachliche Expertise einbringen. Des Weiteren gehören Data Engineers zu diesem Team, deren Aufgabe im Aufbau skalierbarer Datenmodelle und Data Pipelines besteht. Je nach Bedarf werden Data Scientists zum Trainieren fortgeschrittener analytischer Modelle als Bestandteil der Datenprodukt-Teams benötigt.

Durch den Aufbau und die Organisation dieser dezentralen, autonomen und interdisziplinären Datenproduktteams können einige der grundlegenden Schwächen zentralisierter Teams ausgehebelt werden. Der herausragende Vorteil besteht darin, dass dezentrale Teams schnell und flexibel auf sich ändernde fachliche Bedarfe reagieren und an entsprechenden Lösungen arbeiten können. Das fachliche Domänen Know-How befindet sich, anders als bei zentralen Ansätzen, inmitten dieser Teams, wodurch technische Implementierungen stets in Einklang mit den domänenspezifischen, fachlichen Anforderungen umgesetzt werden können. Zudem sollten Datenprodukt-Teams keinen Projektcharakter haben, sondern nach der Entwicklung von Datenprodukten dauerhaft zusammenarbeiten können, sodass auch die Wartung der Datenprodukte und dessen hohe Qualität gewährleistet ist. Nicht zuletzt wird dadurch eine hohe Verfügbarkeit und schnelle Antwortzeit für die Abwicklung domänenspezifischer Bedarfe erreicht, wodurch ein weiterer Nachteil zentraler Ansätze behoben werden kann.

Ein gängiges Beispiel, in dem das Data Mesh Konzept gegenüber herkömmlichen Architekturen einen Vorteil bietet, ist die Kundenberatung bei einem Kreditabschluss. Bei Kreditabschluss müssen Datenprodukte aus verschiedenen Daten Domänen verknüpft werden, um dem Kundenberater kurzfristig eine 360 Grad Sicht auf den Kunden, den er berät.

Dezentraler Ansatz für zentralisierte Probleme

Das Data Mesh bietet mit ihrem dezentralen Ansatz Lösungen für zentralisierte Probleme.  Daten werden in Form von Datenprodukten, die von autonomen interdisziplinären Teams erstellt und betrieben werden, in verschiedenen Domänen verwaltet, verarbeitet und genutzt. Dies führt u.a. zu mehr Agilität bei der Datenverarbeitung und einer breiteren Wissensverteilung.

Voraussetzung sind z.B. eine klar definierte Daten-Ownership und eine höhere Zahl an Mitarbeitern, die mit Daten arbeiten können. Auch ein Datenkatalog macht den Aufbau eines Data Meshs wesentlich einfacher.

Obwohl das Data Mesh eine mögliche Lösung für viele datenbezogene Probleme im Bankensektor ist, ist es nicht immer die beste oder einzige Lösung.

Weiterhin gilt: Die geeignetste Datenarchitektur hängt stark von den konkreten Use Cases ab. Oft lohnt sich auch eine Kombination mit z.B. dem Konzept einer Data Fabric, um wiederum die Schwachpunkte des dezentralen Ansatzes auszugleichen.


Falls Sie am schrittweisen Aufbauen eines Data Meshs interessiert sind, finden Sie in der entsprechenden PwC Studie Informationen darüber, wie man eine Datenplattform nach dem Data Mesh Prinzip aufbauen kann.


Joshua Wenn - Manager, PwC Deutschland

Joshua Wenn, Pw

Joshua Wenn ist Koautor des Beitrags. Er ist Manager im Bereich Products & Technology bei PwC Deutschland und u.a. im Bereich FS Advisory mit einem Fokus auf Daten Management und Digitalen Transformationen tätig. In dieser Rolle unterstützt er Kunden hinsichtlich der Optimierung ihrer Data Management Capabilities e.g. Datenarchitekturen, Datenqualität, Datenstrategie, so wie der Implementierung von neuen Tools.

 

Bicheng Zhou - Senior Associate, PwC Deutschland

Bicheng Zhou, PwC

Bicheng Zhou ist Koautor des Beitrags. Er ist Senior Associate bei PwC Deutschland im Bereich Data & Analytics und hat vertiefte Kenntnisse über Datenarchitekturen.

 

 

Alexander Arnold - Senior Associate, PwC Deutschland

Alexander Arnold, PwC

Alexander Arnold ist Koautor des Beitrags. Der Wirtschaftsingenieur (M.Sc.) ist Senior Associate bei PwC Deutschland im Bereich Big Data & Advanced Analytics und arbeitet an der Konzeptionierung und Implementierung technischer Lösungen in den Bereichen Data Architecture, Data Analytics und Business Intelligence.


Partner des Bank Blog: Ride PWC

PwC ist die führende Wirtschaftsprüfungs- und Beratungsgesellschaft in Deutschland und Partner des Bank Blogs.

Mehr über das Partnerkonzept des Bank Blogs erfahren Sie hier.

Über den Autor

Stephan Bautz

Stephan Bautz ist Senior Manager bei PwC Deutschland im Technology Consulting Team und berät in den Bereichen (Big) Data Architecture, Data Management & Data Governance. Der Wirtschaftsinformatiker ist gleichzeitig bei der Bitkom e.V. Vorstandsmitglied des Arbeitskreis Big Data & Advanced Analytics.

Vielen Dank fürs Teilen und Weiterempfehlen


Mit dem kostenlosen Bank Blog Newsletter immer informiert bleiben:

Anzeige

Get Abstract: Zusammenfassungen interessanter Businessbücher

Kommentare sind geschlossen

Bank Blog Newsletter abonnieren

Bank Blog Newsletter abonnieren