Data Mesh wurde 2019 von Zhamak Dehghani erstmalig entwickelt, vor allem als Reaktion auf die vielen Data Warehouse und Data Lake-Projekte, die zwar viel Geld gekostet haben, aber es oft nicht geschafft haben, aus ihren Nutzern wirklich datengetriebene Organisationen zu machen.

Die Hauptkritik ist, dass Lake oder Warehouse monolithische, zentralistische Strukturen sind, deren enorme Komplexität nur von hochbezahlten IT-Spezialisten beherrscht werden kann. Und weil sich Daten schnell verändern, sind diese dann der Flaschenhals, durch den alle Anforderungen kaum durchkommen: sie skalieren einfach nicht!

Die Ideen von Data Mesh sind allerdings nicht nur technologisch, sondern manchmal geradezu philosophisch. Aber keine Angst! Das Konzept wurde schon vielfach erfolgreich umgesetzt, sogar bei größeren Organisationen wir Adidas, Zalando und Roche Diagnostics.

Letztendlich sind es vier grundlegende Prinzipien, auf die Data Mesh aufbaut, die man auch allesamt in Microsoft Fabric wiederfindet, und die man am besten im englischen Original versteht:

• Domain Ownership
• Data as a Product
• Self-Serve Data Platform
• Federated Governance

Sein wir ehrlich: die meisten Data Warehouse oder Data Lake-Projekte wurden in der Vergangenheit von der IT getrieben, und führten deshalb auch immer zu einer zentralen, technischen Lösung. Bei Data Mesh aber ist derjenige für die Daten verantwortlich, der sie auch produziert, die Fachabteilung oder – neutraler gesprochen – die Domäne. Dort werden die Daten gesammelt und für die Auswertung vorgehalten, und deshalb braucht jede Domäne auch ihre Data Engineers. Weil es die nicht unbegrenzt gibt, muss die Aufbereitung so einfach sein, dass es auch jemand tun kann, der nicht Informatik studiert hat!

Und was sagt Microsoft dazu passend über Fabric? „Simplify, simplify, simplify“… Und der Begriff der Domänen kommt sogar zentral in der Fabric-Oberfläche vor.

Die Daten der eigenen Abteilung nicht eifersüchtig schützen und verstecken, sondern als Produkt betrachten, das man für zufriedene, am besten sogar begeisterte Kunden liebevoll aufbereitet und bewirbt, das verlangt wirklich ein fundamentales Umdenken. Ich bin „Product Owner“, und meine Kunden sind natürlich alle Nutzer aus allen Abteilungen, die meine Daten zur Analyse nutzen wollen, wie etwa der Vertrieb eine Liste der aktuellen Kunden und ihrer Aufträge für alle zur Verfügung stellt. Diese „Datenprodukte“ müssen leicht zu finden, leicht zu nutzen und inhaltlich vertrauenswürdig sein, und dafür trage ich die Verantwortung selbst. Und ich überprüfe auch meinen Erfolg, der dann eintritt, wenn meine Daten rege genutzt werden!

In Fabric gibt es dazu am besten die Möglichkeit, von dem Lakehouse einer Domäne eine Verknüpfung („Shortcut“) zu einem anderen Lakehouse einzurichten, dann werden die Daten nicht einmal kopiert, sondern stehen am Ziel einfach zur Verfügung.

Data Mesh war ja nicht die Idee irgendeines Herstellers, sondern ein theoretisches Konzept, das mit vielen verschiedenen Tools umgesetzt wird. Am Ende soll eine gemeinsame Daten-Infrastruktur als Plattform stehen, wo die Domänen ihre Datenprodukte aufbewahren, vorbereiten und zur Nutzung anbieten. Auch hier gilt das Gebot der Vereinfachung, das auch bei Fabric immer wieder im Vordergrund steht: die Komplexität des Provisionierens und Betreibens so einer Plattform soll für alle abstrahiert werden! Wenn die Domänen alle aktiv mitmachen sollen, darf man sie nicht überfordern, und es dürfen dabei keine neuen Schatten-ITs entstehen!

Fabric ist als „Software as a Service” konzipiert, auch mit dem klaren Ziel, dass man einfach nur eine Kapazität bereitstellt und Nutzer darauf berechtigt, und die können sofort loslegen. Wollen sie eine andere Komponente nutzen, etwa eine SQL-Datenbank, ein Python-Notebook oder eine Streaming-Plattform, muss nichts extra dazugekauft und beantragt werden!

Technologisch wird jeder dort abgeholt, wo er steht, sei es bei Power Query, bei Data Factory, SQL, bei Spark oder bei DAX-Abfragen. Und das funktioniert auch heute schon ganz oft, ohne dass eine zentrale IT das alles umsetzen muss!

Wer könnte gegen ein so modernes und verteiltes Konzept sein? Leider oft die IT, die damit ja gerade ihre Position als „Spinne im Netz“ verlieren soll. Und was ist ihr häufigstes Gegenargument? Ganz einfach, dass dann inkonsistente, unsaubere, duplizierte Daten entstehen; es fehlt ihnen die Data Governance. Aus der bisherigen, schlechten Erfahrung mit „Self Service“-Lösungen ist das absolut nachvollziehbar. Schließlich muss die IT dann im Ernstfall ausbaden, wenn man in Meetings verschiedene Berichte mit Zahlen betrachten muss, die nicht übereinstimmen!

Es muss also Regeln, Standards und vor allem Sicherheitsanforderungen geben. Aber man macht sie eben gemeinsam, föderal, als Verbündete! Und das Hauptziel ist dabei, dass man die Daten verschiedener Domänen leicht zusammenbringen kann, joinen, filtern, aggregieren. Es geht nicht darum, einzelne Gruppen an die Kette zu legen oder ihre Ergebnisse zu disqualifizieren. Das ist eine kommunikativ herausfordernde Aufgabe für ein Change Management!

Microsoft hat das auch erkannt, und bei Fabric jetzt mehr Governance-Funktionen in den Lizenzumfang aufgenommen, so dass nicht jede Organisation gleich das Vollprodukt für Governance, Purview, kaufen muss.

Die Begeisterung für Data Mesh ist ansteckend, so sehr, dass manche Jünger schon von „Seele, Herz, Körper und Geist“ einer solchen Lösung reden. Aber es einfach nur die Anwendung von vielem, was man in der Softwareentwicklung schon lange gelernt hat, wie man komplexe Produkte und die Arbeit daran dezentralisiert, parallelisiert und so besser skaliert. Warum sollten wir Analytics-Teams das nicht auch können, wo uns Microsoft jetzt auch noch eine maßgeschneiderte Plattform dazu hinstellt?