Data Mesh

Book description

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.

Table of contents

  1. Cover
  2. Titel
  3. Impressum
  4. Widmung
  5. Inhalt
  6. Vorwort
  7. Vorbemerkung der Übersetzer
  8. Einleitung
  9. Prolog: Fallstudie
  10. Teil I Was ist Data Mesh?
    1. 1 Data Mesh im Überblick
    2. Ergebnisse
    3. Veränderungen
    4. Prinzipien
    5. Domain Ownership
    6. Data as a Product
    7. Self-Serve Data Platform
    8. Federated Computational Governance
    9. Zusammenspiel der Prinzipien
    10. Data Mesh kurz erklärt
    11. Daten
    12. Operative Daten
    13. Analytische Daten
    14. Entstehungsgeschichte
    15. 2 Das Prinzip Domain Ownership
    16. Domain-driven Design
    17. Strategisches Design
    18. Archetypen von Domänendaten
    19. Quellenorientierte Domänendaten
    20. Aggregierte Domänendaten
    21. Konsumentenorientierte Domänendaten
    22. Einführung von Domain Ownership
    23. Verantwortung wandert flussaufwärts
    24. Verknüpfung von Modellen
    25. Mythos Single Source of Truth
    26. Daten-Pipelines als Implementierungsdetail
    27. Zusammenfassung
    28. 3 Das Prinzip Data as a Product
    29. Product Thinking
    30. Grundlegende Usability-Attribute von Datenprodukten
    31. Einführung von Data as a Product
    32. Domänen verantworten Datenprodukte
    33. Eine neue Sprache
    34. Daten als Produkt statt als Asset
    35. Vertraue, aber prüfe nach
    36. Daten und Logik als Einheit
    37. Zusammenfassung
    38. 4 Das Prinzip Self-Serve Data Platform
    39. Data-Mesh-Plattform im Vergleich
    40. Autonome domänenorientierte Teams als Zielgruppe
    41. Autonome und interoperable Datenprodukte als Kernkonzept
    42. Operative und analytische Funktionen in einer integrierten Plattform
    43. Generalisten als Hauptnutzende
    44. Dezentrale Technologien
    45. Domänenagnostisch
    46. Platform Thinking
    47. Wertschöpfung durch autonome Teams
    48. Wertschöpfung mit autonomen und interoperablen Datenprodukten
    49. Reduktion des Cognitive Load
    50. Skalierung der Bereitstellung von Daten
    51. Förderung einer Innovationskultur
    52. Einführung einer Self-Serve Data Platform
    53. API first
    54. Optimierung für Generalisten
    55. Simplify
    56. High-Level-APIs für Datenprodukte
    57. Nutzerorientierung statt Feature-Orientierung
    58. Klein anfangen und mitwachsen
    59. Zusammenfassung
    60. 5 Das Prinzip Federated Computational Governance
    61. Systems Thinking
    62. Gleichgewicht zwischen Autonomie und Interoperabilität
    63. Dynamische Topologie als Standardzustand
    64. Automatisierung und verteilte Architektur
    65. Föderalismus
    66. Föderales Team
    67. Leitlinien
    68. Policies
    69. Anreize
    70. Automatisierung
    71. Standards als Code
    72. Policies als Code
    73. Automatisierte Tests
    74. Automatisiertes Monitoring
    75. Einführung von Federated Computational Governance
    76. Delegation der Verantwortlichkeit an Domänen
    77. Integration der Policy-Ausführung in jedes Datenprodukt
    78. Automatisierung und Monitoring der Policies
    79. Bestimmung von Polysemen
    80. Messung des Netzwerkeffekts
    81. Mut zu Veränderung
    82. Zusammenfassung
  11. Teil II Warum Data Mesh?
    1. 6 Der Wendepunkt
    2. Die großen Erwartungen
    3. Die große Kluft
    4. Skalierung: Begegnung einer neuen Art
    5. Nichts ist so beständig wie der Wandel
    6. Diskrepanz zwischen Investition und Rendite
    7. Zusammenfassung
    8. 7 Nach dem Wendepunkt
    9. Auf Veränderungen angemessen reagieren
    10. Alignment von Fachlichkeit, Technologie und analytischen Daten
    11. Integration der operativen und analytischen Welt
    12. Dezentralisierung von Datenänderungen
    13. Beseitigung unbeabsichtigter Komplexität
    14. Agilität trotz Wachstum
    15. Beseitigung zentralisierter und monolithischer Komponenten
    16. Reduzierung des Koordinierungsaufwands von Pipelines
    17. Reduzierung des Koordinationsaufwands für Data Governance
    18. Förderung der Autonomie
    19. Verbesserung des Kosten-Nutzen-Verhältnisses
    20. Komplexitätsreduktion durch die Datenplattform
    21. Product Thinking überall
    22. Organisationsübergreifender Datenzugriff
    23. Zusammenfassung
    24. 8 Vor dem Wendepunkt
    25. Evolution der analytischen Datenarchitekturen
    26. Erste Generation: Data-Warehouse-Architektur
    27. Zweite Generation: Data-Lake-Architektur
    28. Dritte Generation: multimodale Cloud-Architektur
    29. Eigenschaften der analytischen Datenarchitektur
    30. Monolithisch
    31. Zentralisiert
    32. Technologieorientiert
    33. Zusammenfassung
  12. Teil III Wie entwirft man eine Data-Mesh-Architektur?
    1. 9 Logische Architektur
    2. Schnittstellen für die Bereitstellung analytischer Domänendaten
    3. Design der operativen Schnittstelle
    4. Design der analytischen Datenschnittstelle
    5. Domänenübergreifende Abhängigkeiten von Analysedaten
    6. Datenprodukt als Architekturquantum
    7. Strukturelle Komponenten eines Datenprodukts
    8. Bereitstellung und Konsum von Daten
    9. Discovery- und Observability-APIs
    10. Die drei Ebenen der Datenplattform
    11. Dateninfrastruktur-Ebene
    12. Datenprodukt-Ebene
    13. Mesh-Ebene
    14. Beispiel
    15. Eingebettete automatisierte Policies
    16. Datenprodukt-Sidecar
    17. Datenprodukt-Container
    18. Control-Port
    19. Zusammenfassung
    20. 10 Datenplattform
    21. Entwurf der Plattform anhand von User Journeys
    22. User Journey der Data Product Developer
    23. Incept, Explore, Bootstrap, Source
    24. Build, Test, Deploy, Run
    25. Maintain, Evolve, Retire
    26. User Journey der Data Product Consumer
    27. Incept, Explore, Bootstrap, Source
    28. Build, Test, Deploy, Run
    29. Maintain, Evolve, Retire
    30. Zusammenfassung
  13. Teil IV Wie entwirft man Datenprodukte?
    1. 11 Entwurf eines Datenprodukts anhand von Affordances
    2. Datenprodukt-Affordances
    3. Merkmale einer Datenproduktarchitektur
    4. Der Einfluss von komplexen adaptiven Systemen auf den Entwurf
    5. Emergentes Verhalten aus einfachen lokalen Regeln
    6. Kein zentraler Koordinator
    7. Zusammenfassung
    8. 12 Daten konsumieren, transformieren und bereitstellen
    9. Daten bereitstellen
    10. Anforderungen der Datennutzer
    11. Entwurfseigenschaften für das Bereitstellen von Daten
    12. Entwurf
    13. Daten konsumieren
    14. Archetypen von Datenquellen
    15. Lokalität des Datenkonsums
    16. Entwurf
    17. Daten transformieren
    18. Programmatische vs. nichtprogrammatische Transformation
    19. Datenflussbasierte Transformation
    20. Machine Learning als Transformation
    21. Zeitabhängige Transformation
    22. Entwurf
    23. Zusammenfassung
    24. 13 Daten finden, verstehen und kombinieren
    25. Daten finden und verstehen
    26. Gefunden werden dank Selbstregistrierung
    27. Finden des globalen URI
    28. Semantische und syntaktische Modelle verstehen
    29. Vertrauen schaffen mit Datengarantien
    30. Untersuchung der Form von Daten
    31. Lernen mit Dokumentation
    32. Entwurf
    33. Daten kombinieren
    34. Anforderungen
    35. Traditionelle Ansätze
    36. Entwurf
    37. Zusammenfassung
    38. 14 Daten verwalten, regeln und beobachten
    39. Lebenszyklus verwalten
    40. Entwurf
    41. Manifest
    42. Daten regeln
    43. Entwurf
    44. Standardisierte Policies
    45. Integration von Daten und Policies
    46. Verknüpfung von Policies
    47. Daten beobachten
    48. Entwurf
    49. Zusammenfassung
  14. Teil V Wie führt man Data Mesh ein?
    1. 15 Strategie und Umsetzung
    2. Sollten Sie Data Mesh schon jetzt einführen?
    3. Data Mesh als ein Teil der Datenstrategie
    4. Data Mesh Execution Framework
    5. Fachlich getriebene Umsetzung
    6. Iterative Ende-zu-Ende-Umsetzung
    7. Evolutionäre Umsetzung
    8. Zusammenfassung
    9. 16 Organisation und Unternehmenskultur
    10. Veränderungen
    11. Kultur
    12. Werte
    13. Anreize
    14. Intrinsische Motivation
    15. Extrinsische Motivation
    16. Struktur
    17. Annahmen über die Organisationsstruktur
    18. Zuschnitt von Datenprodukten
    19. Menschen
    20. Rollen
    21. Weiterbildung
    22. Prozess
    23. Wesentliche Prozessänderungen
    24. Zusammenfassung
  15. Fußnoten
  16. Index
  17. Über die Autorin
  18. Über die Übersetzer
  19. Kolophon

Product information

  • Title: Data Mesh
  • Author(s): Zhamak Dehghani
  • Release date: January 2023
  • Publisher(s): dpunkt
  • ISBN: 9783960092070