Data Products richtig schneiden

This article is also available in English

TL;DR

• Zuschnitt: Wenn ein Data Product zu klein oder zu groß geschnitten ist, müssen Consumer Daten mühsam zusammenstückeln, Verantwortlichkeiten verschwimmen, Logik wird dupliziert – und Incidents werden zum Alltag.
• Consumer: Ein Data Product braucht echte Nutzer:innen und konkrete Use Cases – jetzt, nicht irgendwann. Sein Hauptzweck sollte sich in einem Satz beschreiben lassen, und Data Contracts helfen, Erwartungen explizit zu machen.
• Ownership: Genau ein Team muss klar verantwortlich sein für Semantik, Datenqualität und Betrieb. Ohne stabilen Owner sollte das Data Product nicht existieren.
• Scope: Ziel ist die kleinste sinnvoll eigenständig nutzbare Einheit – direkt einsetzbar ohne zusätzliche Integrationsarbeit, aber nicht aufgebläht mit Daten, die „vielleicht irgendwann nützlich" sein könnten.
• Archetypen: Der richtige Zuschnitt hängt vom Ziel ab. Source-aligned bleibt innerhalb einer Business-Domäne, Aggregates lohnen sich nur, wenn mehrere Teams dieselbe abgeleitete Sicht brauchen und jemand die Governance übernehmen kann, und Consumer-aligned wird um eine konkrete Entscheidung oder einen Prozess für eine definierte Zielgruppe gebaut.

Wer Data Products falsch zuschneidet, produziert vorhersehbare Probleme. Consumer müssen mehrere Datensätze zusammensetzen, nur um einfache Fragen beantworten zu können. Verantwortlichkeiten verschwimmen, weil niemand eindeutig für Semantik, Qualität und Änderungen zuständig ist. Dieselbe Logik wird an mehreren Stellen implementiert – teuer und meist inkonsistent. Data Products blähen sich auf, was es erschwert, die richtigen Informationen zu finden und ihre Inhalte zu verstehen. Sobald Data Products inkonsistent werden und ihre Grenzen verschwimmen, sind operative Störungen vorprogrammiert: Incidents, Daten-Nachlieferungen und Eskalationen durch Stakeholder werden zum Alltag.

Das Ziel ist das Gegenteil. Ein gut geschnittenes Data Product ist ein stabiles, konsumierbares Paket. Seine Semantik ist so klar, dass Consumer keine zusätzliche Übersetzungsschicht brauchen. Sein Profil ist in sich stimmig, das heißt: Erwartungen an Aktualität, Granularität und Zuverlässigkeit sind realistisch und tatsächlich erfüllbar. Kurz gesagt: Das Data Product ist sowohl eigenständig nutzbar als auch verlässlich.

Zhamak Dehghanis großartiges Buch über Data Mesh ist für mich eine wichtige Inspirationsquelle. Durch meine Arbeit als Berater in diesem Feld und durch den Austausch mit Kolleg:innen habe ich Erfahrung darin gesammelt, diese Theorie in die Praxis zu überführen. Dieser Text soll dabei helfen, Data Products sinnvoll zu schneiden, indem er praktische Heuristiken anbietet. Zuerst geht es um Heuristiken, die für alle Data Products gelten. Danach betrachten wir die spezifischen Heuristiken für die drei Archetypen von Data Products: source-aligned, aggregate und consumer-aligned.

Grundlagen

Klar definierte Consumer und Use Cases

Eine der wichtigsten Heuristiken ist der Consumer Fit. Ein guter Schnitt ermöglicht es, die naheliegenden Use Cases produktiv umzusetzen, ohne dass Consumer erst eigene Integrationsarbeit leisten müssen. Der primäre Zweck sollte sich in einem einzigen Satz ausdrücken lassen. Fehlen Use Cases, Consumer oder eine klar erkennbare Zielgruppe, gibt es kein Data Product.

Um zu verstehen, ob ein Data Product für seine Consumer geeignet ist, braucht es solides Requirements Engineering. Das lässt sich sinnvoll über Contract-first und Data-Contract-Workshops abbilden. Data Contracts sind gewissermaßen Schnittstellenbeschreibungen für die Output Ports von Data Products und liefern damit ganz natürlich ein präzises Bild der Anforderungen an das zugrunde liegende Data Product.

Stabile Ownership

Die zweite Heuristik ist stabile Ownership. Ein Data Product muss genau einer Domäne oder einem Team gehören, das für Semantik, Qualität und Betrieb verantwortlich ist. Wenn sich kein klarer Owner bestimmen lässt, lässt sich auch kein Data Product sauber definieren. Denn Data Products müssen über ihren gesamten Lebenszyklus hinweg gepflegt und unterstützt werden, damit sie die Anforderungen ihrer Consumer weiterhin erfüllen.

Es gibt unterschiedliche Auslöser für die Entstehung von Data Products. Die wichtigsten sind:

• Ein Team veröffentlicht seine Daten, weil es selbst Analysen damit durchführt und davon ausgeht, dass die Daten auch für andere interessant sein könnten.
• Es gibt eine konkrete Nachfrage nach bestimmten Daten, sodass das zuständige Team direkt angesprochen wird.
• Ein:e Manager:in oder ein Gremium entscheidet, dass ein Data Product entwickelt werden soll, um einen bestimmten Datenbedarf zu decken.

Im letzten Fall ist die Ownership-Frage besonders wichtig, weil klar sein muss, wer die Kosten für Entwicklung und Betrieb des Data Products trägt.

Konsistente Datenqualität

Die zuvor beschriebenen Data Contracts können weitere Hinweise darauf geben, wie ein Data Product sinnvoll geschnitten sein sollte. Sie enthalten Informationen über die Merkmale der Datenqualität. Diese sollten über die Output Ports hinweg konsistent sein, denn die internen Quellen für die einzelnen Output Ports eines Data Products sollten dieselben sein. Diese Aussage muss allerdings etwas relativiert werden – insbesondere bei zeitabhängigen Eigenschaften. So kann ein täglicher CSV-Export nach S3 naturgemäß nicht so aktuell sein wie ein Echtzeit-Datenstrom über Kafka.

Geringer Integrationsaufwand

Ein Data Product sollte den Integrationsaufwand für seine Consumer möglichst klein halten. Die Abgrenzung passt eher, wenn das Data Product die kleinste sinnvolle eigenständig nutzbare Einheit darstellt, bei der Consumer den Kontext nicht erst durch das Zusammenführen anderer Datensätze rekonstruieren müssen. Im Idealfall können Consumer direkt produktiv mit dem Data Product arbeiten, ohne erst eine zusätzliche Integrationsschicht zu bauen. Wenn die meisten Consumer es sofort mit anderen Produkten kombinieren müssen, ist der Zuschnitt wahrscheinlich zu eng oder es fehlt wesentlicher Kontext.

Gleichzeitig müssen wir darauf achten, dass bestimmte zentrale Datensätze nicht zu Single Points of Failure werden. Insbesondere Stammdaten sind hier Kandidaten, weil ihre Verknüpfung mit anderen Daten oft erheblichen Mehrwert schafft und deshalb häufig erfolgt. Die Integration eines solchen zentralen Data Products birgt Risiken – etwa Kaskadeneffekte im Fehlerfall sowie operative Komplexität, Inkonsistenzen und Verzögerungen. Vor diesem Hintergrund kann ein eigenständiger Datensatz wertvoller sein, wenn er die meisten Use Cases auch ohne angereicherte Daten unterstützt. Gleichzeitig würden seine Konsistenz, Zuverlässigkeit und Nutzbarkeit steigen.

Klar begrenzter Scope

Der Scope eines Data Products sollte begrenzt sein und eng zu seinem beabsichtigten Zweck passen. Er sollte nur das enthalten, was für diesen Zweck wirklich gebraucht wird – nicht alles, was irgendwann vielleicht einmal nützlich sein könnte. Ein enger Scope verhindert semantisches Rauschen und schützt das Data Product davor, zu groß zu werden. Sobald ein Data Product lose zusammenhängende Daten oder spekulative Ergänzungen aufnimmt, ist der Scope wahrscheinlich zu breit.

Auf den ersten Blick scheint das dem Prinzip des geringen Integrationsaufwands zu widersprechen. In der Praxis führen beide Prinzipien zusammen jedoch zu einem stabilen, tragfähigen Scope für Data Products: möglichst nutzerfreundlich, aber ohne unnötigen Ballast.

Allgemeine Heuristiken für den Zuschnitt von Data Products

Klar definierte Consumer und Use Cases

• Lässt sich der Hauptzweck in einem Satz beschreiben?
• Gibt es konkrete Teams oder Rollen, die dieses Data Product heute tatsächlich nutzen wollen?

Stabile Ownership

• Ist genau eine Domäne oder ein Team für Semantik, Qualität und Betrieb verantwortlich?
• Würde dieser Owner auch zukünftige Änderungen glaubwürdig übernehmen?

Konsistente Datenqualität

• Sind die Merkmale der Datenqualität über die Output Ports hinweg konsistent?

Geringer Integrationsaufwand

• Ist das die kleinste sinnvoll eigenständig nutzbare Einheit, die Consumer nicht dazu zwingt, mehrere Data Products zusammenzustückeln?
• Kann ein typischer Consumer dieses Data Product sofort eigenständig sinnvoll nutzen?

Klar begrenzter Scope

• Enthält das Data Product nur das, was für seinen Zweck gebraucht wird?
• Ist es auf Dinge beschränkt, die heute tatsächlich nützlich sind?

Source-aligned Data Products

Semantische Kohärenz

Source-aligned Data Products bilden in den meisten Datenlandschaften die Basisschicht. Sie stellen konsumierbare, domänenspezifische Daten bereit, die nah an der operativen Wahrheit bleiben. In der Praxis umfasst ein source-aligned Data Product typischerweise einen konsistenten Datenausschnitt zusammen mit allen lokalen Dimensionen, die für seine Interpretation nötig sind. Die zentrale Idee ist: Consumer sollen eine verlässliche, klar definierte Repräsentation eines einzelnen Themas erhalten, ohne das Quellsystem erst rückwärts analysieren zu müssen.

Der richtige Scope beginnt bei der Quelle – aber nicht mit der Haltung, einfach alles aus ihr herauszukippen. Ziel ist es, aus Sicht der Consumer das kleinste stabile Paket zu identifizieren. Dazu gehört, zu verstehen, ob sich die Quelldaten sinnvoll aufteilen lassen, zu erkennen, welche Elemente nur gemeinsam sinnvoll sind, und eine schmale Einheit zu finden, mit der Consumer arbeiten können, ohne Integrationen selbst neu aufbauen zu müssen. Wer diese Prinzipien beachtet, verhindert, dass Quellen in winzige Datenschnipsel zerlegt werden, die nur das erzeugende Team noch versteht.

Daten aus genau einer Business-Domäne

Statt ganze, eher technisch geschnittene Systeme zu betrachten, ist es in der Praxis sinnvoller, sich an bestehenden Domänenmodulen oder Microservices zu orientieren. Kund:innen ein Data Product mit dem Namen „Alle Daten aus SAP” anzubieten, ist in der Regel zu breit, semantisch unordentlich und schwer zu beherrschen. Ein Domänenmodul hat dagegen klarere Verantwortungsgrenzen und einen natürlichen Owner. Im Domain-Driven Design st ein Microservice in der Regel einem Bounded Context zugeordnet. Innerhalb dieses Kontexts umfasst das Domänenmodell meist ein oder mehrere Aggregate – nicht zu verwechseln mit dem Archetyp des Aggregate Data Products. Genau diese Aggregate aus dem Domain-Driven Design sind perfekte Kandidaten für source-aligned Data Products.

In der Realität kann es pragmatisch sein, dass ein Team ein Data Product auf Basis eines großen Systems erstellt, dessen Daten aus mehreren Subdomänen stammen – etwa dem erwähnten SAP –, um Betriebskosten zu sparen. Wahrscheinlich verletzt das aber das Prinzip der Domain Ownership. Dann brauchen wir ein Team, das die Ownership für dieses Data Product übernehmen kann, indem es es in spezifischere Produkte aufteilt. Im Kern hat ein solches Data Product dieselben Herausforderungen wie der weiter unten beschriebene Archetyp des Aggregate Data Products und sollte deshalb vermieden werden.

Wer das Ganze stärker aus Sicht der Datenarchitektur betrachten möchte, kann Modellierungsansätze wie Kimballs Dimensional Modeling Techniques nutzen. Kimball beschreibt eine Methode zur dimensionalen Modellierung von Data-Warehouse-Strukturen, in der Geschäftsprozesse als Facts (messbare Ereignisse) auf klar definierter Granularität modelliert und durch beschreibende Dimensionen kontextualisiert werden. Fortgeschrittene Modellierungstechniken wie Conformed Dimensions werden auf höheren Ebenen interessant – also bei aggregate- oder consumer-aligned-Produkten – oder können sogar im Widerspruch zu Data-Mesh-Prinzipien stehen. Diese Geschäftsprozesse, Facts und Dimensionen können aber eine gute Grundlage für den Zuschnitt von Data Products sein, sofern Data Architects zumindest mit den Grundlagen vertraut sind.

Die gleiche Sorgfalt ist nötig, wenn entschieden wird, welche Kontextinformationen in ein Data Product gehören. Kontext, der klar innerhalb derselben Domäne owned, gepflegt und weiterentwickelt wird, sollte Teil des Data Products selbst sein. Kontext, der domänenübergreifend geteilt wird und semantisch konsistent bleiben muss – etwa Kund:innen oder Produkte –, sollte als separates Data Product mit eigener Ownership veröffentlicht werden. Andere Produkte sollten auf diese geteilten Domain-Produkte verweisen, statt sie lokal neu zu definieren. So vermeiden wir semantische Drift: also das schleichende Auseinanderlaufen zentraler Geschäftsbegriffe, bis sie in unterschiedlichen Teilen der Datenlandschaft Unterschiedliches bedeuten.

Blast Radius der Quelldaten

Aus operativer Sicht sollte vermieden werden, dass Routineänderungen am Source Code viele source-aligned Data Products betreffen. Idealerweise bleibt die Auswirkung von Änderungen am Quellschema oder an der Logik möglichst lokal. Das hilft Teams, den Wartungsaufwand für das Data Product klein zu halten, und gibt Consumern gleichzeitig Einblick darin, wie die operative Welt funktioniert. Wie gut das gelingt, hängt natürlich stark von gutem Upstream-Design ab. Deshalb sollten bekannte Schwächen der Quelle bei der Gestaltung der Output Ports deiner Data Products berücksichtigt werden. Unvermeidbar ist allerdings, dass Änderungen an der Qualität der Quelldaten alle Data Products betreffen, die von den entsprechenden aligned source data abhängen.

Spezielle Heuristiken für source-aligned Data Products

Semantische Kohärenz

• Ergibt das Data Product für sich genommen Sinn, oder braucht es dafür die anderen Teile der Quelldaten?
• Wirkt es wie ein zusammenhängendes, integriertes Ganzes – und nicht wie eine zufällige Sammlung verwandter Elemente?

Daten aus genau einer Business-Domäne

• Folgt der Zuschnitt sinnvollen Domänenmodulen statt ganzen Systemen?
• Enthalten die Daten nur internen Kontext oder auch domänenübergreifenden Kontext?

Blast Radius der Quelldaten

• Wirken sich Änderungen an der Datenquelle direkt nur auf dieses eine Data Product aus?

Aggregate Data Products

Wert und Wiederverwendung versus Kosten und Komplexität

Aggregate Data Products bauen auf source-aligned Produkten auf. Sie kombinieren oder verdichten Daten aus mehreren source-aligned Products, um Semantik bereitzustellen, die in einer gesamten Domäne genutzt werden kann. Man kann sie sich als gemeinsame Bausteine vorstellen, die vielen Consumern wiederholte Integrations- und Berechnungsarbeit ersparen. Weil sie domänenübergreifende Bedeutung kodieren, brauchen sie stärkere Governance und mehr Abstimmung als source-aligned Products.

Aggregates sind ein Sonderfall, weil sich Ownership und Kostenverteilung schwerer festlegen lassen. Für ein source-aligned Data Product gibt es in der Regel einen offensichtlichen Owner: die Domäne, die das zugrunde liegende System betreibt. Da sich die Quelldaten von Aggregates oft über mehrere Owner erstrecken, sollten Aggregates nur dann entstehen, wenn ihr gemeinsamer Wert klar ist und die Verantwortung einem einzelnen Team zugewiesen werden kann, das die integrierte Semantik dauerhaft pflegen kann. Bei Aggregates lautet die eigentliche Frage oft nicht, wie man sie schneidet, sondern ob sie überhaupt existieren sollten.

Ein Aggregate anzulegen lohnt sich, wenn:

• mehrere Teams dieselbe abgeleitete Sicht mit derselben Bedeutung benötigen. Eine gute Faustregel sind drei oder mehr Teams. Wenn jedes Team seine eigene Version baut, wird das teuer und führt zu inkonsistenten Ergebnissen.
• die Ableitung selbst teuer ist. Typische Beispiele sind Feature-Berechnungen für Machine Learning, Entity Matching oder Deduplizierung. Eine hochwertige Ableitung einmal bereitzustellen und mehrfach zu nutzen, ist günstiger, als sie an vielen Stellen zu wiederholen.
• der eigentliche Wert erst durch das Zusammenführen mehrerer Quellen entsteht. So kann etwa kein einzelnes source-aligned Data Product eine vollständige Kundensicht liefern. Diese entsteht erst, wenn Bestellungen, Zahlungen, Retouren und CRM-Signale zusammengeführt werden.

Scope und Governance

Sie sind nicht sinnvoll, wenn die einzige Motivation der Wunsch nach zentraler Kontrolle ist oder wenn die gemeinsamen Use Cases in Wahrheit heterogen sind und zwangsläufig zu Streit über Definitionen führen würden. In solchen Fällen ist es besser, die Ableitungen näher bei den Consumern zu belassen und bei Bedarf separate consumer-aligned Products bereitzustellen.

Auch wenn ihre Größe von konkreten Use Cases getrieben wird, brauchen sie dennoch einen engen Scope. Das Risiko besteht darin, ein Aggregate in ein kleines Data Warehouse zu verwandeln, das jede nur denkbare Frage beantworten soll. Das würde Komplexität und Blast Radius erhöhen. Aggregates verändern sich naturgemäß langsam, weil jede semantische Änderung viele Consumer betrifft. Deshalb brauchen sie sorgfältige Governance und klare Grenzen.

Spezielle Heuristiken für Aggregates

Wert und Wiederverwendung

• Gibt es mehr als zwei Teams, die dieselbe abgeleitete Sicht mit identischer Bedeutung brauchen?
• Würden Teams ohne das Aggregate dieselbe Integrations- oder Berechnungslogik immer wieder selbst bauen?
• Entsteht der eigentliche Wert erst durch das Zusammenführen mehrerer Quellen?

Kosten und Komplexität

• Ist die Ableitung teuer (Feature Engineering, Entity Matching, Deduplizierung, source-übergreifende Joins)?
• Gibt es im Unternehmen jemanden, der bereit ist, die Kosten für dieses Data Product zu tragen?

Scope und Governance

• Ist der Scope eng genug, damit das Data Product nicht zu einem Mini-Data-Warehouse driftet?
• Ist das Ergebnis wertvoll genug, um die dafür nötige starke Governance zu rechtfertigen?
• Kann das owning Team die integrierte Semantik trotz mehrerer Quellen dauerhaft pflegen?

Consumer-aligned Data Products

Klarer Zweck

Consumer-aligned Data Products sind für einen spezifischen Zweck entworfen und sollen mit möglichst wenig Aufwand nutzbar sein. Im Vergleich zu source-aligned Data Products sind die Daten – wie der Name schon sagt – auf Endnutzer:innen und anspruchsvollere Analysen optimiert. Statt die Domänenrealität allgemein abzubilden, liefern sie genau die Daten und die Semantik, die Consumer brauchen, um fundierte Entscheidungen zu treffen, Prozesse auszuführen oder ein konkretes analytisches oder operatives Artefakt zu betreiben. Erfolg misst sich daran, ob Consumer das Data Product nutzen können, ohne zuerst eine eigene Integrationsschicht bauen zu müssen.

Ein schneller Test lautet: Dient das Data Product einem zusammenhängenden Zweck für eine klar definierte Zielgruppe? Das Ergebnis kann ein einzelner Report sein oder ein klar abgegrenzter Data Mart, der eine Familie zusammengehöriger Reports unterstützt. Ein Finance Data Mart, der „konsistentes Margen- und Umsatzreporting für den Monatsabschluss“ ermöglicht, besteht diesen Test eindeutig – auch wenn daraus Dutzende Reports gespeist werden. Das Warnsignal ist nicht die Anzahl der beantworteten Fragen, sondern ob diese Fragen demselben Entscheidungskontext angehören. Ein Data Product, das „Finance Reporting, Marketinganalysen, Ad-hoc-Exploration und zukünftige Machine-Learning-Use-Cases“ unterstützen soll, fällt durch, weil es unterschiedliche Zielgruppen und Verantwortlichkeiten vermischt.

Natürliche, fokussierte Größe

Consumer-aligned Products haben meist eine natürliche Größe – aber diese wird durch den zu erledigenden Job bestimmt, nicht durch ein einzelnes Artefakt. Solche Produkte können direkt einem bestimmten Report oder Dashboard entsprechen oder eine Familie eng verwandter Outputs unterstützen, etwa mehrere Sichten auf dasselbe Dashboard. Weitere Beispiele sind Reverse-ETL-Flüsse in operative Tools oder ein Machine-Learning-Modell mit seinem zugeschnittenen Feature-Set. Das ist eine Heuristik, keine harte Regel, hilft aber dabei, den Scope im Griff zu behalten. Wenn ein Data Product viele sehr unterschiedliche Dashboards oder Modelle beliefert, sollte es wahrscheinlich in mehrere Produkte aufgeteilt werden, die jeweils auf einen bestimmten Consumer ausgerichtet sind.

Sinnvolle Grenzen

Ihre Grenzen folgen meist Entscheidungs- oder Prozesslinien statt Systemgrenzen. Ein natürlicher Schnitt ist oft ein geschäftlicher Moment, in dem eine Entscheidung getroffen oder eine Handlung ausgelöst wird. Beispiele dafür sind ein Fraud Analyst, der einen Fall prüft, oder eine Marketing-Verantwortliche, die über die Budgetverteilung entscheidet. Solche Zuschnitte widersprechen oft der Struktur der Quellsysteme – das ist aber in Ordnung, weil consumer-orientierte Produkte nicht die Prozesse abbilden, sondern die Nutzung optimieren sollen.

Business Consumer

Schließlich brauchen sie klare Business-Ziele und ein strenges Scope-Management. Wenn du die Personen oder Teams, die das Data Product nutzen sollen, nicht benennen kannst, besteht die Gefahr, dass du einen nur dünn getarnten Sammeldatensatz baust. Das Data Product sollte nur das enthalten, was für die konkrete Aufgabe gebraucht wird – nicht alles, was irgendwann vielleicht nützlich sein könnte.

Spezielle Heuristiken für consumer-aligned Data Products

Klarer Zweck

• Lässt sich dieser Zweck als Satz aus Verb + Objekt ausdrücken (zum Beispiel Churn nach Segmenten überwachen, Nachfrage nach Kategorien prognostizieren oder Betrugsfälle prüfen)?

Natürliche, fokussierte Größe

• Unterstützt das Data Product genau einen Entscheidungskontext, aus dem ein oder mehrere zusammengehörige Dashboards, Reports oder Outputs entstehen?

Sinnvolle Grenzen

• Folgt die Grenze einem Prozess und nicht einer Systemgrenze?
• Spiegelt der Zuschnitt wider, wie ein Consumer handelt oder entscheidet – und nicht, wie Daten zufällig gespeichert sind?

Business Consumer

• Wird dein Data Product von Business Usern, Data Analysts, Data Scientists oder Anwendungen genutzt?