Eine der größten Herausforderungen, mit denen sich große Unternehmen bei der Datenverwaltung konfrontiert sehen, ist die mangelnde Flexibilität, um aufgrund ihrer größeren und komplexeren Datenstrukturen schnell auf Marktveränderungen zu reagieren. In letzter Zeit hat die Datenindustrie eine Lösung für diese Herausforderung gefunden: Data Mesh und seine 4 Prinzipien, zu denen auch unser heutiges Thema, das domain-gesteuerte dezentrale Dateneigentum, gehört.
Wenn Sie mit dem Framework noch nicht vertraut sind, werfen Sie einen Blick auf unseren Artikel über Data Mesh, in dem das Konzept zusammen mit einem kurzen Überblick über die einzelnen Prinzipien erläutert wird.
Heute werden wir eines dieser Prinzipien vertiefen: das domain-orientierte dezentrale Dateneigentum.
Das Problem: Zentrale Datenteams werden schnell zu einem Engpass
Ursprünglich gab es in vielen Unternehmen ein zentrales Datenteam, das für alle Änderungen verantwortlich war, die das Datenmodell betreffen (von der Orchestrierung der Datenpipeline bis zur Erstellung von Machine Learning-Modellen).
Das Hauptproblem bei diesem Ansatz ist der fehlende Kontext für das Team, was in der Folge zu mehr Hin und Her zwischen Geschäfts- und Datenteams führt. Schließlich beginnen sich die Aufgaben zu stapeln, was zu einem Engpass für das gesamte Unternehmen führt, das sich stark auf dieses zentrale Datenteam verlässt.
Die Lösung: Dezentralisierung von Daten und deren Besitz
Data Mesh schlägt vor, denselben Ansatz zu verfolgen, den Technikteams schon seit einigen Jahrzehnten anwenden. Durch die Einbindung der Mitglieder des Datenteams in die Teams der Geschäftsbereiche wird eine dezentrale Struktur geschaffen, die Geschäfts-, Technik- und Datenkenntnisse im selben Team vereint.
Von zentralisierten Daten zu dezentralisiertem Eigentum
Der unmittelbare Vorteil besteht darin, dass die Mitarbeiter des Datenteams nun am nächsten an den Daten dran sind, die sich auf den jeweiligen Geschäftsbereich auswirken. Dies führt zu mehr Agilität bei der Entscheidungsfindung und Implementierung, da die Fachteams unabhängig und eigenständig an ihren fachbezogenen Datenprodukten und -diensten arbeiten können.
Was ist Domain-Driven Design?
Zhamak Dehghani (der den Begriff Data Mesh geprägt hat) hat dieses Prinzip des Domain-eigentums auf ein anderes, ähnliches (und doch anderes) Paradigma gestützt: das domain-orientierte Design. Domain-driven Design (kurz DDD) wurde ursprünglich von Eric Evans im Jahr 2003 in seinem berühmten Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ vorgestellt. Es umfasst vier Hauptkonzepte:
- Domain: Eine Domäne ist ein Bereich des Wissens, des Einflusses oder der Aktivität.
- Subdomain: Eine Subdomain ist ähnlich wie eine Domain, aber auf einer niedrigeren Ebene, was bedeutet, dass eine Domain normalerweise aus vielen Subdomains besteht.
- Bounded Context: Das Konzept des eingeschränkten Kontexts ist mit dem Konzept der allgegenwärtigen Sprache verknüpft und stellt eine logische Grenze dar, die dazu beiträgt, den Umfang einer Domain zu definieren, während die allgegenwärtige Sprache die Notwendigkeit eines klar definierten Vokabulars innerhalb dieses Kontexts hervorhebt, bei dem jeder jeden Begriff oder jede Definition auf dieselbe Weise versteht.
- Context Mapping: Da ein und dasselbe Konzept in verschiedenen begrenzten Kontexten unterschiedliche Namen haben kann, benötigen wir Context Mapping auf einer höheren Ebene, um Inkonsistenzen zu vermeiden.
Wie sieht Domain-Driven Design in der Praxis aus?
Ein typisches Beispiel zur Erklärung und Veranschaulichung von DDD sind E-Commerce-Unternehmen. In einem E-Commerce-Unternehmen gibt es in der Regel sehr spezifische Geschäftsbereiche (funktionsübergreifende Teams, die sich um eine bestimmte Geschäftsfunktion kümmern), wie z. B.: Kasse, Mobilgeräte, Inhalte, usw.
Eine Subdomain innerhalb der Checkout-Domain könnte der Zahlungsverkehr sein. Wichtig zu erwähnen ist, dass es keine klare Definition dafür gibt, wie eine Domain oder Subdomain abzugrenzen ist.
Zhamak Dehghani schlägt vor, das aktuelle mentale Modell als Ausgangspunkt zu nehmen und es so lange zu überarbeiten, bis eine optimale Struktur gefunden ist. Ein zweiter Punkt, den es zu erwähnen gilt, ist, dass das Domänenmodell kein statisches Dokument ist, was bedeutet, dass es sich im Laufe der Zeit zusammen mit dem Markt und der Organisation selbst weiterentwickeln wird.
Um auf die DDD-Konzepte zurückzukommen: In diesem Beispiel wäre der begrenzte Kontext die Grenze, die die Checkout-Domain definiert, und die allgegenwärtige Sprache wäre zum Beispiel ein Glossar, in dem alle relevanten Definitionen für diese bestimmte Domain oder diesen Kontext beschrieben werden. Dadurch hätte das gesamte Team ein gemeinsames Vokabular und ein gemeinsames Verständnis der domain-spezifischen Begriffe (z. B. definiert jeder die Conversion Rate auf die gleiche Weise).
Das Context Mapping schließlich ist die Zuordnung zwischen Begriffen, die zu verschiedenen Bereichen gehören. In diesem Beispiel könnte das E-Commerce-Unternehmen die folgenden Domain haben: Kunden und Partner.
Der Bereich Verbraucher würde sich auf die gesamte Interaktion mit Personen konzentrieren, die Produkte über die Website kaufen.
Der Partnerbereich würde sich auf die andere Seite der Medaille konzentrieren, d. h. auf die Interaktion mit Unternehmen, die ihre Produkte verkaufen. Die Teammitglieder des Partnerbereichs würden diese Unternehmen als Kunden bezeichnen, während die Teammitglieder des Verbraucherbereichs sie als Anbieter bezeichnen könnten. Das Context Mapping definiert die Beziehung zwischen diesen Begriffen, um Missverständnisse bei der bereichsübergreifenden Kommunikation zu vermeiden.
Abschließende Überlegungen: Meine Erfahrungen mit bereichsorientiertem Datenbesitz in der Praxis
Meiner Erfahrung nach ist es sehr wichtig, bei der Durchführung einer DDD-Übung zu bedenken, dass es viele Diskussionen und ein Hin und Her zwischen den verschiedenen beteiligten Akteuren geben wird.
Zu den komplexen Themen gehören: die Definition von Domains und Subdomains, was gebaut und was gekauft werden soll, die Auswahl der ersten Domain als Pilot für die Migration. Mein Rat ist, den Prozess so schlank wie möglich zu halten und in Bewegung zu bleiben, sonst wird der Fortschritt monatelang durch bloße Diskussionen blockiert.
Abschließend möchte ich noch erwähnen, dass ich aus erster Hand erfahren habe, wie gut die Dezentralisierung von Daten funktioniert, indem die Datenverantwortlichen direkt in das Domain-Team oder die Gruppe integriert werden, und dass ich diesen Ansatz nur unterstützen kann, damit Unternehmen so agil wie möglich werden und schnell liefern können.