Dieser Artikel wurde ursprünglich auf Bigdata-Insider.de veröffentlicht.
Das Data-Mesh-Paradigma entwickelt sich zu einem aussichtsreichen Kandidaten, um den zentralen Data Lake als vorherrschendes Architekturparadigma im Data- und Analytics-Bereich abzulösen. Dabei ist es wichtig zu verstehen, dass das Data-Mesh-Konzept vor allem eine neue organisatorische Sichtweise etabliert und weniger auf technischen Problemlösungen fußt. Die Kerninnovation des Data Mesh besteht darin, Domain-Driven-Design und Produkt-Denken auf die Herausforderungen im Data-und Analytics-Bereich anzuwenden. Vergleichbar mit der Etablierung einer DevOps-Kultur besteht das Ziel darin, Gräben zwischen den beteiligten Parteien zu überbrücken und zu einer Struktur von verteilten Verantwortlichkeiten zu gelangen. Die Wertgewinnung aus Unternehmensdaten kann so nachhaltig skaliert werden.
Die fortschreitende Digitalisierung führt dazu, dass Unternehmen immer größere Datenmengen sammeln – sowohl über ihre eigenen Prozesse als auch über das Verhalten ihrer Kund:innen. Immer mehr Unternehmen sind bestrebt diese Daten effektiv zu nutzen, um Daten- und Fakten-gestützte Produktentscheidungen zu treffen und somit die Erwartungen ihrer Kund:innen besser erfüllen zu können. Wie stark und wie schnell ein Unternehmen interne Entscheidungen auf Basis von Daten statt anhand von Bauchgefühl trifft, ist in manchen Branchen bereits zum entscheidenden Wettbewerbsvorteil geworden.
In der klassischen Business Intelligence (BI) stellt ein zentral gepflegtes Data Warehouse die Grundlage für solche Entscheidungen dar, beispielsweise als Basis für regelmäßiges Reporting. Mit dem Aufkommen von Big Data und der steigenden Popularität von Data Science investieren viele Unternehmen in den Aufbau eines zentralen Data Lakes – manchmal an Stelle eines Data Warehouses, häufiger jedoch in Ergänzung dessen. Der Hauptunterschied beider Konzepte liegt im Zeitpunkt der Kuratierung und Schematisierung. Beim Data Warehouse werden die Daten bereits bei Befüllung so transformiert, dass sie zu einer bestimmten Anwendung passen. Beim Data Lake geschieht dies erst bei deren Verwendung. Beiden Konzepten gemein ist hingegen deren Zentralisierung. Das führt gerade bei großen Unternehmen zu Problemen, die wiederkehrenden Mustern folgen.
Ein häufiges Muster ist das des überlasteten und größtenteils negativ motivierten zentralen “Data Teams”. Dieses Team betreibt die zentrale Dateninfrastruktur, sei es Data Lake oder Data Warehouse. Darüber hinaus trägt dieses Team aber auch die Verantwortung dafür, dass datengetrieben arbeitende Projektteams, Data Scientists und Entscheider:innen mit verlässlichen Reports oder Datensätzen versorgt werden. Die Situation dieses Teams ist dabei häufig nicht beneidenswert. Die Teammitglieder sind einen großen Teil ihrer Zeit damit beschäftigt Fehler zu beheben, die durch Änderungen auf Seiten Daten produzierender Teams entstanden sind. Gleichzeitig sind sie dem Ärger und der Frustration Daten konsumierender Teams oder Individuen ausgesetzt. Dies ist umso nachteiliger, da in diesem Team häufig die geballte Data-Engineering-Kompetenz versammelt ist und die Teammitglieder zu den technisch begabtesten und am Arbeitsmarkt begehrtesten Entwicklern gehören, so jedoch schwer im Unternehmen zu halten sind.
Der Grund warum auch die technisch Versiertesten die Situation nicht nachhaltig verbessern können liegt darin, dass es sich hier in der Regel nicht um ein technisches, sondern um ein organisatorisches Problem handelt. Eine Hauptursache liegt in der ungünstigen Aufteilung von Verantwortlichkeiten und Kompetenzen auf die beteiligten Parteien.
Eine Partei – die der Datenproduzierenden – besitzt das passende Domänenwissen, versteht also die Bedeutung und die Zusammenhänge der Daten und kann direkt verändern wie die erzeugten Daten aussehen. Eine andere Partei – die der Datenkonsumierenden – hat großes Interesse an der Verwendung der Daten, versteht das Potential und die Anwendungsmöglichkeiten für das Unternehmen und kann entsprechende Anforderungen an die Datenqualität formulieren.
Die Mitglieder:innen des Data Teams befinden sich zwischen diesen Parteien: Sie haben die Verantwortung Daten stabil und hochqualitativ zur Verfügung zu stellen, haben aber weder das Domänenwissen noch die Möglichkeit, direkt Einfluss auf die Qualität der Datengenerierung zu nehmen. Auch sind sie nicht diejenigen, die die Daten letztendlich zur Wertschöpfung in Form von datengetriebenen Entscheidungen nutzen. Das bedeutet, dass insbesondere hinsichtlich der Datenqualität das Interesse, die Verantwortung und die Fähigkeit auf drei unterschiedliche Parteien verteilt sind. Diese Konstellation führt unweigerlich zu Reibung, Frustration, und Missverständnisse.
Das Ziel sollte stattdessen darin bestehen, Datenproduzierende und Datenkonsumierende so nah wie möglich zueinander zu bringen. Im organisatorischen Idealfall verwendet ein Daten-produzierendes Team die Daten selbst, ist also auch Konsument, so dass Interesse, Verantwortung, und Fähigkeit im selben Team zusammenfallen. Praktisch ist dieses Ideal häufig nicht erreichbar, da ein Daten-produzierendes Team bereits so viele Aufgaben in seiner Domäne erfüllt, dass es überfordert wäre, würden auch noch Anwendungen zur Datenverwendung vollständig in die Verantwortung dieses Teams fallen.
Insofern stellt auch schon eine Situation einen großen Fortschritt dar, in der sich zwei getrennte Teams direkt über Anforderungen und Konsequenzen von Datenänderungen austauschen, ohne dass eine vermittelnde Partei eine unnötige Indirektion erzeugt. Ziel eines Daten-produzierenden Teams sollte es sein, Daten so zur Verfügung zu stellen, dass Konsumierende ohne detailliertes Domänenwissen Wert aus den Daten gewinnen können, sprich die “Implementierungsdetails” der Daten versteckt werden. Ein solches Daten-produzierendes Team kann dabei durchaus auch selbst Daten eines anderen Teams konsumieren. Beispielsweise gibt es Anwendungs-orientierte Datendomänen, die komplex genug sind um ein eigenes Team von Domänenexperten zu rechtfertigen, die aber selbst auf Quell-orientierten Datendomänen aufbauen und diese bspw. aggregieren.
Aus rein organisatorischer Sicht ist offensichtlich, dass eine solche Struktur mit bilateralen Beziehungen zwischen Datenproduzierenden und Konsumierenden sowie das Zusammenbringen der Verantwortung und des Wissens bzgl. einer Domäne in einem Team weniger Reibung erzeugt, besser skaliert, und zu klareren Verantwortungen und damit zu mehr Qualität führt. Warum aber ist das Muster des überlasteten zentralen Data-Teams dann so allgegenwärtig? Drei Überlegungen treiben immer wieder eine Entwicklung dahin, die Verantwortung für Unternehmensdaten zu zentralisieren:
In allen drei Fällen verhindert häufig die fehlende konzeptionelle Trennung zwischen der Zentralisierung der Datenverantwortung und der Zentralisierung der Dateninfrastruktur, die Vorteile von dezentraler Verantwortung zu erkennen. Denn in allen drei Fällen kann das Bereitstellen einer gemeinsamen (zentralisierten) Self-Service-Dateninfrastrukturplattform Abhilfe schaffen. Diese Infrastruktur muss jedoch strikt domänenagnostisch bleiben und nicht mit einer zentralisierten Datenverantwortung gleichgesetzt werden. Zusammen mit der Etablierung einer Produktdenkweise kann so diesen Sorgen sehr viel nachhaltiger begegnet werden.
Woran erkennt man aber, dass eine Dateninfrastrukturplattform Domänen-agnostisch ist? Ein Team, welches die eigene Domänen-Expertise in Form von Daten zur Verfügung stellen möchte, muss dies mit Hilfe der Plattform umsetzen können – ohne Kontakt zum Team welches diese Plattform verantwortet. Sprich, die Entwickler der Plattform dürfen niemals Domänenwissen über die konkreten Anwendungsfälle benötigen.
Das bedeutet, dass die Plattform Self-Service Werkzeuge zur Verfügung stellen muss, die es Entwickler:innen ohne Data Engineering Expertise ermöglicht, eine neue Datendomäne zu erstellen, zu beschreiben, zu befüllen, deren Nutzung zu beobachten, und ggf. auch wieder zu zerstören.
Eine solche Plattform zu entwickeln, ist zwar eine technische Herausforderung, im Kern aber eine klassische Softwareproduktentwicklung, bei der zuerst typische Use-Cases implementiert werden.
Wichtig ist zu verstehen, dass die zentrale Bereitstellung und Entwicklung einer solchen Plattform nicht die oben genannten organisatorischen Nachteile mit sich bringt, sofern sie eine logische Trennung der einzelnen Datendomänen ermöglicht (die bereitgestellte zentrale Infrastruktur bspw. multi-tenancy fähig ist) und sich die Entwickler:innen dieser Plattform nicht mit den täglich ändernden domänen-spezifischen Problemen des eigentlichen Dateninhaltes beschäftigen müssen. Auf diese Weise kann eine solche Plattform auch von einem kleinen Team von Data Engineers entwickelt werden und die Datendomänenteams benötigen kaum Data Engineering Expertise zur Nutzung der Plattform. Wichtig ist jedoch, die Datendomänenexpertise in allen Daten-produzierenden Teams nachhaltig aufzubauen.
Einer der größten Vorteile einer attraktiven Self-Service-Dateninfrastrukturplattform besteht darin, dass es für Teams viel einfacher ist die angebotenen Möglichkeiten zu nutzen – und dadurch automatisch bestimmte gemeinsame Standards zu erfüllen – als eine eigene nicht standardkonforme Infrastruktur aufzubauen und damit zu einer heterogenen Datenlandschaft beizutragen. Auf diese Weise werden Standards und Governance durch Bequemlichkeit statt durch Zwang getrieben.
Von den oben aufgeführten Herausforderungen dezentraler Verantwortung bleibt somit nur noch die der Datenqualität übrig, und diese kann ohnehin nicht gut skalierend von einem zentralen Team übernommen werden, da ein Team unmöglich genügend Expertise in allen Domänen eines Unternehmens aufbauen kann. Dennoch wird dieses Problem auch nicht einfach durch den Wechsel zur dezentralen Organisation behoben. Hier kommt das Produktdenken ins Spiel. Teams müssen Anreize erhalten ihre Daten hochqualitativ zur Verfügung zu stellen, beispielsweise indem sich ihr Budget an der Anzahl und der Zufriedenheit ihrer Datennutzer orientiert. Auf diese Weise wird ein Team versuchen, den Wert der eigenen Daten zu bewerben und Daten-konsumierende Teams glücklich zu machen.
Zusammenfassend lässt sich formulieren, dass die erfolgreiche Etablierung einer gut skalierenden dezentral organisierten Datenlandschaft von der Etablierung dreier Denkmuster abhängt:
Das Data-Mesh-Paradigma entwickelt sich zu einem aussichtsreichen Kandidaten, um den zentralen Data Lake als vorherrschendes Architekturparadigma im Data- und Analytics-Bereich abzulösen. Dabei ist es wichtig zu verstehen, dass das Data-Mesh-Konzept vor allem eine neue organisatorische Sichtweise etabliert und weniger auf technischen Problemlösungen fußt. Die Kerninnovation des Data Mesh besteht darin, Domain-Driven-Design und Produkt-Denken auf die Herausforderungen im Data-und Analytics-Bereich anzuwenden. Vergleichbar mit der Etablierung einer DevOps-Kultur besteht das Ziel darin, Gräben zwischen den beteiligten Parteien zu überbrücken und zu einer Struktur von verteilten Verantwortlichkeiten zu gelangen. Die Wertgewinnung aus Unternehmensdaten kann so nachhaltig skaliert werden.
Die fortschreitende Digitalisierung führt dazu, dass Unternehmen immer größere Datenmengen sammeln – sowohl über ihre eigenen Prozesse als auch über das Verhalten ihrer Kund:innen. Immer mehr Unternehmen sind bestrebt diese Daten effektiv zu nutzen, um Daten- und Fakten-gestützte Produktentscheidungen zu treffen und somit die Erwartungen ihrer Kund:innen besser erfüllen zu können. Wie stark und wie schnell ein Unternehmen interne Entscheidungen auf Basis von Daten statt anhand von Bauchgefühl trifft, ist in manchen Branchen bereits zum entscheidenden Wettbewerbsvorteil geworden.
Data Warehouse, Data Lake, und die Probleme zentralisierter Datenverantwortung
In der klassischen Business Intelligence (BI) stellt ein zentral gepflegtes Data Warehouse die Grundlage für solche Entscheidungen dar, beispielsweise als Basis für regelmäßiges Reporting. Mit dem Aufkommen von Big Data und der steigenden Popularität von Data Science investieren viele Unternehmen in den Aufbau eines zentralen Data Lakes – manchmal an Stelle eines Data Warehouses, häufiger jedoch in Ergänzung dessen. Der Hauptunterschied beider Konzepte liegt im Zeitpunkt der Kuratierung und Schematisierung. Beim Data Warehouse werden die Daten bereits bei Befüllung so transformiert, dass sie zu einer bestimmten Anwendung passen. Beim Data Lake geschieht dies erst bei deren Verwendung. Beiden Konzepten gemein ist hingegen deren Zentralisierung. Das führt gerade bei großen Unternehmen zu Problemen, die wiederkehrenden Mustern folgen.
Ein häufiges Muster ist das des überlasteten und größtenteils negativ motivierten zentralen “Data Teams”. Dieses Team betreibt die zentrale Dateninfrastruktur, sei es Data Lake oder Data Warehouse. Darüber hinaus trägt dieses Team aber auch die Verantwortung dafür, dass datengetrieben arbeitende Projektteams, Data Scientists und Entscheider:innen mit verlässlichen Reports oder Datensätzen versorgt werden. Die Situation dieses Teams ist dabei häufig nicht beneidenswert. Die Teammitglieder sind einen großen Teil ihrer Zeit damit beschäftigt Fehler zu beheben, die durch Änderungen auf Seiten Daten produzierender Teams entstanden sind. Gleichzeitig sind sie dem Ärger und der Frustration Daten konsumierender Teams oder Individuen ausgesetzt. Dies ist umso nachteiliger, da in diesem Team häufig die geballte Data-Engineering-Kompetenz versammelt ist und die Teammitglieder zu den technisch begabtesten und am Arbeitsmarkt begehrtesten Entwicklern gehören, so jedoch schwer im Unternehmen zu halten sind.
Der Grund warum auch die technisch Versiertesten die Situation nicht nachhaltig verbessern können liegt darin, dass es sich hier in der Regel nicht um ein technisches, sondern um ein organisatorisches Problem handelt. Eine Hauptursache liegt in der ungünstigen Aufteilung von Verantwortlichkeiten und Kompetenzen auf die beteiligten Parteien.
Eine Partei – die der Datenproduzierenden – besitzt das passende Domänenwissen, versteht also die Bedeutung und die Zusammenhänge der Daten und kann direkt verändern wie die erzeugten Daten aussehen. Eine andere Partei – die der Datenkonsumierenden – hat großes Interesse an der Verwendung der Daten, versteht das Potential und die Anwendungsmöglichkeiten für das Unternehmen und kann entsprechende Anforderungen an die Datenqualität formulieren.
Die Mitglieder:innen des Data Teams befinden sich zwischen diesen Parteien: Sie haben die Verantwortung Daten stabil und hochqualitativ zur Verfügung zu stellen, haben aber weder das Domänenwissen noch die Möglichkeit, direkt Einfluss auf die Qualität der Datengenerierung zu nehmen. Auch sind sie nicht diejenigen, die die Daten letztendlich zur Wertschöpfung in Form von datengetriebenen Entscheidungen nutzen. Das bedeutet, dass insbesondere hinsichtlich der Datenqualität das Interesse, die Verantwortung und die Fähigkeit auf drei unterschiedliche Parteien verteilt sind. Diese Konstellation führt unweigerlich zu Reibung, Frustration, und Missverständnisse.
Abbildung 1: Zentrales Data Team als Mittler zwischen Datenproduzierenden und -konsumierenden
Data Mesh: Klar verteilte Verantwortung, gemeinsam genutzte Infrastruktur
Das Ziel sollte stattdessen darin bestehen, Datenproduzierende und Datenkonsumierende so nah wie möglich zueinander zu bringen. Im organisatorischen Idealfall verwendet ein Daten-produzierendes Team die Daten selbst, ist also auch Konsument, so dass Interesse, Verantwortung, und Fähigkeit im selben Team zusammenfallen. Praktisch ist dieses Ideal häufig nicht erreichbar, da ein Daten-produzierendes Team bereits so viele Aufgaben in seiner Domäne erfüllt, dass es überfordert wäre, würden auch noch Anwendungen zur Datenverwendung vollständig in die Verantwortung dieses Teams fallen.
Insofern stellt auch schon eine Situation einen großen Fortschritt dar, in der sich zwei getrennte Teams direkt über Anforderungen und Konsequenzen von Datenänderungen austauschen, ohne dass eine vermittelnde Partei eine unnötige Indirektion erzeugt. Ziel eines Daten-produzierenden Teams sollte es sein, Daten so zur Verfügung zu stellen, dass Konsumierende ohne detailliertes Domänenwissen Wert aus den Daten gewinnen können, sprich die “Implementierungsdetails” der Daten versteckt werden. Ein solches Daten-produzierendes Team kann dabei durchaus auch selbst Daten eines anderen Teams konsumieren. Beispielsweise gibt es Anwendungs-orientierte Datendomänen, die komplex genug sind um ein eigenes Team von Domänenexperten zu rechtfertigen, die aber selbst auf Quell-orientierten Datendomänen aufbauen und diese bspw. aggregieren.
Aus rein organisatorischer Sicht ist offensichtlich, dass eine solche Struktur mit bilateralen Beziehungen zwischen Datenproduzierenden und Konsumierenden sowie das Zusammenbringen der Verantwortung und des Wissens bzgl. einer Domäne in einem Team weniger Reibung erzeugt, besser skaliert, und zu klareren Verantwortungen und damit zu mehr Qualität führt. Warum aber ist das Muster des überlasteten zentralen Data-Teams dann so allgegenwärtig? Drei Überlegungen treiben immer wieder eine Entwicklung dahin, die Verantwortung für Unternehmensdaten zu zentralisieren:
- Die Sorge, nicht genügend Daten-spezifische technische Expertise (Data Engineers, Data Scientists) zu haben, um mehrere Teams entsprechend auszustatten. Damit verbunden ist die Hoffnung, die wenigen Datenexperten am effizientesten und fairsten zu nutzen, indem sie in einem zentralen Team agieren und die Verantwortung für alle Daten übernehmen.
- Die Sorge vor Verlust der Kontrolle über die Datenqualität, beispielsweise weil sich bei dezentraler Verantwortung keine einheitlichen Standards durchsetzen, und somit einem Datenchaos kein Einhalt geboten werden kann.
- Die Sorgen vor mehrfachen Infrastrukturaufwänden, da dieselben Teile einer Dateninfrastruktur (Pipelines, Services, Storage) in jedem Team erneut entwickelt und dauerhaft gepflegt werden müssen.
In allen drei Fällen verhindert häufig die fehlende konzeptionelle Trennung zwischen der Zentralisierung der Datenverantwortung und der Zentralisierung der Dateninfrastruktur, die Vorteile von dezentraler Verantwortung zu erkennen. Denn in allen drei Fällen kann das Bereitstellen einer gemeinsamen (zentralisierten) Self-Service-Dateninfrastrukturplattform Abhilfe schaffen. Diese Infrastruktur muss jedoch strikt domänenagnostisch bleiben und nicht mit einer zentralisierten Datenverantwortung gleichgesetzt werden. Zusammen mit der Etablierung einer Produktdenkweise kann so diesen Sorgen sehr viel nachhaltiger begegnet werden.
Abbildung 2: Datenproduzierende und -konsumierende interagieren direkt, unterstützt von einer gemeinsamen Infrastrukturplattform.
Domänen-agnostische Dateninsfrastruktur-Plattform und Produktdenken
Woran erkennt man aber, dass eine Dateninfrastrukturplattform Domänen-agnostisch ist? Ein Team, welches die eigene Domänen-Expertise in Form von Daten zur Verfügung stellen möchte, muss dies mit Hilfe der Plattform umsetzen können – ohne Kontakt zum Team welches diese Plattform verantwortet. Sprich, die Entwickler der Plattform dürfen niemals Domänenwissen über die konkreten Anwendungsfälle benötigen.
Das bedeutet, dass die Plattform Self-Service Werkzeuge zur Verfügung stellen muss, die es Entwickler:innen ohne Data Engineering Expertise ermöglicht, eine neue Datendomäne zu erstellen, zu beschreiben, zu befüllen, deren Nutzung zu beobachten, und ggf. auch wieder zu zerstören.
Eine solche Plattform zu entwickeln, ist zwar eine technische Herausforderung, im Kern aber eine klassische Softwareproduktentwicklung, bei der zuerst typische Use-Cases implementiert werden.
Wichtig ist zu verstehen, dass die zentrale Bereitstellung und Entwicklung einer solchen Plattform nicht die oben genannten organisatorischen Nachteile mit sich bringt, sofern sie eine logische Trennung der einzelnen Datendomänen ermöglicht (die bereitgestellte zentrale Infrastruktur bspw. multi-tenancy fähig ist) und sich die Entwickler:innen dieser Plattform nicht mit den täglich ändernden domänen-spezifischen Problemen des eigentlichen Dateninhaltes beschäftigen müssen. Auf diese Weise kann eine solche Plattform auch von einem kleinen Team von Data Engineers entwickelt werden und die Datendomänenteams benötigen kaum Data Engineering Expertise zur Nutzung der Plattform. Wichtig ist jedoch, die Datendomänenexpertise in allen Daten-produzierenden Teams nachhaltig aufzubauen.
Einer der größten Vorteile einer attraktiven Self-Service-Dateninfrastrukturplattform besteht darin, dass es für Teams viel einfacher ist die angebotenen Möglichkeiten zu nutzen – und dadurch automatisch bestimmte gemeinsame Standards zu erfüllen – als eine eigene nicht standardkonforme Infrastruktur aufzubauen und damit zu einer heterogenen Datenlandschaft beizutragen. Auf diese Weise werden Standards und Governance durch Bequemlichkeit statt durch Zwang getrieben.
Von den oben aufgeführten Herausforderungen dezentraler Verantwortung bleibt somit nur noch die der Datenqualität übrig, und diese kann ohnehin nicht gut skalierend von einem zentralen Team übernommen werden, da ein Team unmöglich genügend Expertise in allen Domänen eines Unternehmens aufbauen kann. Dennoch wird dieses Problem auch nicht einfach durch den Wechsel zur dezentralen Organisation behoben. Hier kommt das Produktdenken ins Spiel. Teams müssen Anreize erhalten ihre Daten hochqualitativ zur Verfügung zu stellen, beispielsweise indem sich ihr Budget an der Anzahl und der Zufriedenheit ihrer Datennutzer orientiert. Auf diese Weise wird ein Team versuchen, den Wert der eigenen Daten zu bewerben und Daten-konsumierende Teams glücklich zu machen.
Zusammenfassend lässt sich formulieren, dass die erfolgreiche Etablierung einer gut skalierenden dezentral organisierten Datenlandschaft von der Etablierung dreier Denkmuster abhängt:
- Die Strukturierung von Daten in Domänen und Subdomänen und der Zuordnung der vollständigen Verantwortung (sowie der passenden Unterstützung) bzgl. einer Domäne zu einem cross-funktionalen Team.
- Der Anwendung von Produktmanagement auf Datensätze, so dass die richtigen Anreize gesetzt werden, um Daten hochqualitativ und konsumentengerecht zur Verfügung zu stellen.
- Die Bereitstellung domänen-agnostischer Self-Service-Infrastruktur, die keine Datenverantwortung beinhaltet, sondern sich stattdessen auf die Nutzer-freundliche Unterstützung allgemeiner Use-Cases der Datenproduzierenden und Datenkonsumierenden konzentriert.
Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.