Lange Zeit wichen Architekturen von Analytics Systemen stark von modernen Software-Architekturen ab. Während die letzten Jahre oft von Domain Driven Design die Rede war und immer mehr Monolithen in Microservices zerschlagen wurden, blieben Analytics Plattformen wie Data Lake und Data Warehouse weiterhin schwerfällig. Doch nun ist auch hier die Rede von Data Mesh und Data Products. Doch inwiefern unterscheiden sich diese Konzepte nun eigentlich noch und was ist der Unterschied zwischen Microservice und Data Product? Werden hier nicht doch ähnliche Frameworks und Architekturpatterns benötigt? Diese Einordnung soll dieser Vortrag bieten und ein Beispiel bringen, wie eine noch engere Verzahnung im Unternehmen erfolgen kann und somit echte Mehrwerte für Ihre IT-Landschaften schaffen kann.

1. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design 1
Rücken Analytics und SD nun
doch näher zusammen?
21.11.2023
Fabian Hardt
DATA MESH UND
DOMAIN DRIVEN DESIGN

2. © OPITZ CONSULTING 2023 / Öffentlich
AGENDA
Data Mesh und Domain Driven Design 2
MOTIVATION
01 DOMAIN DRIVEN DESIGN /
MICROSERVICES
02 IDEEN /
HERAUSFORDERUNGE
N
04
DATA MESH
03
ZUSAMMENFASSUNG
05

3. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design
MOTIVATION
01
3

4. © OPITZ CONSULTING 2023 / Öffentlich
ARCHITEKTUREN AKTUELLER DATENPLATTFORMEN –
MONOLITHIC DATA SILOS
 Problem: Data Swamp / Datensumpf
 Data Lakes
 End of Support (Hadoop, etc.)
 Betrieb sehr complex
 Extrem breites Wissen nötig
 Wenig agil / schlechte “time to market”
 Mangeldes “Dateneigentum”
 Nachlassende / schlechte Datenqualität
 Steigende Kosten
 Fehlende Katalogisierung
 Enterprise Governance
„Data is like garbage. You’d better know
what you are going to do with it before you
collect it.“ (Mark Twain)
Data Mesh und Domain Driven Design 4

5. © OPITZ CONSULTING 2023 / Öffentlich
MOTIVATION
Data Mesh und Domain Driven Design 5
 Zentrale Data Teams zu langsam – können
nicht alle analytischen Fragestellungen schnell
genug beantworten
 Bottleneck
 Fehlende Autonomie
 Wofür geht die Zeit drauf?
 Technik: Fix broken Pipelines – Changes in
Source DB
 Nur der Rest der Zeit: Verstehen der
Fachdaten – Bau neuer Pipelines
Quelle: https://www.datamesh-architecture.com/

6. © OPITZ CONSULTING 2023 / Öffentlich
WAS FEHLT DER AKTUELLEN
ANALYSTICS WELT?
Data Mesh und Domain Driven Design 6
 Schnelle “time to market” wird immer wichtiger
 Klassische Softwareentwicklung zeigt wie es gehen
kann
 CI/CD, Containerization, hoher Grad der
Automatisierung
 Abteilungen sind oft unzufrieden, weil das BI-Team
mit der Umsetzung nicht hinterherkommt
 Abteilungen wollen Self-Service Angebote
 Wichtig um „Schatten IT“ zu vermeiden
 Schnellere / agileres Vorgehen durch
Dezentralisierung von Systemen
 Data Plattform vs. Integration Plattform
 Wachsen immer weiter zusammen
 Viele Gemeinsamkeiten
Software Development vs. Analytics?

7. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design
SOFTWARE DEVELOPMENT
 Domain Driven Design
 Microservices
02
7

8. © OPITZ CONSULTING 2023 / Öffentlich
WE LIVE IN A „DECENTRALIZE-ERA“!
Data Mesh und Domain Driven Design
Centralized
STATIC
ON-PREM
MONOLITH
VIRTUAL MACHINES
MANUAL CHANGE PROCESS
Decentralized
DYNAMIC
CLOUD / MULTI-CLOUD
MICROSERVICES / SERVERLESS
CONTAINERS, KUBERNETES
AUTOMATED CI/CD TOOL CHAIN
# Services & APIs
CONTROL AND VISIBILITY
Connectivity is the Backbone of Data-driven Organizations …
8

9. © OPITZ CONSULTING 2023 / Öffentlich
WAS IST EINE PRODUKTORIENTIERTE APPLIKATIONS-
ARCHITEKTUR?
Data Mesh und Domain Driven Design
DIGITAL
PRODUCT
Digital
Product
Digital
Product
Business Domain
Shared Platforms
Shared Services (Foundation) incl. integration platform
Hybrid, flexible infrastructure incl. Cloud Services
Standard
(On-Prem)
Business Domain
Business Domain
Digital Product
Standard
(On-Prem)
SaaS-Cloud
Standard
SaaS
Digital
Product
Domains
Products
Platforms
9

10. © OPITZ CONSULTING 2023 / Öffentlich
DOMAIN DRIVEN DESIGN
Data Mesh und Domain Driven Design 10
 Fokus auf (Kern-)Fachlichkeit
 Saubere Analyse, gemeinsam mit Fachexperten
 Einheitliche Sprache, Nutzung von Fachtermini
 Reduktion von Komplexität
 Modell der realen Domäne erstellen
 Diagramme oder auch Text, Abstrahiert die
komplexe Fachlichkeit
 Von IT und Fachexperten lesbar und verständlich
 Universelle Sprache finden und verwenden
 Die Sprache der Fachexperten sollte analysiert und
verstanden werden
 Sollte Einzug ins Anforderungsdokument finden,
sowie Modelle und Code
Sales
HR
Portfolio
Financial
Marketing
The introduction of DDD requires
cultural and structural
change!

11. © OPITZ CONSULTING 2023 / Öffentlich
BUSINESS DOMAINS
Data Mesh und Domain Driven Design 11
 Domain Driven Design (DDD) als Basis
 Lose Kopplung zwischen Systemen
 Änderungen an Modulen sollen möglichst
wenig Auswirkungen auf andere Module
haben
 Stellt die Domäne in den Mittelpunkt der
Modellierungs-/Architekturarbeit
 Oftmals im Microservice-Umfeld –
klassische Softwareentwicklung
 Domäne
 Stellt die Formalität/technische Logik eines
Geschäftsbereichs dar
 HR-Abteilung, CRM-Abteilung, SCM, etc.

12. © OPITZ CONSULTING 2023 / Öffentlich
 Bekannt von den großen Hyperscalern
 Einfach zu bedienende und gut dokumentierte
Software
 Riesige Anzahl an Kunden, die diese Dienste
nutzen und mieten können
DIGITALE PRODUKTE
Data Mesh und Domain Driven Design 12
 Ein Produkt muss relevant für das Kerngeschäft sein und braucht ein Werteversprechen
 Nutzer sollten einen klaren Nutzen für dieses Produkt haben
 Produkte brauchen eine klare “Ownership”
 Verschiedene Arten digitaler Produkte in modernen IT-Umgebungen (digitale Ökonomien)
Software as a Service
 Bekannt vom “Data Mesh” Konzept – in modernen
datengetribenen Unternehmen
 Der “Producer” bietet seine Daten als Produkt über
eine definierte Schnittstelle an
 Bringt Prinzipien von Microservices in Analytics
Abteilungen
Data products
 Schnittstelle, die ein Stück Logik als ein Service
(Produkt) anbietet
 Sorgfältig designte Schnittstelle mit festem
“Contract”
 Kann über eine API-Plattform bereitgestellt
werdem
 Beispiele: REST, SOAP, gRPC, GraphQL
API product

13. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design
DATA MESH
 Grundlagen
 Data Products
 Data Contract
03
13

14. © OPITZ CONSULTING 2023 / Öffentlich
SOFTWARE VS. ANALYTICS
TECHNISCHER BLICK
Data Mesh und Domain Driven Design 14

15. © OPITZ CONSULTING 2023 / Öffentlich
AKTUELLE „PAIN POINTS“
Data Mesh und Domain Driven Design 15
Qualität
Automatisierte Tests,
Automatisiertes
Deployment
Monolith
Aktuell kaum Entkopplung
von Datentöpfen oder
Systemen
Governance
Oft zu wenig Überblick über
vorhandenes + Qualität
Automatisierung
Durch fehlende Automatisierung
ist keine moderne Self-Service
Plattform vorhanden
Zentrale Datenhaltung
Striktes Festhalten an Enterprise
Datenmodell
Bottleneck
Zentrale IT- / Analytics Abteilung ist das
Bottleneck in der Entwicklung

16. © OPITZ CONSULTING 2023 / Öffentlich
DATA MESH „BRING DOMAIN
THINKING TO THE DATA WORLD“
Data Mesh und Domain Driven Design
 2019 von Zhamak Dehghani geprägt
 Kern-Prinzipien:
 “Domain Ownership”
 Daten als Produkt
 Self-Service Infrastruktur Plattform
 Federated Governance
16

17. © OPITZ CONSULTING 2023 / Öffentlich
DATA PRODUCTS
Data Mesh und Domain Driven Design 17
 Sehr große Ähnlichkeit mit Microservices (moderne Softwareentwicklung – Bsp.: API-Produkt)
 Operationale Applikation vs. Analytische Applikation

18. © OPITZ CONSULTING 2023 / Öffentlich
ZIEL - INTUITIVE DATENPRODUKTE
GESCHÄFTSENTSCHEIDUNGEN RICHTIG ZU UNTERSTÜTZEN
Data Mesh und Domain Driven Design
 Eigenschaften eines Data Products
 User Experience (UX)
 Vertrauen in die Daten
 Input ports: Verbindung zu Operationalen
Daten und anderen Data Products
 Output ports: Stellen Data Sets bereit
 Output ports sind mit einem Data contract
versehen
 Ziel: Einfach Nutzbarkeit
Für Data contracts, nutzen wir Data contract first
Ansatz, analog zu APIs!
18

19. © OPITZ CONSULTING 2023 / Öffentlich
DATA PRODUCT
Data Mesh und Domain Driven Design 19
 Versuch Standards zu definieren
 https://dataproduct-specification.com/
 https://datacontract.com/
 Orientiert sich an Softwareentwicklung – Begriffe
„Output Port“ und „Input Port“
 Nah an der OpenAPI Spec
 Beispiele für Data Products
 API-Service
 Zentral über API-Plattform zur Verfügung gestellt
 Events
 Kafka Topics, etc.
 Einfachere Schnittstellen
 Dateibasiet, Datenbankview, …
 Discoverable: Muss leicht zu finden sein
(Data Catalog)
 Addressable: Muss über einen definierten
Weg zugreifbar sein (Data Contracts)
 Trustworthy: Produkte müssen Qualitäts- und
Servicestandards erfüllen
 Secure: Feingrannulare Access Policies für die
Daten sollen definiert sein
 Interoperable: Produkte sollten Standards
folgen und Schnittstellen zum suchen bieten
 Self-describing: Produkt muss Ein- und
Ausgangsports sowie eine aktualisierte
Dokumentation enthalten.
DATSIS PRINCIPLES

20. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design
IDEEN / HERAUSFORDERUNGEN
 Plattformdesign
 Data Product Interaction
 Federated Data Governance
04
20

21. © OPITZ CONSULTING 2023 / Öffentlich
DIGITAL PLATFORMS – DIE GRUNDLAGE FÜR ERFOLGREICHE
DIGITALE PRODUKTE
Data Mesh und Domain Driven Design
 Eigenschaften von digitalen Plattformen:
 Fokus auf DX (Developer Self-Service)
 Sollte erweiterbar sein
 Domänen unabhängiges Design und Organisation
 ”Owner“ ist ein dediziertes Plattform-Team
 Plattform-Team ist verantwortlich für
 Wartung (Patching, Upgrade, etc.)
 Onboarding und Enabling der Domänen-Teams
 Erweiterungen (New features, increasing DX, etc.)
 Examples:
 API Plattform
 Data Plattform
 Developer Plattform
21

22. © OPITZ CONSULTING 2023 / Öffentlich
PLATTFORM
Data Mesh und Domain Driven Design 22
 Modern
 Erweiterbar
 Self-Service
 Klare Regeln / Contracts vorausgesetzt
 Zentrale Dienste
 Kollaboration
 CI/CD Plattform / GIT
 Monitoring – 360 Grad Blick
 Data Catalog
 AuthN / AuthZ / Security Baseline

23. © OPITZ CONSULTING 2023 / Öffentlich
DATA CATALOG /
MARKETPLACE
Data Mesh und Domain Driven Design 23
 Data Catalog übernimmt eine Schlüsselrolle in
Data Mesh Projekten
 Automatisierte Entdeckung / Verwaltung von Data
Products
 Kann Zusammenarbeit zwischen Teams und
Domains fördern
 Vergleiche Ziele DDD – einheitliche Sprache
 Data Governance
 Datenschutz
 Sicherheitsrichtlinien
 Wichtige Grundlage für Automatisierung
 Pflege von Metadaten gehört in CI/CD / Review
Prozess

24. © OPITZ CONSULTING 2023 / Öffentlich
FEDERATED GOVERNANCE
Data Mesh und Domain Driven Design 24

25. © OPITZ CONSULTING 2023 / Öffentlich
MODERN ETL
Data Mesh und Domain Driven Design 25
 Auch ETL ist „stateless“!
 Kann containerisiert passieren, analog zu
Microservices
 Container verbrauchen Ressourcen nur zur
Laufzeit
 Freie Tool / Sprachenwahl
 Domain-Teams können ihr Tool frei wählen
 Governance regelt Anforderungen an Qualität
und DevOps Prozesse
 ETL goes „Code first“
 Automatisiertes Testing
 Automatisiertes Deployment
Erfolgsrezept für Tools
wie dbt

26. © OPITZ CONSULTING 2023 / Öffentlich
TECHNISCHE
HERAUSFORDERUNGEN
Data Mesh und Domain Driven Design 26
 Unabhängige Data Products
 Herausforderungen analog zu Microservices
 Im Falle von Abhängigkeiten wird eine
Versionierung nötig
 Historisierung von Daten der Data Products
sollte mitbetrachtet werden
 Alle Domain-Entitäten sollten auch historisiert
zur Verfügung gestellt werden
 Bereitstellung von Products
 Registrierung in Catalog
 Veröffentlichung über Plattform
 Data Contract
 OpenAPI Spec
 AVRO / Protobuf Schema
 Auf- und Abwärtskompatibilität von Schemata
(siehe AVRO)
 Automatisierung über Pipelines
 Erfassung in Data Catalog (analog API Spec,
etc.)
 Siehe moderne API-Plattform
UND EINIGE IDEEN AUS DER
SOFTWARE ENTWICKLUNG…

27. © OPITZ CONSULTING 2023 / Öffentlich
CROSS-DOMAIN DATA PRODUCT USAGE
Data Mesh und Domain Driven Design 27

28. © OPITZ CONSULTING 2023 / Öffentlich
ANWENDUNGSBEISPIEL
Data Mesh und Domain Driven Design 28

29. © OPITZ CONSULTING 2023 / Öffentlich
BEISPIEL MIT ANALYTISCHEM DATA PRODUKT
Data Mesh und Domain Driven Design 29

30. © OPITZ CONSULTING 2023 / Öffentlich
IDEE VOM DATA MESH 1.0 / DATA MESH LIGHT
(ADVANCED DWH MODERIZATION)
Data Mesh und Domain Driven Design 30

31. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design
ZUSAMMENFASSUNG
 Nochmal die wichtigsten Punkte
05
31

32. © OPITZ CONSULTING 2023 / Öffentlich
FAZIT
Data Mesh und Domain Driven Design 32
 Viele Punkte der modernen Softwareentwicklung
halten Einzug
 DevOps, CI/CD, autom. Testing, Container
 Data Products sehr analog zu API Products
 Orientierung an Integrationsthemen möglich
 Mehr Geschwindigkeit in die Business Domänen
bringen
 Flexiblere Architektur
 Freie Wahl der Waffen
 Vermeidung von „Schatten-IT“
 Aber – Data Mesh steht und fällt mit der Orga
und den Menschen

33. © OPITZ CONSULTING 2023 / Öffentlich
FAZIT
Data Mesh und Domain Driven Design 33
 Domain-Team bilden
 Data Engineers integrieren
 Voneinander lernen und ein „WIR“ werden
 Produktbewusstsein entwickeln
 Plattform-Team
 Evtl. an bestehendes angliedern
 API- / Integrationsplattform, etc.
 Nicht zu viel auf einmal
 Besser als Modernisierung denken
 Data Mesh 1.0 (Data Mesh light) als Idee
 Bestehende, kleinere Marts aus neuen Data
Products laden

34. © OPITZ CONSULTING 2023 / Öffentlich
Data Mesh und Domain Driven Design 34
Q & A

35. © OPITZ CONSULTING 2023 / Öffentlich
KONTAKT
Data Mesh und Domain Driven Design 35
Fabian Hardt
Solution Architect
Fabian.Hardt@opitz-consulting.com
https://twitter.com/fabian_hardt
https://www.xing.com/profile/Fabian_Hardt
https://www.linkedin.com/in/fabian-hardt