Avatar of Daniel Lauxtermann

Was ist eigentlich ein Data Product?

Der Begriff Data Product gehört zum Themengebiet Data Mesh.

In einem Data Mesh Ansatz übernimmt ein Team den Besitz („Ownership“) seiner analytischen Daten. Anstatt Daten zu sammeln („Datalake“) und von einem zentralen Team auswerten zu lassen, stellt jedes Team seine Daten als Data Products zur Verfügung.

Ein Data Product ist eine Menge von relevanten Informationen zum Zweck der Analyse. Das Format ist zunächst zweitrangig.

Ein Data Product sollte sein:

Mögliche Ausprägungen können sein:

Nur eine weitere Anforderung?

Data Product sind auch etwas das für Stakeholder geliefert wird. Ein Team ist Besitzer seiner Daten, doch Stakeholder brauchen diese Daten für Analysen.

Abwarten bis die ersten Anforderungen eingehen, könnte eine Option sein. Data Products gleich von Anfang an mitzudenken, eine andere.

Das Beispiel zeigt den Nutzen Data Products aus dem Interesse des eigenen Teams heraus zu entwickeln.

Ein Anfang ohne Data Products

Dazu eine kleine Geschichte aus der Praxis. In einem Projekt ging es darum, Produktdaten bereitzustellen. Das sollte in mehreren Schritten erfolgen. Zunächst sollte ein Proxy aufgebaut werden, der die bestehenden Produktdaten einliest und transformiert, damit diese in einem neuen Format bereitgestellt werden können. Im nächsten Schritt sollten dann die bestehenden Produktdatenquellen abgelöst werden. Die Konsumenten der Produktdaten sollten idealerweise davon nichts mitbekommen.

Grobe Übersicht der Systemlandschaft
Grobe Übersicht der Systemlandschaft

Im Vorfeld wurden Interviews mit Fach- und Systemexperten durchgeführt. Sogar ein Entwickler mit Erfahrung in der bisherigen Systemwelt war in die Entwicklung aktiv mit eingebunden. Hypothesen wurden aufgestellt und versucht durch Stichproben zu überprüfen.

Der Livegang erfolgte in mehreren Schritten. Mit jedem Schritt tauchten neue Fragen und Probleme auf. Die Folgen: Die Anzahl an Fragen wurde größer. Der Aufwand für die Klärung dieser Fragen und notwendige Datenrecherchen wurde immer größer.

Für die Recherchen wurden typischerweise genutzt:

Mit der Zeit stieg der Aufwand immer mehr an.

Im Ergebnis wurde immer mehr Zeit im Team geblockt.

Eine besondere Herausforderung: Um die Priorität von gefunden Probleme zu beurteilen waren externe Daten notwendig. Produktdaten mit hohem Lagerbestand mussten natürlich schneller geprüft werden als solche mir geringem Bestand.

Wenn wir uns am Anfang zu wenig Gedanken darüber machen wie wir unsere Daten analysieren können, dann werden wir später zur Kasse gebeten.

Wie Data Products geholfen haben

Um den Problemen entgegenzutreten wurden erste Data Products erstellt.

Es entstanden die ersten Tabellen in Google Big Query. Mit diesen ließen sich nun schon einmal quantitative Analysen durchführen. Durch den Abgleich der Update-Nachrichten mit den Produktdaten konnte geprüft werden, ob die Daten im Produktinformationssystem richtig gespeichert wurden. Und es konnte geprüft werden, ob ungewöhnliche Aktualisierungen aus den „alten“ Systemen gesendet wurden.

Um die Auswertbarkeit zu erhöhen wurden im nächsten Schritt die Produktdaten aus den „alten“ System eingebunden. Glücklicherweise waren diese ebenfalls als Data Product veröffentlicht. Jetzt konnte bereits ein Großteil der Reisen der Produktdaten abgebildet werden.

Typische Fragestellungen:

Der entscheidende Punkt war die quantitative Vergleichbarkeit.

Auch dem Product Owner des Teams war es jetzt möglich bei Recherchen und Analysen zu unterstützten. Stück für Stück entstanden erste Berichte, um Analysen durchzuführen. Hierfür konnten jetzt auch BI-Tools wie Microsoft Power BI und Google Looker genutzt werden.

Ein Artikel über BI-Tools wird gesondert erscheinen. Dieser wird auch auf die Frage eingehen, warum Entwicklungsteams sich mit so etwas beschäftigen sollten.

Data Products gehören ins Backlog

Hattest du beim Lesen der beiden letzten Abschnitte den Gedanken: „Warum wurde das alles nicht am Anfang schon gemacht“?

Wichtige Frage. Einfache Antwort? Kostet alles Zeit und Geld.

Gerade am Beginn einer Entwicklung steht ein Team häufig besonders unter Druck. Über Qualitätskriterien sprechen und Szenarien aufstellen? Über notwendige Berichte und fachliche Definition von Daten reden? Dafür ist häufig keine Zeit oder zumindest entsteht schnell dieser Eindruck.

Deshalb gehören Data Products ins Backlog und müssen Teil des Refinements sein. Sie gehören auch in den Scope von Roadmaps und jeder Art von Ereignis, in welchem über Liefergegenstände, Zieltermine und Kosten gesprochen wird.

Tipp: Wenn keine konkreten Anforderungen vorliegen, geht davon aus, dass diese alle kurz vor dem Zieltermin kommen.

Auskunftsfähigkeit fördert Autonomie

In fast jeder Organisation gibt es Berichte mit Kennzahlen und das in unterschiedlicher Detailtiefe. Gerade in großen Organisationen sind Data Products die Basis für Data Teams, um solche Berichte z.B. für den C-Level bereitzustellen. [2]

Doch nähert man sich dem Thema von dieser Seite aus, entsteht vielleicht zuerst ein anderer Gedanke. Data Products sind eine weitere Last für Teams. Nun also noch ein Thema das geliefert werden muss. Deshalb ist es wichtig, das Thema auch aus der Perspektive eines konkreten Teams zu betrachten. Meine Hypothese ist, dass in den überwiegenden Fällen die Aufwände sowieso entstehen. Die Frage ist nur wann und wie sich das auf den Flow des Teams auswirkt.

Als Teams wünschen wir uns doch eine hohe Autonomie. Doch dafür müssen wir auch entlang der wirtschaftlichen Ziele unsere Organisation handeln. Und wie soll das funktionieren, wenn wir nicht wesentliche Daten unseres eigenen Softwareproduktes im Blick haben?

Fazit

Jedes Team sollte sich Gedanken um seine Data Products machen. Starten sollte es damit bereits zum Beginn der Entwicklung, auch wenn noch keine Anforderungen von Stakeholdern vorliegen. In Rahmen eines Data Mesh Ansatzes kommt es quasi automatisch zu Data Products. Doch auch wenn dieser Ansatz nicht verfolgt wird, kann ein Team die Idee eines Data Products für sich selber nutzen.

Data Products ermöglichen es:

Quellen

  1. Evans, E. J., Evans, E. J. & Fowler, M. (2004). Domain-driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.  ↩

  2. Data Mesh Architecture. (2023, Januar). Abgerufen am 4. Januar 2023, von Online hier  ↩