Mit dem Begriff Data as a Product ist ein Produktdenken in Bezug auf Daten gemeint. Daneben wird mit dem Begriff Data Product die technische Komponente bezeichnet, die dieses Produktdenken umsetzen und im Data Mesh realisieren soll.
Wesensmerkmale eines Produkts
Ein Produkt muss im Wesentlichen drei Eigenschaften besitzen: nutzbar, wertvoll und realisierbar (original: usable, valuable & feasible). Damit ein Produkt Erfolg haben kann, muss man es nutzen können. Ein Produkt muss einen Wert vorweisen, damit es nützlich ist. Die Herstellung eines Produkts muss praktikabel sein, damit es erfolgreich sein kann.
Motivation
Die Ziele, die man mit Data as a Product erreichen möchte, sehen wie folgt aus:
- Die Möglichkeit von Domain-orientierten Datensilos beseitigen, indem das Verhältnis von den Teams zu den Daten verändert wird. Daten werden wie ein Produkt bereitgestellt, inklusive Qualitätszusicherungen, anstatt nur eingesammelt und in einem zentralen Datentopf gelagert zu werden.
- Das Erschaffen einer von Daten angetriebenen Innovationskultur, indem das Finden und das Nutzen von qualitativ hochwertigen Daten standardisiert wird – Peer-to-Peer und reibungsfrei.
- Das Erzeugen von Resilienz gegenüber Veränderung durch das Isolieren der einzelnen Data Products, damit die Veränderung des einen nicht die Destabilisierung des anderen zur Folge hat.
- Zusätzlichen Wert von Daten bekommen, indem die Daten über organisatorische Grenzen hinaus geteilt und genutzt werden.
Produktdenken in Bezug auf Daten
Mit Data as a Product wird die Erwartung formuliert, Daten wie ein Produkt zu behandeln und deren Nutzer wie Kunden. Data as a Product soll vor allem den Wert und die Nutzbarkeit von Daten steigern, während hingegen die Realisierbarkeit vor allem beim nächsten Grundprinzip Self-serve Data Platform behandelt wird. Das Ziel ist außerdem, die Kosten und den hohen Aufwand standardmäßiger analytischer Datenarchitekturen zu senken, denn Probleme näher an der Quelle zu lösen ist günstiger und effektiver. Operative Teams sollen ihre Daten nicht als Nebenprodukt betrachten, sondern Produktdenken auf die analytischen Daten anwenden, Verantwortung übernehmen und das bestmögliche Erlebnis für deren Nutzer anstreben.
Wir widmen uns den acht grundlegenden Eigenschaften nun näher, die ein Data Product mit sich bringen muss, um als solches zu gelten:
Eine traditionelle Lösung ist ein zentrales Register oder ein Katalog, in dem alle Datensätze mit zusätzlichen Informationen aufgelistet sind, z.B. Besitzer, Ort, etc. Ein Data Product soll hingegen selbst Informationen zur Auffindbarkeit bereitstellen. Informationen wie Herkunft, Besitzer, Runtime Infos sowie Nutzerinformationen, beispielsweise Top Use Cases oder ermöglichte Applikationen, sollen während des Lebenszyklus – build, deploy, run – kontinuierlich geteilt werden.
Ein Data Product besitzt eine permanente und einzigartige Adresse, damit die Datennutzer dieses programmatisch oder manuell erreichen können. Dadurch wird die kontinuierliche Nutzbarkeit des Data Products gewährleistet, auch wenn einige Aspekte des Data Products dem Wandel unterliegen, wie etwa Semantik, Syntax, neue Zugänge/Suchmöglichkeiten, etc. Die einzigartige Adresse muss globalen Konventionen folgen, um die Erreichbarkeit aller Data Products zu sichern. Das Data Product soll über eine erreichbare Wurzel verfügen, welche einen Überblick über alle Informationen zum Data Product geben soll, beispielsweise Dokumentation, SLOs und die beinhalteten Daten.
Die Nutzer müssen die Bedeutung des Data Products verstehen können, welche Gebilde das Data Product umfasst sowie deren angrenzende Data Products. Die Nutzer müssen verstehen können, wie ihnen die Daten präsentiert werden, wie sie syntaktisch auf die Daten zugreifen und sie durchsuchen können. Idealerweise werden diese Informationen durch beispielhafte Datensätze und Code-Beipiele angereichert.
Die Datennutzer müssen darauf vertrauen können, dass die Daten der Wahrheit entsprechen. In traditionellen Architekturen ist dies die Aufgabe der zentralen Daten-Teams und Pipelines – aufgenommene Daten bereinigen. Data Mesh hingegen legt die Verantwortung den Besitzern des Data Products auf. Diese müssen ein akzeptables Maß an Qualität und Vertrauenswürdigkeit gewährleisten und kommunizieren. Das bedeutet, die Daten müssen bereinigt werden, Integritätstests müssen durchgeführt werden und die Herkunft der Daten muss einsichtlich sein.
Abhängig vom Unternehmen gibt es eine Vielzahl an verschiedenen Nutzern der Daten, beispielsweise Datenanalysten, Datenwissenschaftler, datenintensive Anwendungsentwickler. Diese Nutzer verwenden Daten auf verschiedene Arten und Weisen, z.B. mittels Spreadsheets, über Query Languages, etc. Das Spektrum kann also recht groß sein, dennoch muss das Data Product den Nutzern ermöglichen, die Daten auf ihre natürliche Art und Weise zu nutzen.
Eines der Hauptbedenken im Zusammenhang mit einer verteilten Architektur ist die Fähigkeit, Daten über die verschiedenen Domains hinweg miteinander zu verbinden, filtern und zusammenzuführen. Um die Interoperabilität und die Realisierbarkeit zu gewährleisten, muss unter anderem Folgendes standardisiert werden: Feldtyp, Polysem Identifikator, globale Adresse des Data Products und Verlinken von Daten in anderen Data Products.
Wie schon erwähnt wird dieser Punkt im nächsten Grundprinzip nochmals aufgegriffen.
Ein Data Product muss an sich wertvoll und bedeutsam sein – ohne den Zusammenschluss und das Anreichern mit anderen Data Products. Andernfalls sollte das Data Product womöglich gar nicht existieren. Dieser Punkt mag offensichtlich klingen, doch der Übergang zu einer Data Mesh Architektur birgt die Gefahr eines verbreiteten Anti-Patterns: Warehouse-Tabellen direkt auf Data Products abbilden. Durch dieses Vorgehen können wertlose Data Products entstehen – etwa weil die eine Tabelle die Kundennummer und die andere Tabelle die Kundeninformationen enthält.
Unabhängig von der Architektur ist Sicherheit unabdingbar. In einer verteilten Architektur wird die Zugangskontrolle vom Data Product selbst validiert, direkt im Fluss der Daten. Das gilt für das Zugreifen, Lesen und Schreiben. Die Zugangsrichtlinien können dynamisch verändert werden, indem sie bei jedem Zugriff auf das Data Product kontinuierlich evaluiert werden.
Der Zugang zu den Data Products kann feingranular gesteuert werden – Daten können beispielsweise statistisch ausgewertet werden ohne einzeln gelesen zu werden. Zugangsrichtlinien können global definiert werden und von jedem Data Product individuell durchgesetzt werden. Eine Sicherheitsrichtlinie kann folgende Aspekte beinhalten: Zugangskontrolle, Verschlüsselung, Vertrauensstufen und Vorratsdatenspeicherung.
Übergang zu Data as a Product
Die Data Mesh Prinzipien sind recht intuitiv. Bei der Umsetzung ist jedoch darauf zu achten, nicht in alte Muster zu verfallen. Daher befassen wir uns nun mit der Frage: Wie kann der Übergang erleichtert werden?
Der Verantwortungsbereich der Domains wird erweitert um das Verwalten von Data Products. Hier bietet es sich an, neue Rollen zu definieren:
- Data Product Developer: Die Rolle, die in ihrer Domain verantwortlich für das Entwickeln, Bereitstellen und Aufrechterhalten der Data Products ist, solange diese genutzt werden.
- Data Product Owner: Die Rolle, die in ihrer Domain verantwortlich für die Qualität der Data Products und die Zufriedenheit der Nutzer ebendieser ist.
Anstatt von ausgeschiedenen Daten zu sprechen, die als Nebenprodukt gesehen werden und flussabwärts von einer Pipeline aufgenommen, bereinigt und verarbeitet werden, sollten wir das Wort Konsum als zentralen Begriff sehen. Damit geht einher, dass Daten stromaufwärts bereits gereinigt und aufbereitet wurden und konsumiert werden können. Anstatt von ETL (extract, transform, load) zu sprechen, sollten wir Worte wie veröffentlichen, zur Verfügung stellen oder teilen verwenden. Das sorgt für ein besseres Verständnis von Data Mesh und dem Prinzip Data Product.
In der Vergangenheit wurden bereits Begriffe wie Asset im Zusammenhang mit Daten verwendet. Dies führt jedoch zu einer unvorteilhaften Bewertung des Erfolgs der Architektur. Oftmals werden sehr technische Faktoren herangezogen – etwa die Anzahl der Datensätze und Tabellen, die von einem Lake oder einem Warehouse erfasst werden. Dies fördert das Einlagern und Behalten anstelle des Teilens von Daten.
Mit Data as a Product soll auch die Erfolgsbewertung neu gedacht werden. Als Indikator für Erfolg sollten etwa der Einsatz, die Anzahl der Nutzer oder die Zufriedenheit der Nutzer der Daten gelten.
In der Abwesenheit von Data as a Product-Praktiken passiert es häufig, dass Nutzer von Daten keine andere Wahl haben als die Abstammung ebendieser Daten zu überprüfen, um Vertrauen zu den Daten herzustellen. Data as a Product führt Praktiken ein, die ein grundsätzliches Vertrauen zu Daten herstellen, indem langfristige Verantwortung zugeteilt wird. Ein automatisiertes Testen von Data Products beispielsweise kann diesen Effekt noch zusätzlich verstärken. Anstelle von grundsätzlichem Misstrauen gegenüber Daten sollte eine Kultur nach dem Motto “Vertrauen, aber verifizieren” vorherrschen.
Häufig werden Daten in Zusammenhang mit Tabellen und Speichermedien, separat von den jeweiligen Anwendungen betrachtet. Mit Data Mesh soll ein Shift zu einer architektonischen Einheit gelingen – eine strukturell vollständige Einheit, die ihren Job, das Bereitstellen von qualitativ hochwertigen Daten der jeweiligen Domain, ausführen kann. Dieser Aspekt ist angelehnt an die verbreitete Microservices-Architektur.
Zusammenfassung
Wir fassen noch einmal den Kern von Data as a Product zusammen: Wird dieses Prinzip angewandt, so werden Domain-orientierte Daten wie ein Produkt direkt an die Abnehmer verteilt – Datenanalysten, Data Scientists, etc. Das Data Mesh Konzept legt acht Grundeigenschaften fest, die ein Data Product ausmachen und die Nutzbarkeit gewährleisten sollen:
- Auffindbar
- Adressierbar
- Verständlich
- Vertrauenswürdig und wahrheitsgetreu
- Zugänglich auf natürliche Weise
- Interoperabel
- Wertvoll an sich
Sicher
Jedes Data Product ist autonom, sein Lebenszyklus und seine Wesensmerkmale werden unabhängig von den anderen verwaltet. Das Prinzip Data as a Product führt eine neue Architektur ein, die alle strukturellen Komponenten kontrolliert und umfasst, die für das Verteilen von Data Products nötig sind – Daten, Metadaten, Code, Richtlinien und Deklaration von infrastrukturellen Abhängigkeiten.