Im Juni habe ich auf der TDWI in München zugesehen, wie ein KI-Agent in ca. 18 Minuten ein Datenprodukt baut. Das war ziemlich beeindruckend für mich und für alle, die zugehört haben. Während des Vortrags, wurde mir schnell klar, was dafür vorher da sein muss.
Der Plan für dieses Quartal stand eigentlich seit Januar: Datenprodukte, als Abschluss meiner drei Serien dieses Jahr: KI in der Datenmodellierung, temporale Daten und die Grundlagen der Datenmodellierung. Dann kam der Vortrag „Open Standards for Data Products" von Simon Harrer, und seine Demo passte so gut zur Serie, dass sie jetzt der Aufhänger ist.
Simon hat mir später im Podcast erzählt, was der Agent dafür brauchte. Erstens einen Data Contract, der beschreibt, welche Tabellen entstehen, wie sie befüllt werden und was die Daten darin bedeuten, angehängt an eine Ontologie. Dazu Skills mit den Konventionen des Hauses, von Namensregeln bis zum Umgang mit personenbezogenen Daten. Und einen Marktplatz, in dem er nachsehen konnte, was es schon gibt. Dort hat er die drei Datenprodukte gefunden, auf denen er aufsetzt, und den Zugriff selbst beantragt. Genehmigt wurde für die Demo automatisch, sonst hätte es mit den 18 Minuten nicht geklappt.
Auffällig ist, dass alle drei Dinge Beschreibungen sind und keins davon KI. Um genau diese Beschreibungen ging es in den drei Serien davor. Dieser Artikel ist die Landkarte zu einer dreiteiligen Serie darüber, wie aus dieser Beschreibung bessere Datenprodukte werden. Das ganze Gespräch mit Simon erscheint am 24. November als Folge #005 von meinem Podcast [antifragile data].
Teil 1 · erscheint am 28. Oktober
Was ist ein Datenprodukt? Ein Star Schema mit 15 Tabellen: eins, fünfzehn oder kein Datenprodukt — und was neben der Schnittstelle noch dazugehört.
Teil 2 · erscheint am 18. November
Woher kommen die Daten, wo hört ein Datenprodukt auf, und wie stellt man es so bereit, dass es auch den ersten Breaking Change übersteht?
Teil 3 · erscheint am 9. Dezember
Automatisierung durch Informationsmodelle: wie aus dem Modell die Semantik wird, auf die Contracts und Agenten zugreifen.
Was ist ein Datenprodukt?
Bei Kunden höre ich dazu sehr unterschiedliche Antworten. Ich habe Simon deshalb ein Beispiel aus meiner Dimensional Modeling Fundamentals Class mitgebracht: ein Star Schema fürs Accounting, mit Kostenverrechnung über mehrere Stufen, rund 15 Fakten- und Dimensionstabellen. Ist das ein Datenprodukt, sind es fünfzehn, oder ist es gar keins?
Seine Antwort war: ein Datenprodukt. Die Tabellen gehören einem Team, sie ändern sich gemeinsam und sind nur zusammen sinnvoll nutzbar. Zum Produkt gehört für ihn neben der Schnittstelle auch die Pipeline dahinter, die die Tabellen befüllt — er nennt sie die Fabrik.
Ich erkläre das gern mit dem Drive-in. Wer dort bestellt, will das fertige Produkt und fragt nicht, wo das Brötchen oder das Salatblatt herkommt. Trotzdem gehört all das dazu. Eine physische Tabelle, die ohne weitere Beschreibung bereitgestellt wird, ist dagegen erst einmal nur eine Tabelle.
→ Vertieft in Teil 1 am 28. Oktober.
Wo hört ein Datenprodukt auf?
Das andere Extrem ist die Referenztabelle mit 15 Zeilen und vier Spalten. Auch die ist für Simon ein Datenprodukt, weil sie jemandem gehört, etwa einem Master-Data-Team. Den Zugriff darauf würde er automatisch genehmigen, denn viele brauchen sie und zu schützen gibt es wenig.
Jede einzelne Tabelle zum Datenprodukt zu machen, hält er dagegen für falsch. Sein Maßstab kommt aus der Softwareentwicklung: hohe Kohäsion, geringe Kopplung. Was Nutzer ohnehin zusammen abonnieren, gemeinsam verantworten und gemeinsam versionieren, gehört in ein Produkt, Bestellungen und Bestellpositionen zum Beispiel. Spätestens beim ersten Breaking Change zeigt sich das: Version 2 der Bestellungen neben Version 1 der Positionen wird schnell kompliziert.
→ Vertieft in Teil 2 am 18. November.
Vom Modell zum Mehrwert
In den letzten Monaten habe ich mehrfach gesehen, dass physische Tabellen ohne weitere Beschreibung als Datenprodukt bereitgestellt wurden. Wer die Herkunft kennt, kommt damit eine Weile zurecht. Ein Agent wie in der Demo findet darin nichts.
Für das, was wir früher salopp Schnittstelle genannt haben, gibt es inzwischen drei offene Standards: ODCS beschreibt den Data Contract, ODPS das Datenprodukt und OSI (heute Apache Ossie) die Semantik. Die Trennung hat einen Grund. Eine Bestellnummer taucht in vielen Contracts auf, mal als Bestellnummer, mal als Order ID, und was sie im Endkundenverkauf bedeutet, will man nur einmal beschreiben. Der Contract verlinkt auf diese Beschreibung, und zwar immer nach oben, weil die Semantik nicht jede Umsetzung kennen kann.
Diese technologieunabhängige Beschreibung des Unternehmens ist das, was ich Informationsmodell nenne und was die Grundlagen-Serie im Sommer aufgebaut hat. Aus ihm lässt sich die Semantik beschreiben. Was dort festgelegt ist, erben alle Contracts, die darauf verlinken, etwa die Klassifikation von öffentlich bis streng geheim. Ein Agent findet die Order ID dann auch in einem Produkt, in dem sie Bestellnummer heißt.
Das ist der Mehrwert, den ich im Titel der Serie meine: Datenprodukte, die aus einem Informationsmodell heraus beschrieben sind, taugen mehr, für Menschen wie für Agenten. Warum KI auf diese Grundlage angewiesen ist, steht im KI-Paradox, was ein Informationsmodell wert ist, in Datenmodellierung als Wettbewerbsvorteil.
→ Vertieft in Teil 3 am 9. Dezember.
Datenprodukte haben eine Zeitachse
Simon hat dafür ein schönes Bild. Man kauft im Supermarkt keinen Datenkanister und trägt ihn nach Hause. Man kauft Zugriff, ein Abonnement auf Daten, die sich ständig ändern und durch das Produkt hindurchfließen.
Damit wird die Zeit Teil des Produkts. Wer abonniert, muss wissen, welche Sicht er bekommt: wie die Realität heute aussieht (As-Is), wie sie damals aussah (As-Was) oder was wir damals wussten (As-Of). Diese drei Sichten waren das Thema der Serie über temporale Daten im Frühjahr.
Wie Daten immer rechtzeitig da sind
Der Abonnent sieht die Schnittstelle. Dass das Datenprodukt wie geplant verfügbar ist, dafür sorgt die Engine der Data Solution dahinter, also die Data-Logistik-Prozesse. Roelant Vos und ich haben in Data Engine Thinking die Prinzipien zusammengefasst, nach denen diese Prozesse gebaut sein sollten — darunter idempotent, deterministisch und unabhängig. Der gemeinsame Kern ist, dass jeder Prozess jederzeit laufen und erneut laufen kann, ohne Schaden anzurichten. Im Buch steht dafür ein einfacher Test: den Prozess zweimal hintereinander laufen lassen und schauen, ob das Probleme macht.
Für die Verfügbarkeit zählt besonders, dass Prozesse unabhängig voneinander laufen und bei jedem Lauf alle anstehenden Änderungen verarbeiten. Dann lässt sich die Ladefrequenz ändern, wenn ein Abonnent die Daten früher braucht, ohne dass jemand die Engine umbauen muss.
Woran man den Mehrwert erkennt
Bleibt die Frage, woran man merkt, dass ein Datenprodukt etwas taugt. Ich schaue dafür zuerst auf qualitative Metriken, und die wichtigste ist die Wiederverwendung: Setzen andere darauf auf, oder baut jedes Team sich seine Fassung selbst?
Dazu kommt der Blick auf zwei Seiten, wie gut ein Produkt beschrieben ist und wie stark es genutzt wird. Viel Dokumentation bei wenig Nutzung deutet auf ein Produkt, das an der Zielgruppe vorbei gebaut wurde. Wenig Dokumentation bei viel Nutzung ist ein Risiko, denn dann steckt das Wissen in den Köpfen der Nutzer und nirgends sonst.
Von der Ablage zum Ergebnis
Bill Reynolds hat den ganzen Weg im September in fünf Zeilen gefasst:
Data without structure is storage
Data with shared meaning is an asset
Data with context is information
Information drives decisions
Decisions drive outcomes
Die zweite Zeile ist für mich der Kern dieser Serie. Die besten Datenprodukte entstehen dort, wo ein Informationsmodell, eine saubere Zeitachse und eine Engine, die zuverlässig liefert, zusammenkommen. Dann ist es auch egal, ob am Drive-in ein Mensch bestellt oder ein Agent.
So long,
Dirk
Über diese Serie: „Datenprodukte: Vom Modell zum Mehrwert" führt die drei Serien dieses Jahres zusammen. Teil 1 (28. Oktober) klärt, was ein Datenprodukt ist. Teil 2 (18. November) zeigt, woher die Daten kommen und wie man ein Datenprodukt schneidet und bereitstellt. Teil 3 (9. Dezember) geht der Automatisierung durch Informationsmodelle nach. Das Gespräch mit Simon Harrer erscheint am 24. November als Folge #005 von meinem Podcast [antifragile data].
Das Informationsmodell sauber aufbauen
Begriffe klären, Definitionen verhandeln, konzeptionell und logisch modellieren: Genau das ist die Grundlage für gut beschriebene Datenprodukte und der Kern der Data Modeling Master Class. Neue Termine sind in Vorbereitung.