Obwohl ich beruflich viel mit Daten und Analysen beschäftigt bin, habe ich das Data Mesh erst in jüngerer Zeit als das wahrgenommen, was es wahrscheinlich ist: Das kommende Paradigma für die Nutzbarmachung von heterogenen Unternehmensdaten.

Der Begriff des Data Mesh ist verbunden mit Zhamak Dehghani und ihren Arbeiten zu Definition und anwendbaren Prinzipien des Paradigmas. Dieser Informationsschatz war mir bislang unbekannt, ich habe das Data Mesh als Buzzword des Tages abgetan und mich realen Dingen zugewandt.

Aber das Buzzword blieb, und so habe ich mich einmal eingelesen. Aber trotz der guten Konzepte, Diagramme und der klaren Struktur blieb ein Gefühl von „das hatten wir doch schon mal …“

In einer Phase, die auch mal Zeit zur Reflexion der eigenen Karriere erlaubt, fiel mir auf, dass sich hier ein Kreis schließt. Die GEOSS Plattform (2005 entworfen, 2015 abgeschlossen) kann als frühe Implementierung eines Data Meshs angesehen werden!

Im Titel heißt es „unerwartet“, weil die Technologien und die schiere Größe von GEOSS mit dem Data Mesh nur wenig gemeinsam haben. Hier geht es vor allem um die Gemeinsamkeiten und die Lektionen, die sich daraus ergeben.

Im Folgenden setze ich Kenntnisse über die Konzepte des Data Mesh voraus.

GEOSS, eine frühe Implementierung des Data Mesh

GEOSS ist das Group on Earth Observations System of Systems. „System of Systems“ – wer hier an Microservices denkt, liegt für diese Betrachtung gar nicht so falsch. Über diese Parallele zum Data Mesh wurde aber sicher schon genug geschrieben.

Das Projekt hat das Ziel, die zivilen Erdbeobachtungsdaten der Mitgliedsstaaten zu bündeln, besser verfügbar und nutzbar zu machen. Dabei geht es zum Beispiel um Satellitenaufnahmen und Photogrammetriedaten. GEOSS ist ein Data Mesh für die Erdbeobachtung, wenn man so will.

Die Group on Earth Observations in GEOSS ist eine Gruppe von über 100 Staaten und der Europäischen Kommission. GEOSS dürfte daher mindestens zwei Größenordnungen über der Größe eines Data Mesh Projektes in einer Firma oder einem Konzern liegen. GEOSS ist also sowohl in der Zeit als auch in der Größe eine interessante Quelle, um daraus für das Data Mesh zu lernen.

Ich durfte mehrere Jahre an diesem faszinierenden weltweiten Projekt mitarbeiten und habe in dieser Zeit unglaublich viel gelernt. Noch heute fällt es mir deshalb leicht, die Parallelen in der Architektur des Data Meshs und GEOSS herauszuarbeiten.

Das ist eine interessante Übung, weil sie den Wissenstransfer von GEOSS auf das Data Mesh ermöglicht. In diesem Artikel möchte ich zeigen, dass auch nützliches Wissen für Data Mesh Projekte dabei abfallen kann.

Die Größe von GEOSS erklärt vielleicht, warum ein so viel früher (2005) begonnenes Entwicklungsprojekt die Konzepte des Data Mesh (2019) implementiert. Sie sind offenbar ab einer gewissen Datenmenge praktisch erforderlich. Das kann auch als eine Validierung des Data Mesh gesehen werden.

Die folgende Tabelle führt die Analogie näher aus:

Die Entsprechungen naher auszuführen würde hier den Rahmen sprengen. Zu beachten ist aber, dass die Erdbeobachtung den Begriff des Kartenproduktes oder Geoinformationsproduktes schon lange kannte; GEOSS fügt nur die Integrationsebene, also Self-serve Data Platform und Federated Computational Governance hinzu. Neben diesen eventuell streitbaren konzeptionellen Ähnlichkeiten finden sich aber auch in den Details viele Beispiele, die zeigen, wie ähnlich GEOSS dem Data Mesh war bzw. ist.

Das zeigt sich z. B. im Bereich Federated Governance zum Thema Datenqualität sehr klar. Das dem vor-Mesh Zeitalter zugerechnete zentrale Datenteam ist verantwortlich für die Einhaltung von Datenqualität. Im Mesh ist die zentrale Governance „Responsible for defining how to model what constitutes quality“.

Das war auch ein wichtiger Teil des Projekts GeoViQua, in dem ich an GEOSS mitwirken konnte. Datenqualität sollte beschreibbar, messbar und verbesserbar werden. Entstanden ist das Projekt nicht zuletzt, weil das natürlich nicht der Fall war. So global, verteilt und heterogen wie GEOSS ist, kann eine Modellierung von Datenqualität nur über Standards wie ISO 19157 funktionieren. Damit ist dem Anspruch „defining how to model what constitutes quality“ des Data Meshs mehr als entsprochen.

GEOSS ist wohl etwas zu groß, aber das soll hier nicht Thema sein. Die Größe kann aber ein Faktor sein, der die folgende Betrachtung möglicherweise einschränkt.

L’enfant terrible: Datenqualität

Metadaten zur Datenqualität, Qualität der Metadaten, Messverfahren zur Bestimmung von Metriken und KPIs – man kann vieles machen, aber die Datenqualität entzieht sich oft den wohlgemeinten Maßnahmen. Die zugrundeliegenden Verfahren und Metadaten sind oft zu einfach für den einen Benutzer oder zu kompliziert für den Anderen. Viel Energie verpufft nutzlos, weil Probleme in der Datenqualität zu spät werkannt werden.

Ich wage die These, dass auch im Data Mesh und seiner durchaus richtigen und wichtigen Zuweisung des Themas Datenqualität an das Datenprodukt die Datenqualität nichts von ihrem Status als Enfant terrible der Datenanalyse verlieren wird.

Die Ursache sehe ich in der Diversität der Daten und Nutzungsmuster. Nicht-triviale Qualitätsprobleme fallen fast immer erst in der domänenübergreifenden Verwendung für analytische Zwecke auf. Wenn Datenproduzent und Datennutzer aus verschiedenen Domänen kommen, kann das zu sehr unterschiedlichen Ansprüchen an die Datenqualität führen. Und an dieser Stelle schaut das alte Data Warehouse durch das Fenster und winkt uns mit seinem analytischen Schema, nur gut getarnt als Qualitätsanspruch an das Datenprodukt.

In der Erdbeobachtung begegnet man dem z. B. mit Verarbeitungsstufen (Data Processing Levels), aber das stellt keine allgemeine Lösung dar.

Etwas allgemeiner ausgedrückt wird Qualität am Ende durch den Benutzer bestimmt, und Datenqualität ist hier keine Ausnahme. Neben Feedback ist hier ein klares Vorgehen gefragt, um das Datenprodukt nicht mit auseinanderlaufenden Benutzerkriterien zu überfrachten und damit die Probleme des Warehouse wieder zu importieren.

Als jemand, der am Benutzerfeedback in GEOSS gearbeitet hat, befinde ich das Data Mesh im Bereich Datenqualität noch als ausbaufähig. Hier ist sicherlich noch Bedarf an kreativen Ansätzen und Lösungen.

Zusammenfassung

Das Data Mesh ist ein moderner organisatorischer und technischer Ansatz, Unternehmensdaten nutzbar zu machen. Es adressiert die Schwächen seiner Vorläufer Data Warehouse und Data Lake. Es ist vermutlich ein gutes Zeichen, dass seine Ziele auch in deutlich größerer, wirklich globaler Skala mit grundsätzlich sehr ähnlichen Mitteln verfolgt werden. Kleinere Projekte müssen hier aber genau hinschauen, welche Konzepte für sie passen.

Wenn die Analogien tragen, dann wird Datenqualität aber kaum zu den Themen gehören, von denen man einmal sagen wird, das Data Mesh habe sie lösbar gemacht. Die Verantwortung für Datenqualität zum Produzenten zu schieben ist richtig, aber nicht neu und in der Praxis nicht genug. Ob das in einem Data Mesh Projekt als Problem auftaucht, dürfte vor allem davon abhängen, welche anspruchsvollen domänenübergreifenden Nutzungsszenarien es für die Datenprodukte gibt. Im Zweifel gibt es dann Bedarf für kreative Ansätze und Lösungen zum Thema Datenqualität.

Ausblick

GEOSS hat zwar als internationales Entwicklungsprojekt seine ganz eigenen Probleme, welche die Möglichkeit eines Wissenstransfers einschränken. Die relative Offenheit, mit der Probleme in dem Umfeld benannt werden und die große Ähnlichkeit zu moderneren Ansätzen im Data Mesh machen es aber zu einer über die Erdbeobachtung hinaus interessanten Quelle für Inspiration. Andere transferierbare Themen sind z. B. das Zitieren von Daten, Fremdschlüssel, Metadatenqualität und die Auffindbarkeit von Datensätzen.

Erdbeobachtung und Geoinformation waren schon immer „Big Data“. Dass sich die Lösungsmuster im weiteren Feld der Datenverarbeitung an die der Erdbeobachtung angleichen, ist vielleicht nur eine Frage der Zeit gewesen. Die Zeit wird zeigen, ob „Data Mesh Produkte“ so eine Transformation vereinfachen können.

In der Praxis sehe ich aktuell eine relativ langsame Aufnahme von Data Mesh Konzepten. Wenn Ihre Organisation über Data Lake oder Warehouse hinaus wachsen will, kann sich ein Rückblick auf die Vorläufer durchaus lohnen.