Data Products sind das zentrale Artefakt in einem Data Mesh. Ohne Data-Product-Disziplin gibt es kein Mesh — nur ein dezentralisiertes Data Warehouse mit schönen Worten.
Die Produkt-Analogie
Ein Data Product wird behandelt wie ein Software-Produkt:
- Hat Kunden: Andere Teams, die das Data Product konsumieren
- Hat einen Owner: Verantwortlich für Qualität, Verfügbarkeit, Roadmap
- Hat eine Roadmap: Was kommt in den nächsten Quartalen?
- Hat SLAs: Zusagen über Verfügbarkeit, Latenz, Qualität
- Hat Feedback-Kanäle: Konsumenten können Issues und Wünsche melden
- Wird aktiv entwickelt: Nicht „einmal gebaut, dann liegt es"
Das klingt simpel, ist in der Praxis aber ein kultureller Umbau. Daten-Teams mussten lange funktional denken („ich baue den Ingest"), jetzt müssen sie produktorientiert denken („ich baue ein Data Product, das von Team X genutzt wird").
Eigenschaften eines Data Products
Discoverable. Im zentralen Data Catalog auffindbar. Mit Kurzbeschreibung, Tags, Owner, Kontakt. Jemand, der das Produkt noch nie gesehen hat, soll in 5 Minuten verstehen, was es ist.
Addressable. Hat eine stabile Zugriffs-URL oder API-Endpoint. Konsumenten können es zuverlässig erreichen.
Trustworthy. Qualität ist dokumentiert und kontinuierlich überwacht. Konsumenten wissen, was sie erwarten können.
Self-describing. Schema ist dokumentiert, Semantik ist erklärt. Beispiel-Daten und Beispiel-Queries sind verfügbar.
Interoperable. Folgt organisations-weiten Standards für Formate, Namenskonventionen, Identifier. Erlaubt Joins über Data Products hinweg.
Secure. Access-Control, PII-Handhabung, Consent-Propagation sind implementiert.
Diese 6 Eigenschaften (manchmal auch „DATSIS" genannt) sind der Kern dessen, was ein Data Product ausmacht.
Typische Data-Product-Kategorien
Source-aligned: Spiegeln eine operative Datenquelle (z. B. Customer Records aus dem CRM, Order Events aus dem Shop). Dienen oft als Basis für abgeleitete Produkte.
Aggregate: Fassen mehrere Source-aligned Produkte zusammen (z. B. „Unified Customer Profile" aus CRM + Shop + Support).
Consumer-aligned: Speziell für einen bestimmten Use-Case gebaut (z. B. „Churn-Scoring-Features" für das Marketing-Team).
In einem reifen Mesh existieren alle drei Typen, mit klarer Abhängigkeits-Struktur.
Rollen rund um ein Data Product
Data Product Owner. Verantwortlich für Roadmap, Stakeholder-Management, Priorisierung. Muss Business-Verständnis und Data-Know-how verbinden.
Data Engineer(s). Bauen und pflegen die Pipeline. Technische Umsetzung.
Data Analyst / Scientist (optional). Bei aggregierten oder consumer-aligned Produkten oft relevant für fachliche Logik.
Stakeholder/Konsumenten. Die Teams, die das Produkt nutzen. Liefern Feedback, melden Issues.
Im Mittelstand laufen die ersten drei Rollen oft in Personalunion. Bei größeren Mesh-Setups trennen sich die Rollen klarer.
Das Data-Product-Lifecycle
Discovery. Wird das Produkt überhaupt gebraucht? Welche Konsumenten, welche Use-Cases?
Design. Schema, Semantik, SLA, Ownership definiert.
Development. Pipeline gebaut, Tests, erste Version deployed.
Onboarding. Konsumenten-Teams werden angebunden, Dokumentation finalisiert.
Operation. Monitoring läuft, Feedback wird gepflegt, kleinere Änderungen werden umgesetzt.
Evolution. Breaking Changes, neue Versionen, Erweiterungen.
Retirement. Das Produkt wird eingestellt (selten, aber wichtig als Option).
Jede Phase hat eigene Artefakte und Entscheidungen. Ein einmalig gebautes Data Product ohne Lifecycle wird schnell zur Datenruine.
SLAs in der Praxis
Ein gutes Data Product hat dokumentierte SLAs für mindestens:
Verfügbarkeit: Uptime, erwartete Ausfallfenster, Recovery-Time.
Latenz: Wie schnell ist das Produkt aktuell? Realtime, stündlich, täglich?
Qualität: Welche Quality-Checks laufen? Welche Schwellwerte?
Support: Response-Zeiten bei Issues. Eskalations-Pfade.
Change-Management: Wie werden Breaking Changes angekündigt? Typisch 30–90 Tage Vorlauf.
Die SLAs müssen realistisch sein. Übertriebene Versprechen (99,99 Prozent Verfügbarkeit bei einer Marketing-Analyse-Pipeline) enden in Frust.
Discoverability — der unterschätzte Faktor
Data Catalogs sind 2026 meist technisch solide (Collibra, Atlan, DataHub, Alation). Die Herausforderung ist weniger Tool-Wahl als Disziplin: Jedes Data Product muss im Catalog mit aktuellen Infos stehen.
Praxis-Tipp: Automatische Metadata-Sync aus der Pipeline. Manuelle Pflege im Catalog scheitert nach 6 Monaten. Schema, Lineage, Sample-Daten werden automatisch extrahiert und gepflegt.
Data Contracts als Pflichtergänzung
Sobald ein Data Product mehr als zwei Konsumenten hat, brauchst du Data Contracts. Ohne sie wird jede Schema-Änderung zum Stakeholder-Drama.
Häufige Anti-Patterns
Anti-Pattern 1 — Data Product als umetikettierte Tabelle. Keine Ownership, kein SLA, kein Feedback — einfach eine Tabelle mit „Data Product"-Label. Reine Etikette.
Anti-Pattern 2 — Data Products ohne Konsumenten. Gebaut, weil „man das jetzt so macht", ohne echten Bedarf. Wird nicht genutzt.
Anti-Pattern 3 — Hunderte Data Products ohne Hierarchie. Alles ist ein Produkt. Niemand findet mehr, was wirklich wichtig ist.
Anti-Pattern 4 — Kein Breaking-Change-Management. Schema-Änderungen werden kurzfristig kommuniziert, Konsumenten brechen. Vertrauen verloren.
Verbindungen: Einführung für die Prinzipien-Basis. Data Contracts als formale Ergänzung. Organisationsmodell für Team-Rollen.