Data Mesh

Jochen Christ Hi. Hier ist Jochen. Das wird jetzt nicht ganz einfach, denn wie ihr vielleicht mitbekommen habt, ist Stefan am 10. August plötzlich verstorben. Stefan war für mich nicht nur ein Vorgesetzter und Mentor, sondern auch ein Vorbild, mit vielen Fragen, für mich auch moralisch prägend. Und er war ein Vordenker und großartiger Diskussionspartner, was moderne Softwarearchitektur und technologische Innovationen angeht. Es ist immer noch schwer zu begreifen, dass er nicht mehr da ist. Eine Woche vor seinem Tod hatten wir diese Podcastfolge aufgenommen und im Nachhinein ist die Aufnahme für mich persönlich auch ganz besonders wichtig, denn Stefan hatte mich und uns in den letzten zwei Jahren bei dem Thema immer unterstützt und alle Freiheiten gelassen, das zu tun, was wir für richtig hielten. Ich habe lange überlegt, ob wir die Aufnahme nun veröffentlichen oder ob wir das eher nicht machen sollten, denn einerseits ist es für manche bestimmt schwierig, die Stimme eines Verstorbenen zu hören, aber andererseits ist es auch ein Thema, das für Stefan wichtig war und in das er viel Zeit und Energie investiert hat. Stefan hat immer gesagt, macht das, was ihr für richtig haltet. Deshalb, liebe Hörerinnen und Hörer, entscheidet nun selbst, ob ihr die Folge hören wollt oder nicht. Macht das, was ihr für richtig haltet.

Podcast-Jingle

Stefan Tilkov Hallo und herzlich willkommen zu einer neuen Episode des INNOQ Podcasts. Heute ist mein Gast, mein lieber Kollege Jochen Christ. Hi, Jochen.

Jochen Christ Hi Stefan!

Stefan Tilkov Wie immer fangen wir doch am besten damit an, dass du dich kurz vorstellst und unseren Hörern erzählst, was du bei uns so tust.

Jochen Christ Ja, gerne. Ich bin Jochen, ich bin Berater bei der INNOQ und ich komme eigentlich aus der Softwareentwicklung, ich bin Java Entwickler, habe viel Software Architektur gemacht und seit zwei Jahren beschäftige ich mich intensiv mit Data Mesh. Ich bin zum Beispiel Mitautor gemeinsam mit Kollegen für eine Webseite datamesh-architecture.com. Und wir haben auch das Data Mesh Buch von Zhamak Dehghani übersetzt.

Stefan Tilkov Super. Damit sind wir auch schon beim Thema, um das es heute offensichtlich gehen soll, nämlich Data Mesh. Die erste und offensichtlichste Frage ist: Was um Himmels Willen ist das schon wieder?

Jochen Christ Data Mesh ist ein sozio-technischer Ansatz für eine dezentrale Datenarchitektur. Und da geht es an sich darum, dass die Ownership für analytische Daten an die Teams übergeben wird, die das größte Domain-Wissen haben. Ownership, was ist eigentlich Ownership? Ownership bedeutet im Deutschen so viel wie Verantwortung, aber auch Zuständigkeit. Und das heißt, dass die Teams mit ihren eigenen Daten analytisch arbeiten und auch innovative Daten entwickeln können. Man kann aktuell natürlich an so Dinge wie ChatGPT ganz schnell denken als generative AI, wo man die eigenen Daten nutzt, um coole neue Kunden-Features zu entwickeln.

Stefan Tilkov Okay, jetzt scheint mir der Unterschied genau dieses Ownership-Konzept zu sein. Vielleicht können wir da einen Schritt zurückgehen und sagen, wie das denn häufig ist oder was anders ist. Wie ist es denn normalerweise, wenn man in so einem Szenario ist, in dem man mehrere Teams hat. Das ist, glaube ich, eine Voraussetzung. Wie ist es denn normalerweise um die Daten dort bestellt?

Jochen Christ Ganz oft ist es so, dass wir sehen, dass es viele Softwareentwicklungsteams gibt, aber nur eine oder wenige Daten-Teams, oder BI-Teams Teams hießen die früher auch mal. Und man hat festgestellt, dass diese wenigen zentral organisierten Daten-Teams oft zu einem Flaschenhals wurden und dass die organisatorisch nicht skaliert haben und mit der Geschwindigkeit der Softwareentwicklungsteams mithalten konnten, wenn es darum ging, analytische Fragen zu beantworten und Erkenntnisse aus den Daten für das Unternehmen zu ziehen. Da war man einfach nicht schnell genug.

Stefan Tilkov Aber ist es denn nicht so, dass die Zentralisierung genau der Clou ist? Der Trick ist, den man macht, damit man alle Daten von allen zusammenbekommt, damit man aus dieser riesigen Menge von Daten tolle neue Erkenntnisse ziehen kann?

Jochen Christ Ja, eigentlich schon. Nur dummerweise ist es dann in der Praxis eben doch wichtig zu wissen, was die Daten denn ganz genau bedeuten und wie sie entstanden sind. Auch die Fehlerbedingungen, zum Beispiel, wann bestimmte Daten nicht entstanden oder wenn Prozesse schiefgelaufen sind, wie das dann eigentlich passiert ist. Und dafür ist dieses Domain-Wissen, das Fachwissen notwendig, damit Fachexperten auf die Daten gucken und daraus die richtigen Schlüsse ziehen können. Und dieses Fachwissen zu erarbeiten, ist für zentrale Teams ganz schwierig, wenn die eben ganz viele verschiedene Fachabteilungen oder Fachdomänen kennen müssen. Das hat eben nicht skaliert.

Stefan Tilkov Was du mir sagen willst, ist, dass es möglicherweise gar keine gute Idee ist, alle Daten von allen in einen riesigen Haufen zu packen und zu hoffen, dass sich daraus irgendein Sinn ergibt?

Jochen Christ Ja, genau. Das hat leider viel zu oft nicht funktioniert. Wir sehen, dass der Return of Investment von den Daten-Teams und Datentechnologien einfach häufig nicht gegeben ist. Der Business-Value war einfach nicht groß genug.

Stefan Tilkov Die Frage war natürlich extrem rhetorisch. Ich meine, das haben glaube ich alle schon gesehen, dass genau das passiert. Aber es ist doch trotzdem so, dass es eine Menge spezifischer Werkzeuge, spezifische Methoden, spezifische Ansätze gibt, die so ein Daten-Team unterscheiden von einem normalen Software-Entwicklungsteam? Wie wird das denn adressiert in diesem Data Mesh Ansatz?

Jochen Christ Was man versucht ist, die technische Komplexität herauszunehmen bei dem Arbeiten mit Daten. Bei zentralen Teams war das oft verknüpft. Das Technologiewissen und das Wissen, wie man mit Daten analytisch arbeitet. Das war alles mit zentralen Teams gemeinsam und mit Data Mesh versucht man jetzt durch eine Self-Servce Data Platform die technische Komplexität herauszunehmen, die durch eine Datenplattform bereitzustellen, sodass die Domänen Teams enabled werden, einfacher mit ihren Daten zu arbeiten und diese eben in Form von Datenprodukten zum Beispiel auch anderen zur Verfügung zu stellen.

Stefan Tilkov Vielleicht nehmen wir mal die Begrifflichkeit, die sich da etabliert hat. Es hat schon angefangen mit dem Datenprodukt. Woraus besteht so ein Data Mesh Konzept? Und was muss man kennen, wenn man sich damit beschäftigen möchte?

Jochen Christ Data Mesh hat Zhamak Dehghani vier Prinzipien genannt. Da gehen wir mal kurz durch. Das erste Prinzip ist ‚domain ownership‘. Das zweite ist ‚data as a product‘. Das dritte Prinzip ist die ‚self-service data platform‘. Und das vierte Prinzip ist die ‚federated computational governance‘. Und diese vier Prinzipien zusammen sind so die Kerndefinitionen von dem Data Mesh. Die muss man letztlich auch immer gemeinsam einführen, wenn man das machen möchte. Man kann sich nicht nur einzelne Prinzipien herauspicken, sondern diese Prinzipien ergänzen sich eben gegenseitig.

Stefan Tilkov Okay, wenn wir die der Reihe nach durchgehen und mit der Domain ownership anfangen, ist das die gleiche Domain, die wir auch bei Domain-driven Design sehen oder ist das was anderes, wovon wir hier sprechen?

Jochen Christ Ja, das ist im Wesentlichen die gleiche Domäne. Man unterscheidet dann noch ein bisschen in source-aligned und consumer-aligned Domänen oder Domänendaten. Source-aligned bezieht sich wirklich auf die Domänen auf der technischen Ebene, auch auf der Systemebene. Da, wo Daten anfallen und im Domain-driven Design versucht man eben diese Domänen zum Beispiel entlang einer Wertschöpfungskette oder der Customer Journey zu schneiden. Das sind genau die Domänen, die im Data Mesh auf der source-aligned Ebene auch gesehen werden. Aber bei Data Mesh erkennt eben auch sehr stark die Nutzersicht an. Zum Beispiel Management-Funktionen oder übergreifende Prozesse im Unternehmen, die Daten aus verschiedenen Source-Domänen benötigen, um dann übergreifende Auswertungen zu machen. Und diese Domänen werden auch als Domänen gekennzeichnet, die so im Domain-driven Design vielleicht nicht so explizit definiert werden.

Stefan Tilkov Stelle ich mir das so richtig vor, wie man sie heute glaube ich häufig hat, wenn ich so eine moderne Architektur habe, die eben sehr viel Wert auf autonome Teams legt, dann habe ich einen Haufen von möglichst Ende-zu-Ende orientierten Full-Stack, Value stream-oriented Blabla Teams. Also Teams, die möglichst komplett alles erledigen können, was sie brauchen, um Geschäftswerte zu liefern. Und es sind die gleichen Teams, die jetzt dann eben auch eine Verantwortung haben für ihre Daten, die da drin sind. Und ergänzt werden sie jetzt um Teams, die vielleicht gar nicht in der Hauptsache Software entwickeln, sondern eben analysieren oder andere Funktionen ausführen, wozu sie diese Daten brauchen. Ist das die richtige Vorstellung?

Jochen Christ Ja, genau.

Stefan Tilkov Zu den sieben Teams gibt es jetzt noch drei, die vielleicht eher Consumer sind. Heißt das so? Consumer, oder wie hießen die Dinger?

Jochen Christ Consumer-aligned.

Stefan Tilkov Okay, kann ich mir vorstellen.

Jochen Christ Ich glaube, es ist ein ganz gute Vorstellung, dass man sagt, die autonomen Teams, die wir in der Softwareentwicklung anstreben, die cross-funktional sind, die die Entwicklung machen, Devs, Back Entwicklung, DevOps, Security, die übernehmen jetzt auch die Verantwortung für analytische Daten.

Stefan Tilkov Okay, ist das der Teil, der das Ganze auch zu einem sozio-technischen Ansatz macht?

Jochen Christ Ja, genau. Es geht ganz stark um das Thema: Welche Teams übernehmen welche Verantwortungen für welche Daten? Das würde ich sagen. Das ist das Kernprinzip, immer ergänzt durch Teams, die supporting sind. Zum Beispiel Datenplattform Team oder in Governance Gruppe oder Enabling Team, die diesen Domänen-Teams, Team Topologies, Stream-aligned Teams einfach zuarbeiten, sie unterstützen, damit sie eben effizient Software und neue Features liefern können.

Stefan Tilkov Es ist interessant zu sehen, wie die Gedanken ineinandergreifen. Du hast die Topologies erwähnt, verlinken wir natürlich auch. Es ist ein Buch für die Hörer und Hörerinnen, die das nicht kennen, in dem sie sehr viel über so ein Team-First-Ansatz gesprochen wird. Das passt irgendwie ganz schön mit Domain-driven Design und mit Data Mesh zusammen und mit anderen Strömungen im Moment. Bedeutet das auch, dass ein Data Mesh, weil du hast gerade gesagt. Du hast gerade gesagt: Ich kann mir nicht einzelne Prinzipien rauspicken, sondern die gehören schon alle zusammen. Bedeutet das, dass Data Mesh nur ein guter Ansatz ist für Leute, die solche separaten autonomen Teams für eine gute Idee halten und das verfolgen?

Jochen Christ Vermutlich ja. Ich muss als Unternehmen bereit sein, die Verantwortung und die Autonomie, die Freiheitsgrade in die Teams zu geben. Ich brauche als Team auch die Kapazität, mir Gedanken zu machen. Was mache ich denn jetzt eigentlich mit meinen Daten? Wie kann ich Thesen bilden? Wie kann ich mir neue coole Features überlegen? Und dazu brauche ich eben auch die Kapazität, die Zeit, die Freiheit, mir selbst Gedanken zu machen. Und wenn ich eben sehr stark auch hierarchisch organisiert bin, wenn mein Backlog von außen vorgegeben wird für die nächsten ein, zwei Jahre und durch Roadmaps, dann bringt mir das auch nichts, wenn ich selbst mit Daten arbeiten kann, weil ich ja eh keinen Freiheitsgrad habe, mir zu überlegen, was eigentlich in meiner Domäne, in meiner Fachabteilung besser laufen kann.

Stefan Tilkov Okay, gut, dann bewegen wir uns auf das zweite Prinzip zu, oder?

Jochen Christ Das zweite Prinzip ‚data as a product‘. Ja, es ist nicht das gleiche: ‚data as a product‘ und Datenprodukt. Erst mal das Prinzip ‚data as a product‘. Da kommen die Gedanken aus Product Thinking rein, die wir in der Softwareentwicklung auch kennen. Softwareprodukte bauen, nicht mehr Projekte bauen. Und auf die Datenwelt angewendet bedeutet das eben: Daten so aufbereiten, dass andere Nutzer meine Daten gerne nutzen. Und auch eine Chance haben, sie zu verstehen. Stichwort Dokumentation, Schnittstellen, Beschreibungen. Vielleicht auch so ein Tutorial, wenn man so ein Terabyte weiße Daten hat in verschiedenen Tabellen, dass man den Nutzer auch eine Hilfestellung gibt. So ein Tutorial, wo denn die spannenden Daten vielleicht liegen und wie sie sinnvoll aggregieren werden können. Und dieses durch Confirmation-Trick-Thinking, also Aufbereitung von Daten ist wirklich der Kernpunkt des Prinzips Data als Erfolg.

Stefan Tilkov Das ist so ähnlich, wie ich mir überlege, wie ich zum Beispiel ein schönes User Interface baue oder vielleicht ein elegantes API designe. So ähnlich überlege ich mir jetzt, wie ich ein schönes Datenprodukt desinge. Schön klingt jetzt so rein ästhetisch, ich meine, dass ich ein gutes Datenprodukt designe. Jetzt habe ich schon wieder das Wort benutzt. Ich meine Daten wie ein Produkt gut aufbereitet. Okay, das kann ich verstehen. Warum jetzt dieser Unterschied zwischen Datenprodukt und Daten als Produkt?

Jochen Christ Der Begriff Datenprodukt hat sich auch etabliert und er meint aber eher die technische Sicht, wie ich Daten aufbereite. Das ist ja vergleichbar mit einem micro service self contained system in der Datenwelt. Eine logische Einheit um den bounded Kontext oder um eine bestimmte Dateneinheit, die für sich wertvoll ist und Sinn ergibt. Und dieses Datenprodukt enthält dann auch alle Funktionen, die ich brauche, um diese Daten meinen Nutzern zur Verfügung zu stellen. So Dinge wie Transformationslogik, so Dinge wie Dokumentation, natürlich Datenspeicher, interne Tabellen, aber eben auch Schnittstellen, Beschreibungen, meine Output Ports, die eben ganz klar die Schnittstelle, die API beschreiben, wie auf die Daten zugegriffen werden kann. Dinge wie Berechtigungen werden in dem Datenprodukt definiert und durch die Datenplattform dann ausgeführt und implementiert.

Stefan Tilkov Also stelle ich mir das richtig vor, dass ich, wenn ich als Team diesem Ansatz ‚data as a product‘ folge, dann baue ich als Ergebnis vielleicht ein oder mehrere Datenprodukte?

Jochen Christ Ja, genau.

Stefan Tilkov Okay. Dieses ‚data as a product‘ ist ja so ein bisschen eine Attitüde, so eine Philosophie, dass ich es ernst nehme, richtig? Stelle ich mir das richtig vor?

Jochen Christ Ja, auf jeden Fall.

Stefan Tilkov Okay, dann fehlt ja irgendwie als nächste Stufe sozusagen die konkrete Umsetzung. Und das bringt uns wahrscheinlich zu dem nächsten Prinzip.

Jochen Christ Genau, die konkrete Umsetzungen sind dann die Datenprodukte, die möglichst einheitlich und auch kompatibel sind. Ich möchte die Daten dann auch doch wieder verknüpfen, auch Domain-übergreifend verknüpfen. Da gibt es das dritte Prinzip des ‚self-serve data platform‘, die eben die notwendigen Capabilites zur Verfügung stellt, um so ein Datenprodukt zu entwickeln, zu planen und zu überwachen.

Stefan Tilkov Und das ist jetzt so wie früher bei einem ESB oder so, dass ich jetzt eine centralized data mesh engine brauche? Oder ist das was, was ich schon habe oder was benutze ich da als Plattform?

Jochen Christ Es gibt keine Data Mesh Plattform heute. Wir verwenden in der Plattform eigentlich die klassischen Daten Technologien. Data Warehouse oder Data Link Technologien. Aber wir kapseln sie stärker. Wir führen Information Hiding ein, zum Beispiel.

Stefan Tilkov Das ist etwas ganz revolutionär Neues. Wer hat sich das ausgedacht?

Jochen Christ In der Datenwelt ist das tatsächlich nicht so verbreitet.

Stefan Tilkov Ich weiß.

Jochen Christ Aber wir benutzen eben die bestehenden Datentechnologien. Cloud Anbieter helfen natürlich, weil ich das sehr viel einfacher skalieren kann und auch Self-Service Funktionen hinzufügen kann. Und das stelle ich eben als Plattform-Team meinen Software-Entwicklungsteams zur Verfügung. Häufig kommt man schon in Richtung Governance eben anhand gemeinsam vereinbarter Standards, dass man sagt: Hey, lasst uns doch alle Technologie A, B oder C verwenden.

Stefan Tilkov Was wäre denn so ein Beispiel? Was muss ich mir vorstellen? Was wäre eine Technologie dafür?

Jochen Christ Typische Technologien, die wir sehen, sind zum Beispiel Google BigQuery als Cloud Warehouse oder in Amazon sind wir oft in AWS3 einfach, S3 Buckets, wo Dateien abgespeichert werden und über eine distributed query engine, wie AWS Athena dann auch zugegriffen wird. Andere typische Anbieter sind noch Snowflake und Databricks.

Stefan Tilkov Und das sind natürlich immer die gleichen Anbieter, die man auch benutzen würde, wenn man einen dieser anderen Ansätze fährt, was ja das ist, was du gerade gesagt hast. Es sind nicht andere Tools, die wir benutzen, das sind Tools, die wir anders benutzen in diesem Ansatz.

Jochen Christ Genau. Ich glaube das ist ganz wichtig. Data Mesh ist keine neue Datentechnologie, sondern nur ein anderer Ansatz, wie ich mit Daten umgehe und wer die Verantwortung und Zuständigkeiten für Daten übernimmt.

Stefan Tilkov Das passt ganz gut zu meinem Bild, dass das Ganze praktisch als Synthese entstanden ist aus dieser Autonomiebewegung, die man seit einigen Jahren hat und der Weiterentwicklung der Datentechnologien in Richtung Cloud. Man hätte früher nicht jedem Team eine eigene Data Warehouse Installation verpasst. Das ist irgendwie nie eine Option gewesen, aber auf einmal kann man so was tun, weil es letztendlich nur bedeutet, dass sie Accounts bekommen, mit denen sie auf die Cloud-Dienste zugreifen können. Ist das eine richtige Annahme? Bedeutet Data Mesh in der Konsequenz automatisch eigentlich immer Cloud?

Jochen Christ Meistens ja. Wir haben ein gerade ein Projekt, das auch on prem funktioniert und da nutzen wir die Open Source Alternativen, die es zum Beispiel auch in dem AWS Stack verwendet werden.

Stefan Tilkov Okay, das ist eine private Cloud?

Jochen Christ Ja, oder die self-serve data platform, die dann natürlich mehr leisten muss, habe ich dann aber letztlich auch wieder diese self-serving Funktionalitäten.

Stefan Tilkov Ist das nicht eine enorme Lernkurve für die Teams, weil die auf einmal zusätzlich zu dem anderen Mist, den sie auch schon gerade gelernt haben, müssen Sie jetzt auch noch wissen, wie man diese Datenwerkzeuge benutzt?

Jochen Christ Ja. Das ist so, auf jeden Fall. Man muss jetzt noch einen weiteren Daten Stack verstehen. Glücklicherweise ist die Programmiersprache meistens SQL. Das können die meisten, das lernen sie in der Ausbildung.

Jochen Christ Ja, genau. SQL ist jetzt nicht so revolutionär. Und deswegen empfehlen wir auch immer keine zu komplizierten Datenplattformen einzuführen. Jetzt erst mal vielleicht auf einen Spark zu verzichten und erst mal nur über SQL und einfachen Tabellenstrukturen zu arbeiten. Damit kommen wir schon ziemlich weit. Was man auch braucht, ist eben noch ein BI-Tooling, was die grafischen Auswertungen ermöglicht, so dass man Charts bauen kann. Weil damit kann ich eigentlich recht einfach als Mensch Erkenntnisse treffen, Entscheidungen ableiten, wenn ich mir meine eigenen Daten anschaue, im Zeitverlauf oder Korrelationen bilde. Da helfen eben grafische Tools auch sehr stark. Und ich glaube, das ist ganz wichtig auch für die Akzeptanz, dass die Teams sich darauf einlassen und diese zusätzliche Aufgaben und das zusätzliche Tooling übernehmen lernen ist, glaube ich ganz stark, dass die Teams auch was davon haben, dass sie nämlich ihre eigenen Daten verstehen können, die in den verschiedenen Micro Services anfallen, auch verknüpfen können. Durch die Datentechnik kann ich sie viel einfacher verknüpfen, Joint Aggregation durchführen und dann eben für die eigenen User Stories auch eine Entscheidung ableiten. Das haben wir zum Beispiel im letzten Projekt gemacht werden, wir hatten BigQuery im Einsatz. Und sobald wir alle unsere Kafka-Nachrichten im BigQuery hatten, haben wir versucht jede User Story, die einen Stakeholder hatte mit Daten zu bewerten und zu qualifizieren. Das geht natürlich nicht immer, das sind immer neue Ideen, aber in der Hälfte der Fälle konnten wir eigentlich schon sagen: Diese User Story oder diese Idee betrifft im Monat nur zehn Kunden. Dafür implementieren wir jetzt keine User Story mit acht Storypoints oder sowas.

Stefan Tilkov Bei der Bewertung der Story könnte das also helfen.

Jochen Christ Ja.

Stefan Tilkov Verstehe, für mich wäre ein Beispiel Use Case. Entschuldigung, dass ich einfach dazwischen quassel, das schießt mir durch den Kopf, deswegen muss ich es eben loswerden. Wenn ich zum Beispiel, so wie du es gerade geschildert hast, entlang der User Journey aufgeteilt habe, dann habe ich vielleicht ein Ding, das kümmert sich um Checkout und Payment und da fallen einem offensichtlich ganz viele Dinge ein, die man da gerne darstellen und visualisieren würde. Aufteilung auf verschiedene Payment Verfahren oder die Anzahl der abgebrochenen Checkouts, also offensichtliche Anforderungen. Und wie du gesagt hast, die spielen eine Rolle für das Team, das diesen Teil macht. Das möchte gerne diese Erkenntnis haben. Die wissen auch am besten, wie man diese Information aus den Daten, die sie haben, gewinnt. Und die können das in grafischer Form zur Verfügung stellen, dass jemand sich diesen Report angucken kann und diese interaktive Grafik angucken kann. Oder sie können es als Rohdaten zur Verfügung stellen mit der definierten Beschreibung, sodass andere das in irgendwelche abgeleiteten Produkte einführen können, was eigentlich fast schon offensichtlich eine gute Idee ist. Es ist doch ganz klar, dass das was Gutes ist.

Jochen Christ Und trotzdem macht man in der Softwareentwicklung eigentlich einen großen Bogen darum. Ich habe das den letzten 15 Jahren immer versucht ein bisschen abzuwehren und diese Anfragen, die von Daten Teams kamen, gibt uns immer Zugriff auf Produktionsdatenbank, damit wir coole Auswertungen machen können. Und es war immer so: Nee, Zugriff auf unsere Produktionsdatenbank nicht so gerne. Aber dieser Erkenntnisgewinn ist dann doch extrem wertvoll, wenn man das mal gemacht hat und damit gearbeitet hat. Wenn die Hürde auch nicht so hoch ist, wenn man einfach an die Daten ran kommt oder an die Datenplattform reinkommen, dann ein paar SQL Statements schreiben kann.

Stefan Tilkov Gibt es in der Data Mesh Welt eine grundlegende Philosophie oder eine grundlegende Aussage dazu, ob diese Daten separate Daten sind oder direkt die OLTP Daten? Exportiert man und macht dann Analysen auf dem Exportierten oder hält Data Mesh sich da raus?

Jochen Christ Data Mesh hält sich dann ein bisschen raus, ob ich eine Virtualisierung nur mache oder ob ich eine Exzerption mache. Wir sehen eigentlich in der Regel, dass man Kafka-Nachrichten verwendet und die dann doch auf einen analytischen Speicher rüberzieht, einfach weil Kafka-Nachrichten inmutable sind und mit Datentechnologien kann ich dann doch viel viel schneller Joint Operationen durchführen und die dann spaltenbasierten Technologien vorlegen. Vielleicht auch noch, was auch noch dazukommt, gerade in den quellsystemnahen Datenprodukten. Ein Problem, womit die zentralen Teams immer kämpfen mussten, war das Cleaning von Daten. Wenn es Schemaänderungen gab oder technische Probleme und Daten sind mehrfach drin. Dieses Cleaning, diese Aufbereitung von Daten, das ist etwas, was man eben auch in den Domänen-Teams verankert, dass man sagt: Hey, mal wieder das Stichwort data as a product. Bereitet doch eure Daten so auf, dass andere sie gerne verwenden.

Stefan Tilkov Und der jetzt beginnt wie immer bei solchen Dingen dann damit, dass man sie selbst gerne verwenden möchte. Wenn man etwas für andere tut, kommt nur Murks dabei raus. Wenn man selber der eigene Kunde ist, dogfooding machen muss, dann fühlt sich das ganz anders an. Gibt es analog, wie bei anderen Dingen, Standards zur Beschreibung, auf die man zurückgreifen kann?

Jochen Christ Das hat uns auch überrascht. Dinge wie Open API, Swagger, AsyncAPI hätten wir eigentlich erwartet und die sind gerade im Entstehen. Es entstehen gerade Standards für Datenprodukt-Spezifikationen, wo ich die Output Ports dann eben auch beschreibe, die Daten syntaktisch und auch semantisch beschreibe, Daten Qualitätszusagen gebe. Wie oft werden Daten aktualisiert? Und da entstehen gerade die ersten Standards-Spezifikationen. Und das gleiche gilt auch für Datenkontrakte. Dass man wirklich die Vereinbarung zwischen zwei Teams über die Verwendung und die Nutzung von Daten, die dann halt auch aussagen: Wofür darf ich denn die Daten eigentlich verwenden? Weil das ist noch mal speziell in der Datenwelt im Vergleich zur Service Welt. Wenn ich nämlich Kundendaten habe, dann darf ich damit vielleicht keine Korrelation machen, oder SWAT Analysen sind vielleicht auch sehr eingeschränkt. Stichwort Consent Management.

Stefan Tilkov Ja, passt ganz gut möglicherweise als Überleitung zum vierten Prinzip.

Jochen Christ Ja, ‚federated computational governance‘ versucht jetzt eben diese Dezentralisierung, die wir sehen, soweit in den Griff zu bekommen, dass man gemeinsame Standards definiert für die Interoperabilität, für die Dokumentation, für die Nutzung von Daten, aber auch Vorgaben gibt in Richtung Privacy Security Compliance, dass man sagt: Ihr dürft vielleicht keine persönlichen Informationen in euren Output Ports zur Verfügung stellen bzw. nur dann, wenn ihr genau den Zweck der Datenverarbeitung geklärt habt. Solche Dinge. Und was sehr interessant ist, Zhamak schlägt da eben auch ein federated Ansatz vor. Keine zentrale Governance, sondern förderiert im Sinne von: Die beteiligten Domänen Teams und deren Product Owner kommen zusammen und vereinbaren gemeinsame Regeln, Global Policies, basierend auf ihren Anforderungen oder ihren Problemen, die sie in der Arbeit im Data Mesh haben. Und definieren gemeinsame übergreifende Regeln. Das ist übrigens auch etwas, was wir aus der Software Architektur kennen. Makroarchitektur Richtlinien und Toolings wie Architecture Design Records oder RFCs, wo man eben solche Regeln versucht zu formulieren, zu begründen und die Konsequenzen dann auch zu beschreiben.

Stefan Tilkov Wir sagen oft in irgendwelchen Vorträgen, dass es Voraussetzung für Autonomie ist, dass es wenige klare, gut durchgesetzte Regeln gibt, damit der ganze Kram doch wieder zusammenpasst und dass es da sicher nicht anders sein wird.

Jochen Christ Genau. Vielleicht noch der zweite Aspekt. Dieser Computational Aspect, was Zhamak auch sehr betont, ist, dass man versucht, die Regeln, die man sich auferlegt, möglichst durch die Datenplattform zu automatisieren, damit man sich, wenn man die Plattform nutzt, sich über sie eigentlich gar keine Gedanken machen muss, weil die Plattform sie eh einhält. Ich muss sie nur noch konfigurieren und dann wird das eingehalten.

Stefan Tilkov Das wäre dann vermutlich so was, wie wenn es so einen Beschreibungsstandard gäbe, dass da ein Produkt ist, beschrieben mit diesen und jenen Standards und hält sich an folgende Policies. Und dann würde die Plattform das enforcen. Was sagt man auf Deutsch? Schrecklich - durchsetzen, sicherstellen.

Jochen Christ So eine klassische Policy, persönliche Informationen müssen getaggt werden in der Spezifikation. Und die Plattform stellt sicher, dass da kein öffentlicher Zugriff auf diese Daten möglich wird oder sogar die Plattform erkennt persönliche Informationen anhand bestimmter Muster, Mailadressen, Kreditkartennummern und so weiter und stellt sicher, dass Tech vorhanden ist und gibt eine Warnung aus.

Stefan Tilkov Das Ganze ist ein überaus großes Thema. Ich glaube, wir könnten problemlos jetzt die 3-Stundenvariante und die 12- Stundenvariante, die 3 Tage-Variante der Diskussion aufnehmen. Das tun wir nicht, sondern wir verlinken auf ganz viel. Kannst du vielleicht ein bisschen sagen, was wir so verlinken werden, wo man starten könnte, wenn man sich mit dem Thema beschäftigen möchte?

Jochen Christ Man sollte auf jeden Fall das Buch von Zhamak Dehghani lesen, auf Englisch oder auf Deutsch. Das ist sicher der zentrale Einstieg. Wenn man über das Thema spricht, sollte man es einfach gelesen haben. Dann würde ich noch mal auf unsere Webseite datamesh-architecture.com verweisen, wo wir dann eben auch stärker aus der Engineering Brille auf das Thema gucken, auch verschiedene Text Decks vorstellen, die wir sehen bei unseren Kunden. Und wer noch mehr wissen möchte, wir bieten auch ein 2-Tages-Training bei socreatory zu Data Mesh an, vielleicht ist es auch für jemanden interessant.

Stefan Tilkov Und einen kurzen Plug müssen wir auch noch machen. Ihr habt tatsächlich auch so etwas wie ein Produkt entwickelt. Das müssen wir zumindest kurz in den Werbeblock aufnehmen. Den Data Mesh Manager. Willst du dazu auch noch 30 Sekunden was sagen?

Jochen Christ In unseren Beratungsprojekten haben wir festgestellt, dass einfach ein gutes Tooling für die Verwaltung von Datenprodukten ein Data Mesh fehlt. Und deswegen haben wir mit dem Data Mesh Manager eine SaaS Anwendung entwickelt, um Datenprodukte und deren Abhängigkeiten zu verwalten und auch die Datenprodukte für andere leichter zugänglich zu machen, indem man zum Beispiel ein Produktinventar aufbaut. Und wir haben so eine grafische Übersicht aller Datenprodukte und deren Abhängigkeiten implementiert. Die Dokumentation der Datenprodukte, der Output Ports, der Schema und mit Beispieldaten eben sichtbar. Das zweite sind eben Datenkontrakte abzuschließen. Wenn ich als Nutzer auf ein Datenprodukt von einem anderen Team zugreifen möchte, dass ich dann mit dem Data Mesh Manager die Möglichkeit habe einen Datenkontrakt abzuschließen, mit einer Beantragung und einem Freigabe-Workflow. Und dann kann ich diese Datenkontakte nutzen, um auch automatisiert zum Beispiel Berechtigungen anzulegen. Dass ich in der Datenplattform automatisiert in eine Berechtigung übersetze. Und auch ein Contract Testing haben wir implementiert. Und wenn wir feststellen, dass sich ein Output Port verändert und Kontrakte verletzt werden, dann gibt es eine Warnung. Da habe ich eine sehr hohe Confidence, dass meine Kontrakte eingehalten werden, wenn ich welche abgeschlossen habe.

Stefan Tilkov Das verlinken wir natürlich auch. Wer sich dafür interessiert, kann uns natürlich auch gerne jederzeit kontaktieren. Cool. Shownotes füllen wir entsprechend mit all den Verweisen. Ich denke, es war ein schöner Einstieg. Ich danke dir sehr, Jochen, und ich danke unseren Hörerinnen und Hörern fürs Zuhören und sage: Bis zum nächsten Mal.

Jochen Christ Bis dann, ciao.