Effizientere Datennutzung im Banken- und Finanzsektor mit Data Spine und Data Mesh
Endava
Manchmal entsteht Fortschritt nur, wenn man genau das Gegenteil von dem tut, was man bisher getan hat. Diese Erkenntnis setzt sich derzeit in der Data Science durch: Dominieren aktuell zentrale Datenspeicher wie Data Warehouses und Data Lakes, könnte künftig das Data Mesh, eine verteilte Struktur ohne ein solches zentrales Repository, die Lösung sein. Ganz ohne zentrale Infrastruktur, um die Daten zu verbinden, funktioniert es allerdings nicht – hier kommt der Data Spine ins Spiel. Toby Dixon, Geschäftsführer bei Endava in Frankurt, erklärt die Hintergründe mit Blick auf die Herausforderungen von Finanzdienstleistern.
von Toby Dixon, Endava
Der Finanzsektor gehört seit Jahren zu den größten Datenproduzenten und jede Transaktion trägt zu weiterem Datenwachstum bei. In einer Auswertung aus dem Jahr 2018 lagen die Finanzdienstleistungen auf Platz drei der untersuchten Branchen nach Industrie und Handel.Aufgrund der schieren Menge an Daten und unterschiedlichen Anforderungen im Unternehmen stoßen zentralistische Konzepte alleine heute oft an ihre Grenzen.”
Im Gegensatz zur Ablage in einem oder mehreren zentralen Repositories werden Datenauswertungen oft isoliert von einzelnen Abteilungen für spezifische Zwecke durchgeführt, was den Effekt haben kann, dass diese Datensätze an anderer Stelle nicht nutzbar sind. Das kann wiederum Mehrarbeit in Form von Formatumwandlungen bedeuten. Dieser Zustand ist nicht ideal und Unternehmen brauchen einen Ansatz, um Daten über das gesamte Unternehmen hinweg effizient zusammenzuführen und nutzbar zu machen.
Data Mesh ist das Gegenteil der bislang genutzten Modelle: eine dezentrale Architektur, die unter anderem diesen Austausch vereinfachen soll.”
Probleme der zentralen Datenhaltung
Heutige Datenarchitekturen sind in der Regel zentral ausgerichtet: In einem Data Lake oder Data Warehouse fließen alle Daten zusammen, von wo sie für Analysen wieder „angezapft“ werden. Das kann zu einigen Problemen führen, etwa fehlende Informationen zur Herkunft der Daten, fehlende Metadaten oder mangelnde Datenqualität an sich. Der Datenursprung kann meistens nicht bis zur eigentlichen Quelle zurückverfolgt werden.
Der Weg über eine zentrale Schnittstelle sorgt zudem für eine Entkopplung von Datenproduktion, -verarbeitung und -nutzung. Hochspezialisierte Data Scientists, die für die Analysen und Dashboards für die Exekutivebene zuständig sind, sind in ihren eigenen technischen Teams organisiert und haben wenig Berührungspunkte mit den Fachabteilungen, die die Rohdaten erzeugen, und mit den Teams, die letztendlich datenbasierte Entscheidungen treffen sollen.
Hierbei geht viel Kontext verloren und für die datenerzeugenden Abteilungen entsteht auch kein Anreiz, auf eine hohe Datenqualität zu achten, da sie die Verantwortung an ein zentrales Datenteam abgeben.”
Überhaupt sind die Verantwortlichkeiten für die Unternehmensdaten auf zahlreiche Schultern verteilt, die sich teilweise überlappen, was ebenfalls zu Problemen und Unklarheiten führen kann.
Daten als Produkt – die dezentrale Datenhaltung
Der neue Ansatz ist nun, die Datenarchitektur dezentral zu gestalten, gleichzeitig aber auch die Verantwortung der Teams zu verändern. Anstatt einer zentralen Stelle trägt stattdessen immer ein Data Owner pro Team die Verantwortung, oftmals übernimmt der jeweilige Product Owner diese Funktion. Diese Experten können dann andere Teams beim besseren Verständnis der eigenen Daten unterstützen.
Außerdem ist die Verantwortung für Daten nun klarer geregelt:
Die Teams, die die Daten produzieren, sind auch für ihre Qualität und Vollständigkeit verantwortlich. Data Scientists und Engineers müssen dann allerdings auch Teil der datenproduzierenden Teams werden und dürfen nicht mehr isoliert arbeiten.”
Nur so können sie ihre Kollegen dabei unterstützen, Rohdaten in konsumierbare Datenprodukte umzuwandeln und neue Datenprodukte zu entwickeln.
Darüber hinaus ist wichtig zu wissen, wo sich die Daten befinden, wie auf sie zugegriffen wird und wie sie verwaltet werden. Auch gilt es, über die Werkzeuge und Fähigkeiten zu verfügen, um Daten konsistent zu bearbeiten und für das gesamte Unternehmen nutzbar zu machen. Wichtig dafür sind eine virtuelle Datenschicht und Metadaten, ein Datenkatalog und Suchfunktionen, die diese Funktionen bereitstellen und es ermöglichen, sinnvoll darauf aufzubauen. Diese Schicht kann als Data Spine bezeichnet werden – sie ermöglicht eine zentrale Datenautobahn, zu der die verschiedenen Systeme, in denen sich Daten befinden, sozusagen eine Auffahrt haben. Damit können Finanzdienstleister die Herausforderung lösen, dass ihre verschiedenen Systeme nicht miteinander interagieren können, ohne dafür extra ein zentrales Repository einrichten zu müssen, in dem die Daten gesammelt werden. Auf dieser Grundlage können Daten, die von den Data Ownern angeboten werden, ausgetauscht werden, um mit ihnen zu arbeiten.
Data Spine und Data Mesh einführen – das ist zu beachten
Autor Toby Dixon, Endava
Toby Dixon ist in Frankfurt ansässig, ist Geschäftsführer in Frankfurt und verantwortet den Bereich Finanzdienstleistungen. Er hat mehr als 25 Jahre Erfahrung in der Führung und Gestaltung von großen IT-Projekten, -Programmen und -Portfolios in einer Reihe von Branchen, wodurch er wertvolle Einblicke in IT-Outsourcing-Projekte gewinnen konnte. Als Unternehmensgründer und -inhaber stieß Toby im Jahr 2014 durch eine Fusion mit einer Beratungsfirma aus dem Finanzsektor zu Endava (Website).
Toby Dixon ist in Frankfurt ansässig, ist Geschäftsführer in Frankfurt und verantwortet den Bereich Finanzdienstleistungen. Er hat mehr als 25 Jahre Erfahrung in der Führung und Gestaltung von großen IT-Projekten, -Programmen und -Portfolios in einer Reihe von Branchen, wodurch er wertvolle Einblicke in IT-Outsourcing-Projekte gewinnen konnte. Als Unternehmensgründer und -inhaber stieß Toby im Jahr 2014 durch eine Fusion mit einer Beratungsfirma aus dem Finanzsektor zu Endava (Website).Der Finanzsektor eignet sich sehr gut für den Data-Mesh-/Data-Spine-Ansatz, da hier in der Regel eine entsprechende Unternehmensgröße und -verzweigung gegeben ist. Bei kleineren Unternehmen treten die Probleme der zentralistischen Datenspeicherung dagegen nicht so stark auf.
Unternehmen, die den Ansatz implementieren wollen, müssen sich zunächst die hohen Governance-Anforderungen vergegenwärtigen. In der verteilten Datenspeicherung mit zentralem Datenaustausch spielt Interoperabilität eine wichtige Rolle. So muss der Data Spine Interoperabilität auf Protokoll-, Datenmodell- und Sicherheitsebene etablieren. Dies ermöglicht einen Federation-Ansatz, in dem kein gemeinsames Datenmodell oder -format vorgeschrieben ist. Entscheidend ist zudem eine starke Data Governance Policy, um Chaos zu vermeiden. Eine besondere Rolle kommt dabei den Data Ownern zu, die verantwortlich für die Einhaltung der Policy sind.
Die Datenprodukte wiederum sollen für den Datenkonsumenten selbsterklärend sein, sodass sie direkt selbstständig genutzt werden können. Bei der Erstellung muss daher viel Wert auf eine konsistente Beschreibung von Semantik und Syntax der Daten gelegt werden. Am besten werden auch Beispieldatensätze ergänzt.
Da der Data Spine eine zentrale Komponente der IT-Infrastruktur sein soll, muss er leistungsfähig sein und einen hohen Durchsatz unterstützen. Denn wenn neue Systeme und Datenquellen hinzukommen, müssen diese problemlos an die Datenautobahn angeschlossen werden können.”
Fazit
Zentrale Datenplattformen geraten zunehmend an ihre Grenzen – auch und vor allem im Finanzsektor, wo das Datenwachstum ungebremst ist und die Anforderungen an Geschwindigkeit hoch sind. Der Paradigmenwechsel von der zentralen Datenaggregation zu einer verteilten Infrastruktur mit Datenprodukten und konsistenter Metadatenverwaltung kann dabei helfen, Daten sinnvoller und flexibler zu nutzen.Toby Dixon, Endava
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/146181
Schreiben Sie einen Kommentar