Datenprodukte

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

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

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

Sven Johann: Ähm ja, der Stefan ist Senior Consultant bei der INNOQ seit zweieinhalb Jahren, knapp drei Jahren, ne? Und äh beschäftigt sich hauptsächlich mit dem Thema Data Governance. Ähm 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’s noch andere Dinge, ähm die wichtig wären über dich zu wissen?

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

Sven Johann: Ja, also vielleicht kommen wir da später auch noch drauf. Ich finde es ja, ich bin ja froh, dass bisschen mehr, dass bisschen mehr Liebe in Daten äh kommt, äh vor allen Dingen im Sinne so Data Driven Decision Making ist vielleicht irgendwie ein bescheuerter Begriff, aber ähm bin ich eigentlich ziemlich großer Fan von. Okay, ähm würde sagen, wir wir legen einfach los und zwar weil es eigentlich ein Data Product.

Stefan Negele: Ja, das ist eine sehr gute Frage. Ähm es gibt eigentlich keine offizielle Definition davon. Der Begriff, ich würde sagen, der ist so ein bisschen aus dem ähm 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 ähm geprägt und daraus ist das so ein bisschen entstanden. Also wir müssen schon unterscheiden, Data as a Product und Datenprodukt ist nicht dasselbe.

Sven Johann: Okay.

Stefan Negele: Ähm aber das das Wichtige ist eben das Wort Produkt, also wir haben wir sehen die Daten eben ähm wir haben eben einen Produktgedanken, wenn wir über Daten sprechen und wir sehen die nicht als reine Assets. Ähm also ähnlich wie wir unsere Microservices designen, unsere APIs designen, irgendwie unsere UIs designen, denken wir irgendwie an Kunden, wollen das Ganze anpreisen, ähm und wollen das eben dem Kunden verkaufen, wie eben ein Produkt. Ähm technisch, also so aus Data Engineering Sicht sieht man irgendwie Data Product oft irgendwie aus so einem Sammelsurium an Data Pipelines, Transformationen, Tabellen, alles was sozusagen technisch dazu gehört, um so ein ähm Datensatz aufzubereiten, ähm aber eben nicht nur die Tabelle oder eben nicht nur die Files im S3 Bucket. Beschrieben wird das dann häufig in einem Jamel Format, ähm eben um die Automatisierung zu gewährleisten. Äh da gibt’s irgendwie Standards.

Sven Johann: Ich ich will mal kurz bevor wir bevor wir zu technisch werden, also wir können nie zu technisch werden, aber vielleicht bevor bevor wir technisch werden noch mal vielleicht vielleicht auf einer anderen Ebene, also zum einen wäre natürlich schön, ich ich muss gerade so ein bisschen lachen, ne, als du gesagt hast, wir wir sollten das als Produkt sehen, so wie unsere Services und unsere Schnittstellen und so weiter, aber ich denke, ich leide jeden Tag da drunter, dass Teams mich ignorieren, die mir eigentlich die mich eigentlich als Kunden sehen sollten, ne, weil ich Kunde egal, ne? Äh aber ich sag mal, wenn man es theoretisch richtig machen würde, ja, dann würde man einen Produktgedanken haben. Was wäre denn so ein was wäre denn so ein Beispiel vielleicht für so ein Datenprodukt?

Stefan Negele: Ähm na ja, ich könnte mir, können mir vorstellen, ähm z.B. ich ähm also ich brauche natürlich erstmal den Use Case und der Use Case ähm also von dem aus würde ich immer denken und der Use Case sagen wir mal ist irgendwie ein Dashboard für irgendwelche KPIs darzustellen, beispielsweise, irgendwas Management will irgendwas wissen.

Sven Johann: Okay, ja.

Stefan Negele: Das muss irgendwie mit Daten befeuert werden. Oft liegt das dann oder klassisch liegt das dann oft in zentralen Datenteams, die sammeln sich die Daten irgendwo im im Unternehmen zusammen. Ähm ein Datenprodukt geht das oder ein Datenproduktgedanken geht man das ein bisschen anders an und sagt, okay, ähm ich habe vielleicht ein Team, ähm das irgendwie ähm Dashboards baut, äh für das Management, ähm und das will jetzt Daten ähm von einem Team, das irgendwie eigentlich Microservices baut, ähm und dort ähm die reden dann miteinander und dort ähm werden dann eben Daten exportiert oder bereitgestellt auf einer Datenplattform, dass eben die Auswertung sinnvoll möglich sind, dass da eben auch keine Fehler passieren. Ähm und ähm dass auch irgendwie zwischen Konsumenten und Produzenten irgendwie ein klares Verständnis herrscht.

Sven Johann: Hm, okay, also du ähm ich versuche mal gerade in mein in meiner Welt so nachzudenken, weil ich ich bin ab und zu bin ich bei so einem Kunden, jetzt so vier Mal im Jahr und äh die die machen schon sehr viel mit Daten und die wollen auch viel viel mehr mit Daten machen. Also ist äh ziemlich wichtig, dass man genau weiß, wo man, also wo wo Flaschenhälse sind und wo man optimieren kann, z.B. ne und du hast Microservices angesprochen und ich stelle mir das so vor, die haben z.B. ein die haben ein Lager und in diesem Lager liegen halt ihre Produkte, ne, die sie irgendwie in ihre ähm in ihre Geschäftsstellen bringen. Und an diesen Daten sind natürlich ganz viele andere Organisationseinheiten interessiert, Daten, die sich da die da reinkommen und ändern und im Moment ist das so, sag mal so äh ich tue den wahrscheinlich unrecht, hemdsärmlich gemacht, ja? Ich meine, die denken schon ziemlich in diese Richtung, ja, aber ich meine, bei der großen Organisation dauert natürlich immer lang, bis man das alles so reinbringt, aber das ist halt für mich so dieser Gedanke, ja, ich habe ich habe Consumer von diesen Daten, die interessieren sich dafür und ich kann jetzt nicht ein also wie man früher gedacht hat, so nach dem Motto, ja, ich blas die Daten einfach raus, ne? Wenn jemand kommt und ähm

Stefan Negele: Vielleicht kann man ja.

Sven Johann: Ja.

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

Sven Johann: Mhm. Ja, ja, also ich ich ich muss sagen, ich finde das schon relativ äh also relativ, ich finde es ziemlich attraktiv, ja, weil gerade so meine Erfahrung ist auch immer, wie also wir die Teams, wo ich immer so abhänge, wir produzieren natürlich einen Haufen Daten, die wir an den Data Lake geben, um da drin rum zu fischen, ja? Aber natürlich also diese Anfragen sind halt immer sehr generisch an die Daten, weil die Leute, die natürlich da drin rum fischen, keinerlei Domänen Expertise haben.

Stefan Negele: Ja.

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

Stefan Negele: Ja, genau, also das Canvas ist vor allem auch sinnvoll, um irgendwie so ein Datenprodukt zu erarbeiten, ähm vielleicht in dem Workshop mit mit irgendwie einem Konsumenten der Daten. Ähm hatten wir gerade drüber geredet, ne? Also Konsumenten, Produzenten sollen sich gegenseitig verstehen, sollen gemeinsames Verständnis haben und ähm mit diesem Canvas kann ich eben mich dann gemeinsam beispielsweise in einem Raum einsperren und sagen, hey, wir setzen uns jetzt mal zwei Stunden hin und gucken, was wollt ihr denn eigentlich und wie kriegen wir das dann hin?

Sven Johann: Mhm.

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

Sven Johann: Ja, also in der Canvas steht so der erste Punkt ist, äh wir müssen die Consumer Needs und die Use Cases äh kennen, ja? tefan Negele: Ja.

Sven Johann: Genau, ähm so Beispiele für Konsumenten würde ich jetzt tippen, das sind einfach andere Teams, ja, oder oder oder Wer würde da noch in Frage kommen?

Stefan Negele: Genau, ich hatte ja gerade, hatte ja gerade irgendwie dieses dieses quasi jetzt mal Standardbeispiel ähm genannt. Ähm das kommt natürlich drauf an, wie mein Datenprodukt geformt ist. Ähm wenn ich jetzt diesen Use Case habe, ähm ich ich will eben Daten für ein KPI Dashboard oder was auch immer darstellen, dann sind ähm dann sind meine Konsumenten wahrscheinlich irgendwo dort auch angesiedelt in der entsprechenden Domäne. Ähm es kann natürlich auch sein, dass Konsumenten irgendwie oder das kommt oft vor, dass die aus dem Marketing kommen. Ähm wenn mein Datenprodukt könnte aber beispielsweise ja auch einen Store für irgendwelche ML Features, also Machine Learning Features oder sowas sein.

Sven Johann: Mhm.

Stefan Negele: Ähm dann sind meine Konsumenten aber wahrscheinlich auch andere Teams, wahrscheinlich auch eher ähm Data Scientists oder Data Engineers, irgendwie solche solche äh geartete Teams. Ähm genau, also kann kann mannigfaltig sein. Ich kenne es selber aus dem Alltag auch so, dass man Datenprodukte auch für ähm Stammdatensysteme haben kann. Das heißt, das können dann die Konsumenten können dann gar nicht mal unbedingt analytischen Use Case haben, sondern vielleicht haben die Konsumenten auch einen operativen Use Case.

Sven Johann: Ähm genau, also das ist so mein das ist eigentlich immer mein Gedankengang, weil ich habe so mit Analytics habe ich weniger zu tun, ja, aber operativ schon und wenn wenn du sagst, hast du eben gesagt, ja, Microservice Umfeld z.B.. Äh wenn ich wenn ich so eine Anwendungslandschaft sehe, wir also mittlerweile glücklicherweise die letzten 10 Jahre kopieren wir ja sehr viele Daten. Und das ist so daran denke ich hauptsächlich, ja, dass ich sag, damit ich funktioniere, brauche ich Daten von folgendem Stammdatensystem. Und wie komme ich eigentlich wie komme ich daran, ja? Und meistens ist ja genauso, dass ich die, die diese Daten anbieten, also die bieten die eigentlich gar nicht an, ich muss sozusagen betteln kommen, ja? Also es gibt praktisch überhaupt gar kein Product Thinking auf auf der Seite, ne? Also, dass man halt sagt, ah, ich brauche Daten, äh. Und ähm dann keine Lust, ne? Aber das ähm ja, ich habe folgende Use Cases, ich habe folgende Consumer Needs. Also für bei mir ist tatsächlich eher so im operativen Bereich, das ich wichtig finde. Ja, okay. Also der der Klassiker äh wird man sagen, ähm auch hier wieder, man startet am besten mit Use Cases und was brauchen die Leute überhaupt, passiert seltener als man denkt, ja?

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

Sven Johann: Genau, genau. Ja, ähm dann, wenn ich wenn ich von rechts weiter nach links gehe, da kommen die Data Contracts. Ähm dazu muss ich sagen, wir haben ja schon mit Simon Harra eine Folge zu Data Contracts gemacht, von daher, wer da mehr wissen will, kann man einfach da äh reinschauen, aber vielleicht könntest du noch mal so zwei bis drei Minuten kurz was dazu sagen, was sind überhaupt Data Contracts?

Stefan Negele: Ähm Data Contracts sind im Prinzip ähm Schnittstellendefinition, möchte ich mal so sagen, für eben Daten intensive Anwendung. Ähm also man kann sich das ähnlich vorstellen, wie so einen mal Open AI Spec oder sowas, das wird ganz oft auch irgendwie mit Yaml, JSON Schema und so äh definiert. Ähm der Unterschied zu so sage ich mal so technischeren ähm API Specs ist, dass hier eben ganz viel Wert eben auf ähm auf den auf die Qualitätseigenschaften der Daten gelegt wird, auf die Service Eigenschaften, also es gibt eigentlich klassischerweise in Data Contracts auch sowas wie ähm SLAs, die definiert werden. Ähm es wird wirklich auf Feldebene definiert, ähm wie ist die Qualität dieses Felds, das ist oft für den analytischen Bereich eben eben sehr sehr wichtig, ähm weil es da eben auch einfach starke Unschärfen gibt, gerade wenn ich mit großen Datenmengen ähm arbeite, wie ist denn die Qualität von der Spalte, ist denn das Feld immer gesetzt? Ähm und

Sven Johann: Ja, also also sowas wie die E-Mail ist, das E-Mail-Feld ist zu 70 % gesetzt, obwohl es optional ist, z.B.. Genau, ja, ja.

Stefan Negele: Ähm und ganz viel Wert auch auf Semantik, ne, wenn ich jetzt ein Open ähm API ähm Spec mir angucke von irgendeiner API, dann steht da meistens nicht irgendwie, was ein Feld bedeutet. Das ist in einem Data Contract sehr, sehr wichtig, weil wir wollen ja, das hat ja vorhin schon gesagt, wir wollen ja unseren äh Kunden oder unseren Konsumenten ja ähm erklären, was das bedeutet, was in dem Feld steht. Ähm und deswegen ist da viel eben sehr viel Platz eingeräumt. Ähm klar sind sowas wie technische Daten irgendwie drin, ähm wie verbinde ich mich denn irgendwie ein Server Objekt ähm klassischerweise. Ähm und ja, vielleicht steht auch sowas dran wie ein Preis, ähm weil ähm oft ist ja sowas so ein Produkt zu betreiben, kostet ja was und vielleicht will ja ein Kunde oder ein Konsument eben ähm Daten haben. Und ich sag, ja, aber die die bereitstellen, das kostet richtig viel Geld oder das kostet richtig viel Arbeitskraft.

Sven Johann: Okay, ja.

Stefan Negele: Ähm wir wir stellen da mal einen Preis dran. Also 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, da musste ich, wenn ich irgendwie aus, ich sag mal aus Datenquellen Daten abgesaugt habe, da musste ich ja selber immer Analysen machen, um zu verstehen, wie sich die Daten verhalten, ja, und dann haben wir über die Zeit gelernt und so weiter und das ist natürlich

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

Sven Johann: Mhm.

Stefan Negele: Ähm ja, und sowas kann ich dann eben sinnvoll beschreiben, da geht’s eben wieder auch darum, ne, ähm ich gebe meinem Konsumenten Garantien und auch ein gemeinsames Verständnis, was denn was ähm was steht denn da eigentlich drin in diesem Datensatz.

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

Stefan Negele: Ähm ja, was kommt als Nächstes? Also vielleicht was was da vielleicht noch kommt, ist irgendwie, man muss sich vielleicht mit dem Konsumenten auch auf dem Format einigen.

Sven Johann: Ah, okay, ja, ja, ja, ja.

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

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

Stefan Negele: Man könnte theoretisch auch parallel ähm verschiedene Formate, wenn man nicht mehrere Konsumenten hat. Ähm kostet natürlich mehr bzw. vielleicht bietet meine Plattform mir das ja auch an, wenn ich sag, ähm ich habe da irgendwie viel Automatisierung drin oder ich bin eine große Organisation, ich kann mir das leisten, eine eine große oder eine gute Platten Datenplattform zu haben, dann kann ich vielleicht irgendwo in in meiner Definition eine Checkbox setzen, exportiere als XY. Ähm aber ja.

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

Stefan Negele: Genau, ähm genau und jetzt ähm du hast meintest dann, wo wie machen wir dann weiter? Ähm vielleicht grundsätzlich, was man die ganze Zeit eigentlich irgendwie immer im Auge behalten sollte, ist irgendwie so ähm Begriffe, irgendwie gemeinsame Begriffe, eine gemeinsame Sprache zu finden. Es gibt’s im Canvas so ein Feld Ubiquitous Language, das ist eben aus dem aus dem DDD gegriffen. Ähm ich verwende es üblicherweise dafür, um eben, wenn irgendwelche Begriffe allen, die diesen Contract oder diesen dieses Data Product ähm verstehen müssen oder die jetzt in diesem Workshop sitzen, ähm ähm kennen müssen, dann schreiben wir die da mal runter. Das kann dann am am Ende irgendwie in der Dokumentation oder so weiter landen. Vielleicht referenziere ich auf auf auf eine Definitionskatalog, den ich schon habe, aber eben ähm wir wollen hier einfach Begriffe einfach mal, dass allen, die jetzt irgendwie darüber reden gerade, die darüber kommunizieren, irgendwie ein gemeinsames Verständnis haben, was bedeutet das dann eigentlich?

Sven Johann: Mhm. Das ja gerade eben. Ja, das stelle ich mir tatsächlich im im wahren Leben gar nicht so super einfach vor, also klar, wir können, ich nenne mal ein Beispiel von dem Kunden, den ich eben genannt habe. Äh die haben auch, die haben z.B. Artikel, also im Lager gibt’s Artikel, aber im im gesamten Universum heißen diese Dinger jetzt nicht immer Artikel, sondern manchmal heißen die halt anders. Ja, aber ich bin selbst wenn ich in meinem Universum bin, äh äh ich bin ich bin in meinem Kaufhaus oder oder sonst wo, ja, und das heißt nicht Artikel aus irgendeinem Grund. Artikel ist bei uns vielleicht was ganz anderes, aber trotzdem, also die die die Ubiquitous Language für das Datenprodukt ist ein Artikel und ist klar, der Artikel bedeutet folgende, der hat folgende Eigenschaften, ja, ähm 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 haben wir diese benutzen wir immer diese diese Sprache, ja, diese Begriffe.

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

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

Stefan Negele: Aus Sicht ja genau, aus Sicht dieses Datensatzes, ne? Also was was bedeutet das jetzt auf dieses Datensatz bezogen? Ähm genau, vielleicht ich will ja vielleicht auch noch ich kann ja vielleicht auch referenzieren auf irgendwie irgendwie einen ähm irgendwie einen Katalog, wo vielleicht sowas irgendwie für meine Organisation weiter genauer beschrieben ist und wie das vielleicht weiter, wenn ich irgendwie einen semantischen Layer habe, dann kann ich da vielleicht auch drauf verweisen an der Stelle.

Sven Johann: Ja, ich meine, da denke ich kommt immer wie gesagt, immer auf die Organisation an, wenn wenn sowas wenn wenn alle genau das gleiche verstehen unter Artikel, dann ist einfach, aber meistens ist ja nicht so, aber ich glaube, da ist schon mal wichtig, wenn wenn wir die Konsumenten auch im Raum haben, dass die Konsumenten vielleicht was 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, ähm 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 bei Software Architektur traditionell sag mal INNOQ Style Arc 42 gibt’s ein Glossar, ja? Da sammel ich diese Begriffe, wo würde ich die bei so einem Datenprodukt?

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

Sven Johann: Mhm.

Stefan Negele: einen semantischen Layer, wo ich irgendwie sowas abgebildet habe. Ich würde das aber eben nicht trennen, ähm weil die die Grundlage ist ja dieselbe.

Sven Johann: Ja, ja. Mhm, stimmt, stimmt. Also vermutlich äh 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 irgendwas ausgefeilteres, ne? Also vielleicht habe ich sage ich, ich habe beispielsweise irgendwie eine Datenmodellierung, die ein bisschen komplexer ist. Ähm ich habe irgendwie 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 auf das Umfeld an.

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

Stefan Negele: Genau, ach so, nee, sag du mal, weil ich hätte jetzt einfach weiter gemacht mit dem Canvas, aber.

Sven Johann: Genau, also ich ich hätte ich wollte auch weitermachen mit dem Canvas und zwar habe ich mir notiert, ähm weiß nicht, ob das in der Reihenfolge richtig ist, die Datenquellen.

Stefan Negele: Das ist richtig. Ja, ja, genau, also wir springen dann sozusagen ähm jetzt auf die andere Seite des Canvas, ähm üblicherweise steht das dann eben links und wir überlegen uns jetzt, okay, wir haben jetzt die Anforderung besprochen, wir wissen, was unsere Konsumenten brauchen. Ähm jetzt müssen wir aber mal gucken, ähm wo kommen denn die Daten eigentlich her? Ähm vielleicht haben wir selbst alle Daten, die dafür notwendig sind, um ähm um um das, was die Konsumenten brauchen, ähm auf zu ähm aufzubauen. Ähm brauche ich vielleicht ähm ein externes oder ein anderes Datenprodukt, wo ich irgendwie noch Daten beziehen muss. Ähm also sozusagen, wir wir definieren dann sozusagen Input Ports und sagen, okay, ich habe einen Input Port, das ist vielleicht mein Microservice oder vielleicht mehrere von meinen Microservices und da vielleicht eine API oder eine Datenbank, aus denen ich mir die die Daten hole, vielleicht aber auch irgendwie ein externes System oder ein externes Datenprodukt, ähm aus dem ich mir die Daten ziehe, weil ähm man könnte jetzt sagen, ja, der Konsument kann sich ja die Daten aus dem aus dem anderen Datenprodukt Produkt ja selber holen, gibt’s ja schon, aber wir haben ja gesagt, wir wollen ein Produkt haben, das heißt, das soll schön benutzbar sein, das soll schön verwendet sein. Das heißt, idealerweise mache ich die Joins schon für meinen Konsumenten oder für meine Konsumenten.

Sven Johann: Ja, ja.

Stefan Negele: Weil weil ich ja vielleicht auch am besten weiß, wie ich wie ich den fremden Datensatz darauf ähm also wie ich das am besten scheune, wie das eigentlich damit zusammenhängt. Da muss ich mein Konsument nicht noch mal mit irgendeiner anderen Domäne auseinandersetzen.

Sven Johann: Ja, genau, genau, ja. Kann ich potenziell natürlich auch, also wenn wenn ich fremde Datenquellen habe, äh würde ich sagen, normale Architektur sagen, uh, Abhängigkeit zu einem Nachbarsystem immer ist immer was anderes, wie ich bin selbst unter Kontrolle, da hat man natürlich noch mal so ein paar Risiken drauf. Okay.

Stefan Negele: Klar, ich kann natürlich auch nur entsprechende ähm Garantien dann geben, ne? Also, wenn ich sage, ich habe ein externes System angeboten angebunden, dann können meine Garantien, was ähm Datenqualität und ähm Service Level ähm Objectives betrifft, können natürlich nicht besser sein als die von dem Fremdsystem.

Sven Johann: Das ist genau.

Stefan Negele: Also da habe ich einen einschränkenden Faktor.

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

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

Sven Johann: Genau.

Stefan Negele: Genau.

Sven Johann: Gut, jetzt haben wir sozusagen äh die Mitte eingekreist, ne? Also wir haben Konsumenten, wir haben Use Cases, wir haben Data Contracts, also Schnittstellen, wir haben Source Systeme und äh das ist alles sozusagen links und rechts und in der Mitte ist die Data Product Architecture. Und was ist das denn, die Data Product Architecture?

Stefan Negele: Ja, genau, ähm das ist der Punkt, den finde ich persönlich irgendwie der passt nicht immer, vor allem für so ein Workshop Format mit Konsumenten. Ähm das ist quasi meine große Kritik an diesem Canvas. Ähm sehr viel Raum dafür, wenn wir diesen Canvas nutzen, um das Datenprodukt zu ähm dokumentieren, dann ist das natürlich wichtig. Ähm ich komme gleich dazu, was da eigentlich drin steht. Ähm für mein aber im Prinzip sind das die Interner meines Datenprodukts und das interessiert den Konsumenten wahrscheinlich zumindest in nur auf einer sehr oberflächlichen äh Weise.

Sven Johann: Also vielleicht sorry, dass ich mal kurz rein, wenn ich jetzt Kunde bin, wieso sollte mich überhaupt irgendwas anderes interessieren außer Schnittstellen? äh meine Use Cases und so Ubiquitous Language, also selbst woher die Daten kommen, ist mir ja eigentlich wurscht, oder? Also als als Konsument.

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

Sven Johann: Ja, also wenn du sagst Lineage, ich meine, also Lineage ist so ein würde ich mal sagen, bei zumindest mal einem System von einem Kunden, war wirklich sehr schwierig, das nachzuvollziehen, weil sag mal, ich als System bekomme Daten von von einem anderen System, aber dieses andere System bekommt halt Daten wiederum von einem anderen System, also den Fall, den wir gerade beschreiben, aber dann geht halt noch beliebig weiter, ja? Ähm wie wie wenn ich jetzt sage, okay, ich beziehe ein anderes Datenprodukt, dann würde ich auch in dem Datenprodukt als also von dem Quelldatenprodukt, da würde auch drin stehen, ah, übrigens, die Daten, die kommen entweder aus meinem System, aber die kommen auch noch von einem anderen Datenprodukt.

Stefan Negele: Genau, die genau die Frage ist, auf welchem Level muss ich das eben wissen? Also interessiert mich grob der Datenfluss, dann sage ich, okay, hier war mal irgendwie ein externes System und die Daten sind dann irgendwie durchgelaufen und jetzt sind die bei mir angekommen, aber welches Feld das da in dieser Tabelle war, ist mir egal, dann ist es relativ grob, das kriege ich auch über so ein Datenprodukt, ähm wenn ich so eine Datenproduktarchitektur habe, kriege ich das relativ einfach raus, weil ich kann ja weiß ja, wer wen abonniert, ähm wahrscheinlich. Ähm aber es könnte wirklich dann noch tiefer ins Detail gehen. Man könnte beispielsweise in im Data Contract sowas, da gibt’s so Formate wie beispielsweise Open Lineage oder so, wo man dann eben auf Feldebene sagen kann, diese Daten hat übrigens ursprünglich ähm aus diesem ähm aus diesem anderen Datenprodukt, aus diesem Feld gezogen oder aus diesen Feldern und das dann hat die dann so gemerged oder hier ist diese Transformation entstanden.

Sven Johann: Okay, ja, ja, sehr gut, sehr gut. Also äh genau, wir machen einfach mal weiter mit äh Data Product Architecture, weil bei mir ist, ich komme gerade so Data Lineage, 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, also Daten so Kritikpunkt, ne, wen wen interessieren die Innereien, da waren wir stehen geblieben.

Stefan Negele: Genau, also wie gesagt, das ist dann für meine spätere Doku, wenn ich sag, ich will quasi diesen Canvas nutzen, um ist ja auch ähm völlig valide, ne, zu sagen, hey, ich habe eine grundsätzliche Dokumentation irgendwie in einem in einer grafisch aufgemacht, irgendwie relativ schnell lesbar, in einem in einem Workshop erstellt. Ähm für Konsumenten ist das wahrscheinlich nicht so wichtig, ähm oder wahrscheinlich nicht immer wichtig, aber ich würde eben in diesen in diesen Bereich würde ich eben reinschreiben, okay, wo wurden jetzt Daten beispielsweise zusammen geformt, wie sind Transformationsschritte, welche Technologien habe ich vielleicht eingesetzt, also welche Storage Layer habe ich genutzt, was wird natürlich irgendwie oft vom äh 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. Ähm wenn aber nicht oder wenn ich eine Sonderlocke habe, dann will ich das hier vielleicht reinschreiben, will vielleicht auch reinschreiben, hey, hier habe ich die Daten noch irgendwie auf ähm einer relationalen Datenbank, dann habe ich sie aber über vor überführt irgendwie in in etwas in etwas spaltenbasiertes, was für analytische Zwecke besser geeignet ist, oder ich habe hier einfach nur irgendwie unstrukturierte Files abgelegt. Sowas würde ich da eben ähm dann versuchen zu schreiben, vielleicht schreibe ich sogar einfache einfache SQL Queries rein, wenn das möglich ist, um quasi so ein ähm kann ja Pseudocode sein. Ähm aber um irgendwie so grob zu verstehen, okay, so so so wurden so wurde quasi aus dem, was ich ursprünglich hatte, aus meinen Quellen wurde das, was dann am Ende dann draus geworden ist.

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

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

Sven Johann: Ja, genau, also ich ich ich denke jetzt natürlich wieder nur an meinen speziellen Fall peinlicherweise, wo ich sag, äh ich biete die Daten, die ich habe, biete ich einfach als Stream an. Und ähm klar, du hast halt keinen Zugriff auf meine Datenbank, aber ich habe halt einfach äh

Stefan Negele: Aber klar, genau, das wenn wenn du jetzt sagen, okay, mein Output Port ist irgendwie ein Stream und ich habe so nutze sowieso Kafka, dann kann ich 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 ähm auf auf diesen auf diesen Stream geben, wenn das jetzt mein Output Port wäre, ja, klar.

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

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

Sven Johann: Okay, okay, ja.

Stefan Negele: Äh oder Aggregated, ähm man versucht die auch so ein bisschen zu vermeiden, weil das ist immer die die die Schwierigkeit, wer ownt sowas und ownership ist bei Datenprodukten natürlich ein sehr sehr wichtiges Thema. Wer wer ownt so ein wer ownt so ein Datenprodukt, das eigentlich nur dafür da ist, um ähm quasi irgendwelche Quellen miteinander zu kombinieren, dass dann ein Consumer äh ein Consumer allein Datenprodukt irgendwie daraus was hübsches machen kann. Also idealerweise versuche ich diese Aggregated Datenprodukte irgendwie zu vermeiden. Ähm und das sind aber auch meine Klassifizierung. Ähm

Sven Johann: Okay, okay.

Stefan Negele: Das kommt wahrscheinlich so ein bisschen aus so einer ähm so einem typischen Data Engineering Pattern. Ähm es gibt halt so diese Medallion Architecture, da habe ich ähm äh Bronze, Silber und Gold als Level. Bronze Level ist ähm quasi sozusagen meine Rohdaten, Silber ist ähm quasi sozusagen die die etwas aufbereiteten Daten, die vielleicht schon gereinigten und Gold ist wirklich dann sozusagen die ähm mit denen man dann auch wirklich arbeiten kann.

Sven Johann: Ja, ja, okay, okay. Gut, ähm ja, bevor wir zum Ende kommen, äh jetzt jetzt habe ich z.B. so ein Datenprodukt. Ich denke wieder in in in meiner Kundensituation. Und es gibt es gibt genügend ich habe vielleicht so ein Datenprodukt entworfen, ich habe auch mit meinem Consumer gesprochen oder mit meinen Konsumenten, gibt ja mehrere. Aber es gibt vor allen Dingen in größeren Organisationen, ja, da tauchen natürlich immer neue Services auf, neue Anwendungen, die Daten brauchen. Und da ist z.B. so, also hatte ich neulich noch mitbekommen, ja, ich brauche diese Daten. Ja, wie kommt man eigentlich, wie finde ich überhaupt Daten, ja? Und bei denen war das halt, also idealerweise kennst du jemand, der weiß, wo man nachgucken soll. Ansonsten haben die halt so eine zentrale also ich ich sag das jetzt falsch, ne, aber sagen wir im Confluence steht ist kein Confluence, ist schon hätte fast gesagt professionelles Tool, ne, aber also es gibt einen zentralen Ort, wo man wo man nachschauen kann, welche Daten gibt es und wer sind die Owner, ja? 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: Ähm Ja, gute Frage. Ähm also vielleicht gucken wir uns mal an, was ist ein Marktplatz irgendwie? Marktplatz also ohne jetzt Data ist irgendwie so eine Handelsplattform irgendwie, also eBay oder Amazon. Nutzt jemand noch eBay, ich weiß es nicht. Ähm genau und was was was zeichnet denn aus irgendwie, hat irgendwie gemeinsame Spielregeln ähm und eben, ne, die Ziele sind ja irgendwie davon, dass man halt irgendwie dorthin gehen kann, ähm und man findet irgendwie das, was man sucht, äh dadurch, dass irgendwie alles an einem Ort ist, sinken vielleicht auch irgendwie Kosten für das, was ich da ähm für das, was ich da irgendwie kaufen will. Ähm und bei einem Data Marketplace übertragen wir das eigentlich und setzen noch ein bisschen was oben drauf, ne? Wir sind natürlich ähm wir sind natürlich jetzt irgendwie kein kein kein Amazon für Daten. Ähm Und das was du jetzt beschrieben hast, klang für mich eher, das weiß ich jetzt nicht, ich kenne kenne deinen Kunden nicht, aber für mich klang das jetzt vielleicht eher sowas, wäre das noch näher an so einem klassischen Datenkatalog dran. Dort werden quasi alle Assets oder alle Daten Assets quasi beschrieben, die in einem Unternehmen sind und das sind aber dann auch wirklich nur Assets, das Ownership dran hängt, ist schon mal ein ganz gutes Zeichen, dann weiß ich immerhin, mit wem kann ich reden und ich habe nicht nur irgendwie eine Tabelle im Raum. Ähm bei diesen klassischen Datenkatalogen ist oft eben das Problem, dass ähm eben viel nicht beschrieben wird, ne? Also ich habe im Vorfeld über Semantik gesprochen und so weiter, sowas wird da nicht beschrieben, ähm weil oft dann auch einfach nur irgendwelche irgendwelche Crawler über über die Plattform laufen und irgendwie gucken, wo haben wir welche Datenbanken und das dann einfach unstrukturiert mehr oder weniger da reinwerfen. Ähm und dann habe ich halt einen riesen Bloat an, hey, hier sind irgendwie 1000 Tabellen. Ähm ich weiß aber überhaupt nicht, was die bedeuten und ähm ich weiß nicht, ob diese Spalte jetzt überhaupt noch benutzt wird, ne, weil das sind ja dann operative Systeme. Ähm Und ähm 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, ähm die ich ähm auch wirklich verwenden soll und dann kommen wir auch schon mehr in diese Marktplatzcharakteristik, weil da will ich ja eben, also eine Marktplatz werden üblicherweise Produkte verkauft, da sind wir schon wieder bei dem Wort. Ähm Und ähm die sollen dort eben auch angepriesen werden, ne? Die sollen dort nicht einfach nur auffindbar sein, sondern die sollen auch angepriesen werden. Ich will ja, dass das mir jemand abnimmt. Ähm genau.

Sven Johann: Ja, ich meine, das ist äh jetzt in meinem Fall ist es definitiv in in vielerlei Dimension nicht so der Fall, ne? Also irgendwann schon, ja, soll es so sein, aber jetzt ist eher so, äh es gibt diesen zentralen Ort, wo im Prinzip, ich sag mal so, da werden große Workstreams definiert, unter diesen Workstreams gibt’s Domänen, in den Domänen gibt’s jeweils Anwendungen, also ist im im Prinzip eine Architektur, also du kriegst so ein Architekturüberblick, ne? Also von da geht’s dann zu Arch 40 Doku z.B., aber äh praktisch in diesem Überblicks Tool, also dieses IT Landschaftsüberblicks Tool, da äh so würde ich es mal nennen, da ist auch beschrieben, welche welche Daten es gibt, aber da ist natürlich relativ vermischt, ne? Da sind irgendwie ein Haufen Also ich weiß nicht, ob weiß nicht, ob vermischt so schlecht ist, aber hat sich jetzt erstmal so angehört, das besser ist natürlich, ich gehe, also ist so ein allgemeiner Marktplatz, dann wird alles verkauft, ne, von Elektroartikel über Obst und keine Ahnung, ne? Und äh 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, ne?

Stefan Negele: Genau. Ja, genau und ähm und der Marketplace soll ja halt auch irgendwie Eigenschaften dann aufweisen zu den Dingen, die bei bei Daten eben für mich relevant sind. Also ich will beispielsweise irgendwie, vielleicht kann ich in meinem Marketplace auch irgendwie eine globale global Daten Governance Regeln beschreiben, kann die dann aus den Produkten raus referenzieren, wenn sie dort auf angewendet werden. Ähm vielleicht habe ich auch sowas wie einen semantischen Layer in diesem Katalog oder ähm kann den kann oder kann den anderen semantischen Layer irgendwie sauber darin einbinden. Also diese ganzen Sachen, die eben für die Charakteristik des Datenprodukts wichtig sind, sollten sich halt eben im Data Marketplace halt sinnvoll auch widerspiegeln, ähm weil ähm der ist ja dann auch wieder ein Produkt und das ähm 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, ja? Ähm 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 heißt 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 ein, ich sag mal so so ein MCP Server angeboten, aber der MCP Server der funktioniert, ich frage mich, funktioniert der so, wie ich mir das vorstelle, weil ich ich gehe zum Marktplatz und sag, ich 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 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. Ähm und also was die eben noch oben drauf legen, ist dann sozusagen, dass sie, dass dieser MCP Server, wenn ich das richtig verstanden habe, eben auch dann ähm die Datenquellen auch ansprechen kann, der muss natürlich die Rechte haben, aber in jeder Daten von meinen Datenprodukten steht ja auch drin, wie connecte ich mich denn mit, ne? Wo wo liegt denn jetzt irgendwie dieser Datensatz? Ähm und dann kann ich nicht nur die Datenprodukte finden, sondern kann sogar auch Antworten auf einfache analytische Fragen bekommen.

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

Stefan Negele: Natürlich. Ähm was was die auch noch drinne haben, was ganz cool ist, ähm ich hatte ja gesagt, dass irgendwie ähm Governance eben für Daten auch ein super wichtiges Thema ist und wenn wir schon beim Thema AI sind, ähm die haben eben auch ein Feature, womit man eben auch ähm Governance Regeln beschreiben kann mit natürlicher Sprache 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. Ähm das ist schon ähm das ist schon sehr cool und das zeigt aber auch wieder so eine Charakteristik auf, die eben so ein Data Makeup 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: Ja, also ich hätte jetzt gedacht, dass ich, wenn ich ein, wenn ich Teil von so einem Data Marketplace mit meinem Data Product sein will, dass mir dass mir schon Governance aufgezwungen wird. Also so wenn wir noch mal so den den klassischen Marktplatz sehen, ne, der stellt uns gewisse Dinge zur Verfügung, wie Strom und Wasser und Öffnungszeiten und so weiter. Aber der sagt halt auch, also die Governance ist, du musst musst dann und dann da sein und du musst dann und dann abfahren, musst du den Platz wieder räumen, da ist dein Platz. Und ich hätte hätte jetzt bei dem Marketplace gedacht, dass also zumindest jetzt bei Entropi Data, dass der der Data Contract, also eine Governance Regel ist, jeder muss ein Data Contract haben, ja und so weiter, ja.

Stefan Negele: Genau, der Data Contract, der ist ja auch eben auch ein Governance Tool dann am Ende.

Sven Johann: Ja. Gibt’s noch gibt’s noch andere Governance Regeln?

Stefan Negele: Ähm ja, also

Sven Johann: Also typische, ne, also was man vielleicht so verallgemeinern kann.

Stefan Negele: Ähm muss ich kurz nachdenken. Ähm ja, also ich kann natürlich auch sagen, ne, ähm ich definiere meine ich habe eine Governance Regel, dass ich meine ähm dass ich meine Daten eben als Datenprodukte definiere. Ich kann sagen, wenn ähm Zugriff auf Daten von anderen Teams stattfinden soll, dann muss das eben über diesen Marketplace passieren und darf nicht irgendwie hinten herum ähm passieren.

Sven Johann: Okay, ja, ja.

Stefan Negele: Ähm ja, also gibt’s noch einiges. Ähm globale Daten Governance Regeln sollte man aber so gering halten wie möglich, weil die machen halt einfach sozusagen, dass dann einfach alles nur sperrig. Klar, wenn ich gesetzliche Regulatorien einzuhalten habe, wenn ich sagen muss, ich muss z.B. PII Daten aus, das kann auch so eine Governance Regel sein, ich muss PII Daten, also persönlich Personenbezogene Daten irgendwie ähm ähm kennzeichnen. Ähm dann muss das beispielsweise da auch drin stehen, das wäre dann auch eben Beispiel für was globales. Ich werde aber versuchen, eigentlich meine Daten, also in der Datenprodukt orientierten Architektur würde ich versuchen, meine Governance Regeln möglichst klein im Data Contract zu halten und nicht quasi versuchen, das möglichst schlank zu halten, das was ich sozusagen allen aufzwänge.

Sven Johann: Ja. Ja, also kann ich mir gut vorstellen, bei Software Architektur ist ja auch so, dass du also Governance sollte ja äh to govern kann man ja in zweierlei übersetzen, ja, also zum einen Regeln aufzwingen, ist so die eine Seite, die andere Seite ist anleiten, Rahmenbedingungen schaffen, sowas, ne? Und man man will ja eigentlich immer in dieser anderen Seite sein, damit ich möglichst viel Freiheiten habe, aber trotzdem nicht alle irgendwie in unterschiedliche Richtungen laufen, ja, sondern dass alle praktisch ein gemeinsames Ziel einzahlen. Alright. Ähm gibt’s noch was Wichtiges, was ich nicht gefragt habe?

Stefan Negele: Nee, ich glaube, wir haben das schon weitestgehend ähm durchgesprochen jetzt, also wir haben bestimmt Dinge vergessen, ähm wenn man so redet, dann äh meistens vergisst man das allerwichtigste und wird dann danach drauf hingewiesen. Ähm nee, ähm ich glaube, dass äh die wichtigsten Dinge haben wir besprochen. Ähm genau.

Sven Johann: Alright, dann würde ich sagen, äh vielen Dank äh an alle Zuhörer, die es bis hierhin geschafft haben und äh vielen Dank Stefan.

Stefan Negele: Ja, danke auch und danke an die Hörer und bis dann. Bis denn. Ciao, ciao.