Architekturen für BI & Analytics E-Book

Peter Gluchowski

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Edition TDWI
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 414

Beschreibung

Erfolgsfaktoren für BI-Architekturen

• Umfassendes und anwendungsbezogenes Handbuch
• Einsatz von neuen Technologien wie EAI, Virtualisierung sowie Cloud- und Data-Lake-Architekturen
• Mit vielen Praxisbeispielen aus der BI & Analytics-Welt

Sowohl regulatorische Vorgaben als auch gesteigerte Anforderungen seitens der Fachanwender haben in den letzten Jahren zu immer komplexeren Business-Intelligence- und Analytics-Landschaften geführt, die es zu entwickeln und betreiben gilt. So setzt sich eine heute übliche Architektur aus zahlreichen Einzelkomponenten zusammen, deren Zusammenspiel und funktionale Abdeckung als wesentlicher Erfolgsfaktor für zugehörige BIA-Initiativen zu werten ist.
Dieses Buch setzt sich das Ziel, die derzeit gebräuchlichen Architekturmuster zu beschreiben und dabei einen Überblick über die aktuell verwendeten Technologien zu liefern. Dabei werden nicht nur die architektonischen Frameworks der großen Produktanbieter aufgegriffen, sondern darüber hinaus Lösungen für konkrete Anwendungsfälle präsentiert.

Leseprobe

Prof. Dr. Peter Gluchowski leitet den Lehrstuhl für Wirtschaftsinformatik, insb. Systementwicklung und Anwendungssysteme, an der Technischen Universität in Chemnitz und konzentriert sich dort mit seinen Forschungsaktivitäten auf das Themengebiet Business Intelligence & Analytics. Er beschäftigt sich seit mehr als 25 Jahren mit Fragestellungen, die den praktischen Aufbau dispositiver bzw. analytischer Systeme zur Entscheidungsunterstützung betreffen. Seine Erfahrungen aus unterschiedlichsten Praxisprojekten sind in zahlreichen Veröffentlichungen zu diesem Themenkreis dokumentiert.

Frank Leisten ist als Cloud Solution Architect bei Microsoft tätig und Teil des internationalen Data Governance Rangers Team. Mit diesem verantwortet er die Umsetzung und Implementierung übergreifender Data-Governance-Strategien auf Basis der Microsoft Azure Cloud-Technologie. Offenheit steht hierbei im Vordergrund, das bedeutet sowohl On-Premise-, Hybrid- und Multi-Cloud-Ansätze werden berücksichtigt wie auch die Integration von Drittanbieter-Lösungen. Frank verfügt über umfassende Expertise in mehreren Data-Management-Disziplinen und nutzt diese Erfahrung zur Schaffung nachhaltiger Data-Governance-Lösungen.

Dr. Gero Presser ist Mitgründer und Geschäftsführer bei der QuinScape GmbH, einem Dortmunder IT-Dienstleistungsunternehmen mit 170 Mitarbeitern und dem Fokus auf Data & Analytics. Er organisiert die Meetup-Gruppe »Business Intelligence & Analytics Dortmund« mit über 1.000 Mitgliedern und ist Vorsitzender des TDWI Roundtable Ruhrgebiet.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Peter Gluchowski • Frank Leisten • Gero Presser (Hrsg.)

Architekturen fürBI & Analytics

Konzepte, Technologien und Anwendung

Edition TDWI

Peter Gluchowski

[email protected]

Frank Leisten

[email protected]

Gero Presser

[email protected]

Lektorat: Julia Griebel, Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Anna Diechtierow

Fachliche Beratung und Herausgabe von dpunkt.büchern in der Edition TDWI:

Prof. Dr. Peter Gluchowski · [email protected]

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print    978-3-86490-864-4

PDF     978-3-96910-579-5

ePub    978-3-96910-580-1

mobi    978-3-96910-581-8

1. Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Aus Gründen der besseren Lesbarkeit wird im weiteren Inhalt teilweise auf die gleichzeitige Verwendung der Sprachformen männlich, weiblich und divers (m/w/d) verzichtet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Herausgeber können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Die Wahl einer geeigneten Architektur für die eigene Organisation stellt nach wie vor einen zentralen Erfolgsfaktor für das Gelingen von Business-Intelligence- und Analytics-(BIA-)Aktivitäten dar [DalleMule & Davenport 2017]. Nur durch ein stabiles architektonisches Fundament lassen sich die unterschiedlichen Anforderungen und Wünsche der Anspruchsgruppen in angemessener Zeit und Qualität umsetzen. Empirische Untersuchungen belegen, dass sich grundlegende Architekturbausteine in einigen Branchen (vor allem im Banken- und Versicherungsbereich) über Jahrzehnte nicht ändern, wohl aber stetigen Anpassungen unterliegen. Laut einer Studie aus dem Jahr 2015 nutzen zwei von drei Großunternehmen Data-Warehouse-Systeme, mit deren Aufbau vor zehn oder mehr Jahren begonnen wurde [Purwins 2015].

Insofern erweist sich der Aufbau eines umfassenden BIA-Ökosystems als langfristige Investition, zumal sich der Wechsel auf eine andere technologische Plattform als aufwendiges und langwieriges Unterfangen darstellen kann. Demzufolge sind alle Organisationen gut beraten, sich intensiv mit der Auswahl von Komponenten für eine ganzheitliche BIA-Landschaft auseinanderzusetzen.

Der Sammelband nähert sich dem Thema der BIA-Architekturen vom Allgemeinen kommend zum Speziellen und nimmt dabei eine Strukturierung entlang möglichst abgrenzbarer Teilgebiete bzw. Konzepte vor. Folgerichtig wurden die Beiträge des Bandes in drei Teile aufgegliedert, beginnend mit einer Einführung und der Vorstellung grundlegender Konzepte. Darauf aufbauend erfolgt die Präsentation von Plattformen und Ökosystemen großer Lösungsanbieter, bevor konkrete Architekturbeispiele die Ausführungen komplettieren.

Einleitend bieten Peter Gluchowski, Frank Leisten und Gero Presser in Teil 1 eine »Einführung in die BIA-Architekturen« und erörtern dabei ausgehend von den Anforderungen an eine ganzheitliche BIA-Architektur vor allem die klassischen Architekturen für BIA-Ökosysteme. Anschließend widmen sich Carsten Dittmar und Peter Schulz den »Architekturen und Technologien für Data Lakes« und gehen dabei auf die Abgrenzung zu artverwandten Begrifflichkeiten wie Data Puddle, Data Pond und Data Ocean ein. Der Beitrag zeigt, dass sich auch im Data Lake unterschiedliche Datenbereiche bzw. Zonen finden lassen. Michael Daum konzentriert sich mit seinen Ausführungen auf »Datenzugriffsstrategien für Analytics bei beschränktem Datenquellenzugriff« und bietet Lösungsansätze an – ein Thema mit weitreichender praktischer Bedeutung. Der zunehmenden Bedeutung einer Real-Time-Verarbeitung von Daten trägt das Kapitel zum Thema »Enterprise Application Integration: aktuelle Ansätze« von Martin Janssen Rechnung. Ausführlich erfolgt hier die Erläuterung der Funktionsweise des Enterprises Service Bus auch vor dem Hintergrund aktueller Cloud-Konzepte.

Im zweiten Teil des Sammelbandes wird der Reigen der unterschiedlichen Plattformen und Ökosysteme verschiedener Produktanbieter eröffnet durch Christian Schneider und Gero Presser mit dem Thema »Cloud Data Platform für die Logistikbranche: eine Lösung auf Basis von AWS«. Mittels eines konkreten Einsatzbeispiels werden hier die einzelnen Komponenten von Amazon Web Service in ihrem Zusammenspiel beschrieben. Stefan Ebener präsentiert im Beitrag »Organise the world's data – like Google« zusammen mit seinen Co-Autoren das Google BIA-Ökosystem. Moderne Ansätze und neue Konzepte, wie sie sich in aktuellen Cloud-Architekturen finden, stehen hier im Vordergrund. Ebenfalls im Cloud-Bereich lässt sich der Ansatz von Microsoft verorten, der im Kapitel von Fabian Jogschies mit dem Titel »Die Modern-Data-Warehouse-Architektur von Microsoft« erläutert wird. Als nicht nur in die Zukunft, sondern ebenso in die Vergangenheit gerichtet erweist sich der Text von Daniel Eiduzzis unter der Überschrift »SAP Business Warehouse von gestern bis morgen«, der die Entwicklung des SAP BIA-Ökosystems über mehr als zwei Jahrzehnte beleuchtet.

Der dritte Teil des Sammelbandes beschreibt unterschiedliche Architekturbeispiele und verdeutlicht, dass sich spezifische Ausformungen zumindest teilweise aus den Besonderheiten einzelner Branchen und Rahmenbedingungen ergeben. Der erste Beitrag in diesem Teil von Thomas Müller, Lisa Anne Schiborr und Stefan Seyfert ist im Bankenbereich angesiedelt und arbeitet unter der Überschrift »Aus der Theorie in die Praxis – der Einfluss regulatorischer Anforderungen auf eine moderne Referenzarchitektur« heraus, wie sich vor allem regulatorische Anforderungen auf moderne Architekturen auswirken. Als ebenfalls im Finanzdienstleistungssektor verortet erweisen sich die Ausführungen von Nick Golovin und Don Seur mit der »Case Study: Crédit Agricole Consumer Finance Netherlands«, die sich insbesondere auf die Möglichkeiten und Grenzen einer Datenvirtualisierung fokussiert. Den gleichen Schwerpunkt bedienen Daniel Rapp, Thomas Niewel und Jörg Meiners mit dem Titel »Datenvirtualisierung« und stellen die eingesetzten Technologien am Beispiel der Festo Gruppe vor.

Ein sehr spezielles Einsatzgebiet bildet die Pharmabranche, wie der Beitrag von Jörg Krempien, Jörg Frank und Philipp Kazzer unter der Überschrift »BIA-Architekturen für klinische Studien« zeigt. Auch hier finden sich zahlreiche regulatorische Vorgaben und sonstige Anforderungen, die es technologisch abzudecken gilt. Ein speziell auf die Belange von Data Science und Machine Learning ausgerichtetes Konzept beinhaltet der Text von Gerhard Brückl und Timo Klerx zu »BIA-Architekturen in der Versicherungsbranche«, wobei auch hier ein Data Lake als zentrale Speicherkomponente Verwendung findet. Dass tragfähige Architekturkonzepte nicht nur bei Großunternehmen zentrale Bedeutung haben, belegt Markus Begerow im Kapitel »BIA-Architekturen für kleine und mittlere Unternehmen«. Aus aktuellen, innovationstreibenden Themen für KMU werden hier Anforderungen an die Gestaltung von BIA-Lösungen abgeleitet. Stärker auf einzelne betriebswirtschaftliche Einsatzbereiche geht der Beitrag von Christian Fürstenberg, Oliver Zimmer und Björn Beuter »Integrierte Planung und Reporting im Business-Analytics-gestützten Controlling« ein und stellt dabei das Corporate Performance Management sowie Self-Service in den Vordergrund der Betrachtung.

Aufgrund des Umgangs und der Dynamik des Gesamtthemas ist es leider nicht möglich, alle Teilaspekte in der gleichen Tiefe zu durchdringen und diese überschneidungsfrei zu präsentieren. Allerdings vermittelt der Sammelband durch die Vielzahl der eingenommenen Perspektiven einen breiten Überblick über das Thema mit hinreichender Würdigung der wichtigsten Teilaspekte.

Das vorliegende Werk wendet sich schwerpunktmäßig an betriebliche Anwender und Entscheider aus den IT-Abteilungen und den Fachbereichen, aber auch an Mitarbeiter aus Beratungshäusern, IT-Dienstleistungsunternehmen und Hochschulangehörige sowie Studierende in den immer vielfältigeren Disziplinen rund um Data Management und Analytics. Die Herausgeber hoffen, dass die Leserinnen und Leser wertvolle Anregungen und Hinweise für die Konzeptionierung und Realisierung von Business-Intelligence- und Analytics-Architekturen in eigenen Projekten erhalten.

Ein herzlicher Dank gilt den einzelnen Autoren, die trotz ihrer anderen Verpflichtungen, voller Terminkalender und speziell in einem durch die Covid-19-Pandemie geprägten Zeitintervall dennoch fristgerecht ihre jeweiligen Beiträge einbringen konnten. Wie gewohnt äußerst angenehm und konstruktiv war die Zusammenarbeit mit dem dpunkt.verlag; vor allem gilt hier Christa Preisendanz und dem Verlagsteam ein besonderer Dank.

Abschließend bleibt uns nur zu wünschen übrig, dass die Leserinnen und Leser dieses Sammelbandes interessante und hilfreiche Impulse für ihre eigene Arbeit finden und sich ihr Blickwinkel auf das Thema BIA-Architekturen insgesamt erweitert. Für kritische oder bestätigende Anmerkungen stehen wir unter den nachfolgenden E-Mail-Adressen gerne zur Verfügung:

[email protected]

[email protected]

[email protected]

Chemnitz, Merzenich, Dortmund im August 2021Peter Gluchowski, Frank Leisten, Gero Presser

Inhaltsübersicht

Teil IGrundlagen

1Einführung in die BIA-Architekturen

Peter Gluchowski · Frank Leisten · Gero Presser

2Architekturen und Technologien für Data Lakes

Carsten Dittmar · Peter Schulz

3Datenzugriffsstrategien für Analytics bei beschränktem Datenquellenzugriff

Michael Daum

4Enterprise Application Integration: aktuelle Ansätze

Martin Janssen

Teil IIPlattformen und Ökosysteme

5Cloud Data Platform für die Logistikbranche: eine Lösung auf Basis von AWS

Christian Schneider · Gero Presser

6Organise the world's data – like Google

Stefan Ebener · Stiv Sterjo · Sascha Kerbler · Andreas Ribbrock · Alex Osterloh · Diana Nanova · Christine Schulze · Lukas Grubwieser

7Die Modern-Data-Warehouse-Architektur von Microsoft

Fabian Jogschies

8SAP Business Warehouse von gestern bis morgen

Daniel Eiduzzis

9Aus der Theorie in die Praxis – der Einfluss regulatorischer Anforderungen auf eine moderne Referenzarchitektur

Thomas Müller · Lisa Anne Schiborr · Stefan Seyfert

10Case Study: Crédit Agricole Consumer Finance Netherlands

Nick Golovin · Don Seur

11Datenvirtualisierung

Daniel Rapp · Thomas Niewel · Jörg Meiners

Teil IIIArchitekturbeispiele

12BIA-Architekturen für klinische Studien

Jörg Krempien · Jörg Frank · Philipp Kazzer

13BIA-Architekturen in der Versicherungsbranche

Gerhard Brückl · Timo Klerx

14BIA-Architekturen für kleine und mittlere Unternehmen

Markus Begerow

15Integrierte Planung und Reporting im Business-Analytics-gestützten Controlling

Christian Fürstenberg · Oliver Zimmer · Björn Beuter

Anhang

AAutoren

BAbkürzungen

CLiteraturverzeichnis

Index

Inhaltsverzeichnis

Teil IGrundlagen

1Einführung in die BIA-Architekturen

Peter Gluchowski · Frank Leisten · Gero Presser

1.1BIA-Trends und -Entwicklungen

1.2Architekturkonzepte und -facetten

1.3Datenbezogene Rahmenbedingungen

1.3.1Datenstrategie

1.3.2Data Valuation

1.3.3Data Management

1.4Anforderungen an eine ganzheitliche BIA-Architektur

1.5Klassische Architekturen für BIA-Ökosysteme

2Architekturen und Technologien für Data Lakes

Carsten Dittmar · Peter Schulz

2.1Historie der dispositiven Datenplattformen

2.2Das Data-Lake-Konzept

2.3Architektur eines Data Lake

2.4Datenarchitektur eines Data Lake

2.5Technologien für einen Data Lake

2.6Herausforderungen in der Umsetzung eines Data Lake

3Datenzugriffsstrategien für Analytics bei beschränktem Datenquellenzugriff

Michael Daum

3.1Ursachen von Einschränkungen auf Datenquellen

3.2BIA-Anforderungen an Datenquellen

3.3Datenstrategische Überlegungen

3.3.1Trennung von Problemstellung und technischer Lösung

3.3.2Skalierbarkeit

3.3.3Cloud-Strategie und Datenschutz

3.3.4Data Management

3.4Lösungsansätze bei unterschiedlichen Einschränkungen

3.4.1Technische Probleme der Connectivity

3.4.2(Firmen-)»Politische« Themen und Lizenzen

3.4.3Datenschutzanforderungen beim Zugriff

3.5Entkoppeln von Systemen und Datenvirtualisierung

3.6Abgrenzung und weiterführende Themen

4Enterprise Application Integration: aktuelle Ansätze

Martin Janssen

4.1Ein altbekanntes Thema vor immer neuen Herausforderungen

4.2Der Unterschied zwischen Theorie und Praxis ist in der Praxis weit höher als in der Theorie

4.3Die Zeit des ESB

4.4Neue Anforderungen durch die Clouds

4.5Drei aktuelle Lösungsansätze

4.5.1iPaaS – Integration mittels Low Code und als Turnkey-Lösung

4.5.2Kafka – der neue ESB?

4.5.3Serverless Integration – alles in der Cloud

4.6Fazit

Teil IIPlattformen und Ökosysteme

5Cloud Data Platform für die Logistikbranche: eine Lösung auf Basis von AWS

Christian Schneider · Gero Presser

5.1Herausforderung

5.2Grundlegende Architektur

5.3Technische Architektur mit AWS

5.4Data Lake: AWS S3 und AWS Lake Formation

5.5ETL und mehr: AWS Glue

5.6Data Warehouse: AWS Redshift

5.7Query Engine: AWS Redshift Spectrum

5.8Visualisierung: AWS QuickSight

5.9Flexibilität in der Architektur

5.10Betrieb und Wartung

5.11Ergebnis und Resümee

6Organise the world's data – like Google

Stefan Ebener · Stiv Sterjo · Sascha Kerbler · Andreas Ribbrock · Alex Osterloh · Diana Nanova · Christine Schulze · Lukas Grubwieser

6.1Einführung

6.1.1Herausforderungen für eine erfolgreiche BI-Landschaft

6.1.2Der Nutzen einer erfolgreichen BI-Landschaft

6.2BI in der Public Cloud vs. On-Premises BI

6.2.1Vom Budgetprozess hin zum aktiven Kostenmonitoring

6.2.2Neue Unternehmensstrukturen rund um BIA in der Cloud

6.2.3Trennung von Datenspeicherung und Rechenleistung

6.2.4Elastizität und Skalierbarkeit

6.2.5Infrastruktur als Code – IaC

6.2.6Konvergenz von SQL und KI/ML

6.2.7Vom Prototyp zur Applikation

6.3Moderne Ansätze und neue Konzepte für BIA

6.3.1Data Mesh aka Enterprise Data Evolution

6.3.2Lake House als nächste Generation des Data Lake

6.4Business Intelligence mit Google Cloud

6.4.1Einführung einer serverlosen Architektur

6.4.2Einführung innovativer KI/ML-Technologien

6.4.3KI/ML im produktiven Einsatz

6.4.4Ende-zu-Ende-Anwendung von einer mit KI/ML integrierten Datenplattform

6.4.5Das »Big Picture« als Referenzarchitektur für ein modernes Lake House

6.4.6Betrieb produktiver Anwendungen mit Google

6.5Fazit und Ausblick

7Die Modern-Data-Warehouse-Architektur von Microsoft

Fabian Jogschies

7.1Datenablage mit Azure Data Lake Storage Gen2

7.2Data Ingest und Orchestrierung

7.3Transformation, Serving und ML mit Azure Synapse Analytics

7.4Transformation, Serving und ML mit Azure Databricks

7.5Data Lab Toolbox – Machine Learning

7.5.1Azure Machine Learning (AML)

7.5.2Azure Cognitive Services

7.6Visualisierung mit Power BI

7.7Data Governance mit Azure Purview

7.8Azure DevOps

8SAP Business Warehouse von gestern bis morgen

Daniel Eiduzzis

8.1Business Intelligence made in Walldorf

8.1.1SAP Business Warehouse – Wie alles begann

8.1.2Probleme, Kritik und Herausforderungen im SAP BW-Kontext

8.2Entwicklung des SAP BW

8.2.1Die Zeit vergeht, das SAP BW bleibt

8.2.2Der große Wurf bleibt aus

8.3SAP Business Intelligence – heute und morgen

8.3.1HANA und Cloud geben die Strategie vor

8.3.2Features und Werkzeuge für Data Management und Data Integration

8.3.3Reporting und Analyse dort, wo die Daten generiert werden

8.3.4Hybride Konzepte als State-of-the-Art-Architektur

8.4Ausblick und Fazit

9Aus der Theorie in die Praxis – der Einfluss regulatorischer Anforderungen auf eine moderne Referenzarchitektur

Thomas Müller · Lisa Anne Schiborr · Stefan Seyfert

9.1Aktuelle Herausforderungen

9.2Historisierung

9.2.1Bitemporale Historisierung

9.2.2Best Practice

9.3Datenschichtenarchitektur

9.3.1Datenschichten der Referenzarchitektur

9.3.2Archivierung und Housekeeping

9.4Integrationsarchitektur

9.4.1Verfahren und Werkzeuge

9.4.2Anbindung Metadatenmanagement

9.4.3Anbindung Datenqualitätsmanagement

9.5Metadatenmanagement (MDM)

9.5.1MDM – Kernanforderungen

9.5.2Die Metamodelllandkarte (Modellsichten)

9.5.3Data Lineage

9.5.4Best Practice MDM – Technologie

9.5.5Best Practice MDM – Architektur

9.6Datenqualitätsmanagement (DQM)

9.6.1DQM – Kernanforderungen

9.6.2Prüfregeln

9.6.3Korrekturen

9.6.4Best Practice DQM – Architektur

9.7Fazit und Handlungsempfehlungen

10Case Study: Crédit Agricole Consumer Finance Netherlands

Nick Golovin · Don Seur

10.1Herausforderungen

10.1.1Lange Time-to-Market

10.1.2Zugang zu Echtzeitdaten

10.1.3Daten für operative Zwecke

10.1.4DSGVO-Konformität

10.1.5Anbindung von modernen Datenquellen

10.2Anforderungen an die neue Lösung

10.3Moderne Datenarchitektur

10.4Use Cases

10.4.1360°-Blick auf Kunden

10.4.2Echtzeit-Sales-Monitoring

10.4.3Marketinganalysen

10.4.4Risk Management

10.4.5Data Preparation für regulatorische Reportings

10.5Schlussfolgerung: Datenvirtualisierung das Allheilmittel?

11Datenvirtualisierung

Daniel Rapp · Thomas Niewel · Jörg Meiners

11.1Moderne Datenarchitekturen für das Zeitalter der Digitalisierung

11.2Datenvirtualisierung – ein Überblick

11.2.1Anwendungsfälle der Datenvirtualisierung

11.3Die Technologie der Datenvirtualisierung

11.3.1Zugriff auf das Datenmodell

11.3.2Datenschutz und Sicherheit

11.3.3Query-Optimierung

11.3.4Daten-Caching

11.3.5Datenkatalog

11.4Abgrenzung zu anderen Integrationstechnologien

11.5Kundenbeispiel: Die Festo Gruppe

11.5.1Unternehmensprofil der Festo Gruppe

11.5.2Geschäftsanforderungen

11.5.3Die Lösung

11.5.4Die Mehrwerte

11.6Zusammenfassung

11.6.1Die Anwenderperspektive

11.6.2Die Data-Governance-Perspektive

11.6.3Die IT-Perspektive

Teil IIIArchitekturbeispiele

12BIA-Architekturen für klinische Studien

Jörg Krempien · Jörg Frank · Philipp Kazzer

12.1Über klinische Studien

12.2Anforderungen an die BI-Architektur

12.3Architekturdetails

12.3.1Architekturüberblick

12.3.2Staging

12.3.3Core

12.3.4Publish

12.3.5Virtualisierung (Domänen durch Konfiguration)

12.4Entwicklungsgeschichte und Ausblick

12.5Use Cases

12.5.1Virtual Cut Off

12.5.2Subject Status

12.5.3Baseline Flags

12.5.4Clean Patient Tracker

12.5.5Fraud Detection in Clinical Trials

12.5.6Testautomatisierung (TAT)

13BIA-Architekturen in der Versicherungsbranche

Gerhard Brückl · Timo Klerx

13.1Ausgangssituation

13.2Zielsetzung

13.3Zielarchitektur

13.4Data Lake

13.5Datenverarbeitung

13.6Ablaufsteuerung

13.7Data-Science-Labor

13.8Reporting

14BIA-Architekturen für kleine und mittlere Unternehmen

Markus Begerow

14.1Ausgangssituation

14.2Neue Themen als Treiber für Innovationen

14.2.1Stammdaten- und Datenqualitätsmanagement

14.2.2Cloud-Infrastrukturen

14.2.3Data Science im Mittelstand

14.3Konsequenzen für kleine und mittlere Unternehmen

14.3.1Tabellen- und Textdateien ersetzen keine Datenbank

14.3.2Cloud-Servicemodelle verstehen

14.3.3Data Science light einführen

14.4Fazit

15Integrierte Planung und Reporting im Business-Analytics-gestützten Controlling

Christian Fürstenberg · Oliver Zimmer · Björn Beuter

15.1Die Entwicklung der Finanzplanung und -analyse

15.2Der Weg zur datengetriebenen Unternehmenssteuerung

15.3CCH® Tagetik – eine Lösung für alle Corporate-Performance-Management-Bereiche

15.4Data Literacy – Aufbau von Datenkompetenz im Controlling

15.5Einsatz und Nutzen von Self-Service im Controlling

15.6Power BI als Self-Service-Reporting- und Analyse-Architektur

15.7Einsatz von Power BI im Umfeld von CCH®Tagetik

Anhang

AAutoren

BAbkürzungen

CLiteraturverzeichnis

Index

Teil I

Grundlagen

1Einführung in die BIA-Architekturen

Peter Gluchowski · Frank Leisten · Gero Presser

Der vorliegende Beitrag setzt sich das Ziel, die Rahmenbedingungen für komplexe Business Intelligence & Analytics-(BIA-)Landschaften zu beleuchten. Den Ausgangspunkt für die Betrachtungen bildet der folgende Abschnitt, der BIA-Trends und -Entwicklungen in der letzten Dekade punktuell aufgreift und die Bedeutung für die zugehörigen dispositiven Ökosysteme herausarbeitet. Danach erfolgen eine Abgrenzung und Einordnung der BIA-Architektur zu verwandten Themen wie Unternehmensarchitektur, IT-Architektur, Anwendungsarchitektur und Infrastruktur (Abschnitt 1.2). Anschließend nähert sich Abschnitt 1.3 dem Architekturthema aus einer Datenperspektive, indem die Datenstrategie, die Wertermittlung von Daten und das Datenmanagement im Vordergrund der Betrachtung stehen. Der anschließende Abschnitt 1.4 beleuchtet die Anforderungen an eine ganzheitliche BIA-Architektur aus der Perspektive unterschiedlicher Anspruchsgruppen und macht deutlich, dass sich die Vorstellungen und Ziele erheblich voneinander unterscheiden können. Schließlich greift Abschnitt 1.5 die klassische Hub-and-Spoke-Architektur und die Schichtenarchitektur für BIA-Ökosysteme auf und verweist auf die zugehörigen Defizite.

1.1BIA-Trends und -Entwicklungen

In der letzten Dekade lässt sich eine zunehmende Komplexität analytischer Architekturen feststellen. Waren es noch vor zehn Jahren die klassischen Data-Warehouse-zentrierten Architekturkonzepte, die fast flächendeckend und ausschließlich Verwendung fanden, haben in der Zwischenzeit vielfältige zusätzliche Komponenten und Technologien Einzug in die BIA-Landschaften der Unternehmen gehalten.

Unterstützt wurde diese Entwicklung nicht zuletzt durch die intensive Diskussion um Big Data, die durch die Hypothese geleitet ist, dass die herkömmlichen Konzepte und Technologien nicht dazu in der Lage sind, alle aktuellen Anforderungen in geeigneter Form zu erfüllen. So greifen einige Veröffentlichungen zu dem Thema auf eine Negativabgrenzung zurück und stellen heraus, dass Big Data dann gegeben ist, wenn die Kapazitäten und Funktionalitäten der klassischen Datenhaltung, -aufbereitung und -auswertung sich als nicht ausreichend erweisen [Dittmar et al. 2016, S. 3]. Zumeist wird Big Data heute durch die charakteristischen Eigenschaften beschrieben. Dann zeichnet sich Big Data nicht allein durch das immense Datenvolumen (Volume) aus, sondern ebenso durch die erhebliche Vielfalt an Datenformaten (Variety) sowie durch die Geschwindigkeit (Velocity), mit der neue Daten entstehen sowie verfügbar und damit analysierbar sind [Eaton et al. 2012, S. 5].

Allerdings lassen sich zahlreiche weitere Begrifflichkeiten mit dem Anfangsbuchstaben »V« und somit weitere Dimensionen identifizieren, mit denen Big Data umschrieben wird. Beispielsweise adressiert Veracity als Wahrhaftigkeit oder Richtigkeit der Daten eine weitere Eigenschaft von Big Data, zumal Auswertungen und die damit verbundenen Entscheidungen hierauf beruhen und falsche Daten zu fehlerhaften Analyseergebnissen führen können. Aufgrund der Datenvielfalt und des Datenvolumens erweist sich eine Überprüfung der Daten jedoch häufig als schwierig [Klein et al. 2013, S. 321]. Als weitere Begrifflichkeiten mit »V« finden sich Validity, Volatility, Variability und vor allem Value, auf die hier allerdings nicht weiter eingegangen wird [Gandomi & Haider 2015, S. 139; Khan et al. 2014, S. 3]. Es liegt auf der Hand, dass hieraus gänzlich neue Bedarfe resultieren, die es zu erfüllen gilt.

Auch seitens der Datenanalyse haben sich in den letzten Jahren bemerkenswerte Veränderungen eingestellt, die sich in einer verstärkten Hinwendung zu anspruchsvollen statistisch-mathematischen Verfahren unter Oberbegriffen wie künstliche Intelligenz, Machine Learning oder Data Science zeigen. Derzeit erweisen sich vor allem komplexe künstliche neuronale Netze (Deep Learning) als leistungsfähig, mit denen die Erforschung von Strukturzusammenhängen (Datenmustern) in Datenbeständen eine neue Qualität erreicht [Dorer 2019, S. 119 ff.].

Als Konsequenz aus diesen Entwicklungen erfolgte in zahlreichen Unternehmen eine zumindest teilweise Abkehr beispielsweise von den klassischen, festplattenorientierten relationalen Datenbanksystemen hin zur schemalosen und verteilten Ablage des Datenmaterials, mit der sich auch große und polystrukturierte Inhalte organisieren lassen. Daneben mündet die Forderung nach hoher Verarbeitungsgeschwindigkeit in neuen Herausforderungen, die eine Erweiterung oder Ergänzung der bislang üblichen Batch-orientierten Aufbereitung des Datenmaterials für analytische Zwecke zur Folge hat – spätestens dann, wenn Datenströme zu verarbeiten sind.

Begünstigt wird die Veränderung durch zahlreiche neue Technologien. Bezogen auf die Speicherung von Daten sei hier etwa auf In-Memory-Konzepte, NoSQL-Datenbanksysteme (z.B. als Key-Value Store) sowie auf Cloud-Technologien verwiesen. Im Frontend-Sektor dagegen haben Self-Service-Werkzeuge breiten Raum eingenommen.

Auch aus organisatorischen Gründen haben sich im letzten Jahrzehnt die Voraussetzungen für die Gestaltung von BIA-Architekturen geändert. So erfordert die zunehmende Hinwendung zu agilen Gestaltungsmethodiken mit kurzen Entwicklungszyklen, dass sich inkrementelle und iterative Veränderungen im Systemaufbau auch mit den vorhandenen Landschaften realisieren lassen. Aufgrund des engen zeitlichen Rahmens erweist es sich dabei teilweise als unumgänglich, dass einzelne Entwicklungsschritte durch Automatisierungsverfahren und -komponenten beschleunigt werden. Aber auch aus dem Betrieb von BIA-Lösungen ergeben sich Beschleunigungsbedarfe, die oftmals unter dem Begriffsgebilde DataOps diskutiert werden [Detemple 2020]. Gefordert wird hier sowohl eine Datenpipeline als auch eine Analytics-Pipeline zur möglichst zeitnahen Zurverfügungstellung von Berichten, Dashboards und Analytics-Modellen für den Endanwender.

Weitere Rahmenbedingungen für die BIA-Landschaft ergeben sich aus externen, regulatorischen, aber auch internen Vorgaben, die es zu erfüllen gilt. Als wichtige regulatorische Vorgabe lässt sich die Datenschutz-Grundverordnung (DSGVO) anführen, aus der sich die Notwendigkeit eines besonderen Umgangs mit personenbezogenen Daten und der architektonischen Umsetzung ableiten lässt. In einzelnen Branchen existieren darüber hinaus spezielle Regularien, die weit über den einfachen gesetzlichen Standard hinausreichen. So kann für den Finanzdienstleistungssektor das Regelwerk der BCBS 239 angeführt werden, aus dem sich weitreichende Anforderungen an die Transparenz und Nachverfolgbarkeit der Verarbeitung von Daten ergeben.

Vor diesem Hintergrund wird deutlich, dass eine einfache Architektur mit wenigen Komponenten heute kaum ausreichen kann, um allen Anforderungen gerecht zu werden. Vielmehr stellt sich die Aufgabe, ein analytisches Ökosystem zu gestalten, in dem jeder Baustein definierte Funktionen übernimmt und dabei seine spezifischen Stärken einbringt. Naturgemäß ergibt sich hieraus die steigende Komplexität der Gesamtlandschaft, zumal das reibungslose Zusammenspiel der einzelnen Komponenten eine Herausforderung darstellt.

1.2Architekturkonzepte und -facetten

Der Begriff Architektur findet in zahlreichen Wissensdisziplinen und thematischen Bereichen Verwendung. Allgemein repräsentiert eine Architektur die Gesamtheit aller beschreibenden Darstellungen (Entwurfsartefakte) der erkenntnisrelevanten Objekte derart, dass diese den Anforderungen entsprechend produziert und betrieben werden können (Qualität). Idealerweise bleiben die grundlegenden Teile der Beschreibung möglichst unverändert über die Nutzungsdauer erhalten [Zachman 1997], können aber an geänderte Bedingungen angepasst werden. Die Artefakte bilden neben der Repräsentation von Objekten auch deren Funktionen, Schnittstellen und Beziehungen sowie dynamische Aspekte ab, wie den zeitlichen Ablauf von Austauschbeziehungen [Krcmar 2015, S. 280 f.].

Im Kontext von Informationssystemen umfasst dies die modellhafte Beschreibung der grundsätzlichen Struktur eines Systems mit seinen Elementen, der Beziehungen zwischen den Elementen sowie den Beziehungen des Systems zur Umwelt [ISO 2000; Knoll 2018, S. 889]. Neben der Spezifikation seiner Komponenten und ihrer Beziehungen unter allen relevanten Blickwinkeln lassen sich auch die Konstruktionsregeln zur Erstellung des Bauplans [Sinz 2019] sowie die Prinzipien zur Konstruktion, Weiterentwicklung und Nutzung des Systems zu einer Informationssystem-Architektur zählen [IEEE 2000].

Durch die umfassende, globale Sicht auf ein Informationssystem, die alle relevanten Komponenten beinhaltet, unterscheidet sich die Architektur von eingeschränkteren Ansätzen (z.B. der unternehmensweiten Datenmodellierung). Zudem erfolgt die Konzentration auf eher aggregierte Elemente und Beziehungen, um die Ganzheitlichkeit der Betrachtung zu ermöglichen, ohne den Überblick zu verlieren [Winter & Aier 2019].

Als Teil einer Informationssystem-Architektur beschreibt die Datenarchitektur eines Informationssystems auf Fachkonzept- oder Entwurfsebene die grundlegenden Datenstrukturen und bildet dabei die Datenarchitektur eines ganzen Unternehmens ab oder konzentriert sich als Datenarchitektur eines Anwendungssystems auf einen Ausschnitt des Unternehmens [Winter & Aier 2019]. Demgegenüber repräsentiert die IT-Infrastruktur die technischen Komponenten, bestehend aus Hardware, (System-)Software sowie baulichen Einrichtungen für den Betrieb von (Anwendungs-)Software [Patig et al. 2019].

Um den Bezug zu geschäftlichen bzw. fachlichen Sichtweisen auf die Architekturen und damit ein gutes Business-IT-Alignment zu wahren, sind über die technische Perspektive hinaus weitere Aspekte zu berücksichtigen [Knoll 2018]. So lassen sich strategische und organisationale Ebenen abbilden, die auf den technischen Layern aufsetzen und diese ergänzen.

Auf jeder der betrachteten Architekturebenen finden sich unterschiedliche Objekte, deren Ausgestaltung und Zusammenwirken den Aufbau des Gesamtgebildes bestimmen (vgl. Abb. 1–1). Zur Gestaltung sind verschiedene Modelltypen verwendbar, die beim Entwurf der spezifischen Strukturen unterstützen. So finden sich auf der strategischen Ebene beispielsweise Modelle zur Abbildung von Geschäftsbeziehungen zu Kunden und Lieferanten. Bei der Beschreibung der Organisationsebene gelangen neben Prozesslandkarten und -modellen auch Organigramme sowie (fachliche) Informationslandkarten zur Anwendung. Auf der untersten Ebene, der IT-Infrastrukturebene, finden sich Beschreibungen über das Zusammenspiel (hardwarenaher) technischer Komponenten wie Modelle der Netzwerkinfrastruktur. Die Softwareebene darüber bildet neben den relevanten Datenstrukturen auch den Aufbau der Softwarekomponenten ab, beispielsweise auf Basis von Softwaremodulen oder auch -services.

Eine besondere Rolle spielt bei diesem Konzept die Integrationsebene, die sich als Mittler zwischen betriebswirtschaftlich-fachlicher und technischer Perspektive erweist. Hier werden einzelne Softwarebestandteile zu Anwendungen und Datenstrukturen zu Domänen verknüpft, um einzelne fachliche Prozesse unterstützen zu können. Infolgedessen lassen sich hier Modelle der Applikationslandschaft und Domänenmodelle verwenden. Neben der Verknüpfungsfunktion erwies sich hier in der Vergangenheit die Entkopplung von fachlichen und technischen Komponenten als hilfreich, um die langsam sich ändernden technischen Gegebenheiten (mit Zykluszeiten von 6 bis 10 Jahren) mit den relativ schnell sich ändernden fachlichen Ebenen (von 3 bis 6 Monaten auf der Organisationsebene bis zu 1–2 Jahren auf der Strategieebene) zu synchronisieren [Winter 2008, S. 24 ff.].

Abb. 1–1Architekturebenen des Business Engineering [Winter 2010, S. 90]

Vor dem Hintergrund von sich stetig schneller entwickelnden technologischen Innovationen und dem fast flächendeckenden Einzug von agilen Entwicklungsmethoden erweist es sich als fraglich, ob die unterschiedlichen Änderungsgeschwindigkeiten heute noch in dieser Form gegeben sind. Vielmehr scheint es oftmals so, dass die hohe technische Entwicklungsdynamik als Enabler Druck auf die fachlichen Strukturen und Prozesse ausübt. Als Indikator hierfür mag die oft mühselige Suche nach passenden Business Cases gelten, wenn neue, beispielsweise unstrukturierte Datenbestände in den Unternehmen verfügbar sind.

Der vorliegende Sammelband konzentriert sich mit den zugehörigen Beiträgen auf die Integrations- und die Softwareebene. Hierfür sollen unterschiedliche Architekturkonzepte vorgestellt und diskutiert werden, wie sie sich in einzelnen BIA-Ökosystemen präsentieren.

Bevor jedoch auf die konkreten Ausgestaltungen von BIA-Ökosystemen eingegangen wird, sind zunächst die Rahmenbedingungen für eine geeignete Architektur zu beleuchten, die sich sowohl aus strategischen Überlegungen zum Umgang mit Daten als wichtige Ressource als auch aus den konkreten Anforderungen der Stakeholder ergeben.

1.3Datenbezogene Rahmenbedingungen

Ein Rahmen für die Verarbeitung von Daten in einem Unternehmen besteht im Wesentlichen aus folgenden Teilbereichen: Strategie, Management, Funktion, Prozess und Technologie. Der vorliegende Abschnitt skizziert und positioniert diese Teilbereiche, indem die Handlungsfelder beschrieben und die Wechselwirkungen untereinander aufgezeigt werden. Die folgende Abbildung 1–2 ordnet die Handlungsfelder den entsprechenden Themengebieten zu.

Die strategische Ebene definiert, wie sich Daten im Sinne des Geschäftsmodells nutzen lassen und eine geeignete Datenstrategie (vgl. Abschnitt 1.3.1) abgeleitet werden kann. Die Managementebene schafft ein geeignetes Rahmenwerk zum Umgang mit diesen Daten mittels der Funktionen des Datenmanagements (vgl. Abschnitt 1.3.3). Hierbei werden die Daten zuvor im Rahmen der Data Valuation bewertet und entsprechend ihrer strategischen, wirtschaftlichen und regulatorischen Bedeutung priorisiert und kategorisiert (vgl. Abschnitt 1.3.2). Die Funktionen des Datenmanagements unterstützen oder ermöglichen den Prozess der datenbasierenden Wertschöpfung, die von den Geschäftsfunktionen ausgeführt wird. Datenstrategie und Data Governance regulieren, steuern, verwalten und überwachen die Funktionen des Datenmanagements. Die Management- und Funktionsebenen werden hierbei auf den gesamten Lebenszyklus von Daten angewandt. Die Verwaltung des Lebenszyklus von Daten und die Wertschöpfung auf deren Basis finden im Habitat der Architekturen und ihrer Systemkomponenten statt.

Abb. 1–2Daten-Ökosystem in einem Unternehmen mit Ebenen und Handlungsfeldern

Dementsprechend fundamental sind die Architekturen und damit die Gesamtheit der Systeme zu gestalten, um eine dauerhafte und nachhaltige Basis zur Wertschöpfung aus Daten als Wirtschaftsgut und deren Verwaltung über den gesamten Lebenszyklus zu gewährleisten. Dabei sind vor allem Stabilität, Agilität und Flexibilität der Architekturen und Systeme sicherzustellen. Nachfolgend wird die Herleitung der Architekturanforderungen, von der Strategieebene ausgehend, beschrieben und in Abschnitt 1.4 als Anforderungen an eine BIA-Architektur zusammengefasst.

1.3.1Datenstrategie

Allgemein wird auf der strategischen Ebene von der Unternehmensleitung (bzw. von den verantwortlichen Entscheidungsträgern) festgelegt, wie Daten im Sinne der Unternehmung einzusetzen sind. Im Rahmen der Strategiefindung muss die Denkweise über die Bedeutung von Daten an die jeweiligen spezifischen Bedingungen angepasst werden. Zahlreiche Unternehmen setzen Daten nach wie vor ausschließlich zur Unterstützung und Verbesserung bestehender Prozesse im Sinne von Messen und Verwalten ein [Rogers 2017]. Allerdings erfolgt – in immer mehr Organisationen und vor allem in den letzten Jahren – ein Umdenken in Bezug auf die Bedeutung und den Umgang mit Daten, wie in Tabelle 1–1 gegenübergestellt ist.

Früher

Heute

Die Datengenerierung innerhalb eines Unternehmens ist teuer

Daten werden ständig und überall generiert

Das Speichern und Verwalten von Daten stellt eine Herausforderung dar

Die Herausforderung besteht darin, Daten in wertvolle Informationen zu transformieren

Unternehmen nutzen nur strukturierte Daten

Unstrukturierte und semi-strukturierte Daten sind zunehmend nutzbar und stellen einen großen Wert dar

Daten werden in operativen Silos verwaltet

Wert generieren Daten insbesondere durch übergreifende Verbindungen

Daten sind ein Mittel zur Verbesserung von Prozessen

Daten sind ein immaterieller Vermögenswert und dienen damit der Wertschöpfung

Tab. 1–1Anpassung der strategischen Denkweise [Rogers 2017, S. 139]

Zusammenfassend beinhaltet Tabelle 1–1 folgende Kernaussagen:

Die Generierung von Daten erfolgt heute ubiquitär von Menschen und Maschinen.

Die Herausforderung besteht nicht mehr in der Beschaffung von Daten, sondernin der Informationsgewinnung.

Durch Einsatz fortschrittlicher Technologien und Methoden lassen sich aus Informationen Werte generieren.

Somit stellt sich bei der Strategieentwicklung die Aufgabe, Daten als wesentliche Schlüsselressource und damit wichtiges immaterielles Wirtschaftsgut für die eigene Organisation zu verstehen und zu behandeln, indem ein geeigneter Rahmen zu deren Bewirtschaftung definiert wird (vgl. hier auch die Datenstrategie der UN, abrufbar unter https://www.un.org/en/content/datastrategy/index.shtml). Dabei ist nicht zuletzt die zentrale Frage zu beantworten, welche Daten für das jeweilige Geschäftsmodell von Bedeutung sind oder sein könnten. Als exemplarische Einsatzgebiete von Daten, die bei der Definition einer Datenstrategie Bedeutung erlangen können, lassen sich anführen:

Sammlung heterogener Datenarten für unterschiedlichste Zwecke

Nutzung von Daten zur Prognose im Rahmen der Entscheidungsfindung

Nutzung von Daten zur Entwicklung von Produktinnovationen

Beobachtung des Verhaltens von Kunden

Kombination von Daten aus diversen Bereichen bzw. Domänen

Aus einer strategischen Perspektive können Daten sowohl eine Supporter-Rolle (Unterstützer) als auch eine Enabler-Rolle (Ermöglicher) einnehmen (vgl. Abb. 1–3).

Abb. 1–3Zusammenhang zwischen Datenstrategie und Geschäftsmodell

Die eingenommene Rolle wird durch den jeweiligen Datenstrategieansatz bestimmt, wobei sich hier defensive von offensiven Ausprägungen abgrenzen lassen. Der defensive Teil verfolgt das Ziel, nachteilige Datenrisiken zu minimieren, und widmet Themen wie Datenschutz, Datenintegrität, Identifizierung, Standardisierung sowie dem operativen Verwalten der Daten besondere Aufmerksamkeit. Im BIA-Kontext wird als Ziel die Bereitstellung einer »Single Source of Truth« bzw. eines »Single Point of Truth« verfolgt. Als Treiber für diese strategische Ausrichtung fungieren u.a. allgemeine Anforderungen an den Betrieb der Lösungen neben regulatorischen Vorgaben, was im Ergebnis zu ausgeprägter Stabilität führt. Dagegen verfolgt der offensive Ansatz das Ziel, die Wirtschaftlichkeit zu steigern, Performance-Verbesserungen zu erzielen und die Kundenzufriedenheit zu erhöhen. Auf Basis der offensiven Strategie werden »Multiple Versions of Truth« erzeugt. Der offensive Ansatz eröffnet Chancen und erreicht dies durch Anreicherung der Daten und Verwendung analytischer Anwendungen. Insgesamt wird die Agilität und somit auch die Resilienz bzw. Widerstandskraft des Unternehmens verbessert [DalleMule & Davenport 2017].

Bezogen auf die spezifische Situation einer Organisation sind beide Strategien zu beachten und in Betracht zu ziehen, um unter den jeweiligen Rahmenbedingungen (wie Branche und Geschäftsmodell) ein ausgewogenes Verhältnis zwischen Offensive und Defensive im eigenen Haus zu etablieren. Als Basisannahme muss der Datenstrategie die Einsicht zugrunde liegen, dass nur auf Basis einer defensiven Stabilität eine funktionierende Offensive erfolgreich sein kann.

Bei all dem gilt zu beachten, dass Daten als immaterielle Wirtschaftsgüter über andere Eigenschaften als materielle Wirtschaftsgüter verfügen und somit ein individuelles Umfeld zur Bewirtschaftung geschaffen werden muss. Tabelle 1–2 zeigt einige zentrale Unterscheidungskriterien auf.

Materielle Wirtschaftsgüter

Daten als Wirtschaftsgüter

Spezifische Distribution

Einfache Distribution (Internet etc.)

Einfache Ermittlung des Wertes – Bewertung anhand von Marktpreisen möglich

Komplexe und problematische Wertermittlung

Kosten einfach zu ermitteln

Kosten schwer zu ermitteln

Preisbildung bekannt

Preisbildung nahezu unbekannt

Individueller Besitz; Identifikation und Schutz leicht herstellbar

Vielfacher Besitz möglich; Identifikation und Schutz aufwendig

Hohe Vervielfältigungskosten

Geringe Vervielfältigungskosten

Gebrauch verursacht Wertverlust

Gebrauch generiert Wertgewinn durch Teilung

Tab. 1–2Gegenüberstellung von materiellen Gütern und Daten als Wirtschaftsgüter

Bekannte Methoden und Technologien zum Asset Management können dementsprechend nicht vollumfänglich – insbesondere im Hinblick auf die Ermittlung des Wertes von Daten – herangezogen werden. Der folgende Abschnitt widmet sich unter der Begrifflichkeit Data Valuation speziell dem Thema Wertermittlung von Daten.

1.3.2Data Valuation

Die Standards zur Verwaltung von physischen Assets sind in ISO 55001 geregelt. Basierend auf diesem Standard entwickelte The Institute of Asset Management (IAM) einen Leitfaden zur Bewertung von Wirtschaftsgütern, der als Voraussetzung ein Verständnis über Kosten und Risiken zu einem Vermögensgegenstand über den gesamten Lebenszyklus anführt [Fleckenstein & Fellows 2018, S. 15 ff.].

Als Wirtschaftsgut besitzen Daten einen Wert, der von den Unternehmen zwar erkannt wird, sich allerdings nur schwer bestimmen und quantifizieren lässt. Im International Accounting Standard (IAS) 38 sind immaterielle Wirtschaftsgüter definiert als identifizierbare nicht monetäre Vermögenswerte ohne physische Substanz. Diese Definition trifft auch auf Daten zu, dennoch fließen sie aber bislang nicht als Wirtschaftsgüter in die Bilanzen ein [Treder 2019, S. 43].

Eine Bewertung von Daten kann aus verschiedenen Blickrichtungen und in Abhängigkeit von ihrer spezifischen Rolle in einem Unternehmen durchgeführt werden. Eine gebräuchliche Einteilung unterscheidet zwischen den Bewertungskategorien Kosten, Nutzen und Marktwert. Signifikanten Einfluss auf den Wert von Daten übt die jeweilige Datenqualität aus [Krotova & Spiekermann 2020].

Kosten entstehen entlang des gesamten Data Lifecycle und weisen einen direkten Zusammenhang mit der Bewirtschaftung von Daten auf (z.B. Infrastruktur, Softwarelizenzen, Personal usw.). Eine naheliegende Option besteht darin, die Summe aller angefallenen Kosten für die Erzeugung bzw. Beschaffung und die Pflege der Daten für die Bewertung heranzuziehen. Falls Daten reproduzierbar oder ersetzbar sind, lassen sich alternativ die entsprechenden Reproduktionskosten oder Kosten für einen Datenersatz zugrunde legen [Rea & Sutton 2019, S. 6].

Bezüglich der Kosten seien an dieser Stelle auch Kosten für vermeintlich suboptimale Architekturansätze erwähnt. Lässt eine Architektur z.B. Datensilos zu, dann können Opportunitätskosten entstehen und – im ungünstigsten Fall – sogar die durch Daten gewonnenen Werte zerstören. Als mögliche Folgen von Datensilos lassen sich anführen [Treder 2019, S. 50]:

Unterschiedliche Antworten auf die gleichen Fragestellungen

Verzögerung bei der Umsetzung neuer Geschäftsmodelle

Inkompatibilität bei der Zusammenführung von Silo-übergreifenden Daten

Doppelte Arbeit

Erschwerte Einhaltung regulatorischer Anforderungen

Der Nutzwert von Daten erweist sich als ungleich schwerer bestimmbar als die zugehörigen Kosten und lässt sich nicht immer exakt quantifizieren. Vor allem wenn neben dem tatsächlich generierten Nutzen (»finanzieller Nutzen«) auch der potenziell mögliche Nutzen (»finanzielle Chance«) erhoben werden soll [Glazer 1993], präsentiert sich die Erhebung als große Herausforderung und lässt sich nur zusammen mit Domänenexperten sowie mit erheblichem Aufwand näherungsweise ermitteln [Krotova & Spiekermann 2020]. Tatsächlich generierter Nutzen erwächst aus dem identifizierten Mehrwert, der sich aus der Datennutzung ergibt, beispielsweise durch eine Verbesserung von Prozessabläufen. Daneben gilt es hier, auch Kosten oder entgangene Gewinne zu bestimmen, die aus der Verwendung ungeeigneter oder fehlerhafter Daten resultieren. Potenziell möglicher Nutzen dagegen verweist auf zukünftige Chancen und Risiken durch die Datenverwendung, etwa durch zusätzliche Erlöse oder auch Datenverluste.

Als drittes, mögliches Bewertungskriterium dient der Marktwert der Daten, bei dem die Daten als Produkte verstanden und gehandelt werden [Krotova & Spiekermann 2020, S. 30]. Als Voraussetzung hierfür gilt, dass es Marktteilnehmer mit der Bereitschaft gibt, für die Daten zu zahlen. Erst durch das Zusammentreffen von Angebot und Nachfrage für ein Gut erwächst ein Preis. Obwohl bereits erste Datenmarktplätze existieren, die als Plattform einen geregelten Austausch von Daten und dafür zu zahlende Preise gewährleisten wollen, stehen die zugehörigen Geschäftsmodelle noch am Anfang und befinden sich häufig im Aufbau [Krotova & Spiekermann 2020, S. 31]. Den Regelfall dürften daher heute noch bilaterale Austauschbeziehungen zwischen Anbieter und Nachfrager von Daten darstellen. Einen Sonderfall stellt hier der Handel mit Adress- und anderen personenbezogenen Verbraucherdaten dar, der unter engen rechtlichen Rahmenbedingungen gestattet ist [Goldhammer & Wiegand 2017].

Fazit: Dass Daten heute einen ökonomischen Wert besitzen, wird nicht angezweifelt. Auch wenn sich die Bewertungsmethoden noch in der Entwicklungsphase befinden, müssen Daten als Wirtschaftsgut verstanden und entsprechend behandelt werden.

1.3.3Data Management

Allgemein lässt sich unter Data Management das gesamte Spektrum an technischen, konzeptionellen, methodischen und organisatorischen Methoden, Verfahren und Konzepten zur Steuerung, Beschaffung, Bereitstellung, Verwendung, Qualitätssicherung oder Entsorgung von internen und externen Daten subsumieren. Damit deckt das Data Management den gesamten Lebenszyklus der Daten von ihrer ursprünglichen Erstellung bis zu einem gültigen Ruhezustand ab [Krcmar 2015, S. 178 f.]. Als ausübende Instanz der Datenbewirtschaftung setzt das Data Management die Vorgaben um, die aus diversen Governance-Vorgaben erwachsen [Krotova & Eppelsheimer 2019].

In diesem Kontext erweist sich vor allem das Zusammenspiel von Data Governance und Data Management als richtungsweisend. Obwohl in der betrieblichen Praxis die beiden Begrifflichkeiten häufig als Synonyme Verwendung finden, erweisen sich Data Governance und Data Management als eher komplementär [Al-Ruithe et al. 2018, S. 6]. Als verbindliche Grundlage für die Aktivitäten im Data Management definiert die Data Governance Richtlinien und Prinzipien in den Handlungsfeldern Aufbauorganisation, Prozesse und Standards, Technologie und Kommunikation, die jeweils zu beobachten, zu messen und zu steuern sind [Gluchowski 2020, S. 6; Fleckenstein & Fellows 2018, S. 63 ff.]. Während die Data Governance damit den Ordnungsrahmen für den angemessenen Umgang mit betrieblichen Daten als wichtige Wirtschaftsgüter aufspannt, setzt das Data Management diese Vorgaben mit geeigneten Konzepten und Werkzeugen um und implementiert sie damit in den Entwicklungs- und Betriebsprozessen [Khatri & Brown 2010].

Hierbei gliedert sich Data Management in eine Reihe von Domänen, die zwar jeweils abgrenzbare Teilaspekte adressieren, allerdings nicht isoliert betrachtet oder gar implementiert werden dürfen, sondern aufgrund vielfältiger Wechselbeziehungen stets im Zusammenspiel mit den anderen Domänen zu betrachten sind [Fleckenstein & Fellows 2018, S. 39]. Beim konkreten Zuschnitt der Domänen und der sich daraus ergebenden Beziehungen entstehen vielfältige Wahlmöglichkeiten, die sich in unterschiedlichen Sichtweisen und Abgrenzungen verfestigen. Den nachfolgenden Ausführungen liegt das »DAMA Wheel« zugrunde (vgl. Abb. 1–4), da es vergleichsweise einfach zu verstehen ist und sich in der Praxis etabliert hat.

Abb. 1–4Komponenten des Datenmanagements [DAMA 2017]

Im Ansatz der Data Management Association (DAMA), der unter der Bezeichnung DAMA-Data Management Body of Knowledge (DMBOK) inzwischen in der Version 2 veröffentlicht wurde, setzt sich das Datenmanagement aus elf Komponenten zusammen, von denen die Data Governance den zentralen Ankerbaustein bildet. Der nachfolgende, tabellarische Gesamtüberblick in Tabelle 1–3 leitet über zu einer Beschreibung der für die weiteren Betrachtungen wichtigsten Domänen.

Domäne

Kurzbeschreibung

Data Governance

Orientierung für das Data Management durch Etablierung eines Systems an Verfügungsrechten, Rollen, Prozessen etc.

Data Modeling & Design

Übersetzung von Datenanforderungen in formale Datenmodelle

Data Storage & Operations

Entwurf, Implementierung und Support der Datenspeicherung

Data Security

Management der Vertraulichkeit, Integrität und Verfügbarkeit von Daten

Data Integration & Interoperability

Bewegung und Konsolidierung von Daten zwischen Anwendungen und Organisationen

Document & Content Management

Management des Lebenszyklus von Daten in beliebigen Medien

Reference & Master Data Management

Management der zentralen, geteilten Stammdaten

Data Warehousing & Business Intelligence

Bereitstellung von entscheidungsunterstützenden Daten und Auswertungen

Metadata

Data Management für Metadaten, also beschreibende Angaben über Dateninhalte, -strukturen und -prozesse

Data Quality

Management von Aktivitäten, um Daten in der benötigten Qualität bereitzustellen

Data Architecture

Architektur mit Angaben darüber, wie Daten in ihrem Lebenszyklus durch Systeme fließen

Tab. 1–3Domänen des Data Management gemäß DAMA Wheel

Aufgabe des Master Data Management ist es, dafür Sorge zu tragen, dass die zentralsten Daten einer Organisation wohldefiniert sind [Fleckenstein & Fellows 2018, S. 93]. Hervorgegangen aus dem Management von Kundendaten sowie dem Produktdatenmanagement stehen auch heute diese beiden Entitätstypen im Vordergrund, da sich ihre Bedeutung für die meisten Organisationen als besonders kritisch erweist. Beide Entitätstypen können zwar in komplexen und jeweils hierarchischen Datenmodellen durch verschiedene Sichten unterschiedlicher Fachbereiche münden. Allerdings sind die eigentlichen »Stammdaten« (Master Data) typischerweise klein und beschränkten sich auf wenige Felder mit herausragender und oft übergreifender Bedeutung. Ziel des Master Data Management ist es, für eine konsistente Sicht auf diese Stammdaten in der gesamten Organisation zu sorgen und dabei Dubletten aufzulösen und ggf. die verteilte Bearbeitung der Stammdaten zu ermöglichen. Eng verwandt mit dem Master Data Management ist das Reference Data Management, bei dem Daten Beachtung finden, die zum Klassifizieren und Kategorisieren anderer Daten dienen.

In die Domäne Data Quality fällt das Management der Datenqualität, das das Ziel verfolgt, Daten in derjenigen Qualität bereitzustellen [Fleckenstein & Fellows 2018, S. 101 ff.], die für die spätere Nutzung erforderlich ist. Der Begriff der Datenqualität kann nicht absolut definiert werden, sondern immer nur in Abhängigkeit der späteren Anwendung. Typischerweise lassen sich Richtigkeit, Vollständigkeit, Konsistenz, Latenz und Angemessenheit der Daten voneinander abgrenzen. Das Management der Datenqualität umfasst den gesamten Lebenszyklus von Daten, beginnend mit ihrem Entstehen bzw. ihrer Einpflege in ein System. Wichtige Werkzeuge sind z.B. das Data Profiling, das Data Quality Monitoring sowie das Data Cleansing, wobei sich in diesen Tätigkeitsfeldern die Einbindung von Mitarbeitern aus den Fachabteilungen als erforderlich erweist. Eine hohe Datenqualität erfordert dabei grundsätzlich die übergreifende Zusammenarbeit, Kommunikation und auch Abstimmung. Maßnahmen zur Qualitätsverbesserung von Daten orientieren sich häufig an Vorgehensweisen zur Qualitätsverbesserung in industriellen Prozessen, folgen damit z.B. dem Deming- oder PDCA-Zyklus (bestehend aus Plan, Do, Check, Act) [Deming 1982].

Die Domäne Data Security soll gewährleisten, was häufig mit dem Akronym C.I.A. bezeichnet wird: die Vertraulichkeit (Confidentiality), Integrität (Integrity) und Verfügbarkeit (Availability) von Daten [Fleckenstein & Fellows 2018, S. 166]. Wie in anderen Managementdisziplinen auch, besteht die Aufgabe darin, den gewünschten Status zu planen (z.B. Kategorisierung von Daten nach Schutzbedürftigkeit und Festlegung dessen), diesen umzusetzen, die Einhaltung zu überwachen bzw. zu auditieren und eventuelle Auffälligkeiten in geeigneter Weise zu behandeln.

Metadata umfasst beschreibende Angaben über den Inhalt, die Struktur, die Verarbeitung und die Nutzung von Daten und bildet damit eine Grundvoraussetzung für die effektive Verwendung des Datenbestands einer Organisation [Fleckenstein & Fellows 2018, S. 166]. So wie »Data Management« den professionellen Umgang mit Daten allgemein adressiert, bezieht sich »Metadata Management« auf die Teilmenge der Metadaten. Metadaten vereinfachen die Zugänglichkeit von Daten, z.B. durch die Verwendung eines Datenkatalogs, der Daten-Assets in einem zentralen Verzeichnis verwaltet. Sie helfen mit Einblicken in die Datenherkunft (Data Lineage: Rückverfolgung der Herkunft von Daten von der Auswertung zur Quelle) und Datenverwendung (Impact Analysis: Abschätzung von Auswirkungen in nachgelagerten Systemen bei Veränderungen in Quellsystemen). Darüber hinaus lassen sich Metadaten effizienzsteigernd bei der Automatisierung verwenden (bspw. im Rahmen des Data-Vault-Ansatzes).

Ziel der Domäne Data Modeling & Design ist es, die genauen Datenanforderungen zu verstehen und diese anschließend in ein formales Datenmodell – besteht aus Metadaten zur Beschreibung der konkreten Daten – zu überführen [DAMA 2017, Kap. 5]. Je nach prinzipieller Struktur der Daten gibt es eine Reihe unterschiedlicher Schemata und Notationen für Datenmodelle, darunter UML für objektorientierte Strukturen, Entity-Relationship-Diagramme z.B. in der Chen-Notation für relationale Strukturen oder die Data-Vault-Modellierungstechnik.

Mit Data Integration & Interoperability werden Prozesse beschrieben, im Rahmen derer Daten über System-, Anwendungs- und/oder Organisationsgrenzen hinweg transportiert oder transformiert werden [DAMA 2017, Kap. 8]. Zu den wesentlichen Konzepten zählen das Batch-orientierte ETL bzw. ELT genauso wie Streaming-Ansätze, ein Enterprise Service Bus (ESB) und Data Virtualization.

Mit den einzelnen Facetten des DAMA Wheel sind auch die Handlungsfelder für das Datenmanagement in Unternehmen umrissen, die allerdings auch mit den Zielvorstellungen und Prioritäten der unterschiedlichen Stakeholder in Deckung gebracht werden müssen, wie der folgende Abschnitt aufzeigt.

1.4Anforderungen an eine ganzheitliche BIA-Architektur

Die Gestaltung einer angemessenen Architektur für BIA-Landschaften muss sich an den gegebenen Rahmenbedingungen orientieren. Dazu gehören neben der grundsätzlichen Ausrichtung der jeweiligen Organisation mit Geschäftsmodell und Unternehmensstrategie auch die darauf aufbauenden Vorgaben, die in der Datenstrategie und der Data Governance dokumentiert sind.

Als weiterer wichtiger Bestimmungsfaktor sind die funktionalen und nicht funktionalen Anforderungen der einzelnen Anspruchsgruppen anzuführen. Funktionale Anforderungen werden in erheblicher Weise vom jeweiligen Anwendungskontext determiniert und variieren stark in Abhängigkeit von Branchenzugehörigkeit, Unternehmensgröße und zu unterstützender Unternehmensfunktion. Dagegen adressieren die nicht funktionalen Anforderungen – auch als Qualitätsanforderungen bezeichnet – Themengebiete wie Performance, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit und Portabilität [Pohl & Rupp 2011, S. 16].

Als Anspruchsgruppen lassen sich neben dem Management grob die Anwender von den Entwicklern und Betreibern unterscheiden (vgl. Abb. 1–5). Das Management setzt sich in dieser Einteilung aus den Entscheidungsträgern oberer und ggf. mittlerer Führungsebenen zusammen und nimmt einen eher übergeordneten Blick auf die Systemlandschaft ein (auch wenn Führungskräfte als Anwender auf bestimmte Teile des BIA-Ökosystems zugreifen wollen). Den Entscheidern ist insbesondere die Einhaltung übergeordneter interner und externer Regeln und Vorgaben wichtig, weshalb hier die Themenbereiche Compliance und Governance stark im Fokus stehen. Als Budgetverantwortliche stecken sie den Rahmen für die verfügbaren finanziellen Ressourcen ab und richten besonderes Augenmerk auf Nutzen und Kosten (Wirtschaftlichkeit) eines BIA-Vorhabens.

Den Anwendern von BIA-Lösungen, die zumeist in den einschlägigen Fachbereichen wie Controlling oder Marketing beheimatet sind, liegt vor allem die bestmögliche Unterstützung der eigenen, fachlichen Arbeitsaufgaben am Herzen. Immer stärker rückt dabei die Geschwindigkeit in den Vordergrund, mit der sich neue fachliche Anforderungen im geschäftlichen Kontext ergeben und die rasch in den Systemen ihren Niederschlag finden sollen. Da sich eine derartig ausgeprägte Agilität nicht immer mit den Verfahren eines klassischen Anforderungsund Projektmanagements erreichen lässt, wird häufig größere Autonomie bei der selbstständigen Erarbeitung von Lösungen eingefordert, die in Konzepten wie Self-Service-BI ihre Umsetzung findet. Um dem schnelllebigen fachlichen Umfeld gerecht werden zu können, bedarf es auch Lösungen, die mit möglichst geringem Zeitverzug (Latenz) neue Informationen zugänglich machen. Zur Bewältigung dieser Herausforderung lassen sich Real- bzw. Right-Time-Konzepte verwenden. Daneben werden hier Werkzeuge zur Automatisierung eingesetzt, die zusätzlich von aufwendigen Vorarbeiten zur Datenbereinigung und -transformation entlasten können. In Bezug auf die auswertbaren Datenformate hat seit einigen Jahren eine verstärkte Einbeziehung auch unstrukturierter sowie semistrukturierter Daten in den Fachbereichen Einzug gehalten – teils aus internen (Sensordaten), teils aus externen Quellen (Daten aus sozialen Medien). Unabhängig von der Datenherkunft erwarten die Anwender oftmals, dass sie den angebotenen Inhalten vertrauen können.

In Abgrenzung vom Anwender verfolgen die Entwickler und Betreiber von BIA-Landschaften oftmals abweichende Ziele, aus denen eine andere Priorisierung von Anforderungen resultieren kann. Häufig erhalten hier beispielsweise Aspekte wie Datensicherheit und -schutz eine viel höhere Bedeutung wie auch die Widerspruchsfreiheit der Daten (Konsistenz) und umfangreiche Transparenz über die einzelnen Objekte der Architektur einschließlich Strukturen und Abhängigkeiten (z.B. Datenflüsse). Als wichtige Faktoren gelten weiterhin die Skalierbarkeit der Systemlösung, beispielsweise bei steigendem Datenvolumen, sowie die jederzeitige Verfügbarkeit und Stabilität.

Abb. 1–5Anforderung von Anspruchsgruppen an eine BIA-Landschaft

Die Ausführungen zeigen, dass die unterschiedlichen Anspruchsgruppen stark voneinander abweichende Zielvorstellungen und damit auch Anforderungen an eine geeignete BIA-Systemlandschaft aufweisen.

Der folgende Abschnitt beleuchtet nochmals die klassischen BIA-Architekturen, die über viele Jahre hinweg in den Organisationen als stabiles Fundament für die Gesamtlandschaft genutzt worden sind und bisweilen auch heute noch genutzt werden.

1.5Klassische Architekturen für BIA-Ökosysteme

Bevor der Hauptteil des vorliegenden Sammelbandes auf moderne BIA-Architekturen eingeht, soll an dieser Stelle zunächst ein Blick zurück geworfen werden auf die Architekturformen, die sich langjährig als Standard im Bereich BIA etablieren konnten.

Für eine gewisse Zeit schien die Diskussion um BIA-Architekturen bis auf Nuancen erledigt zu sein. Nach anfänglich konträren Ansätzen hatte sich schließlich die Hub-and-Spoke-Architektur als Quasistandard etabliert [Hahne 2014, S. 10 ff.]. Zugrunde liegen dabei die Kernideen eines Data Warehouse (DWH) durch Trennung von operativen und dispositiven Daten und Zusammenführung von Daten aus unterschiedlichen Quellen in einem abgestimmten Datenmodell (vgl. Abb. 1–6).

Abb. 1–6Hub-and-Spoke-Architektur [Gluchowski et al. 2008, S. 141]

Das Data Warehouse hält Schnappschüsse des unternehmensweiten Datenstands von operationalen Systemen dauerhaft fest und stellt diese für Analysen bereit [Fleckenstein & Fellows 2018, S. 123]. Das DWH-Konzept kam in den 1990er-Jahren erstmalig zur praktischen Anwendung und dient seither als Datenbasis für strategische Berichts-, Analyse- und Planungssysteme [Bauer & Günzel 2013, S. 11–13].

Neben kostenlosen oder kostenpflichtigen externen Daten dienen als primäre Datenquellen die operativen Systeme. Per ETL (Extraktion, Transformation, Laden) werden hieraus Daten über potenziell mehrere Zwischenschichten in ein passendes Schema überführt und im Enterprise Data Warehouse gespeichert. Neben dieser Vorgehensweise bietet sich insbesondere in großen Landschaften mit hohem Datenvolumen ein ELT an, bei dem nach der Extraktion die Daten zunächst in einen speziellen Speicherbereich des Data Warehouse (Staging Area) geschrieben und danach meist mit datenbankeigenen Mitteln wie Views oder Skripten weiterverarbeitet werden.

Anschließend erfolgt die Bereitstellung von Teilmengen der Daten aus dem Data Warehouse für die Fachanwender als Data Marts, dann z.B. zugeschnitten auf die Anforderungen eines spezifischen Fachbereichs. Diese Data Marts dienen schließlich als Datenquelle für die Auswertungen mit geeigneten Endbenutzerwerkzeugen, z.B. einem Berichtssystem oder Softwareprodukten für die Visualisierung der Daten als Dashboard.

Die Bezeichnung Hub-and-Spoke (Nabe und Speiche) wird allgemein für Architekturen verwendet, wenn die Verbindung von der Quelle zur Senke nicht direkt, sondern über einen zentralen Verbindungsknoten führt, die Nabe (engl. Hub). Im konkreten Fall der klassischen BIA-Architektur werden die Daten ausgehend von den Quellsystemen über die zentrale Nabe Data Warehouse in die Data Marts übertragen, von wo aus sie die unterschiedlichen Auswertungswerkzeuge speisen.

Eine Metadatenverwaltungskomponente sowie eine Archivierungs- und Backup-Komponente flankieren die Kernkomponenten der Hub-and-Spoke-Architektur.

Ein näherer Blick auf das Data Warehouse selbst enthüllt verschiedene logische (Daten-)Schichten bzw. Layer (vgl. Abb. 1–7).

Wie bereits vorangehend illustriert, integriert das Enterprise Data Warehouse Inhalte aus (i.d.R. mehreren) Datenquellen und leitet sie schlussendlich an (i.d.R. mehrere) Data Marts bzw. den Reporting Layer für Auswertungen weiter.

Eine zentrale Sammlung der Daten erfolgt im Integration Layer oder Core bzw. Enterprise Data Warehouse. Meist werden die Daten hier heute in größtmöglicher Detaillierung gespeichert und über mehrjährige Zeiträume aufbewahrt. Im Idealfall existiert für die gesamte Organisation nur ein einzelner Integration Layer – dann auch als »Single Point of Truth« (SPOT) bezeichnet – mit aufbereiteten und qualitätsgesicherten Inhalten.