Banken müssen jederzeit in der Lage sein, ihre verschiedenen Risikobereiche zu überblicken und an die Aufsicht zu melden. Das Baseler Committee on Banking Supervision legt dies in der Richtlinie 239 fest (BCBS239). Sie fordert außerdem, dass Aktualität, IT-Konformität und Qualität von Risikoinformationen und verwandten Daten sichergestellt sind.
Aufgabenstellung
Unser Kunde aus der Finanzindustrie möchte sein Finanz- und Risikoberichtwesen entsprechend anpassen. Dafür hat er eine Digitale Analyse und Reporting Plattform (DRAP) aufgebaut. Mit ihr soll ein Datenhaushalt für das Unternehmen aufgebaut werden. Er soll insbesondere qualitätsgesichert, hochwertig, aktuell und kommentiert sein. Dafür stellt DRAP verschiedene Funktionen zur Verfügung, z.B. die Reportdarstellung, Analyse und Datenbeladung (inkl. Statustracking für definierte Anwendungsgebiete).
DRAP nutzt nicht nur bestehende Daten aus dem Financial Data Warehouse (FDW). Es berücksichtigt auch einzelne Zulieferungen individueller Lieferanten. Mit diesen Daten können über DRAP verschiedene Berichte vom Anwender erstellt werden. Das beinhaltet beispielsweise den Kreditrisikobericht (KBB) oder den Gesamtrisikobericht (GRB).
Lösungsansatz
Der Datenhaushalt soll einerseits qualitätsgesichert und metadatengetrieben verwaltet werden. Andererseits müssen ausgewählte Zulieferungen in einen gemeinsamen fachlichen und referenzierbaren Kontext gebracht werden können. Das Konzept der Datenausschnittsbildung und der Versionierung von Lieferungen (Lieferversionen) ermöglicht beides. Sie erweitern die bestehende persistierte Metadatenschicht Generic Logging Area (GLA). Ihre Funktion soll im Folgenden dargestellt werden.
Die Lieferversion
Die oben genannten Berichte setzen sich aus diversen Datenlieferungen zusammen. Sie haben unterschiedliche Granularitätsstufen und werden zu einem bestimmten Stichtag geliefert (in der Regel der Ultimo einer Berichts- und Aggregationsperiode). Die Lieferungen haben unterschiedliche Datei- und Strukturformate: xml, xslx und csy in horizontaler und Key-Value Modellierung. Nicht alle Zulieferungen sind jedoch nur für einen Bericht relevant – häufig haben sie einen periodenübergreifenden Charakter. Außerdem sollen auch bereits vorläufige Ergebnisse in die Berichtserstellung einfließen. Das bedeutet, dass zu einem Sachverhalt und damit von einem Lieferanten ggf. mehrere Lieferungen pro Berichtsperiode erfolgen.
Bei der Erstellung eines Gesamtdatenhaushalts müssen daher verschiedene Informationen zentral hinterlegt werden. Das betrifft die Datengüte, den Lieferzeitpunkt und die Priorität. Die Daten müssen zudem pro Stichtag rechtzeitig zur Verarbeitung bereitstehen. Für all diese Anforderungen wurde die Entität Lieferversion geschaffen. Mit ihr können die Informationen verwaltet und entsprechend referenzierbar gemacht werden.
Eine Lieferversion (LV) ist ein Datenmarker, der metadatengetriebene Informationen enthält. Sie beziehen sich jeweils auf ein Lieferobjekt eines Zulieferers zu einem Zeitpunkt. So erhält jede Zulieferung gemäß dem Lieferzeitpunkt eine aufsteigende technische ID – die Lieferversionsnummer. Mit ihr kann die aktuellste Lieferung pro Stichtag herangezogen werden. So ist es beispielsweise möglich, einzelne Lieferungen pro Stichtag nach einer Korrektur erneut zur Verfügung zu stellen. Hierbei ist sicherzustellen, dass keine Überschreibung einzelner Lieferungen erfolgt. Zusätzlich zur ID erhält jedes zuvor definierte Lieferobjekt auch einen Lieferversionsnamen zur fachlichen Repräsentation. Eine Lieferversion bündelt die je aufgerufenen Datenintegrationsprozesse je Lieferobjekt. Diese sind über folgende Layer einer Integration Run-Sequenz zusammengefasst:
- Landing (LDG)-Layer: Relationale 1:1 Ablage von Daten aus Lieferobjekten
- Staging (STG)-Layer: Fachliche und technische Transformation
- CORE-Layer: Finale technische Integration der Daten (Historisierung/ Versionierung, Ermittlung des ID-Kontextes des DWH)
Jede Lieferversionssequenz erhält schließlich einen Start- und einen Endzeitpunkt (Verarbeitungszeitstempel). Eine Statusinformation gibt zusätzlich an, ob der Prozess gestartet, erfolgreich abgeschlossen oder gescheitert ist. Über die genannten Verarbeitungsschichten (LDG, STG, CORE) werden standardmäßig weitere Entitäten der GLA mit Metadaten befüllt. In der LDG-Layer werden beispielsweise Dateiname und Stichtag technisch persistiert. Über Link-Tabellen sind diese Informationen anhand der Lieferversionsentität zugänglich.
Datenausschnitt
Die Lieferversion ist also eine übergeordnete Sequenz über alle notwendigen Datenintegrationsprozesse einer Zulieferung. Analog dazu bündelt ein Datenausschnitt (DA) mehrere fachlich zusammenhängende Lieferversionen. Gesteuert wird der Zusammenhang zentral über eine Konfigurationstabelle. Während der Berichtserstellung wird er je Lieferversion abgefragt.
Ein Datenausschnitt beinhaltet normalerweise mehrere Lieferversionen, pro Lieferobjekt jedoch höchstens eine. Diese ist gemäß einer Datenpriorisierung ausgewählt. Andererseits kann eine Lieferversion in mehreren Datenausschnitten vorhanden sein, denn der letzte Datenausschnitt spiegelt immer den besten gesamtheitlichen Informationsstand wider. Das hat den Vorteil, dass ein Lieferobjekt nicht zwingend mehrfach geladen, sondern exakt einmal vorliegen muss. Wie die Darstellung im Datenmodell zeigt, handelt es sich hier um eine N:M-Zuordnung.
Datenauschnitterstellung
Für die Erstellung eines Datenausschnitts wurden zwei Zusammensetzungsprozesse etabliert:
Komposition nach Auswahlliste (Cherry-Picking)
Hier entscheidet der Berichtersteller manuell, welche erfolgreich erzeugte Lieferversion zu dem betrachteten Stichtag relevant sein soll. Die Auswahl erfolgt über eine Benutzeroberfläche.
Komposition nach Datenpriorisierung
Hier werden alle Lieferversionen ausgewählt, die für den fachlichen Zusammenhang zuletzt freigegeben und am höchsten priorisiert wurden. Die Auswahl bildet dann automatisch den nächsten Datenausschnitt.
Nutzen & Vorteile
Lieferversionen und Datenausschnitte ermöglichen konsistente Datenhaushalte in komplexen, heterogenen Datenreifungsprozessen. Diese können z.B. im Rahmen des Berichtswesens als Datamart adressiert und aufbereitet werden. Einzelne Teillieferungen werden zu einem fachlich zusammenhängenden Verarbeitungskontext gebündelt. Durch die Datenausschnitte werden sie virtuell in neue Zeitscheiben übertragen. Damit genügt die einfache Beladung einer Zulieferung, um sie in diversen Datenlagen zu bündeln. Letztere entstehen beispielsweise durch neue Zulieferungen anderer Lieferanten. Es ist außerdem möglich, eine historische (Then-Then)-Betrachtung herzustellen. So kann jederzeit genau ausgewiesen werden, welche Informationen in einen Risikobericht geflossen sind und damit der Aufsicht übermittelt wurden.
