Ein leicht verständliches Datenmodell bildet in der apoBank die Basis, um Mitarbeitern im Self-Service die Möglichkeit zu geben, ohne tiefe IT-Kenntnisse schnell Reports und Datenausleitungen zu erstellen. Flankierend zum Datenmodell wurde zudem ein Data-Governance-Tool eingeführt, welches es den Mitarbeitern ermöglicht, sich über Daten, Zuständigkeiten und Datenflüsse zu informieren. So entstehen im Reporting-Alltag große Mehrwerte bei gleichzeitiger Ausrichtung der kompletten Architektur an den Vorgaben der BCBS239 und MaRisk.

Zielpublikum: Fachanwender Finanzindustrie, Data Governance Manager, DWH-Verantwortliche, Data Manager, BI-Analysten
Voraussetzungen: keine
Schwierigkeitsgrad: Basic

Extended Abstract:
Daten spielen in vielen Unternehmen eine zunehmend zentrale Rolle. Dies betrifft sowohl die interne Steuerung als auch Entscheidungen über Maßnahmen für die Ausrichtung des Vertriebs. Dabei werden die Daten im Sinne der klassischen Business Intelligence in Reports und Ad-hoc-Abfragen, aber auch im Umfeld der Advanced Analytics mit Algorithmen der Künstlichen Intelligenz genutzt.

Ziel der Datenbereitstellung muss es mehr und mehr sein, auch Mitarbeiter ohne tiefe (technische) Kenntnisse der Datenmodellierung in die Lage zu versetzen, Auswertungen zu erstellen und Daten ohne Hilfe von Datenexperten zu nutzen. Dies ist aber auf Grund der zum Teil komplexen Datenmodelle und fehlender Beschreibungen der Daten für Fachanwender nur sehr schwer möglich. In dieser Hinsicht unterscheiden sich Banken kaum von anderen Unternehmen. In Banken kommt jedoch hinzu, dass regulatorische Vorgaben der BCBS239 und der MaRisk fordern, dass es eine ausgeprägte Data Governance für insbesondere jene Daten gibt, die für die Risikosteuerung verwendet werden. Es muss also in der gesamten Architektur neben den eigentlichen Daten insbesondere auch die Erfassung von Metadaten, Zuständigkeiten und Data Lineage adressiert werden.

Die Deutsche Apotheker und Ärztebank e.G. (apoBank) arbeitet seit einigen Jahren an der Implementierung und Erweiterung des 'Fachlichen Datenmodells' sowie den flankierenden regulatorischen Maßnahmen. Der Anspruch des Datenmodells im Sinne der 'Abbildung der Fachsprache der Bank' ist sehr herausfordernd, schafft aber enorme Potenziale bei der Befähigung der Banker, eigenständig Reports und Analysen auf den Daten zu erstellen. Da das Kernbanksystem heute ein eher technisches Datenmodell besitzt, war der Weg der Harmonisierung und Transformation der Daten in die Fachsprache komplex. Ziel des Datenmodells ist es, historisierte und materialisierte Tabellen zu erschaffen, die schnell und performant abgefragt werden können. Dazu wurde auf der einen Seite darauf geachtet, dass die Entitäten und Attribute des Datenmodells exakt in der Sprache der Fachanwender benannt wurden, gleichzeitig aber möglichst wenig Joins bei Abfragen benötigt werden. Zudem werden umfangreiche Metadaten erfasst, damit die Nutzung der Daten nicht zu unterschiedlichen Interpretationen führt. Der eigentliche Zugriff erfolgt dann mit gängigen Reportingtools und einfacher SQLs. Alle Informationen rund um das Datenmodell werden im Data-Governance-Tool dataspot. vorgehalten. Die Mehrwerte dieses Ansatzes zeigten sich bereits sehr schnell nach der Einführung der ersten Versionen des fachlichen Datenmodells mit seinen Metadaten.

Die Nutzung von dataspot. als integraler Bestandteil der Data-Warehouse-Architektur begann Mitte 2023. Dataspot. wird sukzessive mit den relevanten Informationen aus dem Data Warehouse und den umliegenden Systemen um die Metadaten zu Datenquellen, Data Lineages und Datenverwendungen sowie organisatorische Zuständigkeiten ergänzt. Diese orientieren sich zu Beginn an den Vorgaben der BCBS239 und MaRisk, sollen aber dauerhaft auf andere Datenbereiche ausgeweitet werden.

Das Data-Governance-Tool dataspot. wurde innerhalb von wenigen Monaten eingeführt. Startpunkt war die Durchführung eines Proof of Concepts anhand von konkreten praktischen Beispielen. Im Zentrum der Betrachtung standen: 

• Erfassung und Pflege von Metadaten 
• Verwaltung und Visualisierung der fachlichen und technischen Data Lineage 
• Fachliche Modellierung von Data-Dictionary-Objekten und grafische Darstellung 
• Erstellung und Pflege von Rollen & Verantwortungen 

Nach der Entscheidung für dataspot. erfolgte der Aufbau der Data-Excellence-Organisation und die Einführung der Software nach der dataspot.-Blueprint-Methode. Diese beinhaltet sowohl den unternehmensweit geschaffenen Metadatenstandard für die apoBank als auch die Modellierungsvorgaben (Sprache, Umfang, Granularität, ...) für die Datenmodelle: 

• Welche Arten von Metadaten (technische, fachliche, Governance-Metadaten) werden erfasst? 
• Welche Metadatenmodelle und Elemente werden gepflegt und von wem? 
• Wie hängen die Metadatenmodelle zusammen? Welche Zusammenhänge werden modelliert? 
• Wie werden die Informationen so plakativ mit dem Fachlichen Datenmodell des DWH verbunden, damit der Anwender das Tool auch in der Praxis als Mehrwert im täglichen Reportingumfeld nutzt?

Ein besonderes Augenmerk wurde zudem auf die Anbindung von technischen Metadaten aus dem Data Warehouse und den angebundenen Quellsystemen gelegt, denn nur wenn die Aktualisierung automatisch erfolgt, kann gewährleistet werden, dass die vorgehaltenen Modelle auch aktuell sind. Die Verbindung der fachlichen mit den technischen Datenmodellen ist dann die zentrale Voraussetzung für eine durchgängige End-to-End-Lineage. Ebenfalls im Fokus standen die Transformationen im Metadaten-Tool: Um die vertikale und horizontale Lineage gut unterscheiden zu können, wurden 12 verschiedene Stereotype für die Arten der Mappings definiert. Diese determinieren die notwendigen Workflows zur Erfassung von Freigabe von Änderungen, die ebenfalls konfiguriert wurden.

Insgesamt bildet das Data Warehouse mit dem Fachlichen Datenmodell in Kombination mit dataspot. und den darin enthaltenen Metadaten-Beschreibungen nun eine Basis, apoBanker schrittweise in Eigenverantwortung an die richtigen und relevanten Daten zu bringen und in Zukunft konform zu regulatorischen Anforderungen Erweiterungen in der Architektur zu implementieren.