Zum Inhalt springen

Data Product

Data Product bezeichnet ein verwaltbares Daten-Artefakt mit Owner, Contract, SLO, Discovery und dokumentierter Konsum-Schnittstelle. Definition und Abgrenzung.

Ein Data Product ist ein Datenbestand, der wie ein Produkt geführt wird: mit einem verantwortlichen Team (Owner), einer festen Beschreibung (Schema), Qualitätszusagen (etwa zu Aktualität und Verfügbarkeit), einer eindeutigen Adresse im Katalog und einer klaren Nutzungs-Vereinbarung für die Abnehmer. Typische Erscheinungsformen sind eine Tabelle, eine gefilterte Sicht (View), ein Merkmals-Bestand für maschinelles Lernen (Feature-Set), eine Schnittstelle (API) oder ein Modell-Zugang. Der Begriff stammt aus dem Data-Mesh-Ansatz (Zhamak Dehghani, 2019) und beschreibt Daten nach denselben Qualitätskriterien wie ein Softwareprodukt.

Was ist ein Data Product?

Ein Data Product überträgt Produktdenken auf Daten. Der Datenbestand wird als eigenständiges Angebot mit klarer Zuständigkeit, Abnehmern und Qualitätsversprechen geführt, mit demselben Anspruch, den ein Softwareprodukt an sein Verhalten stellt. Konkret heißt das: Eine Fachabteilung stellt einen Datenbestand bereit, benennt ein verantwortliches Team, dokumentiert Aufbau und Nutzung und gibt zu, was sie in Sachen Aktualität und Zuverlässigkeit garantieren kann. Der Begriff wurde 2019 von Zhamak Dehghani in dem Aufsatz [„How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh"](https://martinfowler.com/articles/data-monolith-to-mesh.html) auf martinfowler.com geprägt und 2020 mit den [„Data Mesh Principles and Logical Architecture"](https://martinfowler.com/articles/data-mesh-principles.html) formalisiert. Das 2022 im O'Reilly-Verlag erschienene Buch [„Data Mesh: Delivering Data-Driven Value at Scale"](https://www.oreilly.com/library/view/data-mesh/9781492092384/) hat den Begriff zum Referenz-Baustein moderner Datenarchitekturen gemacht.

Konstituierend für ein Data Product sind acht Eigenschaften, die als DATSIS-Attribute etabliert sind. Discoverable: das Datenprodukt ist im Katalog auffindbar. Addressable: es hat eine stabile, eindeutige Adresse (URI, Katalog-Pfad). Trustworthy: Herkunft, Frische und Qualität sind belegbar, in der Regel über SLO und automatisierte Tests. Self-describing: Schema, Semantik und Beispiel-Nutzung sind dokumentiert. Interoperable: offene Formate und Standards ermöglichen den Konsum über Werkzeug-Grenzen. Secure: Zugriff läuft über zentrale Policies (Row-Level-Security, Column-Masking, Attribute-based Access Control). Ergänzend kommen benannter Owner (fachlich verantwortliches Team) und ein Data Contract als expliziter Konsum-Vertrag (Schema-Version, Frequenz, Deprecation-Fenster).

Der Begriff existiert, weil klassische Datenbestände diese Eigenschaften typischerweise nicht als Einheit tragen. Eine Tabelle in einem Data Lake hat ein Schema, aber selten einen benannten fachlichen Owner. Ein Reporting-Datensatz hat einen Owner, aber keinen versionierten Konsum-Vertrag. Ein Feature-Set für ein ML-Modell hat eine Definition, aber keinen dokumentierten SLO. Data Product fasst diese Zusicherungen zu einer Einheit zusammen, die als adressierbares Objekt in Katalog, Lineage, Governance und Marktplatz erscheint. Die Manifestation ist technologie-offen: kuratierte Delta- oder Iceberg-Tabelle, gesicherter View, Feature-Table, REST- oder gRPC-API, ML-Modell-Endpunkt, Sharing-Referenz über Delta Sharing.

Abgrenzung zu Data Set, Marketplace-Listing und Data-as-a-Service

Data Product wird häufig mit benachbarten Konzepten vermischt, die eine andere Funktion tragen. Die folgende Tabelle sortiert die Begriffe entlang ihrer Achse.

BegriffAchseKernunterschied
Data Set / TabelleRohobjektEin Datensatz ohne benannten Owner, ohne SLO und ohne Konsum-Vertrag. Wird durch Owner, Contract und Discoverability zum Data Product; entscheidend für die Aufwertung sind die Zusicherungen selbst.
Data-as-a-ProductPrinzipDie Haltung, analytische Daten produkthaft zu behandeln (ein von vier Data-Mesh-Prinzipien, neben Domain Ownership, Self-Service-Plattform und Federated Governance). Das Data Product ist das konkrete Objekt, in dem sich das Prinzip manifestiert.
Data-Marketplace-ListingBezugsschichtDer Katalogeintrag samt Lizenz und Bestell-/Bezugs-Workflow in einem Data Marketplace. Das Data Product bleibt beim Anbieter; das Listing ist die Vertriebs-Schicht darüber. Ein Data Product kann existieren, ohne im Marketplace zu erscheinen.
Data-as-a-Service (DaaS)BereitstellungsmodellEin von einem Anbieter bereitgestellter Datendienst gegen Entgelt oder auf Basis eines internen Servicevertrags. Das Data Product ist die Artefakt-Einheit, die in einem DaaS-Angebot ausgeliefert werden kann.
Datenprodukt (Marketing-Verwendung)Begriffs-VerwendungMarktkommunikation verwendet „Datenprodukt" gelegentlich für jede kommerziell angebotene Datenlieferung, auch ohne DATSIS-Attribute. Im Data-Mesh-Sinn genügt kommerzielle Verpackung allein nicht.

Zwei Trennlinien sind für die Einordnung besonders wichtig. Die erste betrifft die Abgrenzung zum reinen Data Set: der Unterschied liegt in den Zusicherungen. Ein Datensatz wird zum Data Product durch benannten Owner, Data Contract, dokumentierten SLO und Katalog-Auffindbarkeit; ohne diese Zusicherungen bleibt der Datensatz ein Datensatz. Die zweite betrifft die Abgrenzung zum Marketplace-Listing: das Data Product ist das Artefakt (mit Ownership, SLO, Schema), das Listing ist die Bestell-Ebene darüber (Discovery für externe Konsumenten, Lizenz, Bezugsprozess). Ein interner Marktplatz listet Data Products, erzeugt sie aber nicht.

Beispiel: Sendungsstatus als Data Product in einer Handels-Domäne

Ein typischer Anwendungsfall ist ein Data Product der Domäne Logistik in einem DACH-Handelskonzern. Die Tabelle „Sendungsstatus" liegt als Delta-Tabelle in einem Unity-Catalog-Schema der Domäne. Sie hat einen benannten Team-Owner (Logistik-Datenteam), ein versioniertes Schema mit dokumentierter Deprecation-Frist von zwölf Wochen, definierte Service-Level-Objectives (Frische unter 15 Minuten für 99 Prozent der Datensätze, Verfügbarkeit 99,5 Prozent), Lineage bis zur Kafka-Quelle und Katalog-Metadaten (Klassifizierung, Retention, PII-Kennzeichnung). Der Zugriff für andere Domänen läuft über eine [Delta-Sharing](/insights/databricks/data-sharing/delta-sharing/)-Referenz, die im internen Marktplatz gelistet ist.

Die Domäne Kundenservice abonniert das Data Product für ihr Support-Dashboard. Der Abonnement-Vorgang findet im internen Marktplatz statt: Katalogeintrag prüfen, Nutzungsbedingungen akzeptieren, Freigabe durch das Logistik-Datenteam. Anschließend erscheint der Sendungsstatus als Live-Referenz im Unity Catalog der Domäne Kundenservice und wird in Notebooks und SQL-Warehouses wie eine interne Tabelle abgefragt. Aktualisierungen des Anbieters sind sofort sichtbar, weil es sich um eine Referenz handelt, keine Kopie. Nutzung und Zugriffs-Historie sind auf beiden Seiten protokolliert; die Ownership bleibt bei der Logistik.

Der Reifegrad der Umsetzung wird an konkreten Kennzahlen abgelesen: Anzahl der als Data Product ausgewiesenen Objekte pro Domäne, Time-to-Consume neuer Abonnenten (Antragstellung bis produktiver Zugriff), Cross-Domain-Konsum je Data Product, Anteil der SLO-Verletzungen. Data Product ist damit die adressierbare Einheit, auf die sich Governance, Marktplatz-Discovery, Konsum-Vertrag und Wertmessung gemeinsam beziehen.

Data Product im eigenen Unternehmen umsetzen?

Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.

Gespräch vereinbaren