Data Mesh E-Book

Zhamak Dehghani

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch

Seitenzahl: 532

Veröffentlichungsjahr: 2023

Beschreibung

Data Mesh = verteile Architekturen auch für das Datenmanagement!

• Aus erster Hand: Die Autorin ist die Begründerin des innovativen Data-Mesh-Konzepts
• Von traditionellen Data Warehouses und Data Lakes hin zum dezentralen Data Mesh
• Das Buch zeigt, wie Data-Mesh-Architekturen sowohl organisatorisch als auch technisch implementiert werden

Wir befinden uns an einem Wendepunkt im Umgang mit Daten. Unser bisheriges Datenmanagement wird der Komplexität der Organisationsstrukturen, der immer zahlreicheren Datenquellen und dem steigenden Interesse am Einsatz von künstlicher Intelligenz nicht mehr gerecht. In diesem praxisorientierten Buch führt die Autorin Zhamak Dehghani in Data Mesh ein, ein dezentrales soziotechnisches Paradigma basierend auf Konzepten moderner verteilter Architekturen. Data Mesh ist ein neuer Ansatz für die Beschaffung, Bereitstellung, den Zugriff und die Verwaltung analytischer Daten, der auch skaliert.
Zhamak Dehghani begleitet Softwarearchitekt:innen, Entwickler:innen und Führungskräfte auf ihrem Weg von einer traditionellen, zentralen Big-Data-Architektur hin zu einer verteilten, dezentralen Organisationsstruktur für die Verwaltung analytischer Daten. Dabei behandelt Data Mesh Daten als Produkt, ist stark domänengetrieben und zielt auf eine Self-Serve-Datenplattform ab. Das Buch erläutert technische Migrationsstrategien, aber auch den organisatorischen Wandel hin zu neuen Teamstrukturen, Rollen und Verantwortlichkeiten, die mit dezentralen Architekturen einhergehen.

Leseprobe

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Data Mesh

Eine dezentrale Datenarchitektur entwerfen

Zhamak Dehghani

Deutsche Übersetzung vonJochen Christ & Simon Harrer

Zhamak Dehghani

Lektorat: Alexandra Follenius

Übersetzung: Jochen Christ, Simon Harrer

Copy-Editing: Sibylle Feldmann, www.richtiger-text.de

Satz: Jörg Liedtke, www.liedtke.me

Herstellung: Stefanie Weidner

Umschlaggestaltung: Karen Montgomery, Michael Oréal, www.oreal.de

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-96009-207-0

PDF

978-3-96010-724-8

ePub

978-3-96010-725-5

mobi

978-3-96010-726-2

1. Auflage 2023

Translation Copyright für die deutschsprachige Ausgabe © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Data Mesh, ISBN 9781492092391

© 2022 Zhamak Dehghani. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

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 Autorin noch Verlag noch Übersetzer 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

Für Dad

Dein Licht leuchtet weiter.

Inhalt

Vorwort

Vorbemerkung der Übersetzer

Einleitung

Prolog: Fallstudie

Teil IWas ist Data Mesh?

1Data Mesh im Überblick

Ergebnisse

Veränderungen

Prinzipien

Domain Ownership

Data as a Product

Self-Serve Data Platform

Federated Computational Governance

Zusammenspiel der Prinzipien

Data Mesh kurz erklärt

Daten

Operative Daten

Analytische Daten

Entstehungsgeschichte

2Das Prinzip Domain Ownership

Domain-driven Design

Strategisches Design

Archetypen von Domänendaten

Quellenorientierte Domänendaten

Aggregierte Domänendaten

Konsumentenorientierte Domänendaten

Einführung von Domain Ownership

Verantwortung wandert flussaufwärts

Verknüpfung von Modellen

Mythos Single Source of Truth

Daten-Pipelines als Implementierungsdetail

Zusammenfassung

3Das Prinzip Data as a Product

Product Thinking

Grundlegende Usability-Attribute von Datenprodukten

Einführung von Data as a Product

Domänen verantworten Datenprodukte

Eine neue Sprache

Daten als Produkt statt als Asset

Vertraue, aber prüfe nach

Daten und Logik als Einheit

Zusammenfassung

4Das Prinzip Self-Serve Data Platform

Data-Mesh-Plattform im Vergleich

Autonome domänenorientierte Teams als Zielgruppe

Autonome und interoperable Datenprodukte als Kernkonzept

Operative und analytische Funktionen in einer integrierten Plattform

Generalisten als Hauptnutzende

Dezentrale Technologien

Domänenagnostisch

Platform Thinking

Wertschöpfung durch autonome Teams

Wertschöpfung mit autonomen und interoperablen Datenprodukten

Reduktion des Cognitive Load

Skalierung der Bereitstellung von Daten

Förderung einer Innovationskultur

Einführung einer Self-Serve Data Platform

API first

Optimierung für Generalisten

Simplify

High-Level-APIs für Datenprodukte

Nutzerorientierung statt Feature-Orientierung

Klein anfangen und mitwachsen

Zusammenfassung

5Das Prinzip Federated Computational Governance

Systems Thinking

Gleichgewicht zwischen Autonomie und Interoperabilität

Dynamische Topologie als Standardzustand

Automatisierung und verteilte Architektur

Föderalismus

Föderales Team

Leitlinien

Policies

Anreize

Automatisierung

Standards als Code

Policies als Code

Automatisierte Tests

Automatisiertes Monitoring

Einführung von Federated Computational Governance

Delegation der Verantwortlichkeit an Domänen

Integration der Policy-Ausführung in jedes Datenprodukt

Automatisierung und Monitoring der Policies

Bestimmung von Polysemen

Messung des Netzwerkeffekts

Mut zu Veränderung

Zusammenfassung

Teil IIWarum Data Mesh?

6Der Wendepunkt

Die großen Erwartungen

Die große Kluft

Skalierung: Begegnung einer neuen Art

Nichts ist so beständig wie der Wandel

Diskrepanz zwischen Investition und Rendite

Zusammenfassung

7Nach dem Wendepunkt

Auf Veränderungen angemessen reagieren

Alignment von Fachlichkeit, Technologie und analytischen Daten

Integration der operativen und analytischen Welt

Dezentralisierung von Datenänderungen

Beseitigung unbeabsichtigter Komplexität

Agilität trotz Wachstum

Beseitigung zentralisierter und monolithischer Komponenten

Reduzierung des Koordinierungsaufwands von Pipelines

Reduzierung des Koordinationsaufwands für Data Governance

Förderung der Autonomie

Verbesserung des Kosten-Nutzen-Verhältnisses

Komplexitätsreduktion durch die Datenplattform

Product Thinking überall

Organisationsübergreifender Datenzugriff

Zusammenfassung

8Vor dem Wendepunkt

Evolution der analytischen Datenarchitekturen

Erste Generation: Data-Warehouse-Architektur

Zweite Generation: Data-Lake-Architektur

Dritte Generation: multimodale Cloud-Architektur

Eigenschaften der analytischen Datenarchitektur

Monolithisch

Zentralisiert

Technologieorientiert

Zusammenfassung

Teil IIIWie entwirft man eine Data-Mesh-Architektur?

9Logische Architektur

Schnittstellen für die Bereitstellung analytischer Domänendaten

Design der operativen Schnittstelle

Design der analytischen Datenschnittstelle

Domänenübergreifende Abhängigkeiten von Analysedaten

Datenprodukt als Architekturquantum

Strukturelle Komponenten eines Datenprodukts

Bereitstellung und Konsum von Daten

Discovery- und Observability-APIs

Die drei Ebenen der Datenplattform

Dateninfrastruktur-Ebene

Datenprodukt-Ebene

Mesh-Ebene

Beispiel

Eingebettete automatisierte Policies

Datenprodukt-Sidecar

Datenprodukt-Container

Control-Port

Zusammenfassung

10Datenplattform

Entwurf der Plattform anhand von User Journeys

User Journey der Data Product Developer

Incept, Explore, Bootstrap, Source

Build, Test, Deploy, Run

Maintain, Evolve, Retire

User Journey der Data Product Consumer

Incept, Explore, Bootstrap, Source

Build, Test, Deploy, Run

Maintain, Evolve, Retire

Zusammenfassung

Teil IVWie entwirft man Datenprodukte?

11Entwurf eines Datenprodukts anhand von Affordances

Datenprodukt-Affordances

Merkmale einer Datenproduktarchitektur

Der Einfluss von komplexen adaptiven Systemen auf den Entwurf

Emergentes Verhalten aus einfachen lokalen Regeln

Kein zentraler Koordinator

Zusammenfassung

12Daten konsumieren, transformieren und bereitstellen

Daten bereitstellen

Anforderungen der Datennutzer

Entwurfseigenschaften für das Bereitstellen von Daten

Entwurf

Daten konsumieren

Archetypen von Datenquellen

Lokalität des Datenkonsums

Entwurf

Daten transformieren

Programmatische vs. nichtprogrammatische Transformation

Datenflussbasierte Transformation

Machine Learning als Transformation

Zeitabhängige Transformation

Entwurf

Zusammenfassung

13Daten finden, verstehen und kombinieren

Daten finden und verstehen

Gefunden werden dank Selbstregistrierung

Finden des globalen URI

Semantische und syntaktische Modelle verstehen

Vertrauen schaffen mit Datengarantien

Untersuchung der Form von Daten

Lernen mit Dokumentation

Entwurf

Daten kombinieren

Anforderungen

Traditionelle Ansätze

Entwurf

Zusammenfassung

14Daten verwalten, regeln und beobachten

Lebenszyklus verwalten

Entwurf

Manifest

Daten regeln

Entwurf

Standardisierte Policies

Integration von Daten und Policies

Verknüpfung von Policies

Daten beobachten

Entwurf

Zusammenfassung

Teil VWie führt man Data Mesh ein?

15Strategie und Umsetzung

Sollten Sie Data Mesh schon jetzt einführen?

Data Mesh als ein Teil der Datenstrategie

Data Mesh Execution Framework

Fachlich getriebene Umsetzung

Iterative Ende-zu-Ende-Umsetzung

Evolutionäre Umsetzung

Zusammenfassung

16Organisation und Unternehmenskultur

Veränderungen

Kultur

Werte

Anreize

Intrinsische Motivation

Extrinsische Motivation

Struktur

Annahmen über die Organisationsstruktur

Zuschnitt von Datenprodukten

Menschen

Rollen

Weiterbildung

Prozess

Wesentliche Prozessänderungen

Zusammenfassung

Index

Vorwort

Ich beschäftige mich schon seit mehreren Jahrzehnten mit der Entwicklung von Software für große Unternehmen, und die Verwaltung von Daten war schon immer ein wichtiger Aspekt der Architektur. In den Anfängen meiner Karriere gab es viel Enthusiasmus für ein unternehmensweit einheitliches Datenmodell, das oft in der unternehmensweiten Datenbank gespeichert wurde. Wir haben jedoch schnell gelernt, dass dies zu einer katastrophalen Kopplung führt, wenn eine Vielzahl von Anwendungen auf einen gemeinsamen Datenspeicher zugreift. Aber auch ohne dies gab es größere Probleme. Kernideen eines Unternehmens, wie z.B. »Kunde«, erforderten unterschiedliche Datenmodelle in verschiedenen Domänen. Unternehmensübernahmen machten die Sache noch schwieriger.

Deshalb haben kluge Unternehmen ihre Daten dezentralisiert und Datenspeicherung, -modelle und -verwaltung in die fachlichen Domänen verlagert. Auf diese Weise sind Personen, die die Daten in ihrer Domäne am besten verstehen, auch für die Verwaltung dieser Daten verantwortlich. Sie arbeiten mit anderen Domänen über definierte APIs zusammen. Da diese APIs Logik enthalten können, haben wir mehr Flexibilität bei der Bereitstellung dieser Daten und, was noch wichtiger ist, bei der Weiterentwicklung der Datenverwaltung im Laufe der Zeit.

Während sich dies für das operative Tagesgeschäft immer mehr durchgesetzt hat, blieb die Datenanalyse eine eher zentralisierte Aufgabe. Data Warehouses zielten darauf ab, ein unternehmensweites Repository für kuratierte kritische Informationen bereitzustellen. Doch eine solche zentralisierte Organisationseinheit hatte mit dieser Aufgabe und ihren konkurrierenden Datennutzern zu kämpfen, zumal sie weder die Daten noch die Bedürfnisse ihrer Datennutzer richtig verstanden. Ein Data Lake half, indem er Analysten durch den Zugang zu Rohdaten ermöglichte, näher an die ursprüngliche Quelle heranzukommen. Aber allzu leicht wurde er zu einem Datensumpf mit geringer Datenqualität, mangelhaftem Datenverständnis und unklarer Datenherkunft.

Data Mesh versucht nun, die Erfahrungen, die wir mit operativen Daten gemacht haben, auch auf die Welt der analytischen Daten anzuwenden. Die fachlichen Domänen sind für die Bereitstellung analytischer Daten über APIs verantwortlich, so wie sie es auch für operative Daten tun. Indem sie ihre Daten als echte Produkte betrachten, kommunizieren sie die Bedeutung und Herkunft der Daten und arbeiten eng mit ihren Nutzern zusammen. Um die damit verbundene Aufgabe bewältigen zu können, muss das Unternehmen eine Plattform für die Erstellung und Bereitstellung dieser Datenprodukte zur Verfügung stellen, zusammen mit einer föderalen Governance-Struktur, um die Kohärenz des Ganzen zu gewährleisten. Bei all dem spielt technische Exzellenz eine wichtige Rolle, damit sich die Plattformen und Produkte schnell weiterentwickeln können, wenn sich die Geschäftsanforderungen ändern.

Data Mesh ist also im Grunde eine recht einfache, vielleicht sogar offensichtliche Anwendung eines gut etablierten Grundsatzes der Datenverwaltung auf die Welt der analytischen Daten. In der Praxis ist es jedoch sehr schwierig, dies zu realisieren, vor allem weil sich so viele Investitionen der Anbieter auf zentralisierte Modelle konzentriert haben. Dies wird noch dadurch erschwert, dass die Praktiken (wie Testen, Abstraktionen und Refactoring) nicht unterstützt werden, von denen die Entwicklerinnen und Entwickler von operativen Systemen wissen, dass sie für gesunde Software unerlässlich sind.

Zhamak war an vorderster Front dabei, beriet unsere Kunden auf dem Weg in die Zukunft, lernte aus ihren Rückschlägen und Erfolgen und ermunterte die Anbieter, die Tools zu entwickeln, die den Aufbau dieser Plattformen erleichtern. Dieses Buch bündelt ihr Wissen und das ihrer Kollegen in dieser frühen, aber wichtigen Phase der weltweiten Einführung von Data Mesh. Ich habe beim Review dieses Buchs viel über die damit verbundenen Herausforderungen gelernt. Ich bin überzeugt, dass alle, die ihre Daten optimal nutzen möchten, in diesem Buch den besten Weg finden, den wir kennen.

– Martin Fowler

Chief Scientist, Thoughtworks

Vorbemerkung der Übersetzer

Wir sind Softwareentwickler. In unseren Projekten arbeiten wir typischerweise in kleinen, autonomen Entwicklungsteams, die für eine bestimmte Domäne zuständig sind. Technisch entwickeln und betreiben wir Anwendungen mit UIs, APIs und operativen Datenbanken in Form von Self-contained Systems (https://scs-architecture.org/) in der Cloud. Datenanalysen spielten in unserer täglichen Arbeit lange keine Rolle.

2018 stellte Zhamak Dehghani ihre Idee von Data Mesh vor. Für uns waren ihre beiden Artikel dazu wie eine Art Augenöffner. Data Mesh führt die Ideen von Domain-driven Design, Self-contained Systems, Team Topologies und Product Thinking fort und wendet diese auf die Welt der Daten an.

Wir waren damals Teil eines autonomen Produktteams und haben dann begonnen, die Ideen von Data Mesh bei uns anzuwenden. Wir haben auf Google Big-Query, bereitgestellt vom Datenplattformteam, auf Basis von Domänen-Events Datenprodukte erstellt und darauf Datenanalysen durchgeführt. Dadurch konnten wir als Entwicklungsteam zusammen mit unserem Product Owner eigenständig Hypothesen vor der Umsetzung validieren und den Nutzen nach der Umsetzung messen. Es war unglaublich motivierend, nachweislich sinnvolle Features umsetzen und konkrete Erfolge gemeinsam feiern zu können. Auch wenn wir nur ein einzelnes Entwicklungsteam waren, konnten wir das große Potenzial von Data Mesh für die gesamte Organisation spüren.

Data Mesh ist der nächste logische Schritt in der Dezentralisierung der Softwarearchitektur. Wir wollen diese Idee unterstützen. Deswegen die Übersetzung dieses wegweisenden Buchs, damit sich die Idee auch im deutschsprachigen Raum verbreitet.

– Jochen Christ und Simon Harrer

Zoom, 2022

PS: In eigener Sache möchten wir noch auf unsere Webseite https://www.datamesh-architecture.com/ verweisen, auf der wir näher auf die Perspektive aus Richtung Anwendungsentwicklung und Softwarearchitektur eingehen.

Einleitung

Data Mesh ist der Impuls, der uns in der Art, wie wir an Daten herangehen, auf einen neuen Kurs bringt: wie wir uns Daten vorstellen, wie wir sie erfassen und weitergeben und wie wir aus ihnen Nutzen generieren – im großen Maßstab und im Bereich der Datenanalyse und der künstlichen Intelligenz. Dieser neue Kurs führt uns weg von der Zentralisierung von Daten und deren Ownership hin zu einem dezentralen Modell. Dieser neue Kurs trägt der Komplexität unserer Organisationen, ihrem schnellen Wandel und ihrem kontinuierlichen Wachstum Rechnung. Er zielt darauf ab, selbst große Organisationen in die Lage zu versetzen, trotz des Durcheinanders und der organisatorischen Komplexität einen Mehrwert aus Daten zu ziehen.

Wenn wir auf die Geschichte unserer Branche zurückblicken, haben wir schon einmal einen solchen Impuls erhalten. Die Entstehung von Unix und seiner Philosophie »Schreibe Programme so, dass sie nur eine Aufgabe erledigen und diese gut machen. Schreibe Programme so, dass sie zusammenarbeiten …« war vielleicht der Schmetterling, der mit seinen Flügeln schlug und die Voraussetzungen dafür schuf, dass wir Jahrzehnte später die Komplexität im Herzen von Software durch verteilte Architektur, serviceorientiertes Design, Kommunikation über Standard-APIs und autonome Domänenteams bewältigen konnten. Ich hoffe, dass Data Mesh die Voraussetzung für einen neuen Weg zur Bewältigung der Komplexität im Herzen von Daten in dem Bereich schafft, der sie am meisten benötigt, nämlich Datenanalyse und künstliche Intelligenz.

Ich habe die These von Data Mesh im Jahr 2018 formuliert, nachdem ich in großen und technologisch fortschrittlichen Unternehmen, die erhebliche Investitionen in ihre Datentechnologien getätigt hatten, häufig auftretende Fehler bei der Wertschöpfung aus Daten beobachtet hatte. Die beobachteten Schwierigkeiten bei der Skalierung von Systemen und der Organisation des Datenmanagements, um ihre ehrgeizigen Datenziele zu erreichen, führten dazu, dass ich die jahrzehntelangen Annahmen über die Art und Weise, wie wir aus Daten Wert schöpfen, infrage stellte: Wir sammeln sie, wir speichern sie zentral, wir beauftragen ein Datenteam mit ihrer Verwaltung, und dann lassen wir sie auf eine Vielzahl von Anwendungsfällen los. Diese Annahmen mussten überarbeitet werden.

Die Ideen hinter Data Mesh habe ich etwa zur gleichen Zeit auf einer O’Reilly-Konferenz in New York vorgestellt. Ich nannte den Vortrag »Beyond the Lake« (https://oreil.ly/O3hbf), denn ich bemühte mich, eines der schwierigsten Probleme in der IT zu lösen, nämlich »Dinge zu benennen«. Trotz meiner Befürchtung, harsche Kritik zu ernten, da ich mit frevelhaften Worten unsere Sichtweise auf Daten grundlegend veränderte, wurde der Vortrag vom Publikum positiv aufgenommen. Die Schmerzen von Menschen, die mit Daten arbeiten – Data Analysts oder Data Scientists – waren real; sie alle bemühten sich, zeitnah Zugriff auf qualitativ hochwertige und vertrauenswürdige Daten zu erhalten. Das Gleiche galt auch für die Data Engineers, die versuchen, Daten aus unzuverlässigen Datenquellen in eine Form zu bringen, die andere nutzen können, und das alles ohne engen Kontakt zur Fachabteilung. Die Führungskräfte im Publikum nickten bei der Feststellung, dass die Rendite ihrer Daten- und Analyselösungen nur mittelmäßig war. Ich verließ die Konferenz mit mehr Vertrauen in das, was nach den Lakes kommen könnte. Ein paar Monate später verpasste ich ein einwöchiges Treffen des Tech Advisory Board in China. Meine dreijährige Tochter hatte in der Nacht vor dem Abflug aus den USA Fieber bekommen. Ich schaffte es bis in das Flugzeug und verbarg meine Verzweiflung darüber, dass ich mich eine Woche lang von meinem kranken Kind trennen musste, aber als der Pilot der Besatzung ankündigte, dass die Türen des Flugzeugs geschlossen würden, brach ich zusammen. Ich verließ das Flugzeug. Jetzt hatte ich eine Woche Zeit, mich zurückzuziehen und die Gedanken und Erfahrungen mit Data Mesh in einem Artikel mit dem Titel »How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh« (https://oreil.ly/rxjiW) in Worte zu fassen, der freundlicherweise von Martin Fowler gehostet wurde. Der Artikel war ein voller Erfolg und wurde unglaublich oft gelesen, so als hätte ich gerade die Worte gesagt, an die andere im Stillen bereits gedacht hatten. Drei Jahre später geht nun dieses Buch detailliert darauf ein, warum Data Mesh wichtig ist, was es umfasst und wie man es umsetzt.

Warum ich dieses Buch geschrieben habe und warum gerade jetzt

In den wenigen Jahren, die seit der Vorstellung von Data Mesh vergangen sind, hat es enormen Anklang bei den Unternehmen gefunden, die es eingeführt hatten. Es hat Anbieter dazu ermutigt, zu versuchen, ihre Produkte so anzupassen, dass sie für Data-Mesh-Implementierungen geeignet sind. Es hat eine stetig wachsende Community geschaffen, die ihre Erfahrungen austauscht.

Trotz dieser rasanten Entwicklung schreibe ich dieses Buch vielleicht etwas früher, als ich es mir gewünscht hätte. Wir befinden uns noch in den Anfangsjahren eines grundlegend anderen Ansatzes bei der Bereitstellung und Erstellung von Daten für analytische Anwendungsfälle und Machine Learning. Aber unsere Branche hat die Tendenz, neue Konzepte und Buzzwords bis zur Unkenntlichkeit zu verdrehen. Daher habe ich beschlossen, jetzt dieses Buch zu schreiben, um eine gemeinsame Grundlage für künftige Entwicklungen von Data-Mesh-Implementierungen zu schaffen. Ich wollte sicherstellen, dass wir, bevor wir uns dazu hinreißen lassen, neue technische Lösungen zu entwickeln, verstehen, warum wir etwas ändern müssen, welche Probleme wir lösen wollen und wie wir das tun sollten.

Dieses Buch schafft eine Grundlage für die Ziele von Data Mesh, warum wir uns damit beschäftigen sollten und für seine Grundprinzipien. Wir schauen uns an, wie man die Grundprinzipien anwendet, um eine High-Level-Architektur zu schaffen, und ich gebe Ihnen Werkzeuge an die Hand, mit denen Sie die Implementierung umsetzen und die Organisation und Kultur verändern können.

Wer dieses Buch lesen sollte

Dieses Buch richtet sich an Menschen mit den unterschiedlichsten Rollen und Kompetenzen. Data Mesh ist ein Paradigmenwechsel, und es erfordert den gemeinsamen Einsatz vieler sich ergänzender Rollen und Disziplinen in Bereichen wie Softwarearchitektur, Softwareentwicklung und Administration bis hin zum Produkt- und Top-Level-Management sowie den Führungskräften, um es für ein Unternehmen Wirklichkeit werden zu lassen.

Hier ist eine kurze Zusammenfassung der Personas der Leserinnen und Leser und was sie aus diesem Buch mitnehmen können:

Nutzer analytischer Daten

wie Data Scientists und Data Analysts sollten dieses Buch lesen, um zu verstehen, was Data Mesh ihnen ermöglicht. Sie lernen, wie sie ihrerseits ihre Erkenntnisse und Schlussfolgerungen als neue Datenprodukte im Data Mesh bereitstellen.

Datenlieferanten

, wie Entwicklungsteams oder Data Engineers, sollten dieses Buch lesen, um zu verstehen, wie Data Mesh die beiden Welten der operativen und analytischen Daten und Anwendungen zusammenbringt. Sie werden sehen, wie ihre Rollen in funktionsübergreifende Domänenteams übergehen und welche Art von Architektur sie aufbauen müssen, um Data Mesh zu ermöglichen.

Infrastruktur-Product-Owner, Softwarearchitekten und Softwareentwicklerinnen

sollten dieses Buch lesen, um die Rolle und das Design einer Self-Service-Datenplattform zu verstehen, um eine Reihe von gut integrierten Diensten bereitzustellen, die es funktionsübergreifenden Domänenteams ermöglichen, Daten dezentral im großen Umfang zu teilen.

Data-Governance-Teams

sollten dieses Buch lesen, um die neue Struktur und den neuen Ansatz zur Erreichung von Governance-Zielen zu verstehen, die eine unabhängige Domänenverantwortung für Daten fördern, organisatorische Engpässe beseitigen und sich stark auf Automatisierung stützen. Dieses Buch stellt eine neue Rolle und Form für Data Governance vor.

Führungskräfte und Manager

sollten dieses Buch lesen, um den bevorstehenden Paradigmenwechsel zu verstehen und zu lernen, eine auf Data Mesh basierende Datenstrategie zu formulieren, die Transformation durchzuführen und ihre Organisation auf diesem Weg zu begleiten.

Dieses Buch richtet sich sowohl an Personen, die sich mit Daten und deren Analysen befassen, als auch an diejenigen, die sich mehr auf die Entwicklung von Software und deren Betrieb konzentrieren. Data Mesh schließt die Lücke zwischen diesen beiden Gruppen.

Wenn Sie einen Hintergrund in traditioneller Datenanalyse haben, vielleicht als Data Engineer oder Data Analyst, möchte ich Sie ermutigen, Ihre Vorurteile aus der Vergangenheit abzulegen. Seien Sie offen für neue Wege, das Problem der analytischen Datenverwaltung und -verarbeitung zu lösen. Akzeptieren Sie die Automatisierung als unverzichtbaren Begleiter von Daten.

Wenn Sie einen Hintergrund in Anwendungsentwicklung, Softwarearchitektur oder -infrastruktur haben, lesen Sie dieses Buch mit Empathie für Daten und Analysen. Sehen Sie sich als Teil der Lösung für die Bereitstellung und die Nutzung von Daten zur Verbesserung Ihrer Anwendungen. Stellen Sie sich eine neue Zukunft vor, in der die Arbeit mit Daten und die Entwicklung von Anwendungen zwei sich ergänzende Elemente sind, um Ihre Lösungen erfolgreich zu machen.

Wie man dieses Buch liest

Ich empfehle Ihnen dringend, mit dem »Prolog: Fallstudie« zu beginnen. Dieses kurze Kapitel vermittelt Ihnen ein Gefühl dafür, wie Data Mesh funktioniert. Es veranschaulicht die Auswirkungen von Data Mesh in der täglichen Praxis. Es demonstriert die Prinzipien von Data Mesh anhand einer fiktiven Geschichte über ein digitales Streaming-Unternehmen: Daff, Inc.

Der Rest des Buchs ist in fünf Teile gegliedert:

Teil I, »Was ist Data Mesh?«

In diesem Teil werden die Grundprinzipien von Data Mesh vorgestellt und ihre transformativen Auswirkungen beschrieben. Ich hoffe, dass jeder diesen Teil des Buchs liest, da der Inhalt alle zukünftigen Diskussionen über Data Mesh prägen wird.

Teil II, »Warum Data Mesh?«

Wenn Sie sich nicht sicher sind, ob Data Mesh die richtige Wahl für Sie ist, oder wenn Sie verstehen wollen, welche Probleme es löst und wie es sie löst, oder wenn Sie einfach mitreden wollen, lesen Sie diesen Teil des Buchs. Er vergleicht Data Mesh mit der Vergangenheit und erörtert, warum das, was uns hierher gebracht hat, uns nicht in die Zukunft führen wird. Ich empfehle allen Leserinnen und Lesern, diesen Teil des Buchs sorgfältig zu lesen.

Teil III, »Wie entwirft man eine Data-Mesh-Architektur?«

Dieser Teil richtet sich an alle Menschen in der technischen Praxis und an Führungskräfte. Die Kapitel in diesem Teil des Buchs konzentrieren sich auf die High-Level-Architektur von Data Mesh und dessen Komponenten. Sie helfen Ihnen, Ihre Data-Mesh-Architektur zu entwerfen und Standardtechnologien auf ihre Eignung für Data Mesh zu prüfen.

Teil IV, »Wie entwirft man Datenprodukte?«

Dieser Teil befasst sich mit der detaillierten Gestaltung eines Kernkonzepts von Data Mesh, dem sogenannten Datenprodukt. Es soll komplexe Konzepte vereinfachen, ohne auf notwendige Details zu verzichten. Er sollte für alle Rollen in der Praxis und im Management verständlich sein. Personen, die in einer technischen Führungsposition bei der Implementierung verschiedener Aspekte von Data Mesh sind, sollten den größten Nutzen aus diesem Teil des Buchs ziehen.

Teil V, »Wie führt man Data Mesh ein?«

Dieser Teil ist ein Leitfaden für Personen in Funktionen, die Einfluss auf die gesamte Umsetzung der Datenstrategie und den dazugehörigen organisatorischen Wandel haben. Er enthält konkrete Ratschläge dazu, wie eine evolutionäre Einführung von Data Mesh angegangen werden kann und wie organisatorische Entscheidungen in Bezug auf Teamstruktur, Anreize, Kultur usw. getroffen werden können.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Kennzeichnet neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Fett

Wird für Namen von Domänen und Datenprodukten verwendet.

Feste Zeichenbreite

Wird für Code sowie innerhalb von Absätzen verwendet, um auf Codeelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Feste Zeichenbreite in fett

Zeigt Befehle oder anderen Text an, der vom Benutzer genau so eingegeben werden muss.

Feste Zeichenbreite in kursiv

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Dieses Element steht für einen allgemeinen Hinweis.

Dieses Element steht für eine Warnung oder einen Warnhinweis.

Danksagungen

Ich möchte dieses Buch meinem Partner, Adrian Paoletti, und meiner Tochter, Arianna Paoletti, widmen. Ohne ihre Geduld und selbstlose Liebe und Unterstützung würde es dieses Buch nicht geben. Wir haben in den letzten anderthalb Jahren viele gemeinsame Urlaube und Wochenenden verpasst, damit ich dieses Buch fertigstellen konnte. Ich werde ihnen für ihr Verständnis und ihre Liebe immer dankbar sein. Ich möchte dieses Buch auch meiner Mutter, Nayer Dadpay, und meiner Schwester, Parisa Dehghani, widmen, deren Liebe und ermutigende Worte mich behutsam durch den Prozess der Fertigstellung dieses Buchs geführt haben. Ich liebe euch alle.

Man sagt, ein Buch zu schreiben, sei ein einsames Unterfangen – nicht in meinem Fall. Ich möchte mich bei meinen aufmerksamen Rezensenten bedanken, die mich auf dem Weg des Schreibens begleitet und großzügig ihre Zeit und ihr Feedback zur Verfügung gestellt haben. In keiner besonderen Reihenfolge: Andy Petrella, vielen Dank für das Teilen deiner Perspektive als Data Scientist mit Bescheidenheit und Humor. Chris Ford, ich danke dir für deine durchdachten Kommentare zur Architektur, die meinen Blickwinkel oft erweitert haben. Mammand Zadeh, danke für die Stimme eines erfahrenen und doch pragmatischen Experten für Dateninfrastrukturen, der mir immer dabei hilft, den Bogen von der Idee zur Realität zu spannen. Martin Fowler, danke, dass du das große Ganze beleuchtest, mir die Lücken aufzeigst und mir hilfst, komplexe Konzepte zu veranschaulichen. Danilo Sato und Sam Ramji, ich danke euch für eure Ratschläge, eure Weisheit und eure Zeit.

Viele Mitarbeitende von Thoughtworks waren an der Entstehung wegweisender Themen in der Tech-Industrie beteiligt: Microservices, Continuous Delivery, Agilität, und die Liste geht weiter. Einer der Gründe dafür ist, dass die Führung von Thoughtworks genau die richtigen Bedingungen für die Verbreitung von Kreativität im Streben nach Software-Exzellenz schafft. Ich möchte mich bei Rebecca Parsons und Chris Murphy (keine besondere Reihenfolge) dafür bedanken, dass sie mich beim Schreiben dieses Buchs unterstützt haben. Ich möchte mich bei meinen ehemaligen und derzeitigen Kollegen bei Thoughtworks (ebenfalls ohne besondere Reihenfolge) bedanken: Gagan Madan, Zichuan Xiong, Neal Ford, Samia Rahman, Sina Jahangirizadeh, Ken Collier, Srikar Ayilavarapu, Sheroy Marker, Danilo Sato, Emily Gorcenski, David Colls, Erik Nagler und vielen anderen.

Ich möchte all den Menschen bei O’Reilly danken, die die Veröffentlichung dieses Buchs ermöglicht haben. Aus der wunderbaren und leidenschaftlichen Familie von O’Reilly möchte ich Gary O’Brien hervorheben. Gary, ich danke dir für deine unermüdliche Unterstützung und für all die Wochenenden, die du dir von deiner Familie freigenommen hast, um meine Inhalte zu prüfen und meine Fragen zu beantworten, um mich während der Tiefen und Zweifel aufzumuntern und mich wieder auf den richtigen Weg zu bringen. Melissa Duffield, danke, dass du dieses Buch auf den Weg gebracht hast, mir geholfen hast, den ersten Schritt zu tun, und mich mit deiner unbestreitbaren menschlichen Empathie unterstützt hast.

Schließlich möchte ich meinem Lehrer und Mentor während des Schreibens, Martin Fowler, danken. Martin, ich danke dir, dass du mich bei jedem Schritt unterstützt hast.

Danksagungen der Übersetzer

Zuallererst wollen wir uns bei Zhamak Dehghani bedanken, dass du mit Data Mesh den nächsten logischen Schritt in der Dezentralisierung der modernen Softwarearchitektur so klar beschrieben und damit auch eingeleitet hast. Dein Buch ist ein wundervoll illustriertes Standardwerk für die künftige Generation von Entwicklerinnen und Entwicklern. Zhamak, danke für deine wegweisenden Impulse!

Larysa Visengeriyeva, danke, dass du mit uns das Thema Data Mesh bei INNOQ aufbereitet hast – ohne dich wären wir nie so tief in das Thema abgetaucht und hätten auch nur halb so viel Spaß dabei gehabt. Und dir, lieber Stefan Tilkov, vielen Dank, dass du uns dies überhaupt ermöglicht hast.

Natürlich möchten wir uns auch besonders bei Alexandra Follenius von O’Reilly Deutschland bedanken für die freundliche und unkomplizierte Unterstützung. Danke, dass du unsere zahlreichen E-Mails immer schnell und ausführlich beantwortet hast.

Ein ganz besonderer Dank geht an unsere Familien, die uns an vielen Abenden und Wochenenden den Rücken freigehalten haben.

Prolog: Fallstudie

Die Vorstellungskraft trägt uns oft in Welten, die es nie gab. Aber ohne sie gehen wir nirgendwo hin.

– Carl Sagan

Auf jedes erfolgreiche Unternehmen kommen drei, die gescheitert und vergessen sind. Die Zahl der Gescheiterten übersteigt die Zahl der Überlebenden.1 Im Zeitalter der künstlichen Intelligenz ist es kein seltsamer Zufall, dass die überlebenden und erfolgreichen Unternehmen die heutige Komplexität beherrschen und konsequent datenbasierte Experimente durchführen. Sie stellen sich dem ständigen Wandel und nutzen Machine Learning, um die Realität jenseits menschlicher Logik und Argumentation zu verstehen.

Daff, Inc.,2 ein fiktives globales Musik- und Audio-Streaming-Unternehmen,3 ist ein Beispiel für ein solches Unternehmen. Daff hat seine Mission erfolgreich umgesetzt: »Kunstschaffende und Publikum auf der ganzen Welt miteinander zu verbinden in einem einzigartigen Musikgenuss in jedem Moment des Lebens.« Hinter der Mission von Daff stehen die hohen Erwartungen des Unternehmens an Daten, Analysen und künstliche Intelligenz, die durch einen Ansatz erreicht werden, den man als Data Mesh bezeichnet. Data Mesh ist die Grundlage der Datenstrategie, der Datenarchitektur und des Betriebsmodells von Daff. Es erlaubt dem Unternehmen, skalierbar und schnell mithilfe von Daten und Machine Learning (ML) zu experimentieren, zu lernen und sich anzupassen.

Ich möchte Ihnen die Geschichte von Daff erzählen, nachdem es Data Mesh eingeführt hat. Anhand dieser Geschichte von Daff werden Sie das Wesentliche über Data Mesh erfahren. Sie werden sehen, wie die Prinzipien von Data Mesh angewendet werden. Sie lernen die Vorteile kennen und werden verstehen, wie die Architektur und die Organisationsstruktur aufgebaut sind und funktionieren.

Ich finde, ein komplexer Ansatz wie Data Mesh lässt sich am besten anhand eines Beispiels erklären. Die Entwicklung von Data Mesh steht jedoch noch zu sehr am Anfang, um ein echtes Beispiel für ein Unternehmen mit einem ausgereiften Data Mesh zu schildern. Schließlich sind wir gerade erst dabei, die ersten Data-Mesh-Umsetzungen zu entwickeln. Daher beschreibe ich hier ein fiktives Unternehmen, das die Merkmale aufweist, die ich in einigen Jahren erwarten würde. Auch wenn wir nicht davon ausgehen, dass die Realität genau unserer Vorstellung entsprechen wird, so ist unsere Vision von unserem Ziel doch ein wesentlicher Bestandteil des Verständnisses dessen, was wir zu erreichen versuchen. Um dieses Bild am besten zu vermitteln, schreibe ich über dieses fiktive Unternehmen so, wie es vermutlich in der Wirtschaftspresse präsentiert werden würde.

Während ich die Geschichte erzähle, werde ich Fußnoten setzen, damit Sie zu den späteren Kapiteln springen können, die tiefer in die Aspekte eintauchen, die ich hier nur kurz anspreche. Ich empfehle Ihnen, zunächst die ganze Geschichte zu lesen und erst nach deren Ende zu den späteren Kapiteln weiterzublättern.

Data Mesh in der Praxis

Wir schreiben das Jahr 2022.

Daff hat dank eines konsequenten Fokus auf die User Experience unter Einsatz von Machine Learning ein starkes Wachstum seiner Premium-Abonnenten verzeichnet. Das Unternehmen ist nach wie vor eine der beliebtesten Plattformen, die mithilfe von Daten ein einzigartiges Erlebnis schafft, eine umfangreiche Bibliothek von Inhalten kuratiert und neue und aufstrebende Künstlerinnen und Künstler erreicht. Daff hat sich kontinuierlich weiterentwickelt, indem neue Dienste hinzugefügt und in benachbarte Domänen wie Podcasts, Videos und die Organisation von Live-Events expandiert wurden. Heute ist Daff in fast jedem Land der Welt tätig und verfügt über ein wachsendes Netzwerk lokaler und globaler Geschäftspartner, von Event- und Kunstzentren bis hin zu Workout Platforms.

In den letzten drei Jahren hat Daff die Verwaltung und Nutzung analytischer Daten auf einen Ansatz namens Data Mesh umgestellt. Data Mesh ist ein neuer, skalierbarer Ansatz zur Nutzung von analytischen Daten in großen Unternehmen, der Daten und Business enger als je zuvor zusammenbringt.

Daff setzt ausgefeilte Machine-Learning-Modelle ein, die kontinuierlich Muster in einem vielfältigen und sich ständig weiterentwickelnden Datenbestand innerhalb und außerhalb des Unternehmens auswerten. Das Unternehmen stellt seinen Hörerinnen und Hörern Empfehlungen bereit, die auf ihren Geschmack, ihre Stimmung, ihre Tageszeit und ihren Standort zugeschnitten sind. Mithilfe von Daten unterstützt Daff Künstlerinnen und Künstler mit gezielten Kampagnen, um deren Reichweite zu erhöhen. Mit Datenanalysen, Dashboards, Berichten und Visualisierungen hat Daff das Geschäft jederzeit und in Echtzeit im Blick. Wie Daff seine Daten nutzt, ist nur die Spitze des Eisbergs.

Schauen wir uns mal an, wie Daff das macht.

Eine Kultur der Neugierde und des Experimentierens mit Daten

Eine der bemerkenswertesten Veränderungen bei Daff ist die ausgeprägte Kultur, die es immer wagt zu fragen: »Was wäre, wenn …«: Was wäre, wenn wir etwas ändern würden, um die Dinge nur ein kleines bisschen besser zu machen? Es gibt eine Kultur, die unablässig Experimente durchführt, die Ergebnisse beobachtet, die Daten analysiert, sie interpretiert, daraus lernt und sich anpasst.

Diese Kultur basiert auf einer technischen Grundlage, die es jedem leicht macht, Experimente zu wagen: große Experimente mit angewandtem Machine Learning oder kleine Experimente, bei denen einfach nur die Benutzeroberfläche optimiert wird.

Daff ist in Geschäftseinheiten organisiert, die als Domänen bezeichnet werden. Die Player-Domäne konzentriert sich auf den eigentlichen Musikplayer, der auf mobilen Geräten verwendet wird, die Partnership-Domäne setzt auf eine Zusammenarbeit in Geschäftsfeldern wie Fitnessanwendungen und Kunstveranstaltungen, und die Playlist-Domäne untersucht fortschrittliche Ansätze zur Erstellung von Wiedergabelisten. Jede Domäne kombiniert Softwareentwicklung und fachliche Kompetenzen und ist für die Softwarekomponenten zur Unterstützung der jeweiligen Domäne verantwortlich.

Wenn man sich bei Daff umschaut, stellt man fest, dass jede Domäne ständig zahlreiche Experimente durchführt, um ihre Anwendungen und Dienste zu verbessern. Zum Beispiel experimentieren die Player-Teams ständig mit einer besseren Interaktion mit den Nutzern. Das Partnership-Team experimentiert mit Daten, die von einer Vielzahl externer Quellen wie Workout Platforms, Kunstzentren usw. erfasst werden. Die Playlist-Teams wenden fortgeschrittenes Machine Learning an, um attraktive Musiksammlungen zu kuratieren und zu empfehlen. Und das Artist-Team setzt Machine Learning ein, um neue Künstlerinnen und Künstler zu entdecken, zu überzeugen und aufzunehmen, die normalerweise unentdeckt geblieben wären.

Alle fachlichen Domänen und die mit ihnen zusammenarbeitenden Technologieteams wissen aussagekräftige, vertrauenswürdige und sichere Daten sehr zu schätzen. Und nicht nur das: Jeder erwartet, dass der direkte Zugriff auf Daten im gesamten Unternehmen die Norm ist. Alle wissen, welche Rolle sie dabei spielen, um dies zu ermöglichen. Sie sind alle für die Daten verantwortlich und interessieren sich auch dafür.

In jeder Domäne werden Machine-Learning-Modelle mit Begeisterung immer dann angewendet, wenn ein Feature oder eine Funktionalität durch die Auswertung historischer Daten und Muster umgesetzt werden kann. Die Playlist-Teams verwenden beispielsweise generative Machine-Learning-Modelle, um ausgefallene und wunderschöne Musiksammlungen zu erstellen. Die Sammlungen sind auf verschiedene Aktivitäten ausgerichtet, vom Laufen bis zum konzentrierten Lernen. Das Artist-Team nutzt mehrere Datensätze aus den sozialen Medien und von anderen Agenturen außerhalb von Daff, um aufstrebende Künstlerinnen und Künstler zu erkennen, zu fördern und mit ihrem neuen Publikum zu vernetzen.

Man spürt die Begeisterung für die Datennutzung und das Kennenlernen einer neuen Perspektive, in der man Signale entdecken kann, die für unsere menschlichen Sinne nur ein Rauschen wären.4

Die Datenkultur vor Data Mesh

Diese Kultur steht im krassen Gegensatz zu dem, wie Daff vor drei Jahren war. Datenerhebung, Experimente und Auswertungen waren an ein separates Datenteam ausgelagert worden. Das Datenteam stand unter enormem Druck. Die Domänen hatten kein Vertrauen in die Daten oder konnten die benötigten Daten oft nicht finden. Das Datenteam war ständig damit beschäftigt, die Probleme in der Daten-Pipeline zu lösen, die durch jede noch so kleine Änderung in den Upstream-Anwendungen und ihren Datenbanken verursacht wurden, oder die Anforderungen der ungeduldigen Fachbereiche zu erfüllen, die am besten noch gestern eine Lösung benötigten. Die Domänen selbst hatten keine Verantwortung und kein Interesse daran, dass Daten sowohl einfach verfügbar als auch zuverlässig und nutzbar waren. Die Dauer und die Hindernisse, um an die richtigen Daten zu gelangen, machten es für die Domänen unglaublich schwer, sich an neue Experimente zu wagen.

Der Vergleich der beiden Erfahrungen zeigt, wie weit Daff in den drei Jahren seit der Umstellung auf Data Mesh vorangekommen ist.

Eine enge Partnerschaft zwischen Daten und Machine Learning

Die Kultur des Experimentierens mit Daten scheint einfach zu schön, um wahr zu sein. Um zu sehen, wie sie in der Praxis aussieht, wollen wir die Geschichte eines datenorientierten Features nachvollziehen, an dem Daff kürzlich gearbeitet hat, und die Erfahrungen der beteiligten Personen beleuchten.

Smarte Wiedergabelisten sind ein erfolgreiches Feature der Daff-Plattform. Die Music-Playlist-Domäne hat an mehreren Machine-Learning-Modellen gearbeitet, die Daten aus einer Vielzahl von Quellen miteinander kombinieren, um den Hörern passendere Wiedergabelisten zu empfehlen, je nachdem, wo sie sich befinden, was sie gerade tun, wo ihr Interesse liegt und was der Anlass ist.

Die Machine-Learning-Modelle für Wiedergabelisten nutzen Muster in analytischen Datenprodukten aus einer Vielzahl von Quellen innerhalb des Unternehmens, wie z.B.:

Daten von der

Listener-Domäne: Listener Profiles

,

Listener Social Networks

,

Listener Locations

usw., um den Kontext und die verschiedenen Gruppen von Hörern zu verstehen.

Daten von der

Player-Domäne: Play-Sessions

und

Play-Events

, um das Verhalten und die Vorlieben der Hörer auf ihren Endgeräten zu verstehen.

Daten von der

Music-Album-Domäne: Music Tracks

und

Music Profiles

, um ein besseres Verständnis von den Profilen und Klassifizierungen von Musiktiteln zu erhalten.

Es gibt mehrere trainierte Machine-Learning-Modelle, die smarte Wiedergabelisten erstellen, z.B. Monday Playlists, Sunday Morning Playlists, Focus Playlists usw.

Das Playlist-Team stellt diese ständig verbesserten Zusammenstellungen als Datenprodukte anderen Teams zur Verfügung. Data as a Product ist ein gut etabliertes Konzept, das sich auf Daten bezieht, die nach den etablierten Standards der Datenbereitstellung von Daff geteilt werden. Datenprodukte sind automatisch über das globale Data-Discovery-Tool zugänglich. Sie teilen und garantieren eine Reihe von Service Level Objectives (SLOs), z.B. wie oft jede Playlist aktualisiert wird sowie ihre Genauigkeit und Aktualität. Sie verfügen über eine aktuelle und leicht verständliche Dokumentation. Kurz gesagt, Datenprodukte sind qualitativ hochwertige Daten, die den Nutzern mit den richtigen Zugriffsrechten zur Verfügung stehen, und sie sind leicht zu verstehen und zu nutzen.

Das Player-Team, das sich auf die Präsentation von Inhalten über verschiedene Player-Benutzeroberflächen – wie Handy, Desktop, Auto usw. – konzentriert, gehört zu den Hauptnutzern der Playlist-Datenprodukte. Es liest kontinuierlich die neuesten Wiedergabelisten und präsentiert sie den Hörern.

Das Playlist-Team plant, seine Modelle weiterzuentwickeln, um eine neue Auswahl an Playlists für verschiedene sportliche Aktivitäten zu empfehlen, z.B. Running Playlists, Cycling Playlists und so weiter. Sie müssen vorhandene Daten finden, die Informationen über die Musik enthalten, die die Hörer während ihrer sportlichen Aktivitäten gern gehört haben.

Zunächst geht das Playlist-Team zum Mesh-Discovery-Portal und sucht nach allen Datenprodukten, die etwas mit sportlichen Aktivitäten zu tun haben könnten. Über den Discovery-Mechanismus findet es heraus, dass die Domäne Partnership einige Daten zu diesem Thema enthält. Das Discovery-Tool ermöglicht dem Team, automatisch Zugang zu Dokumentation, Beispielcode und weiteren Informationen über die Datenprodukte zu erhalten. Sie beantragen automatisiert Zugang. Mit den notwendigen Berechtigungen zu den Datenprodukten von Partnership untersuchen sie einige Beispieldatensätze. Sie finden zwar ein paar nützliche Daten über Joint-Members (Mitglieder von Partner-Workout-Platforms), aber keine Informationen über die Musik, die sie auf diesen Plattformen hören oder mögen, wenn sie laufen, Rad fahren oder Yoga machen.

Das Playlist-Team setzt sich mit dem Data Product Owner der Domäne Partnership in Verbindung. Jede Domäne hat einen eigenen Product Owner, der sich um die bereitgestellten Daten der jeweiligen Domäne kümmert. In einem direkten Gespräch teilen sie dem Partnership-Team mit, dass sie Zugriff auf die Musiktitel benötigen, die von Fitnessplattformen während verschiedener Aktivitäten gespielt werden, und auch auf die, die ihre Mitglieder mögen. Dieses Gespräch führt zur Priorisierung der Erstellung von Partner-Playlists-Datenprodukten.

Das fachliche Ziel des Partnership-Teams ist es, durch nahtlose Integration mit Partnerplattformen wie den Workout Platforms und den Zugriff auf die eigene Musik ein besseres Hörerlebnis zu schaffen. Die Erstellung von Datenprodukten für Partner-Playlists steht also im Einklang mit ihrem Geschäftsziel. Das Partnership-Team ist am besten dazu geeignet, diese Datenprodukte zu erstellen. Es arbeitet am engsten mit Partnerplattformen zusammen und kennt deren APIs und den Lebenszyklus dieser APIs, die direkt in die Datenprodukte der Partner-Playlists einfließen.

Dank der Self-Service-Datenplattform, die Daff im Laufe der letzten drei Jahre aufgebaut hat, ist es für das Partnership-Team relativ einfach, neue Datenprodukte zu erstellen. Sie beginnen damit, mit einem der beliebtesten Cycling-and-Workout-Partner zu arbeiten, und nutzen dessen APIs, um auf die Titel zuzugreifen, die ihre Mitglieder gespielt und gut bewertet haben.

Das Partnership-Team nutzt die Werkzeuge der Plattform zur Verwaltung von Datenprodukten, um die Transformationslogik zu erstellen, mit der diese Daten als Datenprodukt in verschiedenen Formaten bereitgestellt werden, zunächst in Form von Delta-Dateien. Um die Integration von Partner-Playlists mit anderen Datenprodukten zu erleichtern, liegt der Schwerpunkt des Transformationscodes auf der Anpassung der Music Track ID an das globale Titel-ID-System, das Daff für alle Datenprodukte verwendet. Innerhalb weniger Stunden haben sie das neue Partner-Playlists-Datenprodukt erstellt, im Mesh deployt und den Playlist-Teams zur Verfügung gestellt, damit sie ihr Experiment fortsetzen können.

In diesem einfachen Szenario kommen einige grundlegende Prinzipien von Data Mesh zum Tragen: Eines ist die dezentrale Domain Ownership5 bezüglich Daten, um eine Trennung zwischen Datennutzern und Datenanbietern zu beseitigen. In diesem Fall kann die Playlist-Domäne direkt mit der Partnership-Domäne zusammenarbeiten, wobei jedes Domänenteam langfristig für die Bereitstellung ihrer Daten (Playlists und Partner-Playlists) verantwortlich ist.

Wir sehen die Kultur und die Technologie, die hinter Data as a Product6 stehen, dem zweiten Prinzip von Data Mesh, in Aktion. Die Teams sind dafür verantwortlich, Daten bereitzustellen, die leicht auffindbar, verständlich, zugänglich und nutzbar sind, sogenannte Datenprodukte. In jedem funktionsübergreifenden Domänenteam gibt es etablierte Rollen wie Data Product Owner, die für die Daten und deren erfolgreiche Bereitstellung verantwortlich sind.

Die Möglichkeit, neue Datenprodukte für Partner-Playlists innerhalb weniger Stunden oder in maximal ein oder zwei Tagen bereitzustellen, und die Möglichkeit, die richtigen Daten zu finden und sie ohne Hindernisse zu nutzen, hängen sämtlich von der Self-Serve Data Platform7 ab. Die Datenplattform stellt funktionsübergreifenden Teams Dienste für die Bereitstellung und Nutzung von Daten zur Verfügung und ebnet den Weg für die effiziente und sichere Erstellung und Bereitstellung von Datenprodukten. Zu den Diensten der Plattform gehören unter anderem die automatisierte Steuerung des Zugriffs, die standardmäßige Verschlüsselung personenbezogener Daten und die Selbstregistrierung aller Datenprodukte mit einem globalen Discovery-Tool.

Daff ist auf bewährte Governance-Policies angewiesen, um Daten sicher und effektiv bereitstellen zu können. Ein Beispiel für eine solche Policy ist eine gemeinsame Vereinbarung darüber, wem welche Daten gehören sollen. In diesem Fall wurde das Partnership-Team zum Eigentümer der Partner-Playlists, da es die Datenquelle am besten kennt und die Beziehungen zu den Partnern pflegt. Das Team kennt die Faktoren, die sich auf die Partnerdaten auswirken, genau. Diese scheinbar einfache und organische Entscheidung wurde auf Grundlage von Heuristiken getroffen, die Daff für die Policy der »langfristigen Verantwortung für Datenprodukte« festgelegt hatte. Eine Gruppe von Domänenvertretern legt die Policies fest, und die Datenplattform automatisiert sie. Dies ist das Prinzip der Federated Computational Governance8 von Data Mesh.

Daff hat dafür einen langen Weg zurückgelegt. Abbildung 1 zeigt diese direkte und dezentralisierte Zusammenarbeit an einem Beispielszenario.

Abbildung 1: Machine-Learning-basierte Erstellung von Wiedergabelisten mit Data Mesh

Drei Jahre zuvor

Das gleiche Szenario hätte vor drei Jahren wochenlange Arbeit, viele Hindernisse und Engpässe sowie mehrere Übergaben zwischen verschiedenen Teams bedeutet. Das hätte wahrscheinlich zu einer unzureichenden Datenqualität geführt. Vor drei Jahren hätte man die Initiative aufgrund des zu erwartenden Zeitaufwands und der vielen Reibungsverluste wahrscheinlich gar nicht erst gestartet, sie eventuell abgebrochen, oder im besten Fall wäre sie wesentlich teurer geworden.

Vor drei Jahren hätte das Playlist-Team das zentrale Machine-Learning-Team bitten müssen, ein neues Modell für Sport-Playlists zu entwickeln und zu trainieren. Die Data Scientists hätten dies unter vielen anderen Machine-Learning-basierten Initiativen im Unternehmen hoch priorisieren müssen. Im günstigsten Fall hätten die Data Scientists dies auch getan und sich dann für die Daten an ein zentrales Data-Lake- oder Data-Warehouse-Team gewendet. Den Zugriff auf die Daten hätten sie dann bei einem zentralen Governance-Team beantragt.

Das hätte nochmals ein paar Tage gedauert. Selbst dann wäre es nicht unwahrscheinlich gewesen, dass die Data Scientists trotz des Auffindens der Daten diese nicht richtig interpretierten. Die Daten wären vermutlich auch veraltet gewesen, da das Partnership-Team viele neue Integrationen vorgenommen hatte, die noch nicht in das zentrale Data Warehouse oder den Data Lake eingeflossen waren. Es wäre nicht verwunderlich gewesen, wenn die Data Scientists solchen Daten misstraut hätten.

Nachdem klar geworden wäre, dass die Data Scientists mehr musikbezogene Daten von Partnern benötigten, hätte das Data-Lake-Team zu dem Data-Engineering-Team gehen müssen, das für Pipelines zuständig war. Dieses Team hätte neue ETL/ELT-Pipelines einrichten müssen, um die Daten von den Integrations-APIs der Partner abzurufen und dem Data Warehouse oder dem Data Lake hinzuzufügen – ein weiteres Backlog, in dem man sich hinten hätte einreihen müssen.

Das zentrale Data-Engineering-Team hätte dann tagelang verhandeln und die für sie völlig neue Partnership-Domäne verstehen müssen, damit sie die Daten aus den Anwendungsdatenbanken in die Pipeline und dann in den Lake übertragen konnten. Sie hätten deren interne Datenbanken verstehen müssen, um etwa die internen Musik-IDs den globalen IDs zuzuordnen. Auch dies hätte wieder etwas gedauert.

Ohne direkte Beteiligung und ohne Verständnis für den Business Case hätte das Partnership-Team wenig Anreize gehabt, die Integration von Musik der Partner9 zu priorisieren und die ETL-Pipelines der Data Engineers zu unterstützen. Die Adhoc-Integrationen hätten tagelang debuggt werden müssen, bis endlich Daten im Data Lake landeten. Aber die Geschichte geht noch weiter.

Die funktional gegliederte Organisationsstruktur und die Technologie von Daff waren für datengestützte Experimente einfach nicht förderlich.10

Abbildung 2 zeigt die Organisationsstruktur und die Architektur von Daff vor Data Mesh. Das Unternehmen wies eine moderne Architektur und Organisationsstruktur auf, da es über gemischte fachliche und technische Entwicklungsteams für autonome Domänen verfügte. Das Daten- und Analyseteam und die Datenarchitektur waren jedoch funktional und zentral organisiert – eine monolithische Architektur auf Basis von Data Lakes und Data Warehouses.

Das zentrale Datenteam und die monolithische Architektur waren angesichts der zunehmenden Zahl von Datenquellen – innerhalb und außerhalb des Unternehmens – und der Vielfalt ihrer Anwendungsfälle zu einem Engpass geworden. Das Datenteam stand unter großem Druck und hatte sich als Reaktion auf das Wachstum von Daff erheblich verlangsamt. Die Rendite der Investitionen war nun auf einem Plateau angelangt.

Man kann sagen, dass die Struktur und die Architektur des Datenteams nicht mehr mit den Zielen und dem Wachstum der Organisation mithalten konnte.11

Abbildung 2: Daffs Organisation und Architektur vor Data Mesh

Die unsichtbare Plattform und die Policies

Mit einem Data Mesh fühlt sich das Sport-Playlist-Szenario für Datennutzer und -anbieter fast magisch an: keine Hindernisse, schnelle ganzheitliche Lösungen, ein Gefühl der gemeinsamen Verantwortlichkeit mit klaren Zuständigkeiten.

Damit dies auch nur im Entferntesten möglich ist, hat Daff eine Reihe von Self-Service-Technologien und Automatisierungen entwickelt, die sich in der Anwendung nativ und fast unsichtbar anfühlen.

Hinter der User Experience der Datenanbieter und Datennutzer, schnell und autonom Daten auszutauschen, verbirgt sich eine Self-Service-Plattform mit entsprechenden Funktionen:

Erstellung, Deployment, Betrieb und Weiterentwicklung von Datenprodukten

In unserem Beispiel ermöglichte die Datenplattform eine reibungslose Erstellung und Weiterentwicklung von Partner-Playlists und Sport-Playlists in kürzester Zeit. Dies umfasste die Integration der Datenquelle, das Erstellen und Testen der Transformationslogik und das Bereitstellen der Daten.

Nutzung von Datenprodukten im Mesh

In unserem Beispiel ermöglicht die Plattform das Suchen und Auffinden von Datenprodukten im gesamten Mesh, den Zugriff auf sie, die Abfrage ihrer Daten, das Abonnieren von Updates und das Verknüpfen und Korrelieren mehrerer Datenprodukte, um neue Playlists zu erstellen.

Diese Funktionen der Plattform sind für die Nutzerinnen und Nutzer (Data Product Developer, Owner und User) optimiert, um den Cognitive Load bei der Bereitstellung von Daten und beim Experimentieren zu minimieren.

Die Optimierung der User Experience für die Nutzer darf für Daff jedoch nicht auf Kosten der Infrastruktur gehen. Während die oben genannten Dienste der Plattform für die optimale Ausgestaltung der User Experience sorgen, kümmert sich der unsichtbare Teil der Plattform, die Infrastruktur-Ebene, die näher an der physikalischen Ebene liegt und weiter vom User entfernt ist, um eine gute Performance und eine optimale Ressourcenauslastung.12 Es unterstützt zum Beispiel:

die effiziente polyglotte Speicherung von Datenprodukten,

die effiziente Query- und Workload-Verarbeitung über Datenprodukte hinweg,

die effiziente Suche und Indizierung sowie

effiziente, minimierte Datenübertragungen.

Die User Experience des Playlist-Teams bei der Verwendung und Kombination mehrerer Datenprodukte, die von verschiedenen Teams stammen, wie Partnerships, Listeners und Music Profiles, hängt auch von einer Reihe globaler Standard-Policies ab, die für alle Datenprodukte gelten:13

Standardisierung von APIs für die Bereitstellung von Daten

Standardisierung von Metadaten, einschließlich SLOs, Dokumentation und Datenmodellierungssprache

Standardisierung der IDs von gemeinsam genutzten Entitäten

Grenzenlose Skalierung mit autonomen Datenprodukten

Data Mesh erfüllt Daffs Wachstumsbestrebungen mit einer skalierbaren organisatorischen und technischen Struktur. Wie Sie am Beispiel der Machine-Learning-basierten Wiedergabelisten gesehen haben, ist die Erstellung neuer Wiedergabelisten oder die Optimierung bestehender Wiedergabelisten einfach eine Frage des Hinzufügens weiterer Datenprodukte und ihrer Verknüpfung, z.B. Running Playlists, Cycling Playlists, Workout Platform X Partner Playlists, Workout Platform Y Partner Playlists usw. Es handelt sich um eine hoch skalierbare Architektur, bei der eine unbegrenzte Skalierung erreicht werden kann, indem weitere gleichwertige Knoten hinzugefügt und miteinander verbunden werden. Datenprodukte werden als Architekturquantum implementiert, d.h. als kleinste Einheit einer Architektur, die unabhängig deployt werden kann und dennoch über alle strukturellen Komponenten verfügt, um ihre Aufgabe zu erfüllen.

Die Architektur stellt sicher, dass jedes Datenprodukt einen Standardsatz von Verträgen für den Zugriff auf und die Bereitstellung von Daten implementiert, sodass jedes Produkt mit anderen Datenquanten im Mesh verbunden werden kann, um Daten und Semantik gemeinsam zu nutzen. Jedes Datenprodukt kapselt seine Transformationslogik und Governance-Policies. Die Architektur verbindet die domänenorientierte organisatorische Autonomie mit einer entsprechenden datenproduktorientierten verteilten Architektur.

Daffs Standardisierung von Datenprodukten hat dem Unternehmen Schnelligkeit und Skalierbarkeit verliehen.14

Der positive Netzwerkeffekt

Der Erfolg von Daff bei der Nutzung von Daten und Analysen lässt sich durch den positiven Netzwerkeffekt zusammenfassen. Dieser entsteht durch die gegenseitige Vernetzung von Domänen, die Datenprodukte austauschen. Je größer das Netzwerk und je mehr Verbindungen hergestellt werden, desto mehr Daten werden zwischen den Domänen ausgetauscht, um Erkenntnisse und Einblicke von hoher Qualität zu generieren, die letztlich das Business verbessern.

Daff hat viel investiert, um seine Data-Mesh-Strategie umzusetzen. Es hat einen organisatorischen und kulturellen Wandel vollzogen und hat mit der Infrastruktur und der Plattform die Grundlage geschaffen. Das Unternehmen hat aber auch genau darauf geachtet, dass sich die Investition durch messbare Erfolge auszahlt.

Extern haben sie durch den Einsatz von Machine Learning und Daten zur Verbesserung des Hörerlebnisses über mehrere Kanäle eine höhere Nutzeraktivität erreicht und die Zahl der aktiven Hörerinnen und Hörer erhöht. Intern wurde die Bearbeitungszeit für den Zugriff auf Daten durch die Beseitigung zentraler und indirekter Flaschenhälse verkürzt. Sie haben das Risiko von Änderungen an den Daten reduziert, indem sie Standardverträge und -schnittstellen für das Auffinden und die Bereitstellung von Datenprodukten geschaffen haben. Sie haben die Zeitverschwendung bei der Entwicklung von Datenprodukten durch die Einführung von Continuous Delivery verringert. Sie haben die Nutzung von Daten im gesamten Unternehmen erhöht, gemessen an der Anzahl der Verbindungen zwischen ihren Datenprodukten. Sie haben die Anzahl der Teams, die datenbasierte Lösungen entwickeln, erhöht, indem sie die Verantwortung für die Daten in jeder Domäne und jedem Team verankert haben. Sie haben die Kosten für Data Ownership und die Erstellung von ganzheitlichen Datenlösungen reduziert, indem sie die Plattformdienste nutzen und sich auf die Developer Experience konzentrieren.

Dies sind einige der Bereiche, in denen sie ihre Data-Mesh-Investitionen messen.15

Warum sollten wir Data Mesh einführen?

Gehen wir noch einmal zurück in das Jahr 2019, das Jahr des Wendepunkts bei Daff.16

In den letzten Jahren hatte Daff erheblich in Datenlösungen wie Data Lakes und Data Warehouses investiert, um große Datenmengen zu speichern. Das Unternehmen hatte ein großes Datenteam unter dem Chief Data Officer aufgebaut, das mit der unternehmensweiten Erfassung, Modellierung und Bereitstellung von Daten sowie der Entwicklung von Analyse- und Machine-Learning-Lösungen für das Unternehmen beauftragt war. Die Organisationsstruktur und das Betriebsmodell, die Daff gewählt hatte, waren damals der Branchenstandard.

In diesem Jahr erkannte Daff, dass die Ziele des Unternehmens im Datenbereich größer waren als die Fähigkeit, sie umzusetzen. Das zentrale Datenteam und die monolithische Architektur waren angesichts der zunehmenden Zahl von Datenquellen – innerhalb und außerhalb des Unternehmens – und der Vielfalt ihrer Anwendungsfälle zu einem Engpass geworden. Das Datenteam stand unter großem Druck und hatte sich als Reaktion auf das Wachstum von Daff erheblich verlangsamt. Die Rendite der Investitionen hatte sich auf einem Plateau eingependelt.

Sie benötigten eine Veränderung, und da entdeckten sie Data Mesh.

Vor der Einführung von Data Mesh untersuchte Daff die Übereinstimmung zwischen dem Unternehmen (mit seinen Zielen, der Organisation und deren technischen Möglichkeiten) und Data Mesh.

Die erwarteten Ergebnisse von Data Mesh waren auf die Lösung ihrer Probleme ausgerichtet:

Schnelles Wachstum und zunehmende Komplexität

Sie sind schnell gewachsen, ihr Geschäft wurde immer komplexer, und die Umsetzung ihrer vielfältigen und ehrgeizigen analytischen Ziele wurde immer langsamer. Data Mesh wurde entwickelt, um Mehrwert aus Daten zu ziehen und die Agilität in komplexen und großen Umgebungen zu erhalten.

Skalierbare Wertschöpfung aus Daten

Sie hatten viel in ihre technischen Grundlagen für Daten und Analysen investiert, doch die Ergebnisse waren nicht zufriedenstellend. Data Mesh macht Daten kosteneffizienter nutzbar, indem es eine größere Anzahl von Softwareentwicklern auch zu Datenentwicklern und -nutzern macht.

Die Ziele von Data Mesh und die Auswirkungen klangen vielversprechend. Es stellte sich jedoch die Frage, ob es damals die richtige Wahl war.

Data Mesh war mit dem bestehenden domänenorientierten Organisationsmodell von Daff kompatibel. Es war eine Erweiterung des bestehenden Designs und der Architektur. Data Mesh baute auf einem dezentralen Modell der Data Ownership auf, das die bestehenden Entwicklungsteams einfach erweiterte.

Tatsächlich war das zentrale Datenteam eines der letzten funktionalen Teams, was im Widerspruch zur damaligen domänenorientierten Organisation stand. In Anbetracht der Bestrebungen, jede Domäne datenorientiert zu gestalten und dort intelligente Entscheidungen zu treffen, war es sinnvoll, die Verantwortung für Daten und Analysen auf die Domänen zu übertragen. Das Unternehmen arbeitete bereits mit BizDevOps-Teams, die auf die jeweilige Fachlichkeit ausgerichtet waren. Die Erweiterung dieser Teams um Datenfunktionen und -verantwortlichkeiten schien daher eine natürliche Entwicklung zu sein, um den Zugang zu und die Nutzung von Daten wirklich zu demokratisieren. Natürlich musste auch die Governance diesen organisatorischen Strukturen folgen.

Sie wussten, dass sie als Vorreiter bei der Einführung von Data Mesh ihre Zeit und Ressourcen in den Aufbau der grundlegenden Technologie und der entsprechenden Plattformen investieren mussten. Daff verstand sich als Softwareunternehmen, in dessen Mittelpunkt die Technologie stand, die nicht nur das Kerngeschäft ermöglichte, sondern es auch gestaltete und erweiterte. Sie scheuten nicht vor technischen Investitionen zurück.17

Daff erkannte, dass die Einführung eines neuen Ansatzes für Daten, der grundlegende Änderungen an der Kultur, der Organisationsstruktur, der Rollenverteilung, der Architektur und der Technologie beinhaltete, eine mehrjährige Transformation sein würde.

Daher wurde die Einführung von Data Mesh in den nächsten drei Jahren schrittweise vorangetrieben. In dieser Zeit setzte Daff sorgfältig ausgewählte datenbasierte Anwendungsfälle um, transformierte die Organisation und etablierte die Plattform und die Technologie.18

Der Weg in die Zukunft

Trotz der geschäftlichen, kulturellen und technischen Erfolge hat Daff noch einen weiten Weg vor sich. Die Einführung von Data Mesh hat die Phasen der Exploration, in denen die Arbeitsweisen und die grundlegende Plattform festgelegt wurden, sicherlich hinter sich gelassen. Sie haben das Mesh auf viele ihrer Domänen expandiert. Um jedoch weiterhin Wert aus dem Mesh zu extrahieren, müssen sie kontinuierlich optimieren und verfeinern. Sie müssen auch Nachzügler in das Mesh bringen und ihre Plattformfunktionen auf Domänen ausweiten, die Altsysteme haben oder noch nicht als domänenorientiertes, funktionsübergreifendes Team arbeiten.

Dies ist der erwartete Verlauf der Einführung von Data Mesh: ein evolutionärer Pfad mit sich wiederholenden Zyklen von Exploration, Expansion und Extraktion.19

Ich hoffe, die Geschichte über Data Mesh bei Daff hat Sie dazu ermuntert, weiterzulesen, sodass wir uns im nächsten Kapitel wiedersehen.

TEIL I

Was ist Data Mesh?

Die einzige Einfachheit, der man vertrauen kann, ist die Einfachheit, die man auf der anderen Seite der Komplexität findet.

– Alfred North Whitehead

Wenn man sich die Umsetzung von Data Mesh anschaut, wie im Beispiel von Daff, Inc. zu Beginn des Buchs, bekommt man einen Eindruck von der technischen und organisatorischen Komplexität, die für die Implementierung erforderlich ist. Wir könnten wahrscheinlich eine ganze Weile über diese komplexen und komplizierten Teile der Data-Mesh-Implementierung sprechen. Um Data Mesh zu verstehen, möchte ich es stattdessen ausgehend von seinen Grundprinzipien diskutieren. Sobald wir die wesentlichen Elemente verstanden haben, können wir sie von Grund auf neu zusammensetzen, um die Implementierungen zu erstellen.

Auf diese Weise werde ich Ihnen in diesem Teil des Buchs Data Mesh vorstellen, wobei ich mich auf die Grundprinzipien und ihre Wechselwirkung untereinander konzentriere.

Bei diesen Grundprinzipien handelt es sich um Leitlinien und Werte, die das Verhalten, die Struktur und die Entwicklung der Implementierungen bestimmen. Meine Absicht für diesen Teil des Buchs ist es, eine Grundlage zu schaffen, die eine Basis für zukünftige Verfeinerungen von Praktiken und Technologien bietet.

Man sollte bedenken, dass dieses Buch zu einer Zeit geschrieben wird, in der sich Data Mesh zweifellos noch in der Innovations- und Early-Adopter-Phase des Innovationszyklus befindet.1 Es ist in einer Phase, in der risikofreudige Innovatoren es aufgegriffen haben und bereits dabei sind, Tools und Technologien dafür zu entwickeln, und prominente Early Adopters passen ihre Datenstrategie und -architektur nach dem Vorbild von Data Mesh an. Daher finde ich es angemessen, zunächst die Prinzipien und den architektonischen Stil von Data Mesh zu erläutern und die spezifischen Implementierungsdetails und Technologien im Laufe der Zeit zu verfeinern und zu entwickeln. Ich gehe davon aus, dass jeder spezifische Implementierungsentwurf oder Tooling-Vorschlag zu dem Zeitpunkt, zu dem Sie dieses Buch lesen werden, bereits überholt sein wird.

Ich habe diesen Teil in fünf Kapitel gegliedert. Kapitel 1, »Data Mesh im Überblick«, gibt Ihnen einen kurzen Überblick über die vier Grundprinzipien und ihr Zusammenspiel. Die folgenden Kapitel konzentrieren sich dann jeweils auf eines der Prinzipien: Kapitel 2, »Das Prinzip Domain Ownership«, Kapitel 3, »Das Prinzip Data as a Product«, Kapitel 3, »Das Prinzip Self-Serve Data Platform«, und Kapitel 5, »Das Prinzip Federated Computational Governance«.

Die Reihenfolge, in der die Prinzipien eingeführt werden, ist wichtig, da sie aufeinander aufbauen. Die domänenorientierte Aufteilung von Data Ownership und Architektur ist das Herzstück des Ansatzes. Alles andere ergibt sich daraus. Data Mesh besteht aus allen vier Prinzipien.

Ich schlage vor, dass alle, die daran interessiert sind, Data Mesh zu verstehen oder anzuwenden, diesen Teil lesen. Ich hoffe, dass das, was dieser Teil bietet, jedes Gespräch über Data Mesh bereichern wird.

KAPITEL 1

Data Mesh im Überblick

»Think in simples«, wie mein alter Meister zu sagen pflegte – das bedeutet, das Ganze in einfachsten Worten auf seine Teile zu reduzieren und zu den Grundprinzipien zurückzukehren.

– Frank Lloyd Wright

Data Mesh ist ein dezentraler soziotechnischer Ansatz für die Bereitstellung, den Zugriff und die Verwaltung von analytischen Daten in komplexen und großen Umgebungen – innerhalb eines Unternehmens oder organisationsübergreifend.

Data Mesh ist ein neuer Ansatz für die skalierbare Beschaffung, Verwaltung und den Zugriff auf Daten für analytische Anwendungsfälle. Diese Art von Daten bezeichnen wir als analytische Daten. Analytische Daten werden für Voraussagen oder Diagnosen verwendet. Sie bilden die Grundlage für Visualisierungen und Berichte, die Einblicke in das Unternehmen geben. Sie werden verwendet, um Machine-Learning-Modelle für fachliche Entscheidungen zu trainieren. Sie sind die wesentliche Voraussetzung dafür, dass Unternehmen weg von Intuition und Bauchgefühl hin zu objektiven und datengestützten Entscheidungen gelangen. Analytische Daten sind die Grundlage für die Software und die Technologie der Zukunft. Sie ermöglichen einen technologischen Wandel von regelbasierten Algorithmen, die von Menschen entwickelt wurden, hin zu datenbasierten Machine-Learning-Modellen. Analytische Daten werden zu einer immer wichtigeren Komponente der Technologielandschaft.

Der Begriff Daten bezieht sich in diesem Buch, wenn nicht anders angegeben, immer auf analytische Daten. Analytische Daten werden für die Erstellung von Berichten und für das Training von Machine-Learning-Modellen genutzt.

Ergebnisse

Um aus Daten in komplexen und großen Organisationen einen Mehrwert erzielen zu können, zielt Data Mesh darauf ab, die folgenden Ergebnisse zu erreichen:

Auf Veränderungen reagieren: Komplexität, Volatilität und Ungewissheit.

Agilität trotz Wachstum erhalten.

Das Kosten-Nutzen-Verhältnis von Daten und Investitionen verbessern.

1

Veränderungen

Data Mesh bringt mehrdimensionale technische und organisatorische Veränderungen gegenüber früheren Ansätzen für analytisches Datenmanagement mit sich.

Abbildung 1-1 fasst die Veränderungen im Vergleich zu früheren Ansätzen zusammen.

Data Mesh erfordert einen grundlegenden Wandel in den Annahmen, der Architektur, den technischen Lösungen und der sozialen Struktur unserer Organisationen in der Art und Weise, wie wir analytische Daten verwalten und nutzen:

Organisatorisch

gesehen, erfolgt eine Veränderung von einer zentralen Data Ownership durch Spezialisten, die auch die Datenplattform betreiben, hin zu einem dezentralen Modell, das die Verantwortung für die Daten in die Domänen zurückverlagert, aus denen sie stammen oder in denen sie verwendet werden.

Architektonisch

gesehen, erfolgt eine Veränderung von der Speicherung von Daten in monolithischen Data Warehouses und Data Lakes hin zur Verknüpfung von Daten über ein verteiltes Mesh von Datenprodukten, auf die über standardisierte Protokolle zugegriffen werden.

Technologisch

gesehen, erfolgt eine Veränderung von Lösungen, bei denen die Daten als Nebenprodukt der Pipelines betrachtet werden, hin zu Lösungen, die die Daten und den Code als eine zusammengehörige autonome Einheit verstehen.

Operativ

gesehen, erfolgt eine Veränderung von einem zentralisierten, operativen Top-down-Modell mit menschlichen Eingriffen hin zu einem föderalen Modell, bei dem automatisierte Policies in das Mesh eingebettet sind.

Konzeptionell

gesehen, erfolgt eine Veränderung unseres Wertesystems weg von Daten als Assets, die gesammelt werden, hin zu Daten als Produkte, die internen und externen Datennutzern zur Verfügung stehen und sie glücklich machen.

Infrastrukturell

gesehen, erfolgt eine Veränderung von zwei getrennten und kaum integrierten Infrastrukturdiensten (einmal für Datenanalysen und einmal für operative Systeme) hin zu einer integrierten Infrastruktur für sowohl operative als auch analytische Systeme.

Abbildung 1-1: Dimensionen der Veränderung

Seit der Einführung von Data Mesh in meinem ursprünglichen Blogpost (https://oreil.ly/1deXz) (freundlicherweise gehostet von Martin Fowler (https://oreil.ly/ybdAb