Data Mesh

Data Mesh ist aktuell ein vieldiskutierter Ansatz, wenn aktuelle Architekturen und Organisationsformen für das Datenmanagement in Unternehmen nicht länger funktionieren. Dahinter verbirgt sich ein sozio-technisches Konzept für einen neuen Umgang mit Daten.

Mit diesem Blog-Post zeige ich Dir, was den Data Mesh Ansatz ausmacht und wie er den Herausforderungen aktueller Data Warehouse- oder Data Lake-Architekturen begegnet.  

In weiteren Blog-Posts lernst Du erste Schritte kennen, wie Unternehmen diesen Ansatz für sich umsetzen können und auch wie der Start in Richtung Data Mesh mit bestehenden Data Warehouse- oder sonstigen Data Management Tools aussehen kann.  

Herausforderungen aktueller Data Warehouse- und Data Lake-Architekturen 

Data Warehouse 

Data Warehouse-Architekturen zeichnen sich dadurch aus, dass in einer zentralen Architektur konsistente, qualitativ hochwertige und integrierte Daten zusammengeführt werden, die dann für Messungen und Analysen herangezogen werden können. Auf dieser Basis werden dann strategische Entscheidungen getroffen.
Um die Datenbasis herzustellen, existiert ein zentrales Team, bestehend aus Expert:innen im Umgang mit analytischen Daten. So lange sich das Domänenwissen, das für die Herstellung dieser Datenbasis benötigt wird, in Grenzen hält, funktioniert dieser Ansatz sehr gut und es ist sichergestellt, dass die Datenqualität hoch ist.  

Wir beobachten jedoch schon seit mehreren Jahren, dass die Menge, die Vielfalt und die Geschwindigkeit von Daten immer weiter steigt (Stichwort Big Data). Dadurch wird auch das Domänenwissen, das zum Verstehen der Daten benötigt wird, immer komplexer. Und gleichzeitig steigen die Anforderungen an die Bereitstellung von Daten und Datenanalysen, da diese nicht mehr nur noch aus der Geschäftsführung kommen – wie in den Anfängen von Data Warehouses – sondern datenbasierte Entscheidungen bereits in vielen alltäglich genutzten Anwendungen gang und gäbe sind. Hier kommt ein zentrales Team an seine Grenzen, da zum einen vermehrt mit den Expert:innen der Domäne kommuniziert werden muss, um deren Wissen zu nutzen. Zum anderen bekommt das zentrale Team viel mehr Anfragen und Aufträge zur Integration weiterer Daten. Sowohl für die vermehrte Kommunikation als auch für die Umsetzung der vielen Aufträge, wird Kapazität benötigt, die in einem zentralen Team nur bis zu einem gewissen Gradexistiert. Wenn eine weitere Skalierung des zentralen Teams nicht mehr möglich oder sinnvoll ist, muss über alternative Ansätze nachgedacht werden.  

Data Lake 

Zu der Zeit, als der Begriff Big Data geprägt wurde, wurde als Antwort darauf der Data Lake-Ansatz entwickelt. Bei einem Data Lake handelt es sich um eine große Datenbasis, in die die verfügbaren Daten zunächst ohne Ansprüche an Konsistenz, Integrität und Qualität gesammelt wurden. Auf diese Weise ist es möglich, Daten in großen Mengen, mit einer großen Vielfalt und schnell zur Verfügung zu stellen. Themen wie Datenqualität, Konsistenz und Integration wurden erst später, je nach Erforderlichkeit eines konkreten Use Cases fokussiert. Dieser Ansatz birgt somit dann Vorteile, wenn z.B. eine schnelle Mustererkennung das Ziel ist. Mit steigenden Anforderungen an die Nachvollziehbarkeit von Datenflüssen und klaren Zuständigkeiten für Daten, zum Beispiel in hoch regulierten Branchen oder wenn es um personenbezogene oder andere sensitive Daten geht, kommen Data Lake Ansätze ebenfalls an ihre Grenzen. 

Der Data Mesh Ansatz 

Der Data Mesh Ansatz versucht nun, die Vorteile bekannter Architekturansätze miteinander zu verbinden und gleichzeitig die oben geschilderten Probleme und Grenzen aufzulösen. Der Data Mesh-Ansatz ist dadurch kein reines Architektur-Konzept, sondern verbindet architekturelle, organisatorische und kulturelle Elemente.  

Im Folgenden gehe ich auf diese Elemente ein: 

Neuverteilung der Verantwortung 

Statt eines zentralen Teams wird die Verantwortung dezentralisiert und rückt nach links (shift left) in die Domänen. Die Verantwortung für die Bereitstellung von Daten liegt im Data Mesh, also dort, wo die Daten entstehen bzw. erzeugt werden und wo das Domänenwissen ist. An dieser Stelle ist auch das Know-how vorhanden, welche Anforderungen an die Datenqualität und die Datensicherheit gestellt werden müssen und was für diese Daten eine ausreichende Datenqualität ausmacht bzw. welche Fallstricke durch inkonsistente, falsche oder fehlende Daten entstehen.  

Damit durch die Dezentralisierung jedoch keine streng getrennten Silos entstehen, beinhaltet die Neuverteilung der Verantwortung mit der föderativen Governance einen weiteren wichtigen Aspekt. Statt Vorgaben von oben zu machen, ist es erforderlich, dass die dezentralen Verantwortungsträger zusammenkommen und sich gemeinsam Vorgaben definieren und darauf festlegen. 

Produkt-Denken 

Daten werden nicht länger “as is” bereitgestellt, sondern in Form von Produkten. Daten als Produkt zu denken, bedeutet zum einen, dass diejenigen, die für die Bereitstellung zuständig sind, den Konsumenten im Blick haben und nur solche Produkte anbieten, bei denen sie wissen oder davon ausgehen, dass diese den Bedürfnissen der Konsumenten entsprechen und dass sie von möglichst vielen Konsumenten genutzt werden können. Zum anderen bedeutet Datenprodukt auch, dass sich ändert, was bereitgestellt wird. Es werden nicht nur Daten bereitgestellt, sondern Daten zusammen mit  

• Transformationscode, der aus eingehenden Daten die entsprechende Aufbereitung, Aggregation oder Transformation herstellt. 
• definierten Schnittstellen, damit Konsumenten auf die so aufbereiteten Daten zugreifen können. 

• Service Level Objectives, die festlegen, wer auf die Daten zugreifen darf, welches Datenqualitätsniveau zugesichert wird etc. Diese werden ebenfalls in maschinenlesbarer Form erstellt, damit sie von der Datenplattform lesbar ist. 

Plattform-Architektur 

Die oben genannten Elemente funktionieren nur dann gut, wenn es eine zentrale Datenplattform gibt, über die die Domänen ihre Datenprodukte entwickeln und deployen können. Die zentrale Plattform prüft, ob die Datenprodukte allgemeingültige Vorgaben zur Bereitstellung einhalten, da nur so sichergestellt ist, dass die Datenprodukte als in sich geschlossene Komponente funktionieren, gleichzeitig mit den anderen Datenprodukten interoperabel sind und außerdem alle an einer zentralen Stelle gesucht und gefunden werden können. 

Zusätzlich ist die Plattform dafür zuständig, dass die von den Domänen angegebenen Service Level Agreements eines Datenprodukts automatisiert ausgeführt werden. So wird zum Beispiel im Service Level Agreement festgelegt, wer Zugriff auf das Datenprodukt haben darf. Die Plattform wertet diese Information aus und stellt sicher, dass ein Abruf der Daten aus dem Datenprodukt über die Output Ports des Datenprodukts nur dann von anderen Domänen möglich ist, wenn diese zur entsprechenden Rechtegruppe gehören. Darüber hinaus kann die Plattform auch am Datenprodukt vermerken, wenn dieses nicht der zugesicherten Datenqualität entspricht, zum Beispiel hinsichtlich der Aktualität der Daten. 

Zhamak Dehghani hat in Ihrem Buch aus diesen Elementen vier Prinzipien definiert, die stark miteinander interagieren. Für weitere Grundlagen des Ansatzes verweise ich daher auf dieses Buch.  

Ab nächster Woche findest Du einen neuen Blogpost, in welchem ich erste Schritte skizziere, die Unternehmen gehen sollten, um ein Data Mesh in ihrer Organisation aufzubauen, inkl. Hinweisen, wie auf bestehende Data Warehouse- oder sonstige Data Management-Tools aufgesetzt werden kann, um mit einem Data Mesh zu starten. 

Autorin

Dr. Saskia-Janina Untiet-Kepp
Senior Managerin