Datenmanagement im Maßstab, 2. Auflage

Kapitel 1. Die Reise zum datengesteuerten Unternehmen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Die Welt vor der COVID-19 war bereits schnell und stark datengesteuert, aber das Tempo des Wandels hat sich rapide beschleunigt. Der harte Wettbewerb, das Zeitalter der Digitalisierung, die steigenden Kundenerwartungen und die zunehmende Kontrolle durch die Aufsichtsbehörden zwingen die Unternehmen, sich in moderne datengesteuerte Unternehmen zu verwandeln. Dieser Wandel wird unweigerlich dazu führen, dass die Organisationen von morgen digitaler sind als die von heute und einen anderen Blick auf Daten haben werden. Die Unternehmen von morgen werden Daten atmen und sich eine Philosophie zu eigen machen, die sie in den Mittelpunkt ihres Geschäfts stellt. Sie werden Daten wie ein Produkt verwalten, strategische Entscheidungen auf der Grundlage von Datenanalysen treffen und eine Kultur haben, die auf der Grundlage von Daten handelt.

Datenorientierung ist nicht nur ein Modewort.¹ Datengesteuert zu sein, verschafft einem Unternehmen einen erheblichen Wettbewerbsvorteil gegenüber anderen Unternehmen. Sie kann proaktiv handeln und vorhersagen, was passieren wird, bevor es passiert. Durch die richtige Nutzung von Daten können Unternehmen schnell auf Veränderungen reagieren. Die Nutzung von Daten führt zu mehr Vertrauen, weil Entscheidungen auf Fakten und nicht auf Intuition beruhen. Mit Daten können neue Branchentrends und Geschäftsmöglichkeiten früher erkannt werden. Auch die Kundenbindung und -zufriedenheit wird verbessert, weil die Daten den Unternehmen sagen, was die Kunden denken, wie sie sich verhalten und was sie wollen. Mit Daten können Unternehmen flexibler, agiler und kosteneffizienter arbeiten, weil sie Einblicke in gemessene Ergebnisse, Mitarbeiterbindung, Abhängigkeiten, Anwendungen und Prozesse erhalten. Die Notwendigkeit für Organisationen, sich in datengesteuerte Unternehmen zu verwandeln, ist also definitiv gegeben.

Bevor wir uns mit der eigentlichen Umstellung befassen, werden wir uns mit den aktuellen Herausforderungen befassen, die eine Neubewertung des Datenmanagements erfordern. Wir werden eine gemeinsame Definition von Datenmanagement aufstellen, die alle Disziplinen und Aktivitäten im Zusammenhang mit der Verwaltung von Daten als Vermögenswert umfasst. Danach werden wir einige wichtige technologische Entwicklungen und Branchentrends näher beleuchten und ihre Auswirkungen auf das Datenmanagement untersuchen. Wir werfen einen Blick auf einige bewährte Methoden aus dem letzten Jahrzehnt des Datenmanagements und erfahren, warum Architekturen der vorherigen Generation schwer zu skalieren sind. Abschließend werden wir uns überlegen, wie eine Datenarchitektur der nächsten Generation aussehen könnte, und ich werde eine Reihe von Aktionspunkten vorstellen, die du bei der Entwicklung deiner Datenstrategie berücksichtigen musst.

Jüngste Technologieentwicklungen und Branchentrends

Die Umstellung einer Organisation auf Datenorientierung ist nicht einfach. Es ist ein langfristiger Prozess, der Geduld und Ausdauer erfordert. Da immer mehr Daten zur Verfügung stehen, können herkömmliche Architekturen aufgrund ihrer Größe, Komplexität, monolithischen Designs und zentralistischen Betriebsmodelle nicht mehr skaliert werden. Die Unternehmen brauchen eine neue Datenstrategie und eine Cloud-basierte Architektur. Auch ein Paradigmenwechsel und eine Änderung der Unternehmenskultur sind erforderlich, denn die zentralisierten Daten- und IT-Betriebsmodelle, die heute funktionieren, werden nicht mehr funktionieren, wenn föderierte Dateneigentums- und Selbstnutzungsmodelle zum Einsatz kommen. Dies erfordert, dass Unternehmen neu definieren, wie Menschen, Prozesse und Technologien mit Daten in Einklang gebracht werden.

Die jüngsten technologischen Entwicklungen und Branchentrends zwingen uns, die Art und Weise, wie Daten verwaltet werden müssen, neu zu bewerten. Wir müssen weg davon, alle Daten in ein einziges Silo zu leiten, hin zu einem Ansatz, der es Bereichen, Teams und Nutzern ermöglicht, Daten einfach und sicher zu verteilen, zu nutzen und selbst zu verwenden. Plattformen, Prozesse und Muster sollten die Arbeit für andere vereinfachen. Wir brauchen Schnittstellen, die einfach, gut dokumentiert, schnell und leicht zu nutzen sind. Wir brauchen eine Architektur, die im großen Maßstab funktioniert.

Obwohl die Entwicklung zu einer wirklich datengesteuerten Organisation viele positive Aspekte hat, ist es wichtig, sich einiger technologischer Entwicklungen und Branchentrends bewusst zu sein, die sich auf die Datenlandschaft auswirken. In diesem Kapitel gehe ich auf jede dieser Entwicklungen und ihren Einfluss auf das Datenmanagement ein. Erstens fragmentiert die Analytik die Datenlandschaft aufgrund der Vielfalt der Anwendungsfälle. Zweitens erschweren neue Softwareentwicklungsmethoden die Verwaltung von Daten. Drittens: Cloud Computing und schnellere Netzwerke fragmentieren die Datenlandschaft. Außerdem müssen Datenschutz-, Sicherheits- und Regulierungsfragen beachtet werden, und das schnelle Datenwachstum und die intensive Datennutzung lassen die betrieblichen Systeme leiden. Und schließlich erfordert die Monetarisierung von Daten eine Architektur von Ökosystem zu Ökosystem. Die Auswirkungen dieser Trends auf das Datenmanagement sind enorm und zwingen die gesamte Branche dazu, neu zu überdenken, wie das Datenmanagement in Zukunft aussehen muss.

Glücklicherweise sind in den letzten Jahren neue Ansätze für das Datenmanagement entstanden, darunter die Ideen des Data Mesh und der Data Fabric:

• Das Datennetz ist eine aufregende neue Methode zur Verwaltung großer Datenmengen. Das Konzept sieht eine Architektur vor, in der die Daten hochgradig verteilt sind, und eine Zukunft, in der Skalierbarkeit durch die Bündelung von Verantwortlichkeiten erreicht wird. Es legt den Schwerpunkt auf den menschlichen Faktor und auf die Herausforderungen, die mit der Verwaltung der immer komplexer werdenden Datenarchitekturen verbunden sind.

• Die Data Fabric ist ein Ansatz , der die heutigen Herausforderungen der Datenverwaltung und Skalierbarkeit angeht, indem er Intelligenz hinzufügt und den Datenzugriff durch Self-Service vereinfacht. Im Gegensatz zum Data Mesh konzentriert es sich mehr auf die Technologieebene. Es handelt sich um eine architektonische Vision, die einheitliche Metadaten mit einer durchgängig integrierten Schicht (Fabric) für den einfachen Zugriff, die Integration, Bereitstellung und Nutzung von Daten nutzt.

Diese neuen Ansätze für das Datenmanagement ergänzen sich und überschneiden sich oft. Entgegen der weit verbreiteten Meinung unter Datenexperten und den Aussagen kommerzieller Anbieter sollten sie nicht als starre oder eigenständige Techniken betrachtet werden. Ich gehe vielmehr davon aus, dass diese Ansätze nebeneinander bestehen und sich gegenseitig ergänzen werden, ebenso wie bestehende Investitionen in operative Datenspeicher, Data Warehouses und Data Lakes.

Beim Übergang zu einer datengesteuerten Organisation müssen Unternehmen Kompromisse eingehen, um die Imperative der Zentralisierung und Dezentralisierung auszugleichen. Einige bevorzugen ein hohes Maß an Autonomie für ihre Geschäftsteams, während andere auf Qualität und Kontrolle Wert legen. Manche Organisationen haben eine relativ einfache Struktur, während andere brutal groß und komplex sind. Es ist nicht einfach, die perfekte Governance-Struktur und Datenarchitektur zu schaffen. Deshalb möchte ich dich ermutigen, bei der Entwicklung deiner Strategie diese Ansätze für das Datenmanagement als Rahmen zu betrachten. Es gibt kein Richtig oder Falsch. Beim Data-Mesh-Ansatz zum Beispiel magst du vielleicht einige der bewährten Methoden und Prinzipien mögen, andere nicht; du musst nicht unbedingt alle anwenden.

In diesem Buch teile ich meine Sichtweise zum Thema Datenmanagement - eine Sichtweise, die auf Beobachtungen aus der Praxis basiert, während ich eng mit vielen großen Unternehmen zusammengearbeitet habe, und die dir hilft, die richtigen Entscheidungen zu treffen, indem du von anderen lernst. Wir werden über die Konzepte des Datengeflechts und der Datenstruktur hinausgehen, denn ich bin der festen Überzeugung, dass eine Datenstrategie sowohl die operative als auch die analytische Ebene umfassen sollte und dass die Methode zur Zerlegung von Datendomänen und Datenprodukten geändert werden muss, um der Größe großer Unternehmen gerecht zu werden. Um dir auf deinem Weg zu helfen, werde ich meine Beobachtungen zu den Strategien und Architekturen teilen, die verschiedene Unternehmen entwickelt haben, und warum und welche Kompromisse sie eingegangen sind.

Bevor wir ins Detail gehen, müssen wir uns darauf einigen, was Datenmanagement ist und warum es wichtig ist. Als Nächstes müssen wir festlegen, wie wir die Grenzen definieren und unsere Landschaft auf der Grundlage verschiedener Kompromisse gestalten. Schließlich werden wir untersuchen, wie aktuelle Unternehmensdatenarchitekturen für heute und morgen gestaltet und organisiert werden können.

Lassen Sie mich die Karten auf den Tisch legen: Dezentralisierung ist kein gewünschter Zustand, sondern die unvermeidliche Zukunft der Daten. Ich bin daher der festen Überzeugung, dass die Skalierbarkeit das Datenmanagement zu einer dezentraleren Organisation zwingt. Ein skalierbares Datenmanagement erfordert, dass du die wichtigsten Verantwortlichkeiten zusammenlegst, strenge Standards festlegst und die zentralen und lokalen Ressourcen und Aktivitäten richtig abstimmst. Diese Veränderung betrifft mehrere Bereiche: Menschen, Prozesse und Technologie. Sie zwingt dich dazu, deine Architektur aufzulösen und die Zuständigkeiten aufzuteilen und zu gruppieren. Die Verlagerung von der Zentralisierung zur Dezentralisierung widerspricht auch der bewährten Methode des letzten Jahrzehnts: dem Aufbau großer Datensilos, in denen alle Daten gesammelt und integriert werden, bevor sie bereitgestellt werden. Obwohl Data-Warehouse- und Data-Lake-Architekturen hervorragende Ansätze für die Nutzung von Daten sind, eignen sich diese zentralisierten Modelle nicht für eine dezentralisierte, verteilte Datenarchitektur.

Nachdem wir nun den Rahmen abgesteckt haben, möchte ich dich bitten, tief durchzuatmen und deine Vorurteile beiseite zu legen. Viele von uns sind vielleicht sehr an zentralisierten Datenarchitekturen interessiert; dies ist seit vielen Jahren eine bewährte Methode. Ich räume ein, dass die Notwendigkeit der Datenharmonisierung und der Einordnung großer Datenmengen in einen bestimmten Kontext nach wie vor besteht und dass dies für Unternehmen von großem Nutzen ist, aber wir müssen bedenken, in welchem Maßstab wir diese Disziplin anwenden wollen. Ist es in einem hochgradig verteilten Ökosystem mit Hunderten oder gar Tausenden von Anwendungen die beste Art der Datenverwaltung, alle Dimensionen zu zentralisieren? Ist es am besten, alle Daten zu integrieren und zu harmonisieren?

Datenmanagement

Der Begriff Datenmanagement bezieht sich auf die Gesamtheit der Prozesse und Verfahren, die zur Verwaltung von Daten eingesetzt werden. Im Data Management Body of Knowledge (DAMA-DMBOK) der Data Management Association ( ) wird der Begriff Datenmanagement ausführlicher erläutert und definiert als "die Entwicklung, Ausführung und Überwachung von Plänen, Richtlinien, Programmen und Praktiken, die den Wert von Daten und Informationsbeständen während ihres gesamten Lebenszyklus bereitstellen, kontrollieren, schützen und steigern".² Das DAMA-DMBOK identifiziert 11 Funktionsbereiche des Datenmanagements, in deren Zentrum die Data Governance steht (siehe Abbildung 1-1). Es ist wichtig, alle diese Bereiche tief in deiner Organisation zu verankern. Andernfalls fehlt dir der Einblick und du wirst ineffektiv, und deine Daten geraten außer Kontrolle. Es wird eine Herausforderung sein, datengesteuert zu werden und so viel wie möglich aus deinen Daten herauszuholen. Analytik ist zum Beispiel nichts wert, wenn du nur Daten von geringer Qualität hast.

Abbildung 1-1. Die 11 Funktionsbereiche des Datenmanagements

Die Aktivitäten und Disziplinen des Datenmanagements sind breit gefächert und umfassen mehrere Bereiche, von denen einige eng mit der Softwarearchitektur verbunden sind.³ In diesem Buch konzentriere ich mich auf die Aspekte des Datenmanagements, die für die Verwaltung einer modernen, skalierbaren Datenarchitektur am wichtigsten sind. Schauen wir uns die 11 Bereiche in dieser Abbildung genauer an und wo sie im Buch behandelt werden:

• Die Data Governance, die in Abbildung 1-1 unter dargestellt ist, umfasst alle Aktivitäten zur Implementierung und Durchsetzung von Befugnissen und Kontrolle über die Verwaltung von Daten, einschließlich aller dazugehörigen Vermögenswerte. Dieser Bereich wird in Kapitel 8 ausführlich beschrieben.

• Die Datenarchitektur umfasst die Definition von dem Masterplan für deine Daten, einschließlich der Blueprints,⁴ Referenzarchitekturen, Visionen für den zukünftigen Zustand und Abhängigkeiten. Die Verwaltung dieser Daten hilft Unternehmen, Entscheidungen zu treffen. Das gesamte Buch dreht sich um die Datenarchitektur im Allgemeinen, aber die Disziplin und ihre Aktivitäten werden in den Kapiteln 2 und 3 ausführlich behandelt.

• Beider Datenmodellierung und -gestaltung geht es um die Strukturierung und Darstellung von Daten in einem bestimmten Kontext und bestimmten Systemen. Das Ermitteln, Entwerfen und Analysieren von Datenanforderungen ist Teil dieser Disziplin. Wir werden diese Themen in den Kapiteln 4, 7 und 11 behandeln.

• Speicherung und Betrieb von Daten bezieht sich auf die Verwaltung des Datenbankdesigns, die korrekte Implementierung und den Support, um den Wert der Daten zu maximieren. Zum Datenbankmanagement gehört auch das Management des Datenbankbetriebs. Darauf gehen wir in Kapitel 11 ein.

• Die Datensicherheit umfasst alle Disziplinen und Aktivitäten, die eine sichere Authentifizierung, Autorisierung und einen sicheren Zugriff auf die Daten ermöglichen. Zu diesen Aktivitäten gehören Vorbeugung, Prüfung und eskalationsmindernde Maßnahmen. Dieser Bereich wird in Kapitel 8 ausführlicher beschrieben.

• Datenintegration und Interoperabilität umfasst alle Disziplinen und Aktivitäten, die mit dem Verschieben, Sammeln, Zusammenführen, Kombinieren und Umwandeln von Daten zu tun haben, um sie effizient von einem Kontext in einen anderen zu übertragen. Dateninteroperabilität bezieht sich auf die Fähigkeit, zwischen verschiedenen Anwendungen so zu kommunizieren, Funktionen aufzurufen oder Daten zu übertragen, dass nur wenige oder gar keine Kenntnisse über die Eigenschaften der Anwendungen erforderlich sind. Bei der Datenintegration hingegen geht es darum, Daten aus unterschiedlichen (mehreren) Quellen in einer einheitlichen Ansicht zusammenzuführen. Dieser Prozess, den ich für den wichtigsten halte, wird oft durch zusätzliche Tools wie Replikations- und ETL-Tools (Extrahieren, Transformieren und Laden) unterstützt. Er wird in den Kapiteln 4, 5 und 6 ausführlich beschrieben.

• Dokumenten- und Inhaltsmanagement ist der Prozess der Verwaltung von Daten, die in unstrukturierten (Medien) und Datenformaten gespeichert sind. Einige Aspekte davon werden in den Kapiteln 5 und 6 behandelt.

• Beim Referenz- und Stammdatenmanagement geht es darum, kritische Daten zu verwalten, um sicherzustellen, dass die Daten zugänglich, genau, sicher, transparent und vertrauenswürdig sind. Dieser Bereich wird in Kapitel 10 ausführlicher beschrieben.⁵

• Data Warehousing und Business Intelligence Management umfassen alle Aktivitäten, die Geschäftseinblicke liefern und die Entscheidungsfindung unterstützen. Dieser Bereich, einschließlich der fortgeschrittenen Analytik, wird in Kapitel 11 ausführlicher beschrieben.

• DasMetadatenmanagement umfasst die Verwaltung aller Daten, die die Daten klassifizieren und beschreiben. Metadaten können verwendet werden, um die Daten verständlich, integrationsfähig und sicher zu machen. Sie können auch dazu dienen, die Qualität der Daten zu sichern. Dieser Bereich wird in Kapitel 9 ausführlicher beschrieben.

• DasDatenqualitätsmanagement umfasst alle Aktivitäten, die mit der Verwaltung der Datenqualität zusammenhängen, um sicherzustellen, dass die Daten genutzt werden können. Einige Aspekte dieses Bereichs werden in den Kapiteln 2 und 3 beschrieben.

Der Teil des DAMA-DMBOK, an dem noch gearbeitet werden muss und der mich dazu inspiriert hat, die erste Ausgabe dieses Buches zu schreiben, ist der Abschnitt über Datenintegration und Interoperabilität. Meiner Meinung nach fehlt es diesem Abschnitt an Tiefe: Die Beziehung zur Anwendungsintegration und Softwarearchitektur ist nicht klar. Es wird nicht auf dezentrale Architekturen eingegangen, und es fehlen moderne Anleitungen zur Interoperabilität von Daten, wie z. B. bewährte Methoden zur Beobachtung und modernes Daten-Pipeline-Management. Darüber hinaus ist die Verbindung zum Metadatenmanagement schwach. Auch Metadaten brauchen Integration und Interoperabilität, denn sie sind über viele Tools, Anwendungen, Plattformen und Umgebungen in unterschiedlichen Formen und Ausprägungen verstreut. Die Interoperabilität von Metadaten - also die Fähigkeit von zwei oder mehr Systemen oder Komponenten, beschreibende Daten über Daten auszutauschen - wird nur unzureichend behandelt: Beim Aufbau und der Verwaltung einer groß angelegten Architektur geht es vor allem um die Integration von Metadaten. Interoperabilität und Metadaten sind auch nicht gut mit dem Bereich der Datenarchitektur verbunden. Wenn Metadaten richtig eingesetzt werden, kannst du sehen, welche Daten an dir vorbeigehen, wie sie integriert, verteilt und gesichert werden können und wie sie mit Anwendungen, Geschäftsfunktionen usw. verbunden sind. Im DAMA-DMBOK gibt es nur wenige Hinweise, wie du deine Daten als Ganzes verwalten kannst, indem du die Metadaten von nutzt und miteinander verbindest.

Eine weitere Sorge, die ich habe, ist die Ansicht des DAMA und vieler Organisationen, die semantische Konsistenz von Ende zu Ende zu erreichen . Derzeit wird immer noch versucht, die Semantik zu vereinheitlichen, um eine unternehmensweite Konsistenz zu erreichen. Dies wird als "Single Version of the Truth" bezeichnet. Anwendungen sind jedoch immer einzigartig, genauso wie die Daten. Bei der Entwicklung von Anwendungen wird viel implizit gedacht. Der (fachliche) Kontext des Geschäftsproblems beeinflusst das Design der Anwendung und findet seinen Weg in die Daten. Diesen Kontext durchlaufen wir, wenn wir vom konzeptionellen Entwurf zum logischen Anwendungsentwurf und zum physischen Anwendungsentwurf übergehen.⁶ Es ist wichtig, dies zu verstehen, da es den Rahmen für jede zukünftige Architektur bildet. Wenn Daten zwischen verschiedenen Anwendungen verschoben werden, ist immer ein Datenumwandlungsschritt erforderlich. Aus diesem Dilemma der Datenumwandlung gibt es kein Entrinnen! In den folgenden Kapiteln werde ich auf diesen Gedanken zurückkommen.

Eine andere Ansicht, die ich in vielen Organisationen sehe, ist, dass das Datenmanagement zentral sein sollte und mit den strategischen Zielen des Unternehmens verbunden sein muss. Einige Unternehmen glauben immer noch, dass die Betriebskosten durch die Zentralisierung aller Daten- und Verwaltungsaktivitäten gesenkt werden können. Außerdem herrscht die Annahme vor, dass eine zentrale Plattform den Nutzern und Verbrauchern die Mühe der Datenintegration abnehmen kann. Die Unternehmen haben viel in ihre Unternehmensdatenplattformen investiert, zu denen Data Warehouses, Data Lakes und Service Busse gehören. Die Aktivitäten des Stammdatenmanagements sind eng mit diesen Plattformen verbunden, denn durch die Konsolidierung können wir gleichzeitig die Genauigkeit unserer wichtigsten Daten verbessern.

Eine zentralisierte Plattform - und das damit verbundene zentralisierte Modell - wird scheitern, weil sie nicht mit den Entwicklungen und Trends mithalten kann, die der Dezentralisierung zugrunde liegen, z. B. Analytik, Cloud Computing, neue Softwareentwicklungsmethoden, Entscheidungsfindung in Echtzeit und Datenmonetarisierung. Viele Unternehmen sind sich dieser Trends zwar bewusst, aber ihnen fehlt das Verständnis dafür, welche Auswirkungen sie auf das Datenmanagement haben. Untersuchen wir die wichtigsten Trends und bestimmen wir das Ausmaß dieser Auswirkungen.

Analytik fragmentiert die Datenlandschaft

Der bahnbrechendste Trend ist die fortgeschrittene Analytik, die Daten nutzt, um Unternehmen reaktionsfähiger, wettbewerbsfähiger und innovativer zu machen. Warum bringt die fortschrittliche Analytik die bestehende Datenlandschaft durcheinander? Je mehr Daten zur Verfügung stehen, desto größer ist die Zahl der Möglichkeiten und Chancen. Bei Advanced Analytics geht es darum, Was-wäre-wenn-Analysen durchzuführen, zukünftige Trends und Ergebnisse oder Ereignisse zu prognostizieren, verborgene Beziehungen und Verhaltensweisen zu erkennen und die Entscheidungsfindung zu automatisieren. Aufgrund des anerkannten Werts und der strategischen Vorteile von Advanced Analytics wurden viele Methoden, Frameworks und Tools entwickelt, um sie auf unterschiedliche Weise zu nutzen. Wir haben nur an der Oberfläche dessen gekratzt, wozu künstliche Intelligenz (KI), maschinelles Lernen (ML) und natürliche Sprachverarbeitung (NLP) in Zukunft in der Lage sein werden.

Hinweis

OpenAIs neuer ChatGPT ist ein verblüffendes Beispiel dafür, wozu KI in der Lage ist. Die Modelle hinter OpenAI, zu denen auch der Generative Pre-trained Transformer (GPT) gehört, können komplexe Aufgaben wie die Analyse von Matheproblemen, das Schreiben von Codeschnipseln, das Verfassen von Buchaufsätzen, das Erstellen von Rezepten anhand einer Zutatenliste und vieles mehr bewältigen.

Diese analytischen Trends zwingen dazu, die Daten auf viele analytische Anwendungen zu verteilen, da jeder einzelne Anwendungsfall andere Daten erfordert. Einzigartige Geschäftsprobleme erfordern eine einzigartige Denkweise, einzigartige Daten und eine optimierte Technologie, um die beste Lösung zu finden. Nehmen wir zum Beispiel eine Marketingabteilung, deren Ziel es ist, neue Verkaufsmöglichkeiten für ältere und jüngere Kunden zu identifizieren. Die Ausrichtung auf diese beiden Zielgruppen erfordert unterschiedliche Merkmale - messbare Eigenschaften für die Analyse von Datensätzen. Zum Beispiel werden jüngere Interessenten anders segmentiert und geclustert als ältere Interessenten. Wenn du von der Marketingabteilung verlangst, einen einzigen Datensatz für beide Zielgruppen zu verwenden, musst du viele Kompromisse eingehen und wirst wahrscheinlich mit einem Feature Store enden, der für keinen Anwendungsfall einen Mehrwert bietet.⁷ Die optimale Lösung, um den größten Nutzen zu erzielen, besteht darin, jedem Anwendungsfall einen eigenen Satz von Merkmalen zuzuordnen, die für den jeweiligen Lernalgorithmus optimiert sind. Die zunehmende Beliebtheit von Advanced Analytics und die daraus resultierende Vielfalt der Anwendungsfälle führen zu zwei Problemen: Datenvermehrung und Datenintensität.

Mit der Datenvermehrung auf sind die Daten über eine Vielzahl von Standorten, Anwendungen und Datenbanken verteilt und verstreut. Das liegt daran, dass die konsumierenden Bereiche die Daten verarbeiten müssen, um sie in ihre eigenen Lösungen einzupassen. Diese Datenverteilung bringt weitere Probleme mit sich. Wenn Daten wiederholt kopiert und im Unternehmen verstreut werden, wird es schwieriger, ihren Ursprung zu finden und ihre Qualität zu beurteilen. Deshalb musst du eine einzige logische Sicht auf dieselben Daten entwickeln, die an verschiedenen Orten verwaltet werden. Darüber hinaus wird die Kontrolle der Daten durch eine weitreichende Datenverteilung noch schwieriger, da die Daten noch weiter verteilt werden können, sobald sie eine bestimmte Anwendung verlassen. Daher musst du einen Rahmen für die effiziente Wiederverwendung von Daten entwickeln und gleichzeitig die Governance und die Einhaltung externer Vorschriften gewährleisten.

Die Verbreitung von Analysetechniken beschleunigt auch das Wachstum der Datenintensität: Das Verhältnis zwischen Lesen und Schreiben ändert sich erheblich. Analysemodelle, die zum Beispiel ständig neu trainiert werden, lesen ständig große Datenmengen. Das hat Auswirkungen auf das Design von Anwendungen und Datenbanken, denn wir müssen die Lesbarkeit der Daten optimieren. Es kann auch bedeuten, dass wir Daten duplizieren müssen, um die Systeme von dem Druck zu entlasten, sie ständig zu bedienen, oder dass wir die Daten aufgrund der großen Anzahl verschiedener Anwendungsfälle und der damit verbundenen Lesemuster vorverarbeiten müssen. Außerdem müssen wir möglicherweise unterschiedliche Darstellungen derselben Daten für viele verschiedene Verbraucher bereitstellen. Es ist nicht einfach, eine große Vielfalt an Lesemustern zu ermöglichen und gleichzeitig Daten zu duplizieren und die Kontrolle zu behalten. Eine Lösung für dieses Problem wird in Kapitel 4 vorgestellt.

Die Geschwindigkeit der Softwareentwicklung ändert sich

In der heutigen Welt sind softwarebasierte Dienstleistungen das Herzstück der meisten Unternehmen, was bedeutet, dass neue Features und Funktionen schnell bereitgestellt werden müssen. Als Reaktion auf die Forderung nach größerer Agilität haben sich bei Unternehmen wie Amazon, Netflix, Meta, Google und Uber neue Ideologien entwickelt. Diese Unternehmen haben ihre Softwareentwicklungspraktiken auf der Grundlage von zwei Überzeugungen weiterentwickelt.

Die erste Überzeugung ist, dass die Softwareentwicklung (Dev) und der Betrieb der Informationstechnologie (Ops) kombiniert werden müssen, um den Lebenszyklus der Systementwicklung zu verkürzen und eine kontinuierliche Lieferung mit hoher Softwarequalität zu gewährleisten. Diese DevOps genannte Methodik erfordert eine neue Kultur, die mehr Autonomie, offene Kommunikation, Vertrauen, Transparenz und disziplinübergreifende Teamarbeit beinhaltet.

Die zweite Überzeugung bezieht sich auf die Größe, in der Anwendungen entwickelt werden müssen. Es wird erwartet, dass die Flexibilität und Geschwindigkeit der Entwicklung zunimmt, wenn Anwendungen in kleinere, zerlegte Dienste umgewandelt werden. Dieser Entwicklungsansatz umfasst mehrere Schlagworte: Microservices, Container, Kubernetes, Domain-driven Design, Serverless Computing usw. Ich werde jetzt nicht auf alle diese Konzepte eingehen, aber es ist wichtig zu erkennen, dass diese Entwicklung in der Softwareentwicklung mit einer höheren Komplexität und einem größeren Bedarf an besserer Datenkontrolle einhergeht.

Die Umwandlung von monolithischen Anwendungen in verteilte Anwendungen - zum Beispiel Microservices- bringt viele Schwierigkeiten für die Datenverwaltung mit sich. Wenn Anwendungen in kleinere Teile zerlegt werden, sind die Daten auf verschiedene kleinere Komponenten verteilt. Außerdem müssen die Entwicklungsteams ihre (einzelnen) einzigartigen Datenspeicher, bei denen sie das Datenmodell vollständig verstehen und alle Datenobjekte zusammen haben, auf ein Design umstellen, bei dem die Datenobjekte überall verteilt sind. Dies bringt verschiedene Herausforderungen mit sich, z. B. erhöhte Netzwerkkommunikation, Replikate von Daten, die synchronisiert werden müssen, Schwierigkeiten bei der Kombination vieler Datensätze, Probleme mit der Datenkonsistenz, Probleme mit der referentiellen Integrität usw.

Der jüngste Trendwechsel in der Softwareentwicklung erfordert eine Architektur, die es Anwendungen ermöglicht, ihre Daten feiner zu verteilen. Sie erfordert auch eine neue DataOps-Kultur und eine andere Design-Philosophie, die mehr Wert auf die Interoperabilität von Daten, die Erfassung unveränderlicher Ereignisse und eine reproduzierbare und lose Kopplung legt. Wir werden diese in Kapitel 2 näher erläutern.

Der Einfluss der Cloud auf das Datenmanagementist unermesslich

Die Netzwerke werden immer schneller, und die Bandbreite steigt Jahr für Jahr. Große Cloud-Anbieter haben bewiesen, dass es möglich ist, Terabytes von Daten innerhalb von Minuten in die Cloud zu verschieben, was einen interessanten Ansatz ermöglicht: Anstatt die Rechenleistung zu den Daten zu bringen - was aufgrund von Netzwerkbeschränkungen die gängige bewährte Methode war - können wir es umdrehen und die Daten durch Verteilung zur Rechenleistung bringen. Das Netzwerk ist nicht mehr der Engpass, so dass wir die Daten schnell zwischen den Umgebungen verschieben können, damit die Anwendungen sie abrufen und nutzen können. Dieses Modell wird besonders interessant, da die Märkte für Software as a Service (SaaS) und Machine Learning as a Service (MLaaS) immer beliebter werden. Anstatt all die komplexen Dinge intern zu erledigen, können wir Netzwerke nutzen, um große Datenmengen für andere Parteien bereitzustellen.

Dieses Verteilungsmuster, bei dem Daten kopiert (dupliziert) und zur Rechenleistung in eine andere Einrichtung, z. B. ein Cloud-Rechenzentrum, gebracht werden, wird die Datenlandschaft noch mehr fragmentieren, so dass eine klare Datenmanagementstrategie wichtiger denn je ist. Das macht eine klare Strategie für die Datenverwaltung immer wichtiger. Du musst Richtlinien aufstellen, denn die Fragmentierung der Daten kann die Leistung aufgrund von Verzögerungen beim Datenzugriff negativ beeinflussen. Außerdem musst du deine Daten anders organisieren und modellieren, denn Cloud-Provider haben Compute und Speicherung voneinander getrennt, um sie unabhängig skalierbar zu machen.

Datenschutz und Sicherheit haben höchste Priorität

Unternehmen müssen die Datensicherheit angesichts der zunehmenden Zahl von Datenquellen und des wachsenden Datenvolumens überdenken. Daten sind unbestreitbar von zentraler Bedeutung für Unternehmen, die optimieren, innovieren oder sich von der Konkurrenz abheben wollen, aber es gibt auch eine dunkle Seite mit unfreundlichen Untertönen, wie Datendiebstahl, Diskriminierung und politischer Schaden, der demokratische Werte untergräbt. Werfen wir einen Blick auf einige Beispiele, um eine Vorstellung von den Auswirkungen eines schlechten Datenschutzes und einer schlechten Datensicherheit zu bekommen.

UpGuard führt eine lange Liste der bisher größten Datenschutzverletzungen , von denen viele aus denselben Fehlern Kapital geschlagen haben. Der Verstoß gegen Cambridge Analytica und 500 Millionen gehackte Konten bei Marriott sind beeindruckende Beispiele für schädliche Ereignisse. Die Regierungen mischen sich zunehmend in die Sicherheit und den Datenschutz ein, weil alle Aspekte unseres privaten und beruflichen Lebens inzwischen mit dem Internet verbunden sind. Die COVID-19-Pandemie, die so viele von uns dazu gezwungen hat, von zu Hause aus zu arbeiten und Kontakte zu pflegen, hat diesen Trend noch beschleunigt. Unternehmen können es sich nicht leisten, die Bedrohungen durch Verletzungen des geistigen Eigentums und Datenschutzskandale zu ignorieren.

Der Trend zu massiven Datenmengen, leistungsfähigeren fortschrittlichen Analysen und einer schnelleren Verbreitung von Daten hat eine Debatte über die Gefahren von Daten ausgelöst und ethische Fragen und Diskussionen aufgeworfen. Lassen Sie mich ein Beispiel aus meinem eigenen Land nennen. In den Niederlanden hat die niederländische Steuerverwaltung ungesetzliche und diskriminierende Aktivitäten durchgeführt. Sie verfolgte Doppelstaatsangehörige in ihren Systemen und nutzte rassische und ethnische Klassifizierungen, um Modelle für den Anspruch auf Kinderbetreuungsleistungen zu trainieren. Das Ergebnis: Tausende von Familien wurden fälschlicherweise als Kriminelle eingestuft und bekamen ihre Leistungen gestrichen. Sie wurden aufgefordert, bereits erhaltene Leistungen zurückzuzahlen, manchmal wegen technischer Vergehen wie dem Fehlen einer korrekten Unterschrift auf einem Formular. Einige Menschen wurden gezwungen, ihr Haus und ihren Besitz zu verkaufen, nachdem ihnen der Zugang zu einer Umschuldung verweigert wurde.

Dies ist nur ein Beispiel für den unsachgemäßen Umgang mit Daten. Da Unternehmen unweigerlich Fehler machen und ethische Grenzen überschreiten, erwarte ich, dass die Regierungen die Regulierung verschärfen, indem sie mehr Sicherheit, Kontrolle und Einblick fordern. Wir haben nur an der Oberfläche der wahren Datenschutz- und ethischen Probleme gekratzt. Vorschriften wie die neuen europäischen Gesetze zu Data Governance und künstlicher Intelligenz werden große Unternehmen dazu zwingen, transparent zu machen, welche Daten gesammelt und gekauft werden, welche Daten kombiniert werden, wie Daten in Analysemodellen verwendet werden und welche Daten weitergegeben (verkauft) werden. Große Unternehmen müssen sich schon jetzt Gedanken über Transparenz und Datenschutz machen und darüber, wie sie mit großen regulatorischen Problemen umgehen können, falls sie das noch nicht getan haben.

Regulierung ist ein komplexes Thema. Stell dir eine Situation vor, in der mehrere Cloud-Regionen und verschiedene SaaS-Dienste genutzt werden und die Daten verstreut sind. Vorschriften wie die GDPR, CCPA, BCBS 239 und das neue Trans-Atlantic Data Privacy Framework zu erfüllen, ist schwierig, weil Unternehmen Einblick und Kontrolle über alle personenbezogenen Daten haben müssen, unabhängig davon, wo sie gespeichert sind. Data Governance und der korrekte Umgang mit personenbezogenen Daten stehen für viele große Unternehmen auf ganz oben auf der Tagesordnung.⁸

Diese strengeren behördlichen Auflagen und datenethischen Bedenken werden zu weiteren Einschränkungen, zusätzlichen Prozessen und verstärkter Kontrolle führen. Erkenntnisse darüber, woher die Daten stammen, wie die Modelle trainiert werden und wie die Daten verteilt werden, sind entscheidend. Eine stärkere interne Kontrolle ist erforderlich, aber dieser Trend zu mehr Kontrolle läuft den Methoden der schnellen Softwareentwicklung zuwider, die weniger Dokumentation und weniger interne Kontrollen beinhalten. Er erfordert eine andere, defensivere Sichtweise auf die Art und Weise, wie Datenmanagement gehandhabt wird, mit stärker integrierten Prozessen und besseren Tools. Einige dieser Bedenken werden in Kapitel 8 behandelt.

Operative und analytische Systeme müssen integriert werden

Die Notwendigkeit, schneller auf Geschäftsereignisse zu reagieren, bringt neue Herausforderungen mit sich. Traditionell gab es eine große Kluft zwischen transaktionalen (operativen) Anwendungen und analytischen Anwendungen, weil transaktionale Systeme in der Regel nicht ausreichen, um große Datenmengen zu liefern oder ständig Daten herauszuschieben. Die bewährte Methode bestand darin, die Datenstrategie in zwei Teile aufzuteilen: die operative Transaktionsverarbeitung und das analytische Data Warehousing und die Big Data-Verarbeitung.

Diese Trennung wird jedoch durch unterbrochen. Operative Analytik, die sich auf die Vorhersage und Verbesserung bestehender betrieblicher Abläufe konzentriert, soll eng mit den transaktionalen und analytischen Systemen zusammenarbeiten. Die Analyseergebnisse müssen wieder in den Kern des operativen Systems integriert werden, damit die Erkenntnisse im operativen Kontext relevant werden. Dasselbe Argument könnte ich auch für Echtzeit-Ereignisse anführen: Wenn Ereignisse einen Status tragen, können dieselben Ereignisse für die betriebliche Entscheidungsfindung und Datenverteilung genutzt werden.

Dieser Trend erfordert eine andere Integrationsarchitektur, die sowohl die operativen als auch die analytischen Systeme gleichzeitig besser verwaltet. Außerdem muss die Datenintegration mit unterschiedlichen Geschwindigkeiten funktionieren, da diese für operative und analytische Systeme unterschiedlich sind. In diesem Buch untersuchen wir die Möglichkeiten, historische Daten im ursprünglichen betrieblichen Kontext zu bewahren und sie gleichzeitig sowohl für betriebliche als auch für analytische Systeme verfügbar zu machen.

Organisationen operieren in kollaborativen Ökosystemen

Viele Menschen denken, dass alle Geschäftsaktivitäten innerhalb der einzigen logischen Grenze stattfinden, in der das Unternehmen tätig ist. Die Realität sieht anders aus, denn viele Unternehmen arbeiten eng mit anderen Unternehmen zusammen. Die Unternehmen integrieren ihre Kerngeschäftsfunktionen zunehmend mit Dienstleistungen von Dritten. Diese Zusammenarbeit beeinflusst die Gestaltung deiner Architektur, denn du musst in der Lage sein, Daten schnell zu verteilen, offene Daten einzubinden,⁹ APIs öffentlich zugänglich zu machen undso weiter.

Diese Veränderungen bedeuten, dass Daten immer häufiger zwischen verschiedenen Umgebungen verteilt sind und somit dezentraler sind. Wenn Daten mit anderen Unternehmen geteilt werden oder Cloud- oder SaaS-Lösungen genutzt werden, landen sie an verschiedenen Orten, was die Integration und das Datenmanagement erschwert. Außerdem treten beim Verschieben von Daten zwischen Plattformen oder Umgebungen unweigerlich Probleme mit der Netzwerkbandbreite, der Konnektivität und den Latenzzeiten auf. Die Verfolgung einer einzigen öffentlichen Cloud oder einer einzigen Plattformstrategie wird diese Herausforderungen nicht lösen, denn die Zukunft gehört der Dezentralisierung. Das heißt, wenn du willst, dass APIs und SaaS-Systeme gut funktionieren und die Möglichkeiten der Public Cloud nutzen, musst du die Datenintegration beherrschen, was du in diesem Buch lernen wirst.

Die hier diskutierten Trends sind wichtig und werden die Art und Weise beeinflussen, wie Menschen Daten nutzen und wie Unternehmen ihre Architekturen organisieren sollten. Das Datenwachstum beschleunigt sich, die Rechenleistung steigt und die Analysetechniken entwickeln sich weiter. Auch der Datenverbrauch steigt, was bedeutet, dass die Daten schnell verteilt werden müssen. Eine stärkere Data Governance ist erforderlich. Auch die Datenverwaltung muss aufgrund von Trends wie Cloud-Diensten, SaaS und Microservices dezentralisiert werden. All diese Faktoren müssen dank des starken Wettbewerbs mit einer kurzen Markteinführungszeit in Einklang gebracht werden. Diese riskante Kombination fordert uns heraus, Daten auf eine völlig andere Art zu verwalten.

Unternehmen sind mit veralteten Datenarchitekturen konfrontiert

Eines der größten Probleme, mit denen viele Unternehmen zu kämpfen haben, ist die Wertschöpfung aus ihren aktuellen Daten Architekturen herauszuholen.¹⁰ Die meisten bestehenden Datenarchitekturen verwenden ein monolithisches Design - entweder ein Enterprise Data Warehouse (EDW)¹¹ oder ein Data Lake - und verwalten und verteilen die Daten zentral. In einer stark verteilten und verbrauchergesteuerten Umgebung werden diese Architekturen den zukünftigen Anforderungen nicht mehr gerecht. Schauen wir uns einige der Merkmale der beiden Architekturen an.

Das Enterprise Data Warehouse: Eine einzige Quelle der Wahrheit

Die Datenarchitekturen der ersten Generation der meisten Unternehmen beruhen auf Data Warehousing und Business Intelligence. Die Philosophie ist, dass die Zentralisierung der Königsweg ist, um das Problem der Datenverwaltung zu lösen. Bei diesem Ansatz gibt es einen zentralen, integrierten Datenspeicher, der jahrelang detaillierte und stabile Daten für das gesamte Unternehmen enthält. Aber wenn es um die Verteilung von Daten im großen Stil geht, hat ein solches monolithisches Konzept mehrere Nachteile.

Die Vereinheitlichung von Unternehmensdaten ist ein unglaublich komplexes Unterfangen, dessen Umsetzung viele Jahre dauert. Die Wahrscheinlichkeit ist relativ hoch, dass die Bedeutung der Daten in den verschiedenen Bereichen von unterschiedlich ist,¹² Abteilungen und Systemen unterscheidet, selbst wenn die Datenattribute ähnliche Namen haben. Also müssen wir entweder viele Varianten erstellen oder die Unterschiede und Unstimmigkeiten einfach akzeptieren. Je mehr Daten wir hinzufügen und je mehr Konflikte und Unstimmigkeiten auftreten, desto schwieriger wird es, die Daten zu harmonisieren. Am Ende werden wir wahrscheinlich einen einheitlichen Kontext haben, der für die Endnutzer/innen bedeutungslos ist. Außerdem kann das Weglassen des Kontexts bei fortgeschrittenen Analysen wie dem maschinellen Lernen ein erhebliches Problem darstellen, da es unmöglich ist, die Zukunft korrekt vorherzusagen, wenn die Daten bedeutungslos oder unkenntlich sind.

Enterprise Data Warehouses verhalten sich wie Integrationsdatenbanken, wie in Abbildung 1-2 zeigt. Sie dienen als Datenspeicher für mehrere datenverbrauchende Anwendungen. Das bedeutet, dass sie ein Verbindungspunkt zwischen allen Anwendungen sind, die auf die Daten zugreifen wollen. Oft wird davon ausgegangen, dass die Zentralisierung die Lösung für das Datenmanagement ist. Dazu gehört die Zentralisierung aller Daten und Managementaktivitäten durch ein zentrales Team, der Aufbau einer Datenplattform, die Verwendung eines ETL-Frameworks und eines kanonischen Modells usw. Bei einer zentralisierten Architektur müssen Änderungen jedochsorgfältig durchgeführt werden, da es viele Abhängigkeiten zwischen den verschiedenen Anwendungen gibt. Manche Änderungen können auch einen Ripple-Effekt für andere Änderungen auslösen. Wenn du ein so stark gekoppeltes und schwer zu änderndes Design geschaffen hast, hast du das geschaffen, was manche Ingenieure einen "großen Schlammball" nennen.

Abbildung 1-2. Zentralisierte Architekturen sind für viele Unternehmen ein Engpass: Ein Team muss warten, bis ein anderes Team seine Arbeit beendet hat

Großer Ball aus Schlamm

Ein großer Schlammball ist ein planlos strukturierter, ausufernder, schlampiger, mit Klebeband und Draht zusammengebundener Spaghetti-Code-Dschungel. Der von Brian Foote und Joseph Yoder eingeführte Begriff beschreibt eine Systemarchitektur, die monolithisch, schwer zu verstehen, schwer zu warten und aufgrund ihrer vielen Abhängigkeiten eng gekoppelt ist. Abbildung 1-3 zeigt ein Abhängigkeitsdiagramm, das dies verdeutlicht. Jede Linie stellt eine Beziehung zwischen zwei Softwarekomponenten dar.

Abbildung 1-3. Big Ball of Mud Abhängigkeitsdiagramm

Wie du siehst, gibt es zwischen allen Komponenten extreme Abhängigkeiten, die es praktisch unmöglich machen, eine Komponente zu ändern, ohne die anderen zu beeinflussen. Data Warehouses mit ihren Schichten, Ansichten, unzähligen Tabellen, Beziehungen, Skripten, ETL-Aufträgen und Planungsabläufen ergeben oft ein solch chaotisches Netz vonAbhängigkeiten.

Aufgrund der hohen Komplexität des Data Warehouse und der Tatsache, dass es von einem zentralen Team verwaltet wird, wird die mangelnde Agilität oft zum Problem. Die längere Wartezeit regt die Kreativität an, Abkürzungen zu nehmen. Ingenieure können zum Beispiel die Integrationsschicht umgehen und Daten aus der Staging-Schicht direkt in ihre Data Marts übertragen, während andere Entwickler Workarounds mit Hilfe von Ansichten erstellen, die Daten aus verschiedenen Schichten schnell kombinieren. Die technischen Schulden (zukünftige Nacharbeit), die sich dadurch ansammeln, werden später Probleme verursachen. Die Architektur wird komplexer, und die Mitarbeiter/innen verlieren den Überblick über die kreativen Lösungen, die für eine rechtzeitige Bereitstellung entwickelt wurden.

Außerdem sind Data Warehouses eng an die zugrunde liegende Lösung oder Technologie gekoppelt, was bedeutet, dass Verbraucher, die andere Lesemuster benötigen, Daten in andere Umgebungen exportieren müssen. Da sich die Anbieterlandschaft verändert und neue Arten von Datenbanken auftauchen, müssen Data Warehouses zunehmend Daten von dem Ort aus verteilen, an dem sie verwaltet werden. Dieser Trend untergräbt die große Vision, ein einziges zentrales Repository effizient zu nutzen und die zugrunde liegende (teure) Hardware zu verwenden.

Lebenszyklusmanagement von historischen Daten ist oft ein Thema. Data Warehouses werden als Archive der Wahrheit angesehen, die es den operativen Systemen ermöglichen, irrelevante Daten zu bereinigen, da sie wissen, dass die Daten im Warehouse gespeichert werden. Für fortschrittliche operative Analysen - etwas, das erst nach dem Aufkommen von Data Warehouses entstanden ist - kann dies ein Problem darstellen. Wenn die Daten von einem zentralen Team umgewandelt wurden, das alle Daten des Unternehmens verwaltet, sind sie für das Team, das sie geliefert hat, möglicherweise nicht mehr erkennbar (oder für den beabsichtigten betrieblichen Anwendungsfall nicht mehr nutzbar). Außerdem kann es schwierig sein, die Daten schnell verfügbar zu machen, da viele Lagerhäuser die Daten in der Regel viele Stunden lang verarbeiten, bevor sie sie speichern. Das ist notwendig, weil die Daten vor der Speicherung umgewandelt, kombiniert und mit anderen Daten integriert werden müssen.

Auch die Datenqualität ist oft ein Problem. Wer ist der Eigentümer der Daten in einem Data Warehouse? Wer ist verantwortlich, wenn die Quellsysteme fehlerhafte Daten liefern? In Unternehmen erlebe ich oft, dass sich ein zentrales Technikteam um Datenqualitätsprobleme kümmert, die von anderen Teams verursacht wurden. In einem Fall haben die Ingenieure die Daten im Staging-Layer korrigiert, damit sie ordnungsgemäß in das Data Warehouse geladen werden konnten. Diese Korrekturen wurden dauerhaft, und im Laufe der Zeit mussten Hunderte von zusätzlichen Skripten angewendet werden, bevor die Datenverarbeitung beginnen konnte. Diese Skripte gehören nicht zu den vertrauenswürdigen ETL-Prozessen und ermöglichen es nicht, den Besitz der Daten und die Herkunft der Daten zurückzuverfolgen.

Auch rechtliche Probleme können auftauchen. Lagerhäuser haben oft keinen Einblick in den Ad-hoc-Verbrauch und die Weitergabe von Daten, vor allem, wenn diese außerhalb der Grenzen, in denen sie verwaltet werden, übertragen werden. Mit den neuen Vorschriften sind das Dateneigentum und der Einblick in den Verbrauch und die Verteilung von Daten wichtig, denn du musst erklären können, welche personenbezogenen Daten von wem und zu welchem Zweck verbraucht wurden.

Angesichts der Gesamtdatenmenge in einem typischen Data Warehouse, der Jahre, die es zu seiner Entwicklung brauchte, des Wissens, über das die Menschen verfügen, und der intensiven geschäftlichen Nutzung wäre eine Ersatzmigration ein riskantes und zeitaufwändiges Unterfangen. Deshalb nutzen viele Unternehmen weiterhin diese Architektur und füttern ihre Geschäftsberichte, Dashboards¹³ und datenintensive Anwendungen aus einem Data Warehouse, trotz der hohen Wartungskosten und mangelnder Flexibilität.

Der Data Lake: Ein zentrales Repository für strukturierteund unstrukturierte Daten

Als die Datenmengen und der Bedarf an schnelleren Erkenntnissen wuchsen, begannen Ingenieure, an anderen Konzepten zu arbeiten. Data Lakes wurden zu einer Alternative für den Zugriff auf rohe und größere Datenmengen.¹⁴ Indem sie die Daten so bereitstellen, wie sie sind, ohne sie erst strukturieren zu müssen, kann jeder Verbraucher selbst entscheiden, wie er sie nutzen, umwandeln und integrieren will.

Data Lakes sind wie Data Warehouses zentrale (monolithische) Datenspeicher, unterscheiden sich aber von Warehouses dadurch, dass sie Daten speichern, bevor sie transformiert, bereinigt und strukturiert wurden. Schemata werden daher oft schon beim Lesen der Daten festgelegt. Dies unterscheidet sich von Data Warehouses, die eine vordefinierte und feste Struktur verwenden. Data Lakes bieten auch eine größere Vielfalt, da sie mehrere Datenformate unterstützen: strukturierte, semistrukturierte und unstrukturierte.

Viele Data Lake-Implementierungen sammeln reine, unveränderte Rohdaten aus den ursprünglichen Quellsystemen. Das Einspeisen roher Anwendungsstrukturen - exakte Kopien - ist schnell und ermöglicht Datenanalysten und Wissenschaftlern einen schnellen Zugriff. Die Komplexität von Rohdaten besteht jedoch darin, dass die Anwendungsfälle immer eine Nachbearbeitung der Daten erfordern. Probleme mit der Datenqualität müssen behoben werden, Transformationen sind erforderlich, und die Daten müssen mit anderen Daten angereichert werden, um sie in einen Kontext zu bringen. Das ist ein Grund, warum Data Lakes in der Regel mit Data Warehouses kombiniert werden. Data Warehouses fungieren in dieser Kombination als hochwertige Speicher für bereinigte und harmonisierte Daten, während Data Lakes als (Ad-hoc-)Analyseumgebungen fungieren, in denen eine große Vielfalt an Rohdaten gespeichert wird, um Analysen zu erleichtern.

Die Entwicklung von Data Lakes ist, genau wie Data Warehouses, eine Herausforderung. Unternehmen wie Gartner, VentureBeat AI und Deloitte sehen hohe Misserfolgsquoten bei Big-Data-Projekten - oft mehr als 60 %.¹⁵ Data-Lake-Implementierungen schlagen in der Regel fehl, u.a. wegen ihrer enormen Komplexität, der schwierigen Wartung und der gemeinsamen Abhängigkeiten:

• Die Daten, die Anwendungen in einen Data Lake einspeisen, sind oft unbearbeitet und stellen wahrscheinlich eine komplexe Darstellung dessen dar, wie die einzelnen Anwendungen ihre Daten intern organisieren. Wenn du diesen Ansatz verfolgst, wird dein Data Lake schnell zu einer Sammlung mit zehntausenden von Tabellen, unverständlichen Datenstrukturen und technischen Werten, die nur von den Anwendungen selbst verstanden werden. Außerdem besteht eine enge Kopplung mit den bereitstellenden Anwendungen, da die geerbte Struktur eine identische Kopie ist. Wenn die Verbraucher diese Daten direkt nutzen, besteht die Gefahr, dass die Datenpipelines zusammenbrechen, wenn die bereitstellenden Anwendungen ihre Datenstrukturen ändern.

• Analytische Modelle in Data Lakes werden oft sowohl auf Rohdaten als auch auf harmonisierten Daten trainiert. Es ist nicht undenkbar, dass sowohl Data Engineers als auch Data Scientists in ihren Data-Science-Projekten Daten technisch aufbereiten und diese Datenpipelines und Modelle von Hand erstellen und betreiben. Data Lakes bergen daher erhebliche (operative) Risiken.

• Data Lakes sind oft eine einzige Plattform, die von vielen verschiedenen Anwendungsfällen genutzt wird. Aufgrund ihrer engen Kopplung, Kompatibilitätsprobleme, gemeinsamen Bibliotheken und Konfigurationen sind diese Plattformen schwer zu warten.

Dies sind nur einige Gründe, warum die Misserfolgsquote bei Big-Data-Projekten so hoch ist. Weitere Gründe sind der Widerstand des Managements, interne Politik, fehlendes Fachwissen und Herausforderungen in Bezug auf Sicherheit und Governance .

Der Schmerz der Zentralisierung

Enterprise Data Warehouses oder zentrale Data Lakes können mit Techniken wie metadatengesteuerter ELT, Datenvirtualisierung, Cloud-Diensten, verteilter Verarbeitung, Echtzeit-Ingestion, maschinellem Lernen für Anreicherungen und so weiter vergrößert werden. Aber es gibt ein viel größeres Problem: das zentralisierte Denken hinter diesen Architekturen. Dazu gehören eine zentrale Verwaltung, zentraler Datenbesitz, zentral gebündelte Ressourcen und zentrale Datenmodelle, die vorschreiben, dass alle dieselben Begriffe und Definitionen verwenden müssen. Eine Folge dieser Zentralisierung ist, dass die Entfernung der Datenexperten aus den Geschäftsbereichen die Kreativität und die Geschäftseinsicht einschränkt. Die Teams sind gezwungen, ständig miteinander zu kommunizieren und Tickets zu verwalten, weil sie auf Distanz sind. Das zentrale Betriebsmodell ist der Engpass: Das zentrale Team kann nicht alle Fragen und Anfragen schnell genug bearbeiten. Nicht umsonst setzenUnternehmen auf dezentrale Methoden wie das Data Mesh und befürworten das Domain-driven Design. Ein föderales Modell mit Domänen-Teams kann eine Superkraft sein: Es fördert Unabhängigkeit und Verantwortlichkeit, es ermöglicht Skalierung, weil autonome Teams Daten parallel verwalten, teilen und nutzen, und es fördert Verbesserungen bei Qualität, Zusammenarbeit und Produktivität.

Die Dezentralisierung hat jedoch auch ihre Tücken. Die Bündelung von Zuständigkeiten beginnt immer mit einer Zentralisierung, die auf Unternehmensebene die Definition von Standards, die Festlegung von Grenzen und die Bereitstellung von Fachwissen und Skalierbarkeit erfordert. Ohne eine zentrale Autorität wird die dezentrale Ermächtigung zu einem großen Problem. Ich habe Situationen beobachtet, in denen Teams begannen, ihre eigenen Technologie-, Interoperabilitäts- und Metadatenstandards zu definieren; in denen Abteilungen die vollständige Kontrolle über ihre eigenen Daten anordneten, so dass sie nicht mit Daten aus anderen Teams kombiniert werden konnten; und in denen Teams ihre eigenen Datenmodellierungsstandards, Referenzdatenstandards, Granularitätsstufen usw. anwandten, so dass es unmöglich war, Daten zwischen Bereichen zu kombinieren oder zu integrieren. Zusammenfassend lässt sich sagen: Skalierbarkeit durch Dezentralisierung ist nicht ohne Risiken, und diese Risiken lassen sich am besten durch eine zentrale Ausrichtung von Organisation, Governance, Technologie und Architektur abmildern. Was du also brauchst, ist eine Datenstrategie: einen Plan, der die Kultur, die Organisation und die Mitarbeiter, die Architektur, die Governance und die Prozesse sowie die Regeln (neu) definiert, die erforderlich sind, um dich in eine datengesteuerte Organisation zu verwandeln.

Festlegen einer Datenstrategie

Nachdem du nun die Bedeutung von Daten, die jüngsten Trends und die Herausforderungen, die mit der Zentralisierung und Dezentralisierung einhergehen, verstanden hast, stellt sich die Frage, wie ein strategischer Weg zu einer erfolgreichen Datentransformation aussehen könnte? Um diese Frage zu beantworten, muss eine Strategieübung durchgeführt werden, bei der die Geschäftsmodelle des Unternehmens und die Rolle der Daten innerhalb dieser Modelle berücksichtigt werden. Strategen und Architekten sollten überlegen, ob Änderungen an den bestehenden Geschäftsmodellen gerechtfertigt sind und ob die Voraussetzungen für die Anwendung von Föderation gegeben sind.

Es ist eine Konvention, mit der Analyse der Organisation und der Bedingungen, unter denen das Unternehmen arbeitet, zu beginnen. Von dort aus muss eine Unternehmenssicht entwickelt werden, die die Bausteine des Unternehmens mit Anwendungen und Datenquellen, Prozessen, Menschen und anderen Technologielösungen verbindet, die zur Umsetzung der Strategie eingesetzt werden. Diese Sicht ermöglicht die Visualisierung der (Daten-)Architektur, mit der die strategischen Ziele des Unternehmens erreicht werden können. Im nächsten Kapitel werde ich auf all diese Aspekte zurückkommen, aber zunächst wollen wir uns die Schritte zur Definition einer Datenstrategie ansehen.

Eine Strategie zu entwickeln, kann schwierig sein. Sie beinhaltet oft eine Vorhersage darüber, welcher Geschäftswert geschaffen werden kann oder was in der Zukunft wahr sein könnte. Sie erfordert die Verknüpfung von hochgesteckten Zielen mit Ressourcen, Prozessen und unterstützenden Fähigkeiten. Wenn du noch keine Datenstrategie hast oder dir über deine Ziele unsicher bist, solltest du die folgenden Punkte beachten:

• Konzentriere dich zunächst auf deine Unternehmensziele und -strategie. Lass dich nicht von dem Hype um die neuesten technologischen Veränderungen mitreißen.

• Nimm die Vision des Unternehmens an und passe sie daran an, wie Daten sie fördern können. Finde heraus, wie Daten eine bessere Rolle bei der Lösung deiner Geschäftsprobleme spielen können. Versuche, die Auswirkungen auf das Geschäft zu quantifizieren. Lege als Nächstes fest, wie deine Kerngeschäftsstrategie für die nächsten drei Jahre und danach aussehen soll.

• Bestimme die richtige Balance zwischen "defensiv" und "offensiv". Hat die volle Kontrolle oberste Priorität? Oder willst du die Flexibilität für disruptive Innovationen haben? Wie wirkt sich die Regulierung auf deine Strategie aus? Diese Überlegungen werden deinen anfänglichen Entwurf und das Tempo der Zusammenlegung bestimmter Zuständigkeiten beeinflussen.

• Lege klare und messbare Meilensteine fest. Erstelle einen Plan, um festzustellen, wann deine Datenstrategie erfolgreich ist und einen Nutzen bringt. Lege Kennzahlen und Leistungsindikatoren (KPIs) fest, um die Ergebnisse zu messen.

• Erstelle einen Kommunikationsplan, um sicherzustellen, dass deine Strategie im gesamten Unternehmen verstanden und kommuniziert wird.

• Bestimme deinen ersten Schwerpunktbereich. Das kann Forschung und Entwicklung, Einhaltung von Vorschriften, Kostensenkung, Umsatzsteigerung oder etwas anderes sein.

• Erkenne die Hindernisse in deiner Organisation, die einen Erfolg verhindern könnten, und suche nach Möglichkeiten, sie zu umgehen.

• Überdenke deine Strategie für Talente und stelle fest, ob deine Organisation in der Lage ist, die Vorteile von Daten voll auszuschöpfen. Wenn nicht, erstelle einen (kulturellen) Übergangs- und Einstellungsplan, um deine Geschäftsabteilungen so auszurichten, dass sie für die Verwaltung und Nutzung von Daten im Allgemeinen verantwortlich sind.

• Definiere, wie deine IT-Fähigkeiten der nächsten Generation aussehen werden. Ist die zukünftige IT für die gesamte Umsetzung verantwortlich? Oder fungiert die künftige IT als Kompetenzzentrum, das Führung, bewährte Methoden, Schulungen, Forschung und Unterstützung bietet?

• Definiere, wie eine datengesteuerte Kultur aussieht. Lege zum Beispiel fest, welche Fähigkeiten und Ausbildungen erforderlich sind. Soll die Datennutzung in vollem Umfang von den Geschäftsnutzern selbst durchgeführt werden? Besteht die Bereitschaft, Daten mit anderen zu teilen?

• Erfasse Daten über deine bestehenden Umgebungen. Nimmt zum Beispiel jede Geschäftseinheit innerhalb der gleichen Ökosystemgrenzen teil? Oder werden in den verschiedenen Umgebungen unterschiedliche Regeln angewandt? Beginne damit, dir einen Überblick über deine Datenlandschaft zu verschaffen, indem du die verschiedenen Umgebungen und Datenquellen analysierst. Untersuche, wo Daten erstellt werden und wie diese Daten verteilt und genutzt werden.

• Finde heraus, ob du deine Softwareentwicklungsmethodik ändern musst. Wenn ja, ermittle, wie sich dies auf dein Liefermodell für den Aufbau deiner Next-Gen-Architektur auswirken könnte.

• Lege fest, wie ein Übergang in die Zukunft aussehen soll. Ist dein Übergang eine radikale Umgestaltung oder eine organische Entwicklung?

• Lege einige erste hochrangige Technologieentscheidungen fest. Planst du zum Beispiel, skalierbares Cloud Computing für die Datenverarbeitung zu nutzen? Bevorzugst du Flexibilität und Anpassungsfähigkeit, so dass du deine IT-Fähigkeiten anbieterunabhängig entwickeln wirst? Oder bevorzugst du die Nutzung nativer Dienste mit dem Risiko, dass du dich an einen Anbieter bindest?

• Erstelle eine Präsentation für die Geschäftsführung mit den wichtigsten Elementen, alles auf hohem Niveau mit Abschnitten: Warum, Was, Lücken, Fahrpläne und Investitionsfälle.

• Erstelle eine Kostenmanagementstrategie, indem du dein Budget mit den Zielen und Anwendungsfällen abstimmst. Lege einen Plan für die Überprüfung und die Bereitschaft zur Investition in das Datenmanagement fest. Außerdem solltest du die Budgets mit deinem IT-Lebenszyklusmanagementprozess abstimmen, der Planung, Outsourcing, Beschaffung, Einsatz und mögliche Stilllegung umfasst.¹⁶

Wenn du diese Aktionspunkte ansprichst, sollten deine übergeordneten Ziele und deine Strategie klar sein. Es ist wichtig, dies zuerst zu tun, denn die strategische Ausrichtung ist die Grundlage für Entscheidungen über Architektur, Prozesse, Arbeitsweisen, Übergangspläne, Governance und so weiter.

Beachte, dass eine datengesteuerte Strategie für jede Organisation anders aussehen wird, je nach ihren Ambitionen, der Größe und Art des Unternehmens, den geplanten Finanzmitteln und Investitionen, der bestehenden Kultur und dem Reifegrad sowie den zugrunde liegenden Geschäftszielen. In meiner vorherigen Position bei ABN AMRO wollten wir zum Beispiel, dass die Kunden während ihrer gesamten digitalen Reise ein maßgeschneidertes, nahtloses und einheitliches Erlebnis haben, wenn sie mit unserer datengesteuerten Bank interagieren. Deshalb haben wir beschlossen, alle Geschäftsbereiche für Privat- und Firmenkunden sowie für das internationale Geschäft eng miteinander zu verzahnen und zu integrieren. Das bedeutete, dass alle Geschäftsbereiche innerhalb desselben datenzentrierten Ökosystems arbeiten, dass sie dasselbe Datenkompetenzprogramm verfolgen und sich an dieselben architektonischen Prinzipien halten mussten. Um dies zu ermöglichen, mussten wir auch die verschiedenen Funktionen der Unternehmensarchitektur integrieren, die für die Gestaltung, Steuerung und Kontrolle des Unternehmens als Ganzes zuständig sind.

In einer anderen Organisation kann die Datenstrategie ganz anders aussehen. Wenn zum Beispiel die Geschäftsziele im Unternehmen weniger eng aufeinander abgestimmt sind, gibt es vielleicht weniger Bedarf an Standardisierung und Integration. Wenn du vor kurzem das traumatische Ereignis eines Datenlecks erlebt hast, wirst du dich wahrscheinlich stark auf den Schutz deiner Daten konzentrieren. Wenn dein primäres Ziel die Monetarisierung von Daten und der Aufbau von Partnerschaften ist, wirst du dich darauf konzentrieren, Interoperabilität für einen wirtschaftlichen Wert und Daten zu liefern, die in dem Sinne wertvoll sind, dass sie sich für die Käuferpartei lohnen. Der wichtigste Punkt ist, dass du deine Datenstrategie an deinen aktuellen und zukünftigen Geschäftsanforderungen ausrichtest.

Bevor wir zum Schluss kommen, möchte ich darauf hinweisen, dass einige Leute der Meinung sind, dass eine übergreifende Strategie nicht notwendig ist. Für sie ist das zu viel Arbeit im Vorfeld. Anstatt einen Plan zu entwickeln, solltet ihr einfach loslegen und sehen, was auf dem Weg passiert, während ihr Anwendungsfälle implementiert. Dieser Ansatz wird auf jeden Fall einen unmittelbaren Nutzen bringen. Langfristig hat er jedoch katastrophale Folgen für deine Architektur, weil es keine Verpflichtung zu Konsistenz und Standardisierung gibt. Ohne einen Leitfaden könnte die Umstellung ein langer Marsch in die falsche Richtung sein, der häufige Neustarts und Rückzieher erfordert.

Einpacken

Eine Strategie ist der Ausgangspunkt für jede digitale Transformation. Daten sind zweifelsohne ein wichtiger Bestandteil davon. Aber wie stellst du sicher, dass die Daten tatsächlich zu deinen langfristigen Zielen und Ambitionen beitragen? Und wie erleichterst du den organisatorischen Wandel, der für die Nutzung von Daten im Allgemeinen erforderlich ist? Hier ist eine Helikopterperspektive gefragt, die es dir ermöglicht, dein Geschäft von Anfang bis Ende zu verstehen. Für eine erfolgreiche Planung musst du dir zunächst ein vollständiges Bild machen. Du musst herauszoomen und dir einen abstrakten Überblick über dein Unternehmen verschaffen, bevor du dich auf bestimmte Problembereiche konzentrierst. Danach musst du eine Architektur und Organisationsstruktur festlegen, die deinen Übergang unterstützt und mit deiner Gesamtplanung, deiner Arbeitsweise und deinem Governance-Modell übereinstimmt. Im weiteren Verlauf des Buches erfährst du mehr über diese Konzepte.

Der schwierigste Teil der Umstellung ist der Entwurf einer Architektur, die allen Anforderungen und Zielen deiner Datenstrategie entspricht. Zunächst musst du dir ein ganzheitliches Bild von deiner Organisationsstruktur, deinen Anwendungen, Prozessen und deiner Datenlandschaft machen. Als Nächstes kannst du verschiedene potenzielle Szenarien ausarbeiten, indem du Dimensionen wie Flexibilität, Offenheit, Kontrolle, Zeit, Kosten für die Umsetzung, Risiken usw. abwägst. Jedes mögliche Szenario kann Roadmaps, Übergangsarchitekturen und verschiedene zukünftige Zustände beinhalten. Dieser Prozess ist eine dynamische und gemeinschaftliche Übung und geht weit über die Erstellung einfacher Visualisierungen hinaus. Ein wichtiger Hinweis dazu: Die Festlegung der strategischen und zukünftigen Ausrichtung beginnt von oben nach unten, vom Unternehmen aus. Sie sollte nicht nur von der IT-Abteilung kommen.

Ein wichtiger Aspekt deiner Datenstrategie ist das Gleichgewicht zwischen den Erfordernissen der Zentralisierung und der Dezentralisierung. Willst du zum Beispiel Governance und Aktivitäten, Architektur und Infrastruktur oder beides zusammenführen? Bei diesem Thema gibt es viel Verwirrung, da wir oft Extreme sehen. Das Data Mesh zum Beispiel ist eine Reaktion auf zentralisierte Datenorganisationen, Architekturen und Governance-Modelle, die eine 180-Grad-Wende einleiten. Es umfasst die Dezentralisierung in allen Aspekten, indem es dafür plädiert, dass alle Daten dezentral in den Händen von Domänen liegen müssen, die eine dezentral verwaltete Infrastruktur nutzen. Auf dem Papier kommt die Dezentralisierung bei Geschäftsführern und IT-Managern gut an , aber in der Praxis ist es nicht so einfach.

Die Dezentralisierung birgt Risiken, denn je mehr Aktivitäten über das Unternehmen verteilt sind, desto schwieriger wird es, die Strategie zu harmonisieren und die Planung abzustimmen und zu orchestrieren, ganz zu schweigen von der Förderung der Kultur und der Rekrutierung der Talente, die für ein angemessenes Datenmanagement erforderlich sind. Die daraus resultierende Fragmentierung wirft auch neue Fragen auf, z. B. "Wie viele Geschäftsmodelle oder Bereiche habe ich?" und "Wie viele Datenplattformen brauche ich?" In der Praxis habe ich festgestellt, dass viele Architekten und Datenexperten die Aufteilung der Bereiche und die Festlegung von Grenzen als den schwierigsten Teil der Dezentralisierung empfinden. Oft mangelt es an einem grundlegenden Verständnis von Geschäftsarchitektur und domänenorientiertem Design. Für viele Datenexperten sind die konzeptionellen Begriffe des domänenorientierten Designs zu schwer zu verstehen. Andere versuchen, zu vereinfachte oder objektorientierte Programmierbeispiele auf ihre Datenlandschaft zu projizieren.

Die Grundsätze der Dezentralisierung sind auch Gegenstand von Diskussionen darüber, wie Daten und Plattformen verwaltet werden müssen. Unter Dateningenieuren herrscht Skepsis, weil es noch keine offenen Interoperabilitätsstandards für Datenprodukte gibt. Außerdem gibt es Bedenken hinsichtlich der Nutzbarkeit von Daten, wenn einzelne Teams in Blasen arbeiten.

Diese Beobachtungen sind eine gute Überleitung zu den folgenden Kapiteln. Im nächsten Kapitel fliegen wir mit dem Hubschrauber eine Ebene tiefer und bringen dich nah genug heran, um deine Architektur, Datendomänen und Landezonen zu identifizieren. Ich werde dir dabei helfen, indem ich das Vokabular der Domänen vereinfache und dir pragmatische Hinweise und Beobachtungen aus der Praxis gebe. Danach wechseln wir auf die Quellsystemseite unserer Landschaft und bleiben dort für ein paar Kapitel, bevor unsere Reise weitergeht. Gute Reise!

¹ Der Markt für Datenanalytik wächst rasant. Laut IDC werden die jährlichen Ausgaben bis 2022 mehr als 200 Milliarden Dollar betragen.

² Der Body of Knowledge wird von der DAMA-Gemeinschaft entwickelt. Er wird nur langsam aktualisiert: Die erste Veröffentlichung war 2008, die zweite 2017.

³ Softwarearchitektur bezieht sich auf das Design und die High-Level-Struktur der Software, die für die Entwicklung eines Systems benötigt wird, das die geschäftlichen Anforderungen erfüllt und Merkmale wie Flexibilität, Skalierbarkeit, Machbarkeit, Wiederverwendbarkeit und Sicherheit umfasst. Wenn du mehr darüber erfahren möchtest, lies Fundamentals of Software Architecture von Mark Richards und Neal Ford (O'Reilly).

⁴ Ein Blueprint wird auch als Referenzimplementierung bezeichnet. Er besteht aus den Definitionen für Infrastructure as Code (IaC), um eine Reihe von Diensten für einen bestimmten Anwendungsfall erfolgreich zu erstellen.

⁵ Wir verwenden in diesem Buch den Begriff "Stammdatenmanagement" (MDM), weil er sich weithin durchgesetzt hat und es zum Zeitpunkt der Erstellung dieses Buches keine branchenweite Alternative gibt, aber wir begrüßen umfassendere Alternativen zur "Master/Slave"-Terminologie.

⁶ Wenn du mehr über die verschiedenen Phasen der Datenmodellierung erfahren möchtest, lies meinen Blogbeitrag "Datenintegration und Datenmodellierung entmystifiziert". Das konzeptionelle Modell wird manchmal auch Geschäftsmodell, Domänenmodell, Domänenobjektmodell oder Analyseobjektmodell genannt.

⁷ Ein Merkmalsspeicher ist ein Werkzeug zum Speichern häufig verwendeter Merkmale (einzelne messbare Eigenschaften oder Merkmale eines Phänomens).

⁸ Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen.

⁹ Offene Daten sind Daten, die frei genutzt werden können und öffentlich zugänglich gemacht werden.

¹⁰ Die Datenarchitektur eines Unternehmens umfasst die Infrastruktur, die Daten und die Schemata, Integrationen, Transformationen, Speicherungen und Workflows, die erforderlich sind, um die analytischen Anforderungen der Informationsarchitektur zu erfüllen.

¹¹ Hintergrundinformationen zu (Unternehmens-)Data Warehouses und warum sie nicht skalierbar sind, findest du in meinem Blogbeitrag "Das Aussterben von Enterprise Data Warehousing".

¹² Eine Domäne ist ein Fachgebiet, das eine Reihe gemeinsamer Anforderungen, Begriffe und Funktionen für jedes Softwareprogramm definiert, das zur Lösung eines Problems im Bereich der Computerprogrammierung entwickelt wurde.

¹³ Berichte sind in der Regel hauptsächlich tabellarisch, können aber zusätzliche Diagramme oder Diagrammkomponenten enthalten. Dashboards sind eher visuell und verwenden eine Vielzahl von Diagrammtypen.

¹⁴ James Dixon, damals Chief Technology Officer bei Pentaho, prägte den Begriff Data Lake.

¹⁵ Brian T. O'Neill führt eine Referenzliste zu den Ausfallraten.

¹⁶ Technologien sind unbeständig, deshalb musst du sie irgendwann ersetzen oder aufrüsten.