In diesem Artikel befassen wir uns genauer mit dem Grundprinzip Self-serve Data Platform. Wir werden Problematiken adressieren, die im Zusammenhang mit den ersten beiden Grundprinzipien, Domain Ownership und Data as a Product, einhergehen können, etwa duplizierter Aufwand für jedes Domain-Team, erhöhte Kosten sowie Inkonsistenzen und Inkompatibilität zwischen den Domain-Teams.
Motivation
Folgende Aspekte motivieren das Erstellen einer Self-serve Data Platform:
- Die Gesamtkosten von dezentraler Datenverantwortung senken
- Die Komplexität der Datenverwaltung abstrahieren und die Aufwände für die Domain-Teams im Hinblick auf die Verwaltung des gesamten Lebenszyklus ihrer Data Products senken
- Die Notwendigkeit für Spezialisierung reduzieren und damit eine größere Gruppe von Entwicklern ansprechen und mobilisieren
- Richtlinien automatisieren, um Standards für alle Data Products herzustellen
Standardisierung von technologischen Lösungen
Eigenschaften der Self-serve Data Platform
Bereits existierende Datenplattformen besitzen Fähigkeiten wie z.B. das Speichern analytischer Daten, Frameworks zur Datenverarbeitung, Data Query Languages, Datenkataloge oder eine Pipeline-Workflow Verwaltung und die können die Basis für eine Self-serve Data Platform bilden. Die Self-serve Data Platform, auch schlicht Data Mesh Plattform genannt, behält viele dieser Fähigkeiten bei, jedoch werden wir feststellen, dass sich die Herangehensweise und die Zielsetzung unterscheidet. Im Folgenden fassen wir die wichtigsten Eigenschaften der Self-serve Data Platform zusammen:
Die Hauptaufgabe der Data Mesh Plattform besteht darin, den Entwicklerteams der Domains zu ermöglichen, ihren neuen Verantwortungen gerecht zu werden. Dazu zählen Aufbau und das Nutzen von Data Products, Daten von operativen Systemen oder sonstigen Quellen einzufangen oder das Transformieren und Teilen von Data Products. Die Plattform muss den Teams all dies auf autonome Art und Weise ermöglichen, ohne jegliche Abhängigkeit von zentralen Daten-Teams oder sonstigen Vermittlern.
Mit Data Mesh steht ein neues, Domain-orientiertes Konstrukt im Mittelpunkt der Datenarchitektur, das Data Product. Die Data Products sind vernetzt und teilen Daten untereinander. Die Data Mesh Plattform muss mit diesem Konstrukt umgehen und die Verwaltung dessen autonomen Lebenszyklus und den all seiner Komponenten unterstützen.
Mit dem Prinzip Domain Ownership wird es den autonomen Domain-Teams ermöglicht, ihre Daten ganzheitlich selbst zu verwalten. Dadurch schließt sich organisatorisch die Lücke zwischen analytischer und operativer Ebene. Dementsprechend muss die Data Mesh Plattform auch eine einheitliche User-Experience bieten. Data Products und ihre entsprechenden Microservices sollten reibungs- und komplikationslos miteinander kollaborieren können. Die Art und Weise dieses Zusammenwirkens sollte für die Domain-orientierten Daten- und Entwickler-Teams natürlich erscheinen.
Heutige Data Platforms haben oft das Problem, dass sie ein hohes Maß Spezialisierung erfordern, wodurch Rollen wie die des Data Engineers entstehen. Diese nicht skalierbare Spezialisierung sollte jedoch keine Notwendigkeit darstellen und ist begründet in einem Mangel an Standards und Konventionen, einem Mangel an Impulsen für technologische Kompatibilität und einem Mangel an Anreiz für Produkte, die einfach zu nutzen sind. Eine Data Mesh Plattform muss dieses Muster durchbrechen. Sie muss Konventionen einführen, die Kompatibilität sowie einfach zu lernende Sprachen und APIs in den Mittelpunkt stellen, damit ein möglichst breites Spektrum an Technologen mitgenommen und eingebunden werden kann.
Der Grund für Data Mesh’s Augenmerk auf der Dezentralisierung über die Domain Ownership ist das Verhindern von organisatorischer Synchronisation und Bottlenecks, die letztendlich die Geschwindigkeit verringern, mit der Veränderungen möglich sind. Dieser Aspekt muss sich auch in der Data Mesh Plattform widerspiegeln, da die zugrunde liegende Technologie direkten Einfluss auf organisatorische Kommunikation und Design hat. Die Kunst des Aufbaus einer solchen Plattform ist es also, eine zentrale Verwaltung der zugrundeliegenden Ressourcen für autonome, dezentrale Domain-Teams zu erreichen.
Wir trennen klar zwischen den Domain-Teams, welche verantwortlich für das Erschaffen von Produkten und Services sind, und den Plattform-Teams, welche die Domain-Teams die technischen Möglichkeiten zur Verfügung stellen. Die Plattform-Teams befassen sich nicht konkret mit den analytischen Daten der Domains wie es bei zentralen Daten-Teams der Fall ist. Das muss sich auch in den Fähigkeiten der Plattform widerspiegeln. Die Plattform muss die Balance halten zwischen Domain-unabhängigen Fähigkeiten und der Möglichkeit, Domain-spezifisch Daten zu modellieren, zu verarbeiten und zu teilen.
Die Ziele der Data Mesh Plattform
Wir befassen uns nun noch etwas konkreter mit der Zielsetzung des Prinzips Self-serve Data Platform. Im Folgenden sind einige Aspekte hierzu aufgelistet:
Beim Designen der Plattform ist es hilfreich sich die verschiedenen Rollen der Plattformnutzer vor Augen zu führen. Betrachten wie etwa den Data Product Developer, verantwortlich für die Verwaltung des Data Products über dessen Lebenszyklus hinweg, so wird klar, dass die Plattform alle für das Aufbauen, Testen, Deployen, Sichern und Aufrechterhalten von Data Products notwendigen Fähigkeiten implementieren muss. Betrachten wir dagegen die Nutzer der Data Products, so ist von Bedeutung, dass die Notwendigkeit von manuellen Eingriffen reduziert wird, um einen reibungsfreien Ablauf zu gewährleisten. Beispielsweise sollten Zugriffsberechtigungen automatisiert werden.
Betrachten wir wiederum die verschiedenen Rollen der Plattformnutzer, Data Product Owner, Data Product Developer und Data Product Nutzer, so ist ersichtlich, dass wir zusätzlichen Wert aus unseren Daten gewinnen können, wenn wir direkte Interaktionen zwischen diesen Rollen ermöglichen.
Die Data Mesh Plattform reduziert die kognitive Belastung durch Abstrahieren von Komplexität, indem sie Details und Informationen über die Art der Implementierung versteckt. Den Entwicklern sollte ein deklaratives Modellieren, etwa das Erklären der Struktur der Daten, der Laufzeit oder der möglichen Größe, ermöglicht werden, ohne dass die Art und Weise, das tatsächliche Erstellen der Datenstruktur, das Anlegen des Speichers, etc., für sie eine Rolle spielt. Die bereits angesprochene Automatisierung, beispielsweise von Datenverifizierungen, kann ebenso dazu beitragen, die Komplexität zu verringern.
Um das Teilen von Daten skalierbar zu gestalten, benötigen wir Standards für kompatible technologische Lösungen. Wir benötigen eine allgemeingültige Sprache und verständliche APIs, damit die verschiedenen Services der Plattform zusammen funktionieren können. Dies ist notwendig, um der Plattform die gewünschten Fähigkeiten, etwa das Überwachen von Data Products über das gesamte Netz hinweg, zu verleihen. Ohne derartige Standards werden wir wieder in alte Muster verfallen und eine monolithische Struktur begünstigen, die das Teilen von Daten schwierig macht.
Mit der Data Mesh Plattform sollen schnelle build-measure-learn-Zyklen möglich werden. Durch das Reduzieren von Komplexität befreien wir die Domain-Teams von unnötiger Arbeit und ermöglichen mehr Kreativität und das Experimentieren mit Ideen. Das ist wichtig, da kontinuierliche Innovation gerade heutzutage eine Kernkompetenz von Unternehmen sein sollte.
Übergang zu einer Self-serve Data Platform
In diesem Abschnitt befassen wir uns mit dem Übergang hin zu einer Data Mesh Plattform. Unabhängig davon, ob eine Plattform aufgebaut wird, gekauft wird oder beides, gibt es einige Aspekte, die zu beachten sind:
Beginne mit dem Aussuchen und Designen der Interfaces, die die Nutzer zu Gesicht bekommen. Unabhängig von Kommandozeile oder grafischem Interface, entscheide zunächst über die genutzten APIs. Dazu kommt noch die Wahl der Protokolle und das Setzen von Standards, um die Kompatibilität von Grund auf zu gewährleisten.
Beim Auswerten verschiedener Plattformtechnologien sollten diejenigen bevorzugt werden, die gängige, weitverbreitete Programmiersprachen ermöglichen, um möglichst viele Entwickler mit einbeziehen zu können. Die Plattform muss ein breites Spektrum an Data Product Developers im Hinblick auf deren Spezialisierung und die verschiedenen Arten an Data Products abdecken und bedienen können.
Mit Data Mesh und dem Konzept der Data Products sorgen wir für eine engere Zusammenarbeit zwischen der analytischen und der operativen Ebene. Dadurch bietet sich auch die Gelegenheit der Vereinfachung. Diese Gelegenheit sollte genutzt werden, um eine Bestandsaufnahme der Plattform-Services zu machen, zu vereinfachen und Duplikate zu entfernten, da operative Technologien oftmals auch analytische Aufgaben übernehmen können.
Um mit dem neuen Objekt Data Product gut umgehen zu können, bedarf es High-Level APIs, die das Arbeiten mit Data Products abstrahieren. Sinnvoll sind beispielsweise APIs, die Data Products erschaffen, entdecken, vernetzen, lesen oder sichern.
Anstatt eine Plattform mit Mechanismen wie etwa einem Datenkatalog zu bauen, sollte das Erlebnis der Nutzer im Vordergrund stehen. Beispielsweise sollte das Entdecken von Data Products einfach gestaltet sein, während die Mechanismen dieses Erlebnis dann nur ermöglichen sollen.
Der Übergang zu einer Data Mesh Plattform kann in kleinen Schritten gegangen werden. Data Mesh Strategien können angewendet werden, ohne dass eine Data Mesh Plattform bereits vorhanden ist. Die Data Mesh Plattform selbst ist als ein (internes) Produkt zu sehen, das kontinuierlich weiterentwickelt wird. Ein grundlegendes Framework kann der Beginn einer Data Mesh Plattform sein und bereits einige Fähigkeiten bieten. Mit der Entwicklung von Data Products und Standards kann auch die Data Mesh Plattform weiterentwickelt werden und ihren Nutzen entfalten.
Zusammenfassung
Der Kern dieses Prinzips besteht darin, eine Plattform mit Services für die Domain Teams zur Verfügung zu stellen. Die Services verwalten den gesamten Lebenszyklus der Data Products und ein zuverlässiges Netz aus miteinander verbundenen Data Products. Sie streamlinen die Erfahrung sowohl der Anbieter als auch der Nutzer der Data Products im Hinblick auf Aufbau und Instandhaltung sowie Zugang und Verwendung.