Warum dein Team Data Products braucht

Daniel Lauxtermann

This blog post is also available in English

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:

• Eine Präsentation fachlicher Daten mit Beschreibung.
• Angemessen aktuell.
• Einfach zugänglich.
• Getestet (hohe Wahrscheinlichkeit das es auch die richtigen Informationen anzeigt).
• Entworfen entlang von Use Cases oder Szenarien (keine dumme Kopie aller Daten).
• Aktiv verwaltet durch das bereitstellende Team.

Mögliche Ausprägungen können sein:

• Eine Menge von Tabellen, die in einem Service wie z.B. Google Big Query zur Verfügung gestellt werden.
• Eine Datei (JSON, CSV oder ähnliches), die regelmäßig bereitgestellt wird (z.B. in einem S3 Bucket).
• Im Prinzip auch schon eine Art Bericht mit Tabellen oder Grafiken.

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.

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:

• SQL Abfragen auf die Datenbanken der beteiligten Softwaresysteme in Verantwortung des Teams.
• Einzelrecherchen über die Benutzeroberfläche der eigenen Softwaresysteme.
• Bestehende Schnittstellen zu den “alten” Softwaresystemen.
• Delegation von Fragen an Systemexperten der “alten” Softwaresysteme

Mit der Zeit stieg der Aufwand immer mehr an.

• Die “alten” Softwaresysteme boten teilweise keine Möglichkeit Massendaten zu prüfen.
• Die Anzahl an zu prüfenden Stichproben wurde immer größer, um Muster zu erkennen.
• Es wurden die ersten Skripte geschrieben, die nicht von allen im Team genutzt werden konnten.
• Die Menge an Anfragen stieg 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.

• Aktualisierungen aus dem Anti Corruption Layer [1]
• Produktdaten inklusive Statusinformationen
• Verletzungen der Produktdatenqualität

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:

• Entspricht der Stand im Quellsystem dem erwarteten Zustand im Produktinformationssystem?
• Sind die erhaltenen Aktualisierungen konsistent mit den Daten aus dem Quellsystem?

Der entscheidende Punkt war die quantitative Vergleichbarkeit.

• Wie viele Produkte mit dem Zustand X gibt es im Quellsystem?
• Wie viele Datensätze in den “alten” und neuen Systemen entsprechen dem Zustand Y?

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.

• Hypothesen konnten auf diese Weise akkurater geprüft werden als nur mit Stichproben.
• Analysen konnten über die Daten mehrerer Systeme hinweg durchgeführt werden.
• Kennzahlen konnten auf Basis der Daten entwickelt werden.
• Prüfungen konnten eingebaut werden, ob Produktdaten online sind oder nicht.
• Berichte konnten für Fachexperten zwecks Eigenrecherche bereitgestellt 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:

• Fragen effizienter zu beantworten.
• Anforderungen anhand von tatsächlichen Daten zu verifizieren.
• Die eigenen Daten weiter zu verbessern.
• Mehr Verantwortung für sein eigenes Produkt zu übernehmen (Outside-in-Perspektive).

Quellen