Datenprodukte

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Massgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Podcast. Heute mit Stefan Negele zum Thema Data Products und Data Marketplace. Hi Stefan.

Stefan Negele: Hallo Sven. Grüße dich.

Sven Johann: Ja, Stefan ist Senior Consultant bei der INNOQ seit zweieinhalb Jahren, knapp drei Jahren. Und beschäftigt sich hauptsächlich mit dem Thema Data Governance. Kann man so sagen.

Stefan Negele: Genau.

Sven Johann: Genau, ich habe das einfach von der INNOQ Webseite geklaut.

Stefan Negele: Das habe ich da, glaube ich, reingeschrieben.

Sven Johann: Genau, gibt es noch andere Dinge, die wichtig wären über dich zu wissen?

Stefan Negele: Ja, genau, ich beschäftige mich ungefähr seitdem ich bei der INNOQ bin grob mit dem Feld Data Governance. Und so bin ich auch zur INNOQ gekommen, habe ich mich stark mit Software-Architektur beschäftigt und das mache ich natürlich auch immer noch, das kriegt man nicht los. Genau, das ist, glaube ich, das Wichtigste. Ich bin eigentlich Software-Ingenieur im Herzen und habe aber den Gefallen an Daten entwickelt und das macht mir sehr viel Spaß.

Sven Johann: Vielleicht kommen wir da später auch noch darauf. Ich bin froh, dass etwas mehr Liebe in Daten kommt, vor allem im Sinne von Data Driven Decision Making. Das ist vielleicht ein bescheuerter Begriff, aber ich bin eigentlich ein ziemlich großer Fan davon. Okay, ich würde sagen, wir legen einfach los. Was ist eigentlich ein Data Product?

Stefan Negele: Ja, das ist eine sehr gute Frage. Es gibt eigentlich keine offizielle Definition davon. Der Begriff ist, würde ich sagen, ein bisschen aus der Data Mesh Theorie, es gab ja das Buch von Zhamak Dehgani zu Data Mesh, und da wurde der Begriff Data as a Product geprägt, woraus das so ein bisschen entstanden ist. Wir müssen schon unterscheiden: Data as a Product und Datenprodukt ist nicht dasselbe.

Sven Johann: Okay.

Stefan Negele: Aber das Wichtige ist eben das Wort Produkt. Wir sehen die Daten eben, wir haben einen Produktgedanken, wenn wir über Daten sprechen und sehen sie nicht als reine Assets. Ähnlich wie wir unsere Microservices, APIs und UIs designen, denken wir an Kunden, wollen das Ganze anpreisen und dem Kunden verkaufen, wie ein Produkt. Technisch, aus Data Engineering Sicht, sieht man Data Products oft als ein Sammelsurium an Data Pipelines, Transformationen, Tabellen – alles, was technisch dazugehört, um einen Datensatz aufzubereiten, aber eben nicht nur die Tabelle oder die Files im S3 Bucket. Beschrieben wird das dann häufig in einem YAML-Format, um die Automatisierung zu gewährleisten. Da gibt es Standards.

Sven Johann: Bevor wir zu technisch werden – wir können nie zu technisch werden, aber vielleicht noch einmal auf einer anderen Ebene: Zum einen wäre es natürlich schön. Ich muss gerade ein bisschen lachen, als du gesagt hast, wir sollten das als Produkt sehen, so wie unsere Services und Schnittstellen. Ich leide jeden Tag darunter, dass Teams mich ignorieren, die mich eigentlich als Kunden sehen sollten, egal. Aber ich sage mal, wenn man es theoretisch richtig machen würde, dann hätte man einen Produktgedanken. Was wäre denn ein Beispiel für ein Datenprodukt?

Stefan Negele: Na ja, ich könnte mir vorstellen, zum Beispiel brauche ich natürlich erstmal den Use Case. Von dem aus würde ich immer denken. Der Use Case ist, sagen wir mal, ein Dashboard, um KPIs darzustellen, beispielsweise. Das Management will etwas wissen.

Sven Johann: Okay, ja.

Stefan Negele: Das muss mit Daten befeuert werden. Oft oder klassisch liegt das dann in zentralen Datenteams, die die Daten im Unternehmen zusammen sammeln. Ein Datenprodukt oder ein Datenproduktgedanke geht man das ein bisschen anders an und sagt: Okay, ich habe vielleicht ein Team, das Dashboards für das Management baut, und das will jetzt Daten von einem Team, das Microservices baut. Die reden dann miteinander, und dort werden dann Daten exportiert oder auf einer Datenplattform bereitgestellt, damit die Auswertung sinnvoll möglich ist und keine Fehler passieren. Und dass auch zwischen Konsumenten und Produzenten ein klares Verständnis herrscht.

Sven Johann: Okay, ich versuche gerade in meiner Welt nachzudenken, weil ich ab und zu bei einem Kunden bin, jetzt so vier Mal im Jahr, und die machen schon sehr viel mit Daten und wollen auch viel mehr mit Daten machen. Es ist ziemlich wichtig, dass man genau weiß, wo Flaschenhälse sind und wo man optimieren kann, zum Beispiel. Du hast Microservices angesprochen, und ich stelle mir das so vor: Die haben zum Beispiel ein Lager, und in diesem Lager liegen ihre Produkte, die sie in ihre Geschäftsstellen bringen. An diesen Daten sind natürlich viele andere Organisationseinheiten interessiert, Daten, die reinkommen und sich ändern. Im Moment ist das, sagen wir mal, ich tue ihnen wahrscheinlich unrecht, hemdsärmlich gemacht. Ich meine, die denken schon ziemlich in diese Richtung, aber bei einer großen Organisation dauert es natürlich immer lange, bis man das alles reinbringt. Aber das ist für mich dieser Gedanke: Ich habe Consumer von diesen Daten, die interessieren sich dafür, und ich kann jetzt nicht, wie man früher gedacht hat, nach dem Motto: Ich blase die Daten einfach raus, wenn jemand kommt.

Stefan Negele: Vielleicht kann man ja.

Sven Johann: Ja.

Stefan Negele: Vielleicht kann man gerade diese Unterscheidung machen. Man hatte oft diesen Gedanken, weil du gerade gesagt hast, ich blase die Daten raus: Man hatte ja früher diesen Big Data Data Lake Gedanken und dann hat man gesagt: Okay, wir haben Analyseanforderungen. Und wir werfen quasi alle Daten, die anfallen, in den Data Lake, und dann kann sich da schon jemand das rauskratzen, was er braucht. Das ist, glaube ich, genau der Unterschied zum Data Product. Da biete ich das auf dem Marktplatz an und sage: Ich habe hier meine Daten, ich gebe auch Garantien dazu. Ich erkläre auch, was sie machen und was sie bedeuten.

Sven Johann: Mhm. Ja, ich muss sagen, ich finde das schon relativ, ich finde es ziemlich attraktiv, weil meine Erfahrung auch immer ist: Die Teams, wo ich abhänge, produzieren natürlich einen Haufen Daten, die wir an den Data Lake geben, um darin herumzufischen. Aber diese Anfragen sind immer sehr generisch an die Daten, weil die Leute, die darin herumfischen, keinerlei Domänenexpertise haben.

Stefan Negele: Ja.

Sven Johann: Du hast dann fünf Leute, die reden mit 20 Teams, und dieser ganze Produktgedanke kommt da eigentlich überhaupt nicht auf. Es ist die Frage, wie kommt man überhaupt strukturiert zu einem Data Product? Und freundlicherweise gibt es ja die Data Products Canvas. Die packen wir auch in die Shownotes – kein Podcast ohne eine Canvas anzupreisen. Aber ich denke, das ist schon ziemlich hilfreich, dass man wirklich auf wenig Platz eine Idee hat, was man zu tun hat. Ich muss sagen, ich habe hier auch dieses Data Mesh Buch liegen, und klar kann man es lesen. Es sollte man auch lesen. Aber um jetzt ein Datenprodukt vielleicht schon anzubieten, ist so eine Canvas gar nicht verkehrt. Genau, bei der Canvas.

Stefan Negele: Ja, genau, das Canvas ist vor allem auch sinnvoll, um ein Datenprodukt zu erarbeiten, vielleicht in einem Workshop mit einem Konsumenten der Daten. Hatten wir gerade drüber geredet: Konsumenten und Produzenten sollen sich gegenseitig verstehen, sollen ein gemeinsames Verständnis haben. Mit diesem Canvas kann ich mich dann gemeinsam beispielsweise in einem Raum einsperren und sagen: Hey, wir setzen uns jetzt zwei Stunden hin und gucken, was ihr eigentlich wollt und wie wir das dann hinbekommen.

Sven Johann: Mhm.

Stefan Negele: Und so können wir das ausgestalten.

Sven Johann: Ja, in der Canvas steht: Der erste Punkt ist, wir müssen die Consumer Needs und die Use Cases kennen.

Stefan Negele: Ja.

Sven Johann: Genau, Beispiele für Konsumenten wären, würde ich tippen, einfach andere Teams. Oder wer würde da noch in Frage kommen?

Stefan Negele: Genau, ich hatte ja gerade dieses Standardbeispiel genannt. Das kommt natürlich darauf an, wie mein Datenprodukt geformt ist. Wenn ich jetzt diesen Use Case habe, ich will Daten für ein KPI-Dashboard oder was auch immer darstellen, dann sind meine Konsumenten wahrscheinlich dort in der entsprechenden Domäne angesiedelt. Es kann natürlich auch sein, oder das kommt oft vor, dass Konsumenten aus dem Marketing kommen. Mein Datenprodukt könnte aber beispielsweise auch ein Store für ML-Features, also Machine Learning Features oder so etwas sein.

Sven Johann: Mhm.

Stefan Negele: Dann sind meine Konsumenten aber wahrscheinlich auch andere Teams, wahrscheinlich eher Data Scientists oder Data Engineers, solche gearteten Teams. Genau, es kann mannigfaltig sein. Ich kenne es selber aus dem Alltag auch so, dass man Datenprodukte auch für Stammdatensysteme haben kann. Das heißt, die Konsumenten müssen dann gar nicht unbedingt einen analytischen Use Case haben, sondern vielleicht haben sie auch einen operativen Use Case.

Sven Johann: Genau, das ist eigentlich immer mein Gedankengang, weil ich mit Analytics weniger zu tun habe, operativ aber schon. Du hast eben das Microservice-Umfeld angesprochen, zum Beispiel. Wenn ich so eine Anwendungslandschaft sehe, kopieren wir glücklicherweise die letzten 10 Jahre sehr viele Daten. Daran denke ich hauptsächlich: Damit ich funktioniere, brauche ich Daten von folgendem Stammdatensystem. Und wie komme ich daran? Meistens ist es ja genauso, dass die, die diese Daten anbieten, sie eigentlich gar nicht anbieten; ich muss sozusagen betteln kommen. Es gibt praktisch überhaupt kein Product Thinking auf der Seite. Dass man halt sagt: Ah, ich brauche Daten. Und dann keine Lust. Aber ich habe folgende Use Cases, ich habe folgende Consumer Needs. Bei mir ist das tatsächlich eher im operativen Bereich, was ich wichtig finde. Ja, okay. Der Klassiker, wird man sagen, auch hier wieder: Man startet am besten mit Use Cases und was die Leute überhaupt brauchen. Das passiert seltener, als man denkt.

Stefan Negele: Genau, wenn die Hörer oder Viewer sich diesen Canvas mal ansehen: Die Use Cases oder die Konsumenten haben wir auf dem Canvas auf der ganz rechten Seite. Das heißt, wir fangen an, diesen Canvas von rechts nach links auszufüllen. Also für Europäer kontraintuitiv, aber genau, rechts, weil wir zuerst an die Konsumenten denken wollen, denn ein Produkt bringt nichts ohne den Kunden. So kann man sich das vorstellen, oder?

Sven Johann: Genau, genau. Ja, dann, wenn ich von rechts weiter nach links gehe, kommen die Data Contracts. Dazu muss ich sagen, wir haben ja schon mit Simon Harrer eine Folge zu Data Contracts gemacht. Wer da mehr wissen will, kann einfach dort reinschauen. Aber vielleicht könntest du noch mal so zwei bis drei Minuten kurz etwas dazu sagen, was Data Contracts überhaupt sind?

Stefan Negele: Data Contracts sind im Prinzip Schnittstellendefinitionen, möchte ich mal so sagen, für datenintensive Anwendungen. Man kann sich das ähnlich vorstellen wie eine OpenAPI Spec oder so etwas. Das wird ganz oft auch mit YAML, JSON Schema und so definiert. Der Unterschied zu eher technischen API Specs ist, dass hier ganz viel Wert auf die Qualitätseigenschaften der Daten gelegt wird, auf die Service-Eigenschaften. Es gibt klassischerweise in Data Contracts auch so etwas wie SLAs, die definiert werden. Es wird wirklich auf Feldebene definiert, wie die Qualität dieses Feldes ist. Das ist oft für den analytischen Bereich sehr, sehr wichtig, weil es da eben auch einfach starke Unschärfen gibt, gerade wenn ich mit großen Datenmengen arbeite. Wie ist denn die Qualität von einer Spalte? Ist denn das Feld immer gesetzt?

Sven Johann: Ja, also so etwas wie: Das E-Mail-Feld ist zu 70 % gesetzt, obwohl es optional ist, zum Beispiel. Genau, ja, ja.

Stefan Negele: Und ganz viel Wert wird auch auf Semantik gelegt. Wenn ich mir jetzt eine OpenAPI Spec von irgendeiner API ansehe, dann steht da meistens nicht, was ein Feld bedeutet. Das ist in einem Data Contract sehr, sehr wichtig, weil wir unseren Kunden oder Konsumenten erklären wollen, was in dem Feld steht. Deswegen ist da viel Platz eingeräumt. Klar sind technische Daten enthalten, wie man sich mit einem Serverobjekt klassischerweise verbindet. Und ja, vielleicht steht auch so etwas wie ein Preis dran, weil das Betreiben eines Produkts oft etwas kostet. Und vielleicht möchte ein Kunde oder Konsument Daten haben, und ich sage: Ja, aber das Bereitstellen kostet richtig viel Geld oder Arbeitskraft.

Sven Johann: Okay, ja.

Stefan Negele: Wir schreiben da mal einen Preis dran. Ich finde das sehr, sehr spannend, und dann kann sich ein Konsument überlegen, ob er es denn wirklich braucht.

Sven Johann: Ja, ja, ja, okay, okay. Ja, also ich muss sagen, mit den Qualitätseigenschaften finde ich auf jeden Fall ziemlich interessant. Ja, weil ich meine, früher vor Data Contracts musste ich, wenn ich aus Datenquellen Daten abgesaugt habe, ja selber immer Analysen machen, um zu verstehen, wie sich die Daten verhalten. Und dann haben wir über die Zeit gelernt und so weiter, und das ist natürlich…

Stefan Negele: Und das ist halt auch oft ein großes Missverständnis. Man sieht so ein Feld und liest die Definition davon vielleicht und hat dann eine Vorstellung: Ja, da steht E-Mail drin, das ist immer gefüllt. Oder vielleicht ist das sogar immer gefüllt, aber es ist vielleicht oft nicht im E-Mail-Format. Da hat vielleicht jemand einfach nur einen Strich eingetragen, weil das irgendwie nicht validiert wurde. Oder es wurde validiert, aber es ist doch trotzdem irgendwie dazu gekommen. Es war ein optionales Feld, aber es wurde eine falsche Form eingetragen. Datumsfelder, wir haben europäische Datumsformate, wir haben weltweite Datumsformate, das sieht alles ganz anders aus. Wenn das ein Freitextfeld ist oder aus mehreren verschiedenen Datenquellen befüllt wurde und das ist jetzt in meinem Datensatz nur ein String, das ist kein aufgearbeiteter Datensatz. Dann lese ich vielleicht die ersten zehn Samples, sehe, oh, das sieht immer aus, als wäre das nach amerikanischer Notation gemacht, aber auf Zeile 1000 haben wir dann plötzlich europäische Notation, und mein Folgeskript bricht dadurch.

Sven Johann: Mhm.

Stefan Negele: Ja, und so etwas kann ich dann eben sinnvoll beschreiben. Da geht es eben wieder auch darum: Ich gebe meinem Konsumenten Garantien und auch ein gemeinsames Verständnis, was denn eigentlich in diesem Datensatz steht.

Sven Johann: Ich denke auch, ich selbst muss mir vielleicht noch mal genauer ansehen, wie meine Datenqualität überhaupt ist. Ganz oft weiß man das eigentlich gar nicht so genau. Gut, ja, also wir haben mit unseren potenziellen Konsumenten gesprochen, wir wissen, was die brauchen, wir entwerfen eine Schnittstelle, also Data Contract. Was kommt als Nächstes?

Stefan Negele: Ja, was kommt als Nächstes? Vielleicht muss man sich mit dem Konsumenten auch auf ein Format einigen.

Sven Johann: Ah, okay, ja.

Stefan Negele: Wie die Daten angeliefert werden sollten, steht üblicherweise auch im Contract. Aber vielleicht braucht ein Konsument das als BigQuery Tabelle beispielsweise. Wenn ich jetzt sage, ich nutze BigQuery in meiner Organisation, vielleicht will ich das aber auch als Kafka Stream haben, vielleicht will ich einen File Export haben. Das ist natürlich stark abhängig vom Use Case. Ich würde sagen, das ist noch etwas, das damit reinspielt.

Sven Johann: Ja, ja, also man kann auch mehrere Formate wahrscheinlich anbieten, oder?

Stefan Negele: Man könnte theoretisch auch parallel verschiedene Formate anbieten, wenn man mehrere Konsumenten hat. Das kostet natürlich mehr, beziehungsweise vielleicht bietet meine Plattform mir das ja auch an. Wenn ich sage, ich habe da viel Automatisierung drin oder ich bin eine große Organisation, ich kann mir das leisten, eine große oder eine gute Datenplattform zu haben, dann kann ich vielleicht irgendwo in meiner Definition eine Checkbox setzen: 'Exportiere als XY’. Aber ja.

Sven Johann: Okay. Datenplattform können wir vielleicht später noch mal darauf eingehen.

Stefan Negele: Genau, und jetzt meintest du, wie machen wir dann weiter? Grundsätzlich sollte man die ganze Zeit Begriffe und eine gemeinsame Sprache finden. Es gibt im Canvas ein Feld 'Ubiquitous Language’, das ist aus dem DDD gegriffen. Ich verwende es üblicherweise dafür, um Begriffe, die alle kennen müssen, die diesen Contract oder dieses Data Product verstehen müssen oder die jetzt in diesem Workshop sitzen, dort aufzuschreiben. Das kann dann am Ende in der Dokumentation oder so landen. Vielleicht referenziere ich auf einen Definitionskatalog, den ich schon habe, aber wir wollen hier einfach Begriffe so festhalten, dass alle, die gerade darüber reden und kommunizieren, ein gemeinsames Verständnis haben, was das eigentlich bedeutet.

Sven Johann: Mhm. Das stelle ich mir tatsächlich im wahren Leben gar nicht so super einfach vor. Klar, wir können, ich nenne mal ein Beispiel von dem Kunden, den ich eben genannt habe. Die haben zum Beispiel Artikel. Im Lager gibt es Artikel, aber im gesamten Universum heißen diese Dinge jetzt nicht immer Artikel, sondern manchmal heißen die halt anders. Ja, aber selbst wenn ich in meinem Universum bin, ich bin in meinem Kaufhaus oder sonst wo, und das heißt nicht Artikel aus irgendeinem Grund. Artikel ist bei uns vielleicht etwas ganz anderes, aber trotzdem, die Ubiquitous Language für das Datenprodukt ist ein Artikel, und es ist klar, der Artikel bedeutet Folgendes, der hat folgende Eigenschaften, ja, der hat, weil es aus dem Lager kommt, der hat Gewicht und so weiter, was vielleicht im Lager, sorry, was vielleicht in irgendeinem Kaufhaus dann keinen mehr interessiert. Oder wie gesagt, die nutzen andere Begriffe, aber zumindest mal für die Schnittstelle benutzen wir immer diese Sprache, diese Begriffe.

Stefan Negele: Wenn ich den Begriff ständig verwende, dann sollte ich ihn irgendwie erklären, vor allem, wenn es vielleicht eine Mehrdeutigkeit gibt.

Sven Johann: Genau, aber das ist ja praktisch nur die Ubiquitous Language aus Sicht des Datenproduzenten, also aus Sicht des Teams, das das Data Product anbietet, weil…

Stefan Negele: Aus Sicht, ja genau, aus Sicht dieses Datensatzes, oder? Was bedeutet das jetzt auf diesen Datensatz bezogen? Genau, vielleicht will ich ja auch noch, ich kann ja vielleicht auch auf einen Katalog referenzieren, wo so etwas für meine Organisation genauer beschrieben ist und wie das vielleicht weiter, wenn ich einen semantischen Layer habe, dann kann ich da vielleicht auch drauf verweisen an der Stelle.

Sven Johann: Ja, ich meine, da kommt es immer, wie gesagt, auf die Organisation an. Wenn alle genau das Gleiche unter Artikel verstehen, dann ist es einfach. Aber meistens ist es ja nicht so. Aber ich glaube, da ist es schon mal wichtig, wenn wir die Konsumenten auch im Raum haben, dass die Konsumenten vielleicht etwas anderes unter dem Artikel verstehen, aber es heißt trotzdem Artikel bei uns, weil es ist unser Artikel und er hat folgende Eigenschaften, und fertig ist die Laube sozusagen. Okay, ja.

Stefan Negele: Genau, aber das ist eben…

Sven Johann: Sorry, vielleicht nur eine Frage: Wie, also ihr sammelt, wo wird das beschrieben? Also diese Ubiquitous Language, sag mal bei Software-Architektur traditionell, sag mal INNOQ Style Arc 42, gibt es ein Glossar, ja? Da sammle ich diese Begriffe. Wo würde ich die bei so einem Datenprodukt sammeln?

Stefan Negele: Wenn ich das jetzt in einem Canvas habe, da habe ich ein Feld dafür, um in dieser Session oder in diesem Dokument das zu besprechen. Ansonsten kommt das auch wieder auf die Organisation an, was habe ich denn gegeben? Ich würde da jetzt auch nicht stark trennen zwischen Datenwelt und sonstiger Software, das soll ja irgendwie gemeinsam gedacht werden. Das heißt, ich würde dann auch vielleicht ein Glossar in einem Wiki haben, vielleicht habe ich eben, wenn ich da ein bisschen weiter bin…

Sven Johann: Mhm.

Stefan Negele: Einen semantischen Layer, wo ich so etwas abgebildet habe. Ich würde das aber eben nicht trennen, weil die Grundlage ja dieselbe ist.

Sven Johann: Ja, ja. Mhm, stimmt. Also vermutlich ist der Begriff, sag mal Artikel, wenn wir schon eine Software-Architektur haben, dann ist der Begriff Artikel schon in unserem Glossar beschrieben, ja? Okay, ja.

Stefan Negele: Genau, aber vielleicht habe ich da auch etwas Ausgefeilteres, oder? Also vielleicht sage ich, ich habe beispielsweise eine Datenmodellierung, die ein bisschen komplexer ist. Ich habe eine Ontologie irgendwo beschrieben, die auch wirklich Abhängigkeiten und so weiter voneinander beschreibt, dann kann ich auch darauf verweisen.

Sven Johann: Mhm.

Stefan Negele: Kommt stark auf das Umfeld an.

Sven Johann: Okay. Ich habe mir hier, ja?

Stefan Negele: Genau, sag du lieber. Ich hätte jetzt einfach mit dem Canvas weitergemacht.

Sven Johann: Genau, ich wollte auch mit dem Canvas weitermachen. Ich habe mir notiert – ich weiß nicht, ob das in der Reihenfolge richtig ist – die Datenquellen.

Stefan Negele: Das ist richtig. Ja, genau. Wir springen dann jetzt auf die andere Seite des Canvas. Üblicherweise steht das links, und wir überlegen uns: Wir haben die Anforderungen besprochen, wir wissen, was unsere Konsumenten brauchen. Jetzt müssen wir aber gucken, woher die Daten eigentlich kommen. Vielleicht haben wir selbst alle Daten, die dafür notwendig sind, um das, was die Konsumenten brauchen, aufzubauen. Brauche ich vielleicht ein externes oder ein anderes Datenprodukt, wo ich noch Daten beziehen muss? Wir definieren dann Input Ports und sagen: Ich habe einen Input Port, das ist vielleicht mein Microservice oder mehrere meiner Microservices, und da vielleicht eine API oder eine Datenbank, aus denen ich mir die Daten hole. Vielleicht aber auch ein externes System oder ein externes Datenprodukt, aus dem ich mir die Daten ziehe. Man könnte zwar sagen, der Konsument kann sich die Daten aus dem anderen Datenprodukt selbst holen, aber wir haben ja gesagt, wir wollen ein Produkt haben, das gut benutzbar und verwendbar sein soll. Das heißt, idealerweise mache ich die Joins schon für meinen Konsumenten oder für meine Konsumenten.

Sven Johann: Ja.

Stefan Negele: Weil ich ja vielleicht auch am besten weiß, wie ich den fremden Datensatz am besten joine und wie das damit zusammenhängt. So muss sich mein Konsument nicht noch mit einer anderen Domäne auseinandersetzen.

Sven Johann: Ja, genau. Das kann ich potenziell auch. Wenn ich fremde Datenquellen habe, ist eine Abhängigkeit zu einem Nachbarsystem immer etwas anderes, als wenn ich selbst die Kontrolle habe. Da hat man natürlich noch ein paar Risiken.

Stefan Negele: Klar, ich kann natürlich auch nur entsprechende Garantien geben. Wenn ich sage, ich habe ein externes System angebunden, dann können meine Garantien bezüglich Datenqualität und Service Level Objectives nicht besser sein als die des Fremdsystems.

Sven Johann: Das ist genau.

Stefan Negele: Da habe ich einen einschränkenden Faktor.

Sven Johann: Sagt man so, ne? Manchmal können wir ja trotzdem besser sein. Ich nenne ja immer gerne dieses Beispiel, dass Netflix zufälligerweise zuverlässiger ist als AWS, obwohl Netflix auf AWS läuft, weil sie Multi-Region und so weiter haben. Ich könnte mir vorstellen, wenn mein Source System unzuverlässig ist, dass ich vielleicht trotzdem eigene Repair Actions oder Ähnliches habe. Das könnte wahrscheinlich auch sein.

Stefan Negele: Ja, oder wenn ich sage, mein Produkt ist ein täglicher Export: Wenn mein Source System dann nicht eine Verfügbarkeit von X Nachkommastellen hat, schaffe ich es trotzdem, einmal am Tag an die Daten zu kommen und den Export zu ziehen.

Sven Johann: Genau.

Stefan Negele: Genau.

Sven Johann: Gut, jetzt haben wir sozusagen die Mitte eingekreist, ne? Wir haben Konsumenten, Use Cases, Data Contracts (also Schnittstellen), Source Systeme. Das ist alles links und rechts, und in der Mitte ist die Data Product Architecture. Was ist denn die Data Product Architecture?

Stefan Negele: Ja, genau. Das ist der Punkt, den finde ich, der passt nicht immer, vor allem für ein Workshop-Format mit Konsumenten. Das ist quasi meine große Kritik an diesem Canvas. Wenn wir diesen Canvas nutzen, um das Datenprodukt zu dokumentieren, dann ist das natürlich wichtig. Ich komme gleich dazu, was da eigentlich drin steht. Im Prinzip sind das die Interna meines Datenprodukts, und das interessiert den Konsumenten wahrscheinlich nur auf einer sehr oberflächlichen Weise.

Sven Johann: Sorry, dass ich kurz reingrätsche: Wenn ich jetzt Kunde bin, wieso sollte mich überhaupt etwas anderes interessieren außer Schnittstellen, meine Use Cases und Ubiquitous Language? Selbst woher die Daten kommen, ist mir ja eigentlich wurscht, oder? Als Konsument.

Stefan Negele: Nee, ich will schon oft wissen, wo die Daten herkommen, aus welchen Quellen ich sie bezogen habe. Beispielsweise, wenn ich irgendwo Vergleiche anstelle und so weiter, dann interessiert mich ja schon die Lineage meiner Daten. Ich kenne das wirklich bis auf Feldebene, dass ich wissen will, woher die Daten kommen und durch welche Transformationsschritte sie gelaufen sind. Solche Tools für Datentransformation, klassische Data Engineering Tools, bieten das oft auch an, dass sie einem das quasi automatisiert ausspucken. Das kommt nicht von ungefähr. Ich will schon gerne wissen, aus welchem Quellsystem meine Daten eigentlich kommen.

Sven Johann: Ja, wenn du sagst Lineage: Lineage war bei zumindest einem System von einem Kunden wirklich sehr schwierig nachzuvollziehen, weil ich als System Daten von einem anderen System bekomme, aber dieses andere System bekommt wiederum Daten von einem anderen System – also den Fall, den wir gerade beschreiben, der sich beliebig fortsetzen kann. Wenn ich jetzt sage, ich beziehe ein anderes Datenprodukt, dann würde auch in dem Quelldatenprodukt drinstehen: Die Daten kommen entweder aus meinem System, oder sie kommen auch noch von einem anderen Datenprodukt.

Stefan Negele: Genau, die Frage ist, auf welchem Level muss ich das wissen? Interessiert mich grob der Datenfluss, dann sage ich: Hier war mal ein externes System, und die Daten sind durchgelaufen. Welches Feld in dieser Tabelle war, ist mir egal. Das kriege ich auch über ein Datenprodukt, wenn ich eine Datenproduktarchitektur habe, kriege ich das relativ einfach raus, weil ich weiß, wer wen abonniert, wahrscheinlich. Es könnte aber wirklich noch tiefer ins Detail gehen. Man könnte beispielsweise im Data Contract Formate wie Open Lineage nutzen, wo man auf Feldebene sagen kann: Diese Daten wurden übrigens ursprünglich aus diesem anderen Datenprodukt, aus diesem Feld gezogen oder aus diesen Feldern, und das hat sie dann so gemerged, oder hier ist diese Transformation entstanden.

Sven Johann: Okay, ja, sehr gut. Genau, wir machen einfach mal weiter mit Data Product Architecture, weil ich gerade bei Data Lineage bin. Da müssen wir vielleicht noch mal eine eigene Folge draus machen.

Stefan Negele: Vielleicht reden wir noch mal genauer drüber, ja, wir schweifen ab.

Sven Johann: Genau. Okay, Daten, Kritikpunkt: Wen interessieren die Innereien? Da waren wir stehen geblieben.

Stefan Negele: Genau, wie gesagt, das ist dann für meine spätere Doku. Wenn ich sage, ich will quasi diesen Canvas nutzen, um zu dokumentieren, ist das ja auch völlig valide, zu sagen: Hey, ich habe eine grundsätzliche Dokumentation grafisch aufgemacht, relativ schnell lesbar, in einem Workshop erstellt. Für Konsumenten ist das wahrscheinlich nicht immer wichtig, aber ich würde eben in diesen Bereich reinschreiben: Wo wurden jetzt Daten beispielsweise zusammengeformt? Wie sind Transformationsschritte? Welche Technologien habe ich vielleicht eingesetzt? Also welche Storage Layer habe ich genutzt? Das wird natürlich oft von der Plattform vorgegeben. Ist dann die Frage, ob man es hier noch mal dokumentieren muss, wenn das sowieso in der Organisation übergreifend überall gleich ist. Wenn aber nicht, oder wenn ich eine Sonderlocke habe, dann will ich das hier vielleicht reinschreiben. Ich will vielleicht auch reinschreiben: Hey, hier habe ich die Daten noch auf einer relationalen Datenbank, dann habe ich sie aber überführt in etwas spaltenbasiertes, was für analytische Zwecke besser geeignet ist, oder ich habe hier einfach nur unstrukturierte Files abgelegt. So etwas würde ich da eben versuchen zu schreiben. Vielleicht schreibe ich sogar einfache SQL Queries rein, wenn das möglich ist, um quasi so einen Pseudocode zu haben. Aber um so grob zu verstehen, wie aus dem, was ich ursprünglich hatte, aus meinen Quellen, das wurde, was dann am Ende draus geworden ist.

Sven Johann: Ja, kann vermutlich auch ziemlich einfach sein, nach dem Motto: Ich reiche die Quelle eins zu eins weiter.

Stefan Negele: Ja, dann ist die Frage, warum ich das tue. Warum reiche ich eine Quelle eins zu eins weiter? Wahrscheinlich habe ich schon noch einen Transformationsschritt, zumindest auf einen anderen Daten Layer, weil ich dem Konsumenten ja wahrscheinlich keinen Zugriff auf meine Datenbank geben will. Dann würde ich die Daten vielleicht nicht transformieren, aber zumindest in ein anderes Format rübergeben.

Sven Johann: Ja, genau. Ich denke jetzt natürlich wieder nur an meinen speziellen Fall, wo ich sage: Ich biete die Daten, die ich habe, einfach als Stream an. Klar, du hast halt keinen Zugriff auf meine Datenbank, aber ich habe halt einfach…

Stefan Negele: Aber klar, genau. Wenn du jetzt sagst, mein Output Port ist ein Stream und ich nutze sowieso Kafka, dann habe ich ja schon eine Plattform, die irgendwie skaliert. Dann muss ich es vielleicht nicht noch mal extra gruppieren, dann kann ich vielleicht einfach auch Zugriff auf diesen Stream geben, wenn das jetzt mein Output Port wäre, ja, klar.

Sven Johann: Ja. Okay. Wenn ich noch mal auf die Canvas gucke, gab es da noch diesen Punkt Classification. Der hat mir irgendwie nichts gesagt. Was bedeutet das eigentlich?

Stefan Negele: Ja, das ist auch eine Sache, die eigentlich aus dem Data Mesh kommt. Ich will meinem Konsumenten auf irgendeine Art und Weise sagen, wofür dieses Datenprodukt gedacht ist oder welche Klasse es hat. Ich beschreibe es am besten anhand der Klassifikation, die man üblicherweise nutzt. Wir haben Source-Aligned Datenprodukte, das sind üblicherweise die Datenprodukte, die du jetzt auch gerade beschrieben hast. Ich bin sehr nah an der Quelle dran. Ich will die Daten irgendwie weitergeben an ein anderes System. Ich will wahrscheinlich noch gar keine großen Transformationsschritte machen, ich will sie vielleicht ein bisschen bereinigen, ich will sie erklären, beschreiben, was drin ist und wie die Qualitäten davon sind. Aber im Prinzip sind das eigentlich nur die Daten aus den Quellsystemen, eben sehr nah am operativen dran. Dann haben wir auf der anderen Seite Consumer-Aligned Data Products, die sind dann eben schon sehr aufgearbeitet, haben wirklich einen speziellen Use Case, beispielsweise, ich gehe mal wieder auf mein Beispiel, mein Dashboard fürs Management oder sowas, oder mein Feature Store für meine Machine Learning Technologien. Und dazwischen gibt es dann noch die Aggregates, nennt man das, nicht zu verwechseln mit DDD Aggregates.

Sven Johann: Okay, okay, ja.

Stefan Negele: Oder Aggregated. Man versucht die auch so ein bisschen zu vermeiden, weil das ist immer die Schwierigkeit, wer besitzt so etwas? Und Ownership ist bei Datenprodukten natürlich ein sehr, sehr wichtiges Thema. Wer besitzt so ein Datenprodukt, das eigentlich nur dafür da ist, um quasi irgendwelche Quellen miteinander zu kombinieren, damit ein Consumer-Aligned Datenprodukt irgendwie daraus etwas Hübsches machen kann? Also idealerweise versuche ich diese Aggregated Datenprodukte irgendwie zu vermeiden. Und das sind aber auch meine Klassifizierungen.

Sven Johann: Okay, okay.

Stefan Negele: Das kommt wahrscheinlich so ein bisschen aus einem typischen Data Engineering Pattern. Es gibt halt diese Medallion Architecture, da habe ich Bronze, Silber und Gold als Level. Bronze Level ist quasi meine Rohdaten, Silber sind die etwas aufbereiteten Daten, die vielleicht schon gereinigten, und Gold ist wirklich das, womit man dann auch wirklich arbeiten kann.

Sven Johann: Ja, ja, okay, okay. Gut, ja, bevor wir zum Ende kommen, jetzt habe ich zum Beispiel so ein Datenprodukt. Ich denke wieder in meiner Kundensituation. Und es gibt genügend, ich habe vielleicht so ein Datenprodukt entworfen, ich habe auch mit meinem Consumer gesprochen oder mit meinen Konsumenten, es gibt ja mehrere. Aber es gibt vor allen Dingen in größeren Organisationen, da tauchen natürlich immer neue Services auf, neue Anwendungen, die Daten brauchen. Und da ist zum Beispiel so, hatte ich neulich noch mitbekommen, ja, ich brauche diese Daten. Ja, wie kommt man eigentlich, wie finde ich überhaupt Daten? Und bei denen war das halt, idealerweise kennst du jemanden, der weiß, wo man nachgucken soll. Ansonsten haben die halt so eine zentrale, ich sage das jetzt falsch, aber sagen wir, im Confluence steht, ist kein Confluence, ist schon, hätte fast gesagt, professionelles Tool, aber es gibt einen zentralen Ort, wo man nachschauen kann, welche Daten es gibt und wer die Owner sind. Jetzt weiß ich nicht so genau, ob das schon ein Data Marketplace ist, deswegen frage ich dich mal, was ist denn eigentlich ein Data Marketplace?

Stefan Negele: Ja, gute Frage. Also vielleicht gucken wir uns mal an, was ist ein Marktplatz? Marktplatz, ohne jetzt Data, ist irgendwie so eine Handelsplattform, also eBay oder Amazon. Nutzt jemand noch eBay, ich weiß es nicht. Genau, und was zeichnet ihn aus? Er hat gemeinsame Spielregeln, und die Ziele sind ja, dass man dorthin gehen kann und man findet irgendwie das, was man sucht, dadurch, dass irgendwie alles an einem Ort ist, sinken vielleicht auch die Kosten für das, was ich da kaufen will. Und bei einem Data Marketplace übertragen wir das eigentlich und setzen noch ein bisschen was obendrauf. Wir sind natürlich kein Amazon für Daten. Und das, was du jetzt beschrieben hast, klang für mich eher, das weiß ich jetzt nicht, ich kenne deinen Kunden nicht, aber für mich klang das jetzt vielleicht eher nach einem klassischen Datenkatalog. Dort werden quasi alle Assets oder alle Daten-Assets beschrieben, die in einem Unternehmen sind, und das sind aber dann auch wirklich nur Assets. Dass Ownership dranhängt, ist schon mal ein ganz gutes Zeichen, dann weiß ich immerhin, mit wem ich reden kann, und ich habe nicht nur irgendwie eine Tabelle im Raum. Bei diesen klassischen Datenkatalogen ist oft das Problem, dass viel nicht beschrieben wird. Also ich habe im Vorfeld über Semantik gesprochen und so weiter, so etwas wird da nicht beschrieben, weil oft dann auch einfach nur irgendwelche Crawler über die Plattform laufen und irgendwie gucken, wo haben wir welche Datenbanken und das dann einfach unstrukturiert mehr oder weniger da reinwerfen. Und dann habe ich halt einen riesigen Bloat an, hey, hier sind irgendwie 1000 Tabellen. Ich weiß aber überhaupt nicht, was die bedeuten, und ich weiß nicht, ob diese Spalte jetzt überhaupt noch benutzt wird, weil das sind ja dann operative Systeme. Und genau, also da wäre es dann zumindest schöner, wenn ich sage, okay, ich habe dann beispielsweise so einen Katalog wirklich nur für Daten, die ich auch wirklich verwenden soll, und dann kommen wir auch schon mehr in diese Marktplatzcharakteristik, weil da will ich ja eben, auf einem Marktplatz werden üblicherweise Produkte verkauft, da sind wir schon wieder bei dem Wort. Und die sollen dort eben auch angepriesen werden, die sollen dort nicht einfach nur auffindbar sein, sondern die sollen auch angepriesen werden. Ich will ja, dass das mir jemand abnimmt. Genau.

Sven Johann: Ja, ich meine, das ist jetzt in meinem Fall definitiv in vielerlei Dimension nicht so der Fall. Irgendwann schon, ja, soll es so sein, aber jetzt ist es eher so, es gibt diesen zentralen Ort, wo im Prinzip, ich sag mal so, da werden große Workstreams definiert, unter diesen Workstreams gibt es Domänen, in den Domänen gibt es jeweils Anwendungen, also ist im Prinzip eine Architektur, du kriegst so einen Architekturüberblick. Also von da geht es dann zur arc42-Doku zum Beispiel, aber praktisch in diesem Überblicks-Tool, also dieses IT-Landschaftsüberblicks-Tool, da, so würde ich es mal nennen, da ist auch beschrieben, welche Daten es gibt, aber da ist natürlich relativ vermischt. Da sind irgendwie ein Haufen, ich weiß nicht, ob vermischt so schlecht ist, aber es hat sich jetzt erstmal so angehört. Besser ist natürlich, ich gehe, also ist so ein allgemeiner Marktplatz, dann wird alles verkauft, von Elektroartikel über Obst und keine Ahnung. Aber idealerweise hat man unterschiedliche Marktplätze, wo ich unterschiedliche Dinge haben will. Wenn ich jetzt zu meinem Data Marketplace gehe, dann weiß ich, da finde ich, da kann ich meinen Korb mit Daten füllen, wenn ich mich nur für Daten interessiere.

Stefan Negele: Genau. Ja, genau, und der Marketplace soll ja auch Eigenschaften aufweisen zu den Dingen, die bei Daten eben für mich relevant sind. Also ich will beispielsweise, vielleicht kann ich in meinem Marketplace auch eine globale Daten-Governance-Regel beschreiben, kann die dann aus den Produkten heraus referenzieren, wenn sie dort angewendet werden. Vielleicht habe ich auch so etwas wie einen semantischen Layer in diesem Katalog oder kann den anderen semantischen Layer sauber darin einbinden. Also diese ganzen Sachen, die eben für die Charakteristik des Datenprodukts wichtig sind, sollten sich halt eben im Data Marketplace sinnvoll auch widerspiegeln, weil der ist ja dann auch wieder ein Produkt und das soll ja wiederum auch so gut benutzbar sein und den Usern auch möglichst viel Informationen über die Daten geben, die sie eben an der Stelle brauchen. Und bei einem Microservice will ich wahrscheinlich eben andere Informationen haben als bei einem Datenprodukt.

Sven Johann: Ja, genau, genau, ja. Ja, jetzt vielleicht so abschließende Frage, wie finde ich mich da zurecht? Jetzt haben wir hier unsere Kollegen Jochen und Simon, also Jochen Christ, Simon Hara, die haben ja ein eigenes Produkt rausgebracht, hieß früher mal Data Base Manager. Ich weiß gar nicht mehr genau, wie das jetzt heißt.

Stefan Negele: Entropi Data.

Sven Johann: Heißt die Firma Entropi, Produkt heißt auch Entropi Data.

Stefan Negele: Ja, soweit ich weiß, ja.

Sven Johann: Ja, okay. Und okay, das kenne ich jetzt natürlich, also wie das aussieht. Die haben jetzt auch so einen, ich sag mal so, so einen MCP Server angeboten, aber der MCP Server, der funktioniert, ich frage mich, funktioniert der so, wie ich mir das vorstelle, weil ich gehe zum Marktplatz und sage, ich beschreibe in natürlicher Sprache, was ich brauche.

Stefan Negele: Mhm.

Sven Johann: Und dann spuckt er mir raus, diese Datenprodukte kannst du nutzen, oder wie muss ich mir das vorstellen?

Stefan Negele: Das Coole, was so ein Marktplatz ausmacht, ich habe ja die ganzen Metainformationen zu meinen Daten da drin stehen. Ich habe ganz viel Semantik, also ich habe genau das, womit ein LLM arbeiten kann, deswegen bietet sich da so ein MCP Server auch an. Und also was die eben noch obendrauf legen, ist dann sozusagen, dass dieser MCP Server, wenn ich das richtig verstanden habe, eben auch dann die Datenquellen ansprechen kann, der muss natürlich die Rechte haben, aber in jedem Datenprodukt steht ja auch drin, wie connecte ich mich denn? Wo liegt denn jetzt dieser Datensatz? Und dann kann ich nicht nur die Datenprodukte finden, sondern kann sogar auch Antworten auf einfache analytische Fragen bekommen.

Sven Johann: Ja, wenn die Kreditkarte hinterlegt ist bei teuren Abfragen, ja.

Stefan Negele: Natürlich. Was die auch noch drin haben, was ganz cool ist, ich hatte ja gesagt, dass Governance für Daten auch ein super wichtiges Thema ist, und wenn wir schon beim Thema AI sind, die haben eben auch ein Feature, womit man auch Governance-Regeln mit natürlicher Sprache beschreiben kann, und das wird dann eben quasi auch überprüft, ob die eingehalten werden, automatisiert. Zumindest hatten sie das mal, das hatte ich mal in der Demo gesehen. Das ist schon sehr cool und das zeigt aber auch wieder so eine Charakteristik auf, die eben so ein Data Marketplace haben soll. Also Governance sollte eben eingebaut sein und sollte halt irgendwie auch der Default sein, dass die gemacht wird von so einem Datenprodukt.

Sven Johann: Ich hätte jetzt gedacht, dass mir, wenn ich Teil von so einem Data Marketplace mit meinem Data Product sein will, schon Governance aufgezwungen wird. Wenn wir noch mal den klassischen Marktplatz sehen, der stellt uns gewisse Dinge zur Verfügung, wie Strom und Wasser und Öffnungszeiten und so weiter. Aber der sagt auch, die Governance ist, du musst dann und dann da sein und du musst dann und dann abfahren, musst den Platz wieder räumen, da ist dein Platz. Und ich hätte jetzt bei dem Marketplace gedacht, zumindest jetzt bei Entropi Data, dass der Data Contract eine Governance Regel ist: Jeder muss einen Data Contract haben.

Stefan Negele: Der Data Contract ist auch ein Governance Tool.

Sven Johann: Gibt es noch andere Governance Regeln?

Stefan Negele:

Sven Johann: Typische, was man vielleicht verallgemeinern kann.

00:50:19 Stefan Negele: Muss ich kurz nachdenken. Ich kann natürlich auch sagen, ich habe eine Governance Regel, dass ich meine Daten als Datenprodukte definiere. Ich kann sagen, wenn Zugriff auf Daten von anderen Teams stattfinden soll, dann muss das über diesen Marketplace passieren und darf nicht hinten herum passieren.

Sven Johann: Ok

Stefan Negele: Es gibt noch einiges. Globale Daten-Governance-Regeln sollte man aber so gering wie möglich halten, weil sie alles nur sperrig machen. Klar, wenn ich gesetzliche Regulatorien einzuhalten habe, wenn ich sagen muss, ich muss PII-Daten, also personenbezogene Daten, kennzeichnen, dann muss das da auch drin stehen. Das wäre dann auch ein Beispiel für etwas Globales. Ich werde aber versuchen, in einer datenproduktorientierten Architektur meine Governance Regeln möglichst klein im Data Contract zu halten und das, was ich allen aufzwänge, möglichst schlank zu halten.

Sven Johann: Kann ich mir gut vorstellen, bei Software-Architektur ist es auch so, dass Governance to govern in zweierlei Hinsicht übersetzen kann: zum einen Regeln aufzwingen, die andere Seite ist Anleiten, Rahmenbedingungen schaffen. Man will ja immer in dieser anderen Seite sein, damit ich möglichst viel Freiheit habe, aber trotzdem nicht alle in unterschiedliche Richtungen laufen, sondern dass alle auf ein gemeinsames Ziel einzahlen. Gibt es noch etwas Wichtiges, was ich nicht gefragt habe?

Stefan Negele: Ich glaube, wir haben das weitestgehend durchgesprochen. Wir haben bestimmt Dinge vergessen, meistens vergisst man das Allerwichtigste und wird danach darauf hingewiesen. Ich glaube, die wichtigsten Dinge haben wir besprochen.

Sven Johann: Vielen Dank an alle Zuhörer, die es bis hierhin geschafft haben, und vielen Dank, Stefan.

Stefan Negele: Danke auch und danke an die Hörer.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Massgeblich ist immer das im Mitschnitt gesprochene Wort.

Was ist ein Datenprodukt?

Sven Johann und Stefan Negele diskutieren die Definition eines Datenprodukts, das sich vom reinen «Data as a Product»-Konzept aus der Data Mesh Theorie unterscheidet. Stefan Negele betont, dass ein Datenprodukt nicht nur ein Datensatz ist, sondern ein Produkt im eigentlichen Sinne, das mit einem Produktgedanken entwickelt wird. Ähnlich wie bei Microservices oder APIs geht es darum, Kundenbedürfnisse zu verstehen, das Produkt attraktiv zu gestalten und es den Konsumenten anzubieten. Technisch gesehen umfasst ein Datenprodukt nicht nur Tabellen oder Dateien, sondern ein Sammelsurium aus Data Pipelines, Transformationen und weiteren technischen Komponenten, die zur Aufbereitung eines Datensatzes gehören. Diese werden oft in einem YAML-Format beschrieben, um Automatisierung zu ermöglichen. Als Beispiel nennt Stefan Negele Daten für ein KPI-Dashboard, die von einem Microservice-Team bereitgestellt werden, um eine sinnvolle Auswertung zu ermöglichen und ein klares Verständnis zwischen Produzenten und Konsumenten zu schaffen.

«Der Begriff, ich würde sagen, der ist so ein bisschen aus dem aus der Data Mesh Theorie, also es gab ja das Buch von Zhamak Dehghani zu Data Mesh und da ist so dieser wurde so dieser Begriff Data as a Product geprägt und daraus ist das so ein bisschen entstanden.»

Vom Data Lake zum Datenprodukt: Die Data Products Canvas

Stefan Negele grenzt das Konzept des Datenprodukts klar vom traditionellen Data Lake ab. Während im Data Lake alle anfallenden Daten gesammelt werden, in der Hoffnung, dass sich jemand das Benötigte herauskratzen kann, wird ein Datenprodukt aktiv auf einem Marktplatz angeboten, inklusive Garantien und Erklärungen zu dessen Bedeutung. Um Datenprodukte strukturiert zu entwickeln, empfehlen Sven Johann und Stefan Negele die Data Products Canvas. Dieses Tool eignet sich besonders gut für Workshops mit Datenkonsumenten, um ein gemeinsames Verständnis zu schaffen. Die Canvas wird von rechts nach links ausgefüllt, beginnend mit den Consumer Needs und Use Cases. Konsumenten können dabei andere Teams, Marketingabteilungen, Data Scientists für Machine Learning Features oder auch operative Systeme für Stammdaten sein. Stefan Negele betont, dass der Startpunkt immer der Use Case ist, da ein Produkt ohne Kunden keinen Sinn ergibt.

«Man hatte oft diesen Gedanken, ich blas die Daten raus, man hat ja früher irgendwie diesen diesen Big Data Data Lake Gedanken und dann hat man gesagt, okay, wir haben Analytics Anforderung und wir werfen quasi alle Daten, die anfallen in den Data Lake und dann kann sich da schon jemand das rauskratzen, was er braucht und das ist, glaube ich, eben genau der Unterschied zum Data Product.»

Data Contracts und Ubiquitous Language

Im Kontext von Datenprodukten spielen Data Contracts eine zentrale Rolle. Stefan Negele beschreibt sie als Schnittstellendefinitionen für datenintensive Anwendungen, vergleichbar mit einer OpenAPI Spec, jedoch mit einem starken Fokus auf Datenqualität, Serviceeigenschaften (wie SLAs) und Semantik. Auf Feldebene wird definiert, wie die Qualität eines Feldes ist (z.B. ob es immer gesetzt ist oder ein bestimmtes Format einhält) und was es bedeutet. Dies ist besonders wichtig, um Missverständnisse zu vermeiden und Konsumenten klare Garantien zu geben. Auch technische Verbindungsdaten und sogar ein Preis für die Bereitstellung der Daten können im Contract enthalten sein. Ein weiterer wichtiger Aspekt ist die Ubiquitous Language, ein Konzept aus dem Domain Driven Design. Sie dient dazu, eine gemeinsame Sprache und ein einheitliches Verständnis für alle Begriffe zu schaffen, die im Zusammenhang mit dem Datenprodukt stehen. Dies kann durch ein Glossar in einem Wiki oder einen semantischen Layer unterstützt werden, wobei Stefan Negele betont, dass eine Trennung zwischen Daten- und Softwarewelt hier nicht sinnvoll ist.

«Der Unterschied zu technischeren API Specs ist, dass hier eben ganz viel Wert auf die Qualitätseigenschaften der Daten gelegt wird, auf die Service-Eigenschaften, also es gibt eigentlich klassischerweise in Data Contracts auch sowas wie SLAs, die definiert werden.»

Datenquellen, Architektur und Klassifikation

Nach der Definition der Konsumentenbedürfnisse und Data Contracts geht es um die Datenquellen. Stefan Negele erklärt, dass ein Datenproduktteam entscheidet, woher die benötigten Daten stammen – sei es aus eigenen Microservices, externen Systemen oder anderen Datenprodukten. Das Team ist idealerweise dafür verantwortlich, Daten zu joinen und aufzubereiten, um den Konsumenten die Arbeit zu erleichtern und ihnen die Auseinandersetzung mit fremden Domänen zu ersparen. Die Data Product Architecture beschreibt die internen Abläufe des Datenprodukts, wie Transformationen, eingesetzte Technologien und Speicherschichten. Obwohl diese Details für Konsumenten oft nur oberflächlich relevant sind, sind sie für die Dokumentation und das Verständnis der Datenherkunft (Lineage) wichtig. Stefan Negele erläutert zudem die Klassifikation von Datenprodukten:

• Source Aligned Data Products: Nah an der Quelle, minimale Transformation, Fokus auf Bereinigung und Erklärung der Rohdaten.
• Consumer Aligned Data Products: Stark aufbereitet, für spezifische Use Cases wie Dashboards oder Machine Learning Feature Stores.
• Aggregated Data Products: Zwischenschicht, die verschiedene Quellen kombiniert. Diese werden idealerweise vermieden, um Ownership-Probleme zu umgehen.

«Idealweise mache ich die Joins schon für meinen Konsumenten oder für meine Konsumenten. Weil ich ja vielleicht auch am besten weiß, wie ich das am besten joine, wie das eigentlich damit zusammenhängt.»

Der Data Marketplace und Data Governance

Ein Data Marketplace ist eine Handelsplattform für Datenprodukte, die über einen einfachen Datenkatalog hinausgeht. Er zeichnet sich durch gemeinsame Spielregeln aus und ermöglicht es, Datenprodukte nicht nur zu finden, sondern auch aktiv anzubieten und zu bewerben. Stefan Negele betont, dass ein Marketplace die Charakteristiken von Datenprodukten widerspiegeln sollte, einschließlich Metainformationen und Semantik. Er erwähnt den MCP Server von Entropy Data als Beispiel für ein Tool, das durch die Nutzung von Metadaten und Semantik in Kombination mit LLMs nicht nur die Auffindbarkeit von Datenprodukten verbessert, sondern auch einfache analytische Fragen beantworten kann. Data Governance ist ein integraler Bestandteil eines Data Marketplace. Data Contracts dienen hierbei als Governance-Tool. Globale Governance-Regeln sollten so gering wie möglich gehalten werden, um Flexibilität zu bewahren, aber gesetzliche Regulatorien (z.B. Kennzeichnung von PII-Daten) müssen eingehalten werden. Stefan Negele plädiert dafür, Governance-Regeln möglichst schlank im Data Contract zu halten und nicht zu versuchen, alles global aufzuzwingen.

«Das coole, was eben so ein so ein Marktplatz ja ausmacht, ich habe ja die ganzen Metainformationen zu meinen Daten eben da drin stehen. Ich habe ganz viel Semantik, also ich habe genau das, womit ähm ein LLM irgendwie arbeiten kann, deswegen bietet sich da so ein MCP Server auch an.»