Was ist ein Data Product?

Ein Data Product ist ein gesteuerter, wiederverwendbarer Datenbestand, der mit Blick auf seine Abnehmer gebaut ist. Es hat eine verantwortliche Person, festgelegte Qualitätsstandards, eine Dokumentation und ist über einen Datenkatalog auffindbar. Anders als ein Rohdatensatz, der im Warehouse liegt, trägt ein Data Product eine Qualitätszusage: Jemand steht für seine Richtigkeit, seine Aktualität und seine Dokumentation ein.

Der Begriff stammt aus dem Architekturansatz Data Mesh, der die Verantwortung für Daten auf die Domänenteams verteilt, statt sie in einer einzigen Data-Engineering-Funktion zu bündeln. Data Products bringen aber auch außerhalb von Data Mesh Nutzen. Jede Organisation, die verlässliche, wiederverwendbare Daten für Analysen und KI braucht, profitiert davon, wichtige Datenbestände als Produkte statt als bloße Tabellen zu behandeln.

Was ein Data Product von einem Datensatz unterscheidet

Der Unterschied liegt in der Verpflichtung zur Pflege, nicht in der Technik. Ein Datensatz ist ein technisches Artefakt: eine Tabelle, eine Datei, ein API-Endpunkt. Ein Data Product ist dasselbe Artefakt plus die Governance, die Dokumentation, die Verantwortung und die Qualitätszusage, die es für andere tragfähig machen.

Ein konkretes Beispiel: Eine Tabelle customer_orders in Ihrem Warehouse ist ein Datensatz. Ein Data Product „Bestellhistorie der Kunden“ umfasst diese Tabelle, einen Schema-Vertrag, ein SLA zur Aktualität, eine verantwortliche Person im Team für die Auftragsabwicklung und Definitionen aus dem Business Glossary für jedes Feld. Die Abnehmer wissen, was sie bekommen, wen sie ansprechen, wenn etwas bricht, und welche Qualitätszusagen gelten.

Dem Data Product fehlen gegenüber dem Rohdatensatz fünf Dinge nicht: eine verantwortliche Person, die die Qualität hält, eine Dokumentation, die Inhalt und vorgesehene Nutzung erklärt, Qualitätsstandards mit messbaren SLAs, ein Katalogeintrag, damit Abnehmer es finden, ohne herumzufragen, und ein Entwurf aus Sicht der Abnehmer, der es für seine Zielgruppe brauchbar macht.

Kerneigenschaften eines Data Product

Zhamak Dehghani, von der das Konzept Data Mesh stammt, hat sechs Eigenschaften beschrieben, die ein Data Product von einem Rohdatensatz trennen. Sie ergeben eine praktische Prüfliste für Teams, die Data Products bauen und bewerten.

Auffindbar

Ein Data Product, das niemand findet, ist kein Produkt. Auffindbarkeit verlangt einen Eintrag im Datenkatalog mit genug Metadaten, damit Abnehmer die Eignung beurteilen können, ohne die verantwortliche Person zu fragen. Dazu gehört, Zweck, Inhalt, Qualitätsmerkmale und Zielgruppe zu dokumentieren.

Adressierbar

Jedes Data Product hat eine stabile, eindeutige Adresse, auf die sich Abnehmer verlässlich beziehen können. Einheitliche Namenskonventionen, stabile API-Endpunkte oder Tabellennamen und eine Versionierungsstrategie sagen den Abnehmern, welche Fassung sie nutzen. Adressierbarkeit macht Data Products berechenbar genug, um darauf aufzubauen.

Selbstbeschreibend

Ein selbstbeschreibendes Data Product bringt genug Metadaten mit, dass ein neuer Abnehmer versteht, was es enthält und wie es zu nutzen ist, ohne die verantwortliche Person zu konsultieren. Dazu gehören Dokumentation auf Feldebene, Verknüpfungen ins Business Glossary, Angaben zur Data Lineage, die die Herkunft zeigen, und Qualitätskennzahlen für die Eignungsprüfung.

Vertrauenswürdig

Vertrauen entsteht aus gleichbleibender Qualität. Die verantwortliche Person sagt Richtigkeit, Vollständigkeit und Aktualität zu und steht ein, wenn diese Zusagen nachlassen. Die Überwachung durch Data Observability erkennt Abweichungen schnell, und Abnehmer werden benachrichtigt, wenn Probleme auftreten.

Interoperabel

Data Products entfalten den größten Wert, wenn sie sich mit anderen kombinieren lassen, um komplexe Fragen zu beantworten. Interoperabilität verlangt einheitliche Datenformate, gemeinsame Definitionen im Business Glossary und übliche Konventionen dafür, wie Schlüsselobjekte (Kunden, Produkte, Zeit) über Domänen hinweg dargestellt werden. Ohne sie verlangt das Kombinieren brüchige Integrationsarbeit, die den Self-Service untergräbt.

Unmittelbar nutzbar

Ein Data Product ist über die Schnittstellen erreichbar, die seine Abnehmer ohnehin nutzen: SQL, APIs, Dateien oder Streaming. Die verantwortliche Person baut keine unnötigen Hürden ein, also keine proprietären Formate, keine umständliche Authentifizierung, keine undokumentierten Schemata, die den praktischen Nutzen schmälern.

Data Products und Data Mesh

Data Mesh ordnet die Verantwortung für Daten den Fachdomänen zu. Das Team der Kundendomäne verantwortet die Data Products zu Kunden. Das Team der Auftragsabwicklung verantwortet die zu Bestellungen. Wer die Daten am besten versteht, ist dafür verantwortlich, daraus ein tragfähiges Data Product zu machen, das der Rest der Organisation nutzen kann.

Diese verteilte Verantwortung ist es, die Data Mesh skalieren lässt. Ein zentrales Data-Engineering-Team wird zum Engpass, sobald Dutzende Domänenteams neue Datensätze brauchen. Die Verantwortung zu verteilen gibt jedem Team die Eigenständigkeit und die Rechenschaft, Data Products zu erzeugen, die der ganzen Organisation dienen.

Die Spannung zwischen Eigenständigkeit und Interoperabilität

Die größte praktische Hürde bei Data Mesh ist, die Interoperabilität über eigenständige Domänenteams hinweg zu halten. Wählt jedes Team eigene Formate, Namenskonventionen und Qualitätsstandards, wird die Föderation der Data Products zusammenhanglos. Data Mesh begegnet dem mit föderierter rechnergestützter Governance: Eine zentrale Funktion legt die Standards und Konventionen fest, denen alle Data Products folgen müssen, während die einzelnen Teams sie so umsetzen, wie es zu ihrer Domäne passt.

Data Products für die Nutzung durch KI entwerfen

KI-Systeme werden neben menschlichen Analysten zu den wichtigsten Abnehmern von Data Products. Für sie zu entwerfen verlangt Aufmerksamkeit für Dimensionen, die bei menschlichen Abnehmern weniger zählen und für Maschinen unverzichtbar sind.

KI-Systeme brauchen reiche, maschinenlesbare Metadaten: fachlichen Kontext, der erklärt, was die Daten bedeuten, gültige Wertebereiche, Data Lineage für die Herkunft und Vertrauenswerte für die Verlässlichkeit. Ein KI-Agent, der ein Data Product ohne diesen Kontext bekommt, kann es mechanisch verarbeiten, aber nicht klug nutzen. Für KI entworfene Data Products sollten ihre Metadaten in Formaten mitbringen, die KI-Agenten programmatisch verarbeiten, womit sich der Bogen zum Semantic Layer schlägt, der Fachbegriffe auf technische Strukturen abbildet.

Data Products einführen

Die technische Seite von Data Products, also Katalogeintrag, Qualitätsüberwachung und Dokumentationsstandards, ist unkompliziert, sobald die Werkzeuge stehen. Die organisatorische Seite, also Rechenschaft über die Verantwortung, Governance-Standards und ein verändertes Denken der Domänenteams über ihre Daten, ist schwerer und wichtiger.

Mit wertvollen, schmerzhaften Daten anfangen

Die besten Kandidaten für die ersten Data Products sind Datensätze, die breit genutzt und schlecht dokumentiert sind, deren Qualität häufig in Frage steht oder die schwer zu finden sind. An ihnen zeigt sich der Nutzen sofort, und das schafft Rückhalt für die weitere Einführung.

Eine Spezifikation für Data Products festlegen

Bevor Sie Teams bitten, Data Products zu erzeugen, legen Sie fest, was ein Data Product in Ihrer Organisation bedeutet: welche Dokumentation nötig ist, welche Qualitätsstandards gelten, was der Katalogeintrag enthalten muss, welche SLAs erwartet werden. Eine klare Spezifikation nimmt die Unklarheit und gibt den Domänenteams ein konkretes Ziel. Fangen Sie mit einer schlanken, erreichbaren Fassung an und ziehen Sie die Latte an, während die Organisation reift.

Einen Katalog der Data Products aufbauen

Ein Datenkatalog ist die Entdeckungsschicht, die Data Products auffindbar macht. Tragen Sie alle Data Products mit genug Metadaten ein, damit Abnehmer sie beurteilen können, ohne die verantwortliche Person zu fragen. Der Katalog ist zugleich die Governance-Oberfläche: Dort stehen die Qualitätskennzahlen, dort ist die Verantwortung dokumentiert, dort liegt die Lineage offen.

Wie Dawiso Data Products unterstützt

Dawiso liefert das Fundament, das Data Products verlangen: den Katalogeintrag für die Auffindbarkeit, das Metadatenmanagement für die Selbstbeschreibung, die interaktive Data Lineage für die Nachvollziehbarkeit, die Einbindung des Business Glossary für semantische Einheitlichkeit und Qualitätskennzahlen für die Vertrauensprüfung.

Domänenteams können ihre Data Products unmittelbar in Dawiso dokumentieren, technische Objekte mit Begriffen aus dem Business Glossary verbinden und sie so in der ganzen Organisation auffindbar machen. Die fachlich verständliche Oberfläche der Plattform macht die Pflege von Data Products auch für Fachleute aus den Domänen praktikabel, nicht nur für technische Datenfachleute.

Über das Model Context Protocol (MCP) können KI-Agenten den Katalog von Dawiso programmatisch abfragen: Definitionen von Data Products nachschlagen, die Aktualität prüfen, die Lineage abrufen und die Verantwortung verifizieren. Damit werden Data Products über eine einzige Governance-Schicht für menschliche Analysten und KI-Systeme gleichermaßen nutzbar.

Fazit

Data Products stehen für eine Verschiebung darin, wie Organisationen Daten verwalten und teilen. Wichtige Datenbestände als Produkte zu behandeln, mit Verantwortung, Qualitätszusagen, Dokumentation und einem Entwurf aus Sicht der Abnehmer, macht Daten vertrauenswürdiger und nützlicher für Analysen, KI und Anwendungsentwicklung. Die Verschiebung ist ebenso organisatorisch wie technisch: Sie verlangt von den Domänenteams, für die Daten einzustehen, die sie erzeugen, und von der Governance, die Standards zu setzen, die Data Products interoperabel machen. Organisationen, die diesen Schritt gehen, stellen fest, dass ihre Daten wertvoller werden, nicht weil sich die Daten geändert hätten, sondern weil sie so geführt werden, dass man verlässlich auf ihnen aufbauen kann.