In dieser Studie wird eine Business Intelligence-Referenzarchitektur für Banken und Versicherungen entwickelt, die den aktuellen Regularien von Finanzdienstleistungsunternehmen gerecht wird. Die Regularien für Banken und Versicherungen sind aufgrund der Finanz-/Wirtschaftskrise im letzten Jahrzehnt stark gestiegen. Die Architekturen der Unternehmen müssen entsprechend den Anforderungen ausgelegt sein, die aktuell und in Zukunft gelten. Solvency II fordert die Übermittelung von ca. 5000 Kennzahlen an die Aufsichtsbehörden. Werden diese nicht rechtzeitig aufgrund nicht intakter IT-Architekturen übermittelt, kann schlimmstenfalls die Versicherungslizenz entzogen werden. Die Anforderungen ergeben sich aus den aktuellen Regularien wie den Grundsätzen für die effektive Aggregation von Risikodaten und die Risikoberichtserstattung (BCBS239). Diese Studie analysiert die einzelnen Anforderungen, die sich aus den Gesetzen und den Verlautbarungen ergeben und fasst diese zusammen. Aus den gewonnenen Ergebnissen der Anforderungsanalyse wird eine BI-Architektur entwickelt und diskutiert. Als Ergebnis steht eine Referenzarchitektur zur Verfügung, die den Regularien gerecht wird.

Textprobe: Kapitel 4.2.5. Ladekomponente: Nachdem die Daten transformiert wurden, befinden sich die bereinigten und angemessen aufbereiteten Daten in der Rohdatenschicht. Die Daten sind für die Speicherung in Core Data Warehouse, Auswertungsdatenbank sowie in den Data Marts geeignet. Zwei Ladekomponenten sind für die Weiterleitung zuständig. Die erste Komponente ist für die Übertragung der Daten aus der Rohdatenschicht in das Core Data Warehouse zuständig. Die zweite Komponente überträgt dann die Daten aus dem Core Data Warehouse in die Auswertungsdatenbank bzw. von der Auswertungsdatenbank in die Data Marts - dorthin werden die auswertungsspezifischen Daten (wie beispielsweise die aggregierten Daten) übertragen. Datenbankmanagementsysteme nutzen dafür das jeweils zu Grunde liegende Ladewerkzeug (etwa den SQL*Loader oder PowerCenter von Informatica). 4.2.6. Core Data Warehouse: Das Core Data Warehouse wird auch als Basisdatenbank bezeichnet. Es ist zwischen der Rohdatenschicht und der Auswertungsdatenbank - vgl. Kapitel 4.2.7 - in der Referenzarchitektur angesiedelt. Weitere gebräuchliche Bezeichnungen für diese Datenbank sind beispielsweise konsolidierte Datenbank, Datendrehscheibe oder operative Datenbasis. Auf einer feingranularen Ebene enthält das Core Data Warehouse die gesamten Daten des Data Warehouse. Dadurch ist die Basis für die spätere Analyse gegeben. Das Core Data Warehouse ist nicht nach den Analysekomponenten entwickelt, sondern nach den Anforderungen des Datenbankentwurfes konzipiert. Das heißt, dass die Relationen sich in der dritten Normalform befinden sollen (Ziel ist eine redundanzfreie Speicherung). Des Weiteren ist die Datenhaltung bereinigt und historisiert durchzuführen. Damit stellt das Core Data Warehouse eine integrierte Datenbasis für unterschiedliche Analysen zur Verfügung - die allerdings unabhängig von den konkreten Analysen ist. Die Daten sind also nicht voraggregiert, um beispielsweise bestimmte Analysen zu beschleunigen. Die Hauptaufgabe der Komponenten ist es, das Data Warehouse mit bereinigten Daten zu versorgen. Aus diesem Grund ist streng genommen eine physikalische Speicherung der Daten nicht nötig und redundant, weil die kompletten Daten in den Datenwürfel geladen werden. Die redundanzfreie Speicherung und das neutrale Datenformat als Vorteile stehen der redundanten Speicherung eines großen Datenbestands als Nachteil gegenüber. Aus dem genannten Grund wird in der Praxis die Datenbank oft nur virtuell realisiert. Trotzdem nimmt das Core Data Warehouse eine zentrale Bedeutung für die Data-Warehouse-Architektur ein. Charakterisiert wird das Core Data Warehouse wie folgt: 1 Die Schemata der verschiedenen Datenquellen und die integrierten Daten liegen vor (integrierte Sicht). 2 Alle Daten - aktuelle und historische - liegen in der Datenbank vor. Die Daten sind in der niedrigsten Granularität - auf der Ebene der Detaildaten –vorhanden. 3 Die Modellierung ist nicht speziell auf eine Auswertung ausgelegt, sondern auf Anwendungsneutralität. Es gibt keine Aggregate (wie sie etwa mit Blick auf typische OLAP-Anfragen anzutreffen sind). 4 Die Daten werden nach einer definierten Zeit an die Auswertungsdatenbanken übermittelt. Dort kann der Detailierungsgrad für den jeweiligen Auswertungszweck verdichtet werden. 5 Die Aktualisierung der Datenbank kann nach dem Aktualisierungsbedarf gesteuert werden. Durch eine häufigere Aktualisierung kann so eine zusätzliche Konsistenzprüfung vermieden werden. 6 Der Prozess der Datenbereinigung fand bereits in der Rohdatenschicht statt, deshalb enthält das Core Data Warehouse ausschließlich bereinigte Daten. Zu den Funktionen des Core Data Warehouse gehören: 1 Es nimmt alle notwendigen Daten, die für Auswertungen benötigt werden, in Form eines (logisch) zentralen, operativen Datenlagers auf und integriert die Daten in eine Datenbank. 2 Es hat die Funktion der Distribution, indem es die Verteilung der Daten aus der Rohdatenschicht an die Auswertungsdatenbanken übernimmt. 3 Durch die bereinigten und angereicherten Daten, ist die generelle Datenqualität sichergestellt. Das Core Data Warehouse kann als die einzige Quelle der Wahrheit - engl. single point of truth (SPOT) - bezeichnet werden, da alle Daten im Zusammenhang mit dem Repository konsistent im Core Data Warehouse zusammengeführt werden. Durch die oben genannten Funktionen kann das Core Data Warehouse als der einzige erlaubte Ausgangspunkt für die Verteilung der Daten in die Auswertungsdatenbank angesehen werden - nicht nur für die Weitergabe der Daten in die Auswertungsdatenbank, sondern für jegliche Weitergabe der Daten, z.B. der Rückgabe der Daten ins Quellsystem. Nur die Daten im Core Data Warehouse sind zusammengeführt, transformiert, vereinheitlicht und qualitativ bereinigt. In den nachfolgenden Auswertungen muss immer auf die Daten des Core Data Warehouse zurückgegriffen werden, ansonsten besteht die Gefahr von widersprüchlichen Aussagen und den daraus folgenden Verlusten an Aussagekraft und Glaubwürdigkeit der Daten. Aktualisierung des Core Data Warehouse: Neben der anwendungsneutralen Struktur ist ebenfalls das Aktualisierungsintervall von Bedeutung. Entscheidend für die Aktualisierung des Core Data Warehouse ist dabei die geforderte Aktualität der Daten. Müssen beispielsweise Daten täglich an die Aufsichtsbehörde übergeben werden, ist eine Übermittlung einmal pro Woche nicht ausreichend. Es wird dabei zwischen Echtzeitaktualisierung, Aktualisierung in periodischen Zeitabständen und Aktualisierung in Abhängigkeit von Änderungsquantität in den Quelldaten unterschieden. Bei der Echtzeitaktualisierung wird versucht, die Daten aus den Quellsystemen zeitnah in das Core Data Warehouse zu überführen. Aus diesem Grund muss eine ständige Verbindung zwischen den Datenquellen und dem Core Data Warehouse gewährleistet sein. Bei der Aktualisierung in periodischen Zeitabständen werden die Änderungen vom Quellsystem in einem definierten Zyklus - beispielsweise täglich, wöchentlich oder monatlich -in das Core Data Warehouse überführt. Die Aktualisierung in Abhängigkeit einer Änderungsquantität überführt die Daten nach einer definierten Anzahl von Änderungen im Quellsystem an das Core Data Warehouse. Die Entscheidung kann je nach Anwendungsfeld von technischen, inhaltlichen oder organisatorischen Gesichtspunkten abhängen. Die gleiche Designentscheidung ist für den Transfer der Daten von dem Core Data Warehouse zur Auswertungsdatenbank zu treffen. Qualität der Daten im Core Data Warehouse: Ist die Datenqualität der Quelldaten gut, bedeutet das noch lange nicht, dass gute Daten in dem Core Data Warehouse vorliegen. Innerhalb des Core Data Warehouse muss nachvollziehbar sein, wie die Daten hineingelangt sind und welche Transformationen sie durchlaufen haben. Gute Metadaten sind daher ein wichtiger Betrachtungsgegenstand für die Datenqualität, sie müssen diesen Qualitätsanforderungen entsprechen. An die Daten und Metadaten im Core Data Warehouse werden folgende Qualitätsanforderungen hinsichtlich der Nachvollziehbarkeit anhand des Qualitätsmerkmals Verständlichkeit und der Verfügbarkeit anhand der Qualitätsmerkmale Vollständigkeit, Zeitnähe und Genauigkeit gestellt: Nachvollziehbarkeit anhand des Qualitätsmerkmals Verständlichkeit: 1 Liegt eine Beschreibung der automatischen Transformation (Transparenz der Verarbeitungsabläufe) vor und ist diese verständlich sowie für die Anwender und Entwickler zugänglich? 2 Existiert eine Beschreibung (Data Lineage) des Datenflusses von der Datenquelle bis hin zur Auswertungsdatenbank bzw. zu den Data Marts? Ist die Benennung der Verantwortlichkeit für die Datenflüsse bzw. für die einzelnen Wege erfolgt? 3 Es sollte eine Arbeits- und Verfahrensanweisung vorliegen. In der Arbeits- und Verfahrensanweisung sollten alle relevanten Prozesse - ausgehend von den Quellsystemen bis hin zur Anwendungsschicht - beschrieben werden. 4 Verfügbarkeit anhand der Qualitätsmerkmale Vollständigkeit, Zeitnähe und Genauigkeit 5 Erfolgt die Lieferung der Daten in der gewünschten Schnelligkeit und im benötigten Zeitrahmen? 6 Sind die notwendigen Daten im Core Data Warehouse und den nachgelagerten Datenbanken zusammen mit den Metadaten im Repository vorhanden? 7 Werden dem Empfänger die gewünschten Daten mit richtigem Inhalt und in richtiger Form zur Verfügung gestellt? Werden dem Systembetreuer Abbrüche oder Unterbrechungen in der Datenversorgung zugänglich gemacht? 8 Ist sichergestellt, dass der Zugriff auf die Datenbanken technisch und organisatorisch funktioniert? 4.2.7. Auswertungsdatenbank : Eine einzige zentrale Auswertungsdatenbank für relevante Unternehmensdaten und Metadaten innerhalb einer Data Warehouse Architektur lässt sich in vielen Fällen konzeptuell und technisch nur schwer realisieren. Die Ad hoc Konzeption eines solchen zentralen Core Data Warehouse ist im Projektmaßstab oft zu komplex und ressourcenintensiv. Aus technischer Sicht ist eine einzige Komponente problematisch sowohl hinsichtlich der Skalierbarkeit (wie beim Anwachsen der Nutzeranzahl) als auch hinsichtlich der Volumen-, der Datenbestände bzw. der daraus folgenden Antwortzeiten. Um die Verteilung der Verarbeitung sicher zu stellen, wird von einer zentralen Datenbank abgewichen. In einem Data Warehouse sollen die Daten anwendungsbezogen und logisch integriert werden - eine physische Integration der Daten in jeder Ebene ist dafür nicht zwingend notwendig. Ziel ist es, einen inhaltlich beschränkten Fokus des Unternehmens oder einer Abteilung in einer Auswertungsdatenbank abzubilden. Unterschiedliche Abnehmer von Report und unterschiedliche Granularitäten sind ebenfalls Gründe für den Einsatz von Data Marts. Eigenständigkeit, Datenschutzaspekte durch die Teilsicht auf die Daten und Verringerung des Datenvolumens sind unteranderem Gründe für die Erstellung von Data Marts. Die Komplexität kann reduziert werden, indem nur Teilmengen (Abteilungen) des Unternehmens abgebildet werden (wie etwa Schadensmanagement bei Versicherungen oder Wertpapierhandel bei Banken). Des Weiteren wird das Datenvolumen verringert und die klare Verantwortlichkeit kann abgebildet werden. Aus Datensicht werden die Daten aus dem Core Data Warehouse in die Auswertungsdatenbank verteilt. Dabei sind zwei Architekturen möglich: Die erste Variante ist eine abhängige Auswertungsdatenbank, dorthin werden die Daten aus dem integrierten Datenbestand des Core Data Warehouse geladen. Die zweite Variante ist eine unabhängige Auswertungsdatenbank, die eine isolierte Sicht auf die Quellsysteme ohne Verwendung eines Core Data Warehouse darstellt. Abhängige Auswertungsdatenbank Durch eine Vielzahl von Anfragen an ein und dieselbe Datenbank, kann diese schnell zum Flaschenhals der gesamten Architektur werden. Aus diesem Grund ist es sinnvoll, das Core Data Warehouse als zentralen Datenbestand zu verwenden, die Auswertungsdatenbanken allerdings entsprechend der Auswertungsbedürfnisse (etwa Abteilungen) zu verfeinern. Diese Architektur wird auf Grund ihrer Form als Nabe-Speiche-Architektur […] bezeichnet. Die Daten werden aus den Datenquellen in eine zentrale Core Data Warehouse - Sammelfunktion - und anschließend in die Auswertungsdatenbank bzw. die Data Marts - Verteilfunktion - transportiert. Bei diesem Architekturansatz ist die Reduzierung der Schnittstellen gewährleistet. Die Auswertungsdatenbank sollte nur Extrakte des Core Data Warehouse enthalten, sie können schon aggregiert sein. Auf dieser Ebene findet keine Datenbereinigung - bei der Befüllung der Auswertungsdatenbank - mehr statt, das bedeutet, dass die Ergebnisse der Auswertungen auf einer Auswertungsdatenbank immer inhaltlich und strukturell konsistent mit den Auswertungen auf dem zentralen Core Data Warehouse sind. Aus diesem Grund können einfache Replikation bzw. Sichtenmechanismen zum Befüllen verwendet werden.

• BCBS 239

• MaRisk

• Basel

• Solvency

• Regulatorische Anforderungen

Nils Keller, M.A., wurde 1986 geboren. Nach seiner Berufsausbildung als Fachinformatiker mit Fachrichtung Systemintegration in einem renommierten norddeutschen Unternehmen in der Entsorgungswirtschaft entschied sich der Autor, seine fachlichen Qualifikationen im Bereich der Wirtschaftsinformatik durch ein Studium weiter auszubauen. Das Bachelorstudium der Wirtschaftsinformatik an der Jade Hochschule in Wilhelmshaven schloss er im Jahre 2011 mit dem akademischen Grad des Bachelor of Science erfolgreich ab. Anschließend vertiefte er sein Wissen in Form eines Masterstudiums der Wirtschaftsinformatik an der Technischen Hochschule Mittelhessen in Friedberg und schloss dieses im Jahr 2014 mit dem akademischen Grad Master of Science ab. Bereits während des Studiums sammelte der Autor umfassende praktische Erfahrungen in den Branchen Finanzdienstleistung, Gesundheitswesen und Logistik. In dieser Zeit entwickelte der Autor ein besonderes Interesse an der Business Intelligence.