Data Contracts

Back to episode

Transcript

Sven: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts, heute zu Data Contracts mit Simon Harrer. Hallo Simon. Simon, dann für die, die dich noch nicht kennen, stell dich doch mal noch kurz vor.

Simon: Hallo! Schön, dass ich da wieder da sein darf bei dir. Ich bin Berater bei INNOQ seit 2018, also schon einige Zeit. Und ich bin eigentlich so im Herzen Software-Entwickler.

Simon: Und vor drei, vier Jahren bin ich in die Welt der Daten abgedriftet, auf die dunkle Seite, sage ich immer. Weil einfach Daten, da passiert Innovation, da passieren die spannenden Dinge. Da wollte ich dabei sein. Und Data Contracts ist so eine tolle Schnittstelle, eine tolle Kombination. Und da bin ich gespannt, was wir heute da alles dazu bereden werden.

Sven: Vor deinem Wechsel in die Datenwelt, du hast auf jeden Fall ein Buch geschrieben, Java by Comparison, warst ziemlich bei Mob Programming involviert, also mob.sh ist auch so ein Tool von dir.

Sven: Genau, also ziemlich umtriebig. Genau, aber jetzt was du nicht erwähnt hast, was natürlich auch das Data Mesh Buch übersetzt ins Deutsche von Zhamak Dehghani und ja, und an der Data Contracts Spezifikation und CLI gearbeitet. Okay, aber dazu, da diskutieren wir jetzt.

Simon: Da kommt dann alles noch, genau.

Sven: Genau. Aber wenn du sagst, bei den Daten passieren die spannenden Dinge. Also was hat dich da getriggert? Also was waren so die Dinge, wo du gedacht hast, da geht jetzt was ab?

Simon: Ich glaube, das Spannende war, ich war mit INNOQ bei einem Projekt bei Breuninger. Gibt es auch eine Case Study, kann man nachlesen. Ist alles veröffentlicht. Und dort haben wir im E-Commerce ein Order-Management-System gebaut. Wir waren komplett verantwortlich für den Betrieb als kleines Team. Und da ist dann etwas passiert, was noch nie in meinem Leben passiert ist. Das Backlog ist leer gelaufen.

Simon: Das passiert eigentlich nie. Und das lag daran, dass wir halt mit Mob Programming sehr effizient waren in der Umsetzung. Wir waren echt schnell. Und andererseits war das Projekt oder die Software, die wir gebaut haben, war eingebettet in ein großes Wasserfallprojekt. Es ging um ein neues Dienstleit-Warenversenderzentrum, das gebaut wurde. Das ist dann irgendwann in Betrieb gegangen und wir haben eine Komponente gebaut, um das irgendwann anzuschließen.

Simon: Und dann war dieses große Projekt durch, und die neuen großen Projekte, da waren wir nicht so intensiv beteiligt, und deswegen gab es diese Lücke, sozusagen. Und deswegen hatten wir dann Zeit, und genau diesen Moment, als unser Backlog leergegangen ist, kam jemand bei Breuninger herum, vom Datenplattformteam, hat gesagt, hey, wir haben Google BigQuery jetzt, und wer möchte das denn mal nutzen?

Simon: Und dann haben wir begonnen, unsere Daten die wir dort, ja eh in unseren operativen Self-Contained-Systems hatten, einfach mal auf Google BigQuery zu schieben und dann zu analysieren. Und dann haben wir geguckt, was steckt denn in unseren Daten drin, was könnten wir denn tun? Und dann kamen ganz viele coole Ideen und eine Idee war, dass wir, wenn man praktisch zwei Bestellungen schnell hintereinander abgibt,

Simon: Die würden typischerweise in zwei Paketen verschickt. Und wir kamen überlegt, na, könnte man das vielleicht in einem Paket verschicken? Und haben damit dann solche Ideen dann analysiert, geguckt, was hat das für einen Impact, wenn man das machen würde? Und dann hatten wir so ein Feedback-Loop, also wirklich datengetriebenes Arbeiten. Und das war sozusagen der magische Moment für mich. Dieses echte datengetriebene Arbeiten.

Simon: Das dann verändert, wie ich Software entwickle, wie man priorisiert.

Sven: Ja, okay. Ja, das war mir gar nicht so bewusst. Also ich hatte ja, bevor ich bei INNOQ war, ist jetzt auch schon über neun Jahre, also bin jetzt seit neun Jahren oder so da, ich in Holland gelebt.

Sven: Und die Holländer, wie das halt so ist, die sind in vielen Sachen uns ja so ein paar Jahre voraus. Kann man immer gucken, was die so treiben. Und damals sind die auch schon durch die Gegend gezogen und haben gesagt, “Data is the new oil”. Also alles in die Daten. Und wir hatten damals auch so einen Produktmanager, der datengetrieben gearbeitet hat. Und mir war das eigentlich, also ich habe das von den Buzzwords auch gekannt.

Simon: Mhm. Ja. Mhm.

Sven: Und ich fand das dann auch ziemlich interessant. Also ich war noch lustigerweise in so einem Unternehmen was selbst ein Daten-Broker war, da hat es irgendwie nahe gelegen, auch zu gucken. Und ich fand das ganz cool. Aber bei mir war die Enttäuschung dann irgendwie da, weil wenn du, wenn du mit den Daten praktisch, also wir hatten irgendwann mal, wir hatten so ein Feature umgesetzt, beziehungsweise nicht umgesetzt, einfach weil wir gesagt haben, die Daten sagen, so wie das gewollt ist, ist das Quatsch.

Sven: Nutzt keiner und so weiter. Und dann haben die gesagt, ja, wir wollen aber trotzdem, das soll trotzdem weiterlaufen. Ja, aber ich meine, wir müssen doch jetzt irgendwie was machen. Und die so, alles bleibt beim Alten. Ist egal, was die Daten sagen. Das hat mich so ein bisschen, das hat mich so ein bisschen, wie soll ich sagen, also enttäuscht. Aber so grundsätzlich die Idee,

Simon: Ja.

Sven: Dass wir wirklich datengetrieben arbeiten, das finde ich auch total interessant. Also ich meine, das machen ja schon viele Firmen seit langer Zeit.

Simon: Ich kannte es halt vorher nicht. Man hat halt einfach Stories, der Product Owner hat einfach Stories definiert, man hat die umgesetzt, man hat die schon hinterfragt. Aber dieses wirklich ein Knall hat, nach den Daten zu gehen und dann auch Feature-Wünsche von anderen, von anderen Stakeholdern abzuschmettern, weil man sagt, Quatsch, das lohnt sich nicht. Das betrifft nur eine Ringe mehr. Es ist kein Business Case, wenn ich das umsetze. Das fand ich halt total beeindruckend.

Sven: Ja, genau.

Simon: Aber ich würde gerne noch einen Nachsatz machen, warum ich auch in die andere, also es gibt noch einen zweiten Grund, warum ich in die Welt der Daten gegangen bin. Jetzt ein bisschen was Provokatives, um ein bisschen die Hörerinnen und Hörer vielleicht auch schon mal auf einzustellen. Ich habe das Gefühl, in der Softwareentwicklung gibt es nicht mehr so viel Innovation. Wir haben die Innovation, also da, wo es spannend ist, wo coole neue Dinge passieren, das ist in der Welt der Daten, das ist in AI, das ist in den Large Language Models.

Simon: Natürlich immer in der Schnittstelle zur Softwareentwicklung. Ich muss das ja integrieren. Aber in der Softwareentwicklung selber haben wir die Innovation eher im organisatorischen. Im Domain Driven Design, Team Topologies, da kriegen wir die Innovation rein. Aber in der echten Kernsoftwareentwicklung sehe ich sie nicht.

Sven: Vielleicht gibt es, da müsste ich mal noch drüber nachdenken, also es passiert schon immer ein bisschen was. Aber die Sache ist immer, wo gehen, wo passieren die großen Schritte? Also ich kann mich noch so erinnern, ich war früher, in einem frühen Leben war ich ja total in der Springwelt. Und dann, also es ist auch schon, sagen wir so vor zehn Jahren oder so, eigentlich vor 14 Jahren, da kann man sagen, okay, bei Spring tut sich ja immer noch was.

Simon: Ja. Ja.

Sven: Aber da war halt Continuous Delivery, Cloud und so weiter. Da passieren halt viel mehr Dinge. Also die Innovationssprünge sind viel höher. Und da würde ich auch sagen, also da ist wahrscheinlich bei Daten, da ist man jetzt gerade bei diesen großen Sprüngen dabei. Ja. Genau.

Simon: Ja, genau, vielleicht lass es uns ne weniger provokativ formulieren. Vielleicht passiert da gerade mehr als woanders. Ich glaube, darauf können wir uns einigen, dass wir da auch ein bisschen weniger provokativ unterwegs sind.

Sven: Genau. Ähm, wir wollten über Data Contracts reden. Jetzt sagst du bei Breuninger, ähm, habt ihr datengetrieben gearbeitet? Werner Vogel, CTO von Amazon, der hat ja mal bei ACM Queue, hat der ja mal ein Interview gegeben, schon vor 18 Jahren oder so, wo er gesagt hat,

Sven: Also das berühmte, “you build it, you run it”. Wir gehen nah an den Kunden ran. Wir arbeiten vom Kunden rückwärts, auch in Produktion. Und wir gucken auch, wie verhält sich die Anwendung in Produktion. Also im Grunde genommen hat er das propagiert, was ihr auch gemacht habt. Aber wie ist sozusagen der Sprung von da nach Data Contracts, ja, ohne dass wir bis jetzt definiert haben, was Data Contracts sind. Aber vielleicht kannst du mal ganz kurz so die Geschichte aufzeigen.

Simon: Ich glaube, wenn du ein Team in einem Team bist, das eben genauso eine Ende-zu-Ende-Verantwortung hat, dieses you “build it, you run it”, komplett durchdenken und dann auch datengetrieben ist, dann nutzt du ja deine Daten, um deine Systeme zu verbessern. Es kommt aber zu dem Punkt, wo du merkst, das reicht nicht, ich hätte gerne noch andere Daten, die mir helfen, noch eine noch bessere Entscheidung zu treffen. Dann wird es ja spannend, wie kriege ich die Daten der anderen Teams?

Simon: Und ich will vielleicht nicht einfach nur die Produktionsdaten der anderen Teams, sondern ich hätte die gerne in einer schön aufbereiteten, historisierten Form, mit hoher Qualität, mit schöner Absicherung. Und da kommen wir eigentlich zu den Data Contracts. Wenn ein anderes Team mir Daten bereitstellt, dann hätte ich natürlich gerne ein Versprechen damit. Ich will nicht einfach nur, dass die mir irgendwie Daten irgendwo hinwerfen. Und dann nehme ich die und dann ändern die die einfach, weil das ist eigentlich eine Schnittstelle für mich.

Simon: Und es ist eigentlich keine Schnittstelle im klassischen Sinne, also keine, vielleicht keine REST-API, weil ich will vielleicht auf deren großen Datenschatz zugreifen, den die haben, und der ist halt Gigabyte oder Terabyte groß. Und ich möchte den wirklich zurück, ich möchte ja Analysen machen in die Vergangenheit rein, also brauche ich historisierte Daten. Und solche Themen. Und dafür ist eigentlich Data Contract da. Das Data Contract soll als Spezifikation beschreiben, was mir die andere Partei, anderes Team zur Verfügung stellt, dass ich mich darauf verlassen kann.

Sven: Okay, weil die, ich sag mal, so ursprünglich habe ich gedacht, na ja, da gibt es halt irgendwie ein Kafka-Teams von, also,

Sven: Also andere Teams publizieren da ihre Änderungen. Das reicht, ja. Aber jetzt höre ich so raus, ja, kann man machen, aber das sind dann nur die… Da würden die historischen Daten fehlen oder was würde da genau fehlen? Ja. Ja.

Simon: Genau, also das Kafka-Topic, wenn wir sagen, das ist ein Kafka-Topic, das mir ein anderes Team bereitstellt, dann ist das die Daten, die sie mir bereitstellen. Aber was für Garantien bekomme ich denn? Okay, vielleicht kriege ich einen Afro-Schema daneben. Okay, dann habe ich so eine Sicherheit für das Schema.

Simon: Dann ist die Frage, ist das garantiert? Also garantieren Sie mir, dass es keine Breaking Changes gibt? Also wird das irgendwo dokumentiert? Ich verlasse mich ja drauf. Ich baue ja etwas drauf. Das ist das eine. Und dann haben wir noch einen anderen Aspekt. Ich denke, du schaust, wenn du jetzt Kafka hast, schaust du immer Record for Record. Du schaust dir immer einen Record nach dem anderen an. In der analytischen Welt schaut man sich das eher spaltenweise an.

Simon: Also ich habe nicht die Row-Ansicht, die Record-Ansicht, sondern ich habe die Column und die Spalten-Ansicht, die Spalten-Denken. Und das brauche ich eigentlich auch. Also ich möchte darüber auch Zusicherung haben. Schau dir an, du hast eine Spalte E-Mail-Adresse. Die ist optional. Für mich als Nutzer, sei das jetzt vielleicht jetzt mein Team bei Breuninger oder in irgendwie ein Team von Data Scientists, die die Machine Learning Use Cases haben. Die wollen diese E-Mail-Adressen nutzen. Für die ist es aber, ob das jetzt optional ist, das hilft denen erstmal nicht. Für die ist es viel wichtiger, wie viel Prozent der E-Mail-Adressen sind denn da? Fehlen nur ein Prozent? Fehlen fünf Prozent? Oder fehlen eigentlich 99 Prozent? Es ist total selten, dass das überhaupt gefüllt ist. Das hat eine Riesenauswirkung darauf, wie sie das nutzen können als Konsumenten.

Simon: Und das wollen wir eben auch mit dem Contract spezifizieren und garantieren und auch prüfen können. Ist die E-Mail-Adresse eigentlich fast immer gesetzt, aber manchmal fehlt sie. Es hat eine ganz andere Aussage, als das sie es optional und, ja, keine Ahnung, darauf verlassen kannst dich nicht. Für die transaktionale Verarbeitung ist das okay. Dann entscheide ich halt, ob ich halt eine Fallunterscheidung sie ist da oder es ist nicht. Und dann tue ich unterschiedliche Dinge in der Analysewelt oder Datenwelt.

Simon: Interessiere ich mich für die ganze Spalte, dann ist mir eher so eine Mengenverteilung wichtig.

Sven: Ah, okay, also die, ich hör jetzt auch so raus, klar, wenn ich so an so einem Kafka-Topic lausche, dann bekomm ich die Daten, aber ich muss sie natürlich dann selbst bei mir lokal noch mal irgendwie vorhalten. Also ich muss sie irgendwie verarbeiten. Vielleicht brauche ich die für transaktionale Zwecke, aber wenn ich sie für Analytics brauche, dann müsste ich noch meinen eigenen Analytics-Topf bei mir aufmachen, in meinem Team. Und das würde da fehlen bei dieser Analytics-Topf. Den nutze ich einfach, den ein anderes Team sozusagen zur Verfügung stellt.

Simon: Genau, und wenn du jetzt eine gute Datenplattform hast, wo ich dort Daten bereitstelle, Kafka ist noch ein bisschen Spezialfall, aber wenn ich jetzt so einen Google BigQuery zum Beispiel habe, dann kann ich da ja Daten ablegen. Und wenn jetzt mehrere Teams dort Daten ablegen, kann ich als Konsument diese Daten auch einfach kombinieren. Und dann wird es cool, weil ich dann ja sehr einfach einen Join machen kann, über riesige Datenmengen,

Simon: Ich muss natürlich berechtigt sein, und dann kann ich auf Basis dessen bessere Auswertungen machen oder wieder weiter Daten aufbereiten und wieder bereitstellen für andere. Und das Entscheidende ist halt, dass auch wenn du jetzt eine Datenbank-Tabelle auf BigQuery hinstellst, ist das eine Schnittstelle. Und wir reden ungern über Daten als Schnittstelle in der operativen Welt. Das ist so ein bisschen verpönt, und das verstehe ich auch, weil man die nicht gemanagt hat.

Sven: Ja, klar. Also ich meine, wenn man sagt, wenn du meine Daten willst, hier ist mein Schema und hier ist der Datenbank zu Griff. Böse, böse, Integration über Datenbank will man nicht haben. Aber für Analysezwecke ist gut, gut. Das ist genau richtig.

Simon: In der Welt der Daten ist das die natürlichste Schnittstelle, weil ich ja auf die Joins optimiere. Ich glaube, der Unterschied ist, wenn du einfach jemandem Zugriff auf deine operative Datenbank gibst,

Simon: dann sagst du ja nicht, das ist jetzt eine megastabile Schnittstelle, die ich dir zur Verfügung stelle, sondern das ist eher so ein Mega-Dirty-Hack-Workaround. Aber wenn du sagst, ich stelle jetzt Daten hier als View oder als Tabelle explizit als Schnittstelle zur Verfügung, ich verstehe sie als Team, das dies anbietet, auch als Schnittstelle, dann warum nicht? Also, dann ist halt, dieses API ist halt eigentlich SQL.

Sven: Hm. Genau. Hm. Ja.

Simon: Und das hat ja auch Vorteile. Es hat ja nicht nur, also wenn ich die Nachteile wegnehme, hat es auch Vorteile, die diese SQL-Technologie bietet. Das ist so ein bisschen der Mindshift, der hier eigentlich stattfindet.

Sven: Ja, also ich meine, ich denke immer so daran zurück vor, also ich glaube so 2010, 2011, weil so die Zeit, wo NoSQL so hoch kam,

Sven: Und da war, also initial war ich total heiß. Dann hatten wir so ein Projekt, wir hatten MongoDB benutzt und dann musste ich so eine größere Migration machen. Und dann habe ich gesagt, ah cool, jetzt mache ich hier meine Migration mit MapReduce und dann MongoDB war ja damals noch, musste man mit JavaScript drüber rödeln und dann

Simon: Ja. Ja.

Sven: Da war ich eine Stunde drin und habe gedacht, was für ein Scheiß, ich will eine Query Language, man will eine Query Language. Genau, man will die. Jetzt hast du gesagt, ich stelle als Team das zur Verfügung, aber

Sven: Ich habe immer so, also mein Verständnis war immer, das passiert immer im Kontext, also Data Contracts hat man irgendwie immer im Kontext Data Mesh, aber ich höre jetzt irgendwie so raus, also man kann schon eine zentrale Datenplattform haben, wo alle, also wo Leute, die interessiert sind, die können, also ich bin interessiert und es gibt eine zentrale Datenplattform und da publizieren sozusagen alle Teams ihre analytischen Daten mit einem Data Contract.

Simon: was?

Sven: Und da kann ich dann auch meine, da kann ich meine Analysen, da kann jedes Team Analysen fahren, sozusagen. Muss ich mir das so vorstellen?

Simon: Genau, also Data Contacts eigentlich die niederschwelligste und sinnvollste Art und Weise, mit Daten eigentlich zu arbeiten. Ich sag ja einfach nur, jemand teilt Daten und wenn ich Daten teile, muss ich einfach auch klar definieren, was hängt denn da dran? Was garantiere ich denn, wenn ich diese Daten teile? Oder werfe ich eigentlich nur Daten hin und die können sich jederzeit ändern und die können auch jederzeit gelöscht werden?

Simon: Und das ist eigentlich das, wo Data Contracts einsteigen will. Und ich kann das in einem Data Mesh Ansatz machen. Das passt auch super dazu. Würde ich auch empfehlen. Aber Data Contracts ist eigentlich der kleine Einstieg. Das kann ich immer tun. Und es ist eigentlich auch total sinnvoll, das zu tun. Und da sieht man eigentlich, dass die Welt der Daten halt auch von den Erfahrungen in der Softwareentwicklung lernen kann und auch was aufzuholen hat. Weil, ich meine, schauen wir mal zurück, wann Swagger rauskam. Das ist auch schon ein paar Jahre her.

Sven: Ja. Hm.

Simon: Und mittlerweile ist OpenAPI recht verbreitet. In der Welt der Daten gab es ganz wenig. Ganz, ganz wenig. Man hatte auch nicht so viel Austausch zwischen den Teams. Man hatte diese Dezentralisierung nicht, die wir jetzt in der Softwareentwicklung hatten. Man hatte ganz viele Teams, auch im Engineering-Bereich passiert ganz viel Transformation auch in der Welt der Daten.

Simon: So was wie Trunk-Based Development findet plötzlich Einzug auch im Data Engineering. Ganz, ganz spannende Beweggründe. Aber ich glaube, Data Contract ist für mich so das Zentralste, weil es einfach diese Schnittstellenspezifikationen gefehlt haben.

Sven: Ja genau.

Simon: Und wenn du, das ist auch ganz witzig, wenn wir da mit Kunden sprechen und du redest über Data Mesh, das ist immer schwierig, weil das ist Organisation und das ist immer ein großer Change. Aber dann sagst du, hey, ihr teilt auch Daten und ihr habt doch hier ein Team oder ein Subteam, das teilt Daten mit anderen Leuten. Und da gibt es irgendwie Probleme. Lass uns doch ein Data Contract, lass uns mal spezifizieren, was ihr da teilt. Lass uns mal Stabilität reinbringen. Und da gibt es keine Argumente dagegen.

Sven: Ja, das kann ich mir gut vorstellen. Ja.

Simon: Was willst du dagegen sagen? Also nichts begründet zumindest, nichts sinnvoll begründet. Und das ist eigentlich der Weg rein. Stabilität, dass du ein Fundament aufbauen kannst, um dann coole Use Cases wie AI oder was auch immer darauf aufbauen zu können oder Analytics oder was auch immer.

Sven: Ja, dann wir reden schon seit 20 Minuten um den heißen Brei. Also ich denke, war schon notwendig, um so ein bisschen Kontext zu bekommen. Aber wir wollen auch mal so ein paar Elemente von so einem Data-Contact oder eigentlich alle Elemente immer vom Data-Contact durchsprechen. Und ich war auch gerade eben so ein bisschen getriggert, weil so Datenqualität und Service-Levels, da habe ich mich ja auch mal mit beschäftigt in der Datenwelt. Das fand ich eigentlich auch ziemlich interessant. Okay, aber legen wir mal los.

Sven: Ich hab mir mal, also du hattest ja dankenswerterweise, ihr habt ja eine Seite datacontracts.com, verlinken wir alles in den Show Notes, in Gernot, Gernot Starkes Buch hast du noch mal einen Kapitel dazu geschrieben, da habe ich es auch rausgeklaut. Und ja, das Allererste, was da ist,

Sven: Ich hätte jetzt schon, wollte jetzt eigentlich schon die Elemente fragen, aber wie, wie, wie wird eigentlich so ein Data Contract spezifiziert? Also ist das irgendwie YAML, so wie alles YAML ist oder? Ja.

Simon: Die einfache Antwort ist ja, natürlich ist es YAML, wir sind ja YAML-Engineers mittlerweile geworden. Die Idee ist eben, vielleicht fangen wir nochmal an mit einer Definition, was ist ein Data Contract? Und ein Data Contract ist eben kein Contract. Ein Data Contract ist eigentlich eine Spezifikation, eine Schnittstellenspezifikation, eine Beschreibung meines Datenangebotes für andere.

Simon: mit allen Dingen, die dazugehören. Also natürlich die Spezifikation des Schemas der Daten. Was haben die Daten für eine Struktur? Was sind das für Datentypen? Das ist so, glaube ich, klar. Das muss auf alle Fälle mit drin sein. Aber was noch dazukommt, ist zum Beispiel, wem gehören die Daten? Das ist in der Datenwelt ein spannendes Thema, weil oft fühlt sich keiner verantwortlich.

Simon: Man hat nicht so diese klare Ownership wie über die operativen Systeme, wo du im Team das baust und ist natürlich verantwortlich für die Schnittstellen, die das System anbietet. Das ist ganz klar. Das ist in der Welt der Daten anders. Das hat sich dann noch nicht so etabliert. Deswegen ist das, das klingt einfach, aber das ist einer der wichtigsten Hebel. Ganz klar zu sagen, wer ist zuständig? Wer ist verantwortlich? Und wem gehören die Daten. Dann so Dinge wie die Nutzungsbedingungen. Was darf ich denn mit den Daten machen?

Simon: unterliegen die vielleicht Lizenzbedingungen, weil das externe, es können ja auch externe Daten sein, die jemand gekauft hat, jetzt intern bereitstellt und dann darf ich die nicht wieder weitergeben oder ich darf sie intern auch nicht allen geben. Also zum Beispiel Statistikdaten oder Wetterdaten werden häufig gekauft, die darf ich nicht einfach mit einer API wieder nach außen geben oder Wechselkurse oder andere Dinge, da darf ich das vielleicht nicht. Oder ich habe

Simon: Daten, die also geschützt sind durch eine Datenschutzerklärung, die gilt. Vielleicht gibt es auch mehrere Datenschutzerklärungen, weil die Firma groß genug ist, weil sie in mehreren Regionen operiert, wo unterschiedliche Gesetze gelten und dann gelten unterschiedliche Bedingungen. Das muss ich alles mit berücksichtigen und das ist eigentlich Teil meines Datenangebotes. Weil sonst kann ich als Konsument mit den Daten ja nicht sich sauber und sicher arbeiten.

Sven: Ja, ich meine die Nutzungsbedingungen. Okay, das ist natürlich intern. Deswegen muss man es wahrscheinlich intern klären. Ich stelle mir halt gerade so vor, dass ich halt die Nutzungsbedingungen lese und denke, oh gut. Ich greife trotzdem drauf zu und mache irgendwas, aber.

Simon: Ja, das ist spannend, weil es geht eben darum, wenn ich jetzt deine Daten haben will, dann muss ich ja Zugriff irgendwie bekommen. Dann kriege ich, wenn es vielleicht schützenswerte Daten sind, also Daten über Personen, über Menschen, also persönlich identifizierbar, dann haben die einen höheren Schutzgrad und dann kriege ich die vielleicht nicht einfach. Und wer ist jetzt verantwortlich, mir Zugriff zu begeben?

Simon: Und eine Antwort ist eben, ich beantrage Zugriff und du, weil es deine Daten sind, du musst diese Entscheidung treffen und du musst dich an diese Gesetze halten, weil wenn du das falsch machst, also wenn du mir Daten gibst, die ich nicht haben darf, dann ist das dummerweise halt vielleicht ein Verstoß gegen die DSGVO und die kann ja sehr scharf, hat ja ein sehr scharfes Schwert mit der Umsatzstrafe.

Sven: ok ok ja

Simon: Und dann wird es schon irgendwie, also dann wird es halt doch relevant und dann wird es auch C-Level relevant. Und das ist dann schon etwas, wo gerade Data Governance ist und die haben sehr viel Macht in den Unternehmen. Die freuen sich zum Beispiel über solche Data Contracts, weil die können sagen, ihr müsst es klar spezifizieren in euren Angeboten von Daten, was für Schutzklassen gibt es, wie sensibel sind die Daten.

Simon: Und dann können wir auch überwachen, dass das alles passt, dass, wenn ich Daten beantrage von dir, dass mein Nutzungszweck zu dem Angebot, zu den Bedingungen deines Angebots passt. Da kann ich dann auch Automatisierungen oder Hilfestellungen machen, um das eben abzudecken oder auch zu erkennen. Ich kann zum Beispiel auch codieren in den Nutzungsbedingungen, meine Daten dürfen die EU nicht verlassen. Und dann hat jemand anderes Datenangebote gesagt, die Daten dürfen China nicht verlassen. Das muss ich ja auch sicherstellen.

Sven: Hmm.

Simon: Und solche Dinge, ich glaube, da möchte ich einfach klar sagen, dieses Lachse, das nutze ich einfach. Ich glaube, das ist in vielen Firmen nicht so einfach, weil du willst auf keinen Fall den Datenabfluss in die andere Wirtschaftsregion haben. Da gibt es ganz große Probleme, wenn das passiert. Und Data Contacts wären ein Mittel, um sozusagen aus Metadatensicht zu überwachen, dass das nicht passiert.

Sven: Hmm.

Sven: Ja, ich habe natürlich wieder völlig das falsche Verständnis gehabt, weil ich denke mir halt, ja, Datenplattform, ja, also wir haben, man sieht schon, ich habe wieder keine Ahnung. Aber also bei uns war es zumindest mal damals so, bei diesem Daten-Broker.

Sven: Wir haben auch “You build it, you run it” gemacht und ich habe natürlich Zugriff auf alles gehabt. Und dann sage ich halt, okay, ich brauche die, ich muss irgendwie über verschiedene Datentöpfe Daten korrelieren, mache ich einfach. Und dann war ja natürlich meine naive Vorstellung, dass es da, da gibt es eine Datenplattform, da sind einen Haufen Big Query Tables. Ich habe Zugang dazu und ich kann einfach

Sven: machen, was ich will, aber das ist nicht so. Also wenn ich praktisch auf. So ein BigQuery Table oder Materialized View oder wie auch immer Zugriff haben will, muss dieser Zugriff explizit beantragt werden. Hm.

Simon: Ja, dann gibt es unterschiedliche Vorgehensweisen, aber je sensibler, kriegst du nicht so einfach Zugriff. Also gerade bei uns in der EU oder gerade im Dachraum haben wir eher dieses, ich muss Zugriff beantragen, weil ich das absichern will, hat auch den Vorteil, dass ich als Datenanbieter dann weiß, wer nutzt denn meine Daten und auch warum.

Simon: Das ist ja auch was Schönes. Ich kenne dann meine Nutzer plötzlich.

Sven: Ja, ja, ja.

Simon: Und ich weiß, was die damit tun. In der operativen Welt wissen wir das eigentlich immer. Mit unseren APIs tauschen wir dann Secrets aus, mit den API-Keys, dass wir drauf zugreifen können. Und dann gucken wir, welches Team ist das? Was machen die denn da? Sind dann die Geschäftsprozesse, die danach folgen, passieren? In der Datenwelt ist das halt bisher nicht gewesen. Da wusstest du nicht. Das ist ein riesiger Spaghetti-Code gewesen. Jeder greift auch irgendwelche Daten zu, gigantische

Simon: Komplexität in der Abhängigkeit. Und du kannst auch nichts mehr abschalten, du kannst auch nichts mehr löschen, weil du ja nie weißt, wer nutzt es und warum und ist das wichtig? Und genau das wollen wir eigentlich über Contracts auch, also wir wollen da Klarheit reinbringen. Einerseits im Angebot und dann gibt es noch dazu ein kleines Add-on. Das ist dann eben so ein Agreement, wo wir dann sagen, okay, warum nutzt du das? Und wir möchten das festhalten.

Simon: dass dieser Konsument diese Daten nutzt mit diesem Contract. Ja. Mhm.

Sven: Ich muss gerade lachen, weil unser wunderbarer Case bei einem Kunden war, du weißt nicht, wer die Daten nutzt. Wir hatten aus Kostengründen unsere Performance-Testumgebung abgeschaltet.

Sven: und haben halt einfach gesagt, wir testen, wir machen Performance-Tests auf Produktion, das haben wir unter Kontrolle, hatten wir auch, war alles kein, also, ist ein bisschen riskant, aber wir waren, sagen wir mal, so reif, dass das alles kein Problem war. Wir hatten 80.000 Test-Accounts auf Produktion angelegt, ja, die waren auch als Test-Accounts gefleckt, aber, naja, wir wussten halt, also, die Daten wurden halt einfach abgegriffen und dann sind irgendwo die,

Simon: Mhm.

Sven: die Sektkorken geknallt, weil wir ja innerhalb von einem Monat 80.000 neue bezahlende Subscriber hatten. Und ja, das hat mir zur größten Freude beigetragen, als dann rauskam, dass das doch nicht so war.

Simon: Ja, wenn der Bonus, den man sich dann erhofft hat, doch nicht kommt.

Sven: Ja. Gut. Interessant auf jeden Fall. Ja, das wäre uns… Also jetzt in dem Beispiel wäre das halt nicht passiert, weil wir hätten, sagen wir mal, unsere Schnittstelle hätte halt… Ich meine, wir haben das auch kommuniziert, muss man dazu sagen. Also es ist auch klar, dass… So klar war es offensichtlich nicht, dass…

Sven: Wisse Accounts einfach Test-Accounts sind, aber natürlich in dem Contract hätte man nochmal expliziter darauf hingewiesen, hätte gesagt, hier dran erkennt ihr, dass das ein Test-Account ist, wenn ihr damit Analytics macht und

Simon: Genau, also eine Variante wäre halt, man stellt im Contract, sagt man ihm bewusst, das ist die Spalte, um zu unterscheiden, ob es ein Test-Account ist oder nicht. Das wäre das eine. Oder das Team, das dieses System, diese Accounts, diese Subscriptions managt, stellt Daten einfach, also die wissen ja selber, die müssen ja bei sich wissen, ob das

Simon: oder diese Accounts, die da erstellt wurden, die müssten eigentlich dann sagen, es gibt hier, das sind die echten Accounts. Also ich stelle mehrere Datensätze zur Verfügung. Einmal die echten Accounts und einmal die Test-Accounts. Also man könnte das sozusagen aufsplitten, um solche Sachen zu verhindern, weil man sagt, die Test-Accounts, die sind eigentlich für keine weitere Analyse notwendig. Also nehme ich sie frühzeitig raus, um eben diese

Simon: um für meine Konsumenten ein besseres Datenangebot zu machen. Das ist ein bisschen Product Thinking, die Richtung Data Products dann, wo ich die Daten so aufbereite, dass sie für meine Konsumenten am besten geeignet sind.

Sven: Ja, genau, also das hat mich damals auch so ein bisschen genervt und ich verstehe das jetzt so, dass dieses Problem, was mich damals genervt hat, gelöst ist. Also da war es so, es gibt so eine zentrale Datenplattform und wir haben so einen ETL-Prozess,

Sven: Und dann gibt es einen Haufen Abstimmungen, da kann man den Leuten natürlich sagen, ja, das bieten wir hier so an und dann zieht das mal raus und übrigens daran erkennt man, dass es ein Test-Account ist. Und dann machen die Leute irgendwas und dann konsumieren andere Leute irgendwas und das ist sozusagen außerhalb von

Simon: Ja, das ist eine sehr gute Frage.

Sven: von meiner Zugriffsphäre. Ich kann einfach nur kommunizieren, dass die Dinge so sind, wie sie sind. Was aber da genau passiert, das liegt halt im Team, die praktisch diesen ETL-Prozess da entwickelt haben. Und so würde ich sagen, wir bieten hier ein Datenprodukt an.

Sven: Wir exportieren, meinetwegen, also wir haben unseren eigenen ETL-Prozess, der, oder wie auch immer das macht, wie man das macht, ja, also wir pflegen praktisch unsere Analytics-Datenbank selbst. Genau.

Simon: Genau, oder halt den Teil, der von unseren operativen Systemen kommt, wo wir eh am meisten Bescheid wissen und eigentlich immer

Simon: eigentlich klar wissen, wenn sich da was ändert oder wenn jetzt dieses Flag Test-Account, vielleicht wurde das ja erst eingeführt, dann können wir das sofort berücksichtigen. Das ist in unserem Kreis, in unserem Bounded Context, in unserem Domänen Kreis. Ja, das geht aber jetzt ein bisschen mehr Richtung data mesh, also diese klare Verantwortlichkeit,

Sven: Ja.

Simon: und dann mit Datenprodukten, mit dem Produktgedanken Daten anbieten und die Ownership auch übernehmen, nicht nur über die operativen Daten, sondern auch über die analytischen Daten. Also es ist sozusagen die andere Richtung. Data Context kann man da auch einsetzen, das ist auch sinnvoll, aber man kann die auch einfach so einsetzen, also ohne, ohne dass man es so macht. Geht immer. Das will ich einfach immer wieder sagen hier in dem Podcast. Data Context gehen immer.

Sven: Ja, die gehen immer. Genau, ich starr gerade auf Datenqualität, das wäre sozusagen der nächste Punkt in der Liste.

Simon: Wir können auf die anderen Elemente vom Datacamera noch eingehen. Genau, Datenqualität. Ich habe es so ein bisschen schon angesprochen.

Simon: Einerseits ist es natürlich irgendwie, dass das Schema, das Schema muss natürlich das sein. Im Contract spezifiziere ich die Datentypen und dann kann ich da ja pro Spalte oder ich sage jetzt immer Spalte, aber es kann ja auch ein JSON sein oder eine verschachtelte Struktur. Ich gebe dann an, was haben da für Typen und dann kann ich weitere Constraints definieren, weitere Einschränkungen. Manche sind required, also die Klassiker, die man so kennt. Dann kann ich noch eins runtergehen. Ich kann reguläre Ausdrücke definieren.

Simon: die ich dann prüfen kann, ob die erfüllt sind. Und dann kann ich eben zu diesen, das ist jetzt ein bisschen neuer, diese klassischen Datenqualitätschecks gehen, wo ich eben sagen kann, vielleicht habe ich auch zwei Tabellen und dann sage ich, diese beiden Tabellen haben immer die gleiche Row Count. Das ist zum Beispiel eine Datenqualitätsprüfung, dass das nicht auseinanderläuft oder die eine Tabelle hat mindestens so viele Rows wie die andere.

Sven: Hmm. Hmm.

Simon: Also, im Prinzip definiere ich in Varianten, die ich also prüfen kann. Und die mache ich explizit. Und ich kann auch beschreiben, warum die sinnvoll sind. Dieses Beispiel mit den E-Mail-Adressen. Kann ich ja sagen, die sind eben, 5% sind maximal nicht vorhanden. Das ist so. Also, ich schaue eben nicht mehr auf die einzelnen Zeilen, sondern ich schaue immer auf den gesamten Datensatz.

Simon: und definiere für diesen Datensatz in Varianten. Und ich glaube, das ist der Unterschied zu den klassischen operativen APIs. Mhm.

Sven:: Ja, ich meine, ich bin gerade so, also ich denke mir so, ja klar, das ist natürlich total super, wenn man das hat, weil grundsätzlich, wenn ich Daten, also wenn ich mir die Daten irgendwo ziehe, so in meiner alten Datenwelt, es gibt irgendwo eine Schnittstelle und ich muss praktisch meine Schatten, meine Schattendatenhaltung dafür anlegen und dann muss ich ja selbst

Sven: muss ich mir praktisch die Datenqualität ja selbst nicht aus den Fingern saugen, aber ich muss ja sozusagen immer mal gucken, okay, wie viel hab ich denn überhaupt? Wie verändert sich das über die Zeit? Also wir mussten damals ja immer die Daten von anderen analysieren, um praktisch das, was so ein Data Contact mir schon sagen kann, zu verstehen. Und dann ist er dir auch nur best guess, weil du weißt halt nicht, was kommt. Ja, vielleicht, dass der große Spike im November kommt.

Sven: Das weißt du erst, wenn der November da ist. Und ja, sehr schön, sehr schön.

Simon: Vielleicht die Motivation, warum die Datenqualität so wichtig ist. Data scientists sind ja sehr teuer, die haben häufig einen Doktortitel, die werden sehr teuer eingestellt und sollten ja eigentlich ihr Wissen einsetzen, also da Machine Learning Modelle aufbauen, explorative Analysen machen.

Simon: In der Realität sind 80% ihrer Zeit sind sie mit Data Cleaning beschäftigt. Also die Datenqualität passt nicht und sie müssen sie sauber machen. Manches können sie selber tun. Und trotzdem 80% ist auch viel zu viel. Die sollen lieber 80% Modelle trainieren. Weil das ist ihre Kompetenz, keine Kompetenz. Aber es ist eine andere Geschichte. Und jetzt ist die Sache, sie können manche Sachen, kannst du als Konsument korrigieren.

Sven: Ja.

Simon: Manche Sachen kannst du aber nicht als Konsument korrigieren. Die kannst du nur als Produzent korrigieren. Oder wenn du so eine Kette stellst, als Kette vor. Ganz am Ende ist der Data Scientist, der das Modell trainiert oder der die Analyse macht. Und ganz links sozusagen ist das operative System. Und was wir eigentlich wollen, ist ein Shift Left in der Qualität der Daten. Also wir wollen möglichst früh in diesem Prozess möglichst hohe Datenqualität erreichen.

Sven: Hm. Nein.

Simon: Und deswegen wollen wir eigentlich auch schon, dass das Team, das ein operatives System hat und dann ihre Daten ja schon anbietet, für Datenqualität sagt. Und dazu müssen sie Datenqualität ja auch definieren und überprüfen können. Das ist die Motivation, warum das so wichtig ist. Und warum wir dann einen großen Benefit haben in den Firmen, wenn wir frühzeitig die Qualität der Daten erhöhen. Weil ich kann sie dann eigentlich oft nur erhöhen, indem ich dann das operative System besser mache. Oder da

Simon: die Datenfassung besser tue. Das ist sehr ergiebig der Kunde an Geschichten.

Sven: Ja, das kann ich gut nachvollziehen. Wir hatten bei einem, also der gleiche Kunde, wo die Testaccounts so schiefgelaufen sind. Genau. Da war, da war zum Beispiel auch, also ich habe mich ziemlich viel um so Service Levels gekümmert. Da muss man sagen, so Service Level, so Verfügbarkeit, Performance, okay. Da haben wir Erfahrung.

Sven: Das machen wir halt einfach so, sozusagen. Da gibt es genügend Literatur, Tools, wie auch immer dazu. Was ich ganz interessant gefunden habe, waren Service Levels für Data Scientists. Weil das war im Grunde genommen genau die ähnliche Kerbe, wie du gesagt hast. Sie haben halt gesagt, naja, also unser Service Level war Freshness of Data. Die Daten dürfen nicht älter als X sein und

Simon: Mhm. Mhm.

Sven: Und dann ist halt, ja und so nach dem Motto, wieso ist das wichtig? Naja, also genau aus den Gründen. Also die Leute arbeiten halt da drauf, die müssen sich drauf verlassen, weil die, wir arbeiten halt mit den, mit den Ergebnissen. Da werden, also das war so das große Ziel, ich weiß nicht, ob es so wirklich funktioniert, aber auf Basis dessen werden halt Entscheidungen getroffen und wenn

Simon: Vielen Dank für’s Zuschauen.

Sven: Ja, wenn du dich nicht darauf verlassen kannst, dass die Daten immer aktuell sind, dann kannst du ja auch schließlich so Trends ablesen und das war schon im Prinzip dein Argument. Also da sind Leute, die kosten einen Haufen Geld und die sollen einfach wertvolle, ich sag mal, Entscheidungsvorlagen treffen. Also ich weiß nicht, ob Entscheidungsvorlage das richtige Wort dafür ist, aber

Sven: Und ich soll nicht die ganze Zeit darüber brüten, ob so Scheiße, die Daten sind schon wieder Mist.

Simon: Genau, ich glaube, Service-Level ist ein super Stichwort, weil das ist auch noch ein Element vom Data-Contract. Es gibt eine kleine Überschneidung zu den Data-Quality-Themen. Genau, aber sowas wie Freshness, wie aktuell sind die Daten, ist hochrelevant. Aber auch sowas wie Latency, wenn du überlegst, es macht Schnipp,

Simon: Jemand bestellt was im Online-Shop. Wie lange dauert es, bis ich in den Daten, die du mir da anbietest, auf der Datenplattform diese Bestellung sehe? Erst dann kann ich sie ja weiterverarbeiten. Erst dann kann ich sie für meine Machine Learning Use Case, was auch immer, weiter benutzen. Wie lange dauert es denn im schlimmsten Fall? Und dann wird es relevant,

Sven: Hmm. Hmm.

Simon: Auch noch anzugeben, ja, wie befüllst du das dann? Ist das eher so ein reguläres Befüllen, also Batchverfahren, einmal am Tag? Oder wird das einfach durchgestreamt? Und das hat ja dann Auswirkungen auf die Garantien, die ich machen kann für so ein Latency. Wenn ich das nur einmal am Tag mache, dann habe ich ja mindestens 24 Stunden Latency. Im schlimmsten Fall, weil ich sozusagen, die Bestellung kommt genau nahe, nachdem mein Job durchgelaufen ist. Dann dauert es wieder 24 Stunden, bis ich das dann sehe. Plus die Laufzeit des Jobs.

Simon: Und das ist ja für mich wichtig, weil nur dann kann ich vielleicht dann mit den Daten nichts anfangen, weil sie für meinen Anwendungsfall überhaupt nicht genügen. Und das möchte ich eben auch mit codieren und manches kann ich dann auch automatisiert prüfen.

Simon: Ich kann automatisiert prüfen, ist diese Latency irgendwo gebrochen? Das kann ich prüfen. Ich kann immer den Fehler prüfen oder rausfinden, ob es irgendwo nicht stimmt. Ich kann nicht prüfen, ob es wirklich gilt. Das ist das Problem mit den Tests. Ich kann Fehler finden. Ich kann rausfinden, wenn ich eine Violation habe. Anderer Aspekt ist noch Data Retention. Wie lange gehen die Daten denn zurück?

Simon: Das ist ja auch relevant. Also ich meine, was ist die Zeitspanne, auf die ich da zugreifen kann? Ist das nur einfach ganz aktuell, letzten 24 Stunden und dann wird es gedroppt? Dafür ist die Auflösung groß oder gehe ich halt auf zehn Jahre zurück und nach zehn Jahren wird es aber gecuttet, weil auch Bewahrungsfrist ist dann vorbei.

Sven: Ja, okay. Ja, also ich muss gerade noch mal dran denken, so

Simon: Also das sind so relevante Daten auch für die Konsumenten und das spannende ist, wenn dir der Contract ergibt, dir das halt vor als Konstrukt, als Template zum Ausfüllen und dann denkst du da halt dran und dann führst du das als Anbieter aus und gibst damit dein Versprechen ab.

Sven: Bei Monitoring-Daten ist das ja auch so, aber dann interessiert, also wenn du die analysieren willst, dann ist ja, also Data Retention ist ja dann auch immer so eine Sache. Wie lange hast du alle Daten? Wann werden die zusammen aggregiert? Wann kannst du nicht mehr drauf zugreifen? Und ja, man muss sich jetzt sozusagen immer mühsam zusammensuchen.

Simon: Hm?

Sven: Wenn man denn überhaupt dran denkt, ich glaube, dann ist noch mal so ein Punkt, ja. Also wenn du so einen Data Contract anbietest, dann musst du dir nichts zusammensuchen und du musst auch an nichts denken, weil es ist halt alles an einer Stelle. Also ich gucke einfach drauf und da ist alles beschrieben. Gut, gibt es sonst noch was zu Datenqualität zu sagen?

Simon: Ich glaube, das Spannende ist, wenn ich das erfasst habe, dann kann ich das ja prüfen. Also ich kann ja gucken, wenn dann Daten irgendwo liegen, ob das jetzt ein Kafka-Topic ist, kann ich prüfen mit den Nachrichten in Kafka. Ich kann es über eine Google BigQuery-Tabelle oder Dateien auf einem S3-Speicher. Kann ich ja dann hergehen und schaue mir den Contract an, gehe den durch und schaue, ob die Daten, die dort liegen, dem Contract genügen.

Simon: Und das ist eben, wo der große Vorteil ankommt. Und da gibt es eben Werkzeuge. Wir haben so ein Open Source Werkzeug, das Data Contract CLI, das das kann. Und da kann man genau diesen Contract dann lesen und diese Überprüfung durchführen. Dann kriege ich ein Prüfprotokoll am Ende raus. Und das kann ich ja kontinuierlich tun. Dann habe ich ein Monitoring aufgesetzt. Oder ich tue es während der Entwicklung. Dann kann ich in der

Simon: Ich meine, dass die ICD-Pipeline eben abbrechen, wenn ich merke, in der Entwicklung habe ich irgendwie Fehler gemacht oder das passt gerade nicht mit meinen Testdaten zum Beispiel. Genau.

Sven: Ja, interessant. Also die Data Contract CLI ist, ja, ist halt einfach ein, ist ein Tool, dem gebe ich als, also beidseitig, also ich als Bereitsteller der Schnittsteller, aber auch als Konsument kann es nutzen. Und,

Sven: Und ja, da braucht, das braucht wahrscheinlich auch noch Zugangsdaten. Aber dann kann ich sozusagen kann ich auch consumer-driven-contract-testing sozusagen machen, wenn ich okay. Ja. Hm.

Simon: Genau, das wäre so der nächste Schritt, dass du als Konsument das auch ausführst und vielleicht sogar noch erweiterst, dass du weitere Qualitätserwartungen, also das eine sind ja Garantien des Anbieters, der Anbieter ja der Daten überwachen möchte und deine Erwartung als Konsument könntest du dann ja auch eintragen und dann überwachen, wenn du sagst, ich habe aber weitere Einschränkungen.

Sven: Dann hätten wir aber zwei, ne? Also der… Ja.

Simon: Dann hätte man zwei. Aber würde es erst mal gehen, spricht erst mal nichts dagegen. Natürlich wäre es gut, wenn die erfüllt werden und die so wichtig sind, dann sollte man die als Konsument eigentlich den Produzenten mitgeben und sagen, bitte pack die mal da mit rein und biete die auch wirklich mit an für andere. Das wäre dann eigentlich der Zyklus. Ja, genau.

Sven: Ja, könnt mal sozusagen hier für euer Backlog, wenn ihr noch Zeit habt, da ist es. Ja.

Simon: oder einfach Merge-Request stellen. Mit hier dieser Qualitätscheck, der geht auch. Haben wir herausgefunden und für uns ist das gut. Oder eben der geht nicht. Hier bitte der Merge-Request ist dann sozusagen der Auftakt des Feature-Requests. Genau.

Sven: Okay, wir würden vielleicht noch mal ganz fix, ich würde gleich noch mal auf Tools zurückkommen, wie Data Contract CLI oder auch Data Contract Manager, vielleicht noch mal ganz fix abschließen, die Elemente. Du hattest ja schon mal angesprochen, Datenmodell wird auch erklärt.

Simon: Genau da vielleicht noch, das ist, ich kann im Datenmodell beliebige weitere Informationen mit anreichern. Also ich kann sowas wie eine Datenklassifikation, sind das jetzt geheime Daten, interne sensible Daten oder vielleicht sogar einfach öffentliche Daten, das kann ich eben auch pro Spalte eigentlich mitgeben.

Simon: Ich kann dort auch hinterlegen, ob das personenbezogene Daten sind, vielleicht gibt es auch mal Daten, die health, also gesundheitsrelevante Daten, die haben auch noch mal eine andere Schutzklasse. Also solche Daten, solche Informationen, was auch immer, jeder Kunde ist da ein bisschen anders, hat da vielleicht noch weitere Requirements. Das kann ich alles in dieses Datenmodell packen. Alles, was hilft, diese Spalten besser zu beschreiben.

Sven: Ja, ja.

Simon: Tug pack ich da mit rein. Weil dann kann ich als Konsument ja dieses Datenmodell lesen und sehen, ah, das hat ja hier diese Zusatzinformation und dann kann ich das besser verstehen, was das ist oder was ich tun muss, was für Bedingungen mit Nachsicht zieht, wenn ich diese Daten nutzen möchte. Hoffentlich auch eine gute Beschreibung.

Sven: Also mehr als nur Name der Spalte und Datentyp.

Sven: Der nächste Punkt, den ich hier aufgeschrieben habe, sind Definitionen. Da kann ich mich gar nicht mehr so genau dran erinnern. Was wären Definitionen?

Simon: Definitionen sind wiederverwendbare oder sind so Business-Definitionen, Business-Glossar könnte man sagen oder zum Beispiel definiere ich eine Bestellnummer einmal, also das Team, das eine Bestellnummer, da wo die entsteht, der gehört ja die Definition einer Bestellnummer. Was das ist, wie die beschrieben ist, welches Format die hat, vielleicht welche Schutzklasse sie hat. Ist es eine PR1-Formation oder nicht?

Simon: Und die können diese Definition anbieten. Und dann können andere in anderen Data Contracts diese Definition einfach weiter benutzen. Und sagen, diese Spalte entspricht dieser Definition. Und dann sind sie fertig mit der Beschreibung. Und dann wird alles aus dieser anderen Definition gezogen. Und gerade so eine Bestellnummer in einem Onlineshop, die taucht überall auf. Und dann ist es besser, man beschreibt die einmal, anstatt dass alle sie unterschiedlich beschreiben müssen.

Sven: Genau, ja.

Simon: Also sie werden ja immer unterschiedlich beschrieben, wenn das nicht einheitlich regelt. Es ist aber auch okay, wenn eine Firma mehrere Bestellnummern hat, also verschiedene Arten, vielleicht sind es auch verschiedene Kontexte, dann ist es auch wieder fein. Dann gibt es halt einmal den Bestellnummer im Kontext Einkauf, den Bestellnummer im Kontext Verkauf. Das sind ja komplett unterschiedliche Kontexte und darüber könnte man es dann auch unterscheiden.

Sven: Letzter Punkt dazu, das ist einfach Beispiele.

Simon: Genau, ich glaube, was sehr spannend ist, ist, dass ich als Konsument, um die Daten zu verstehen, bin ich ganz schön auf Beispiele angewiesen. Und nicht nur ein Beispiel, also es ist nicht so, dass ich ein Beispiel habe, wie dieses Datumsformat ausschaut konkret oder was wir im operativen Bereich haben, sondern ich brauche ja ein Gefühl, was in der Spalte steht.

Simon: Nicht, was in der Zeile steht. Eigentlich möchte ich ein Gefühl haben, was in der Spalte dann für mich zu erwarten ist. Und was da vielleicht für Variationen vorkommen. Oder am liebsten hätte ich auch ein Beispiel für den gesamten Datensatz, dass ich ein Gefühl bekomme, wie kann ich dann damit weiterarbeiten? Weil meine Weiterarbeit ist ja auf den gesamten Datensatz und nicht einfach nur auf ein einzelnes Beispiel. Und das ist so ein kleiner Shift, sag ich mal,

Simon: wenn man so erst der API aus der Open API Welt kommt. Da hat man ganz wenig Beispiele und dann maximal ein Element. Und das war’s dann. Ja.

Sven: Immerhin, ja, also hilft schon mal weiter, aber mehr Beispiele sind natürlich besser.

Sven: Okay, wunderbar. Also ich weiß jetzt auf jeden Fall ziemlich viel über Data Contracts und die Zuhörer hoffentlich auch. Wir hatten die Data Contract CLI angesprochen als Tool, das uns einfach hilft bei der Verifikation, entweder für Konsumenten oder Produzenten.

Sven: Aber es gibt ja auch noch, damit würde ich noch enden wollen, es gibt noch den Data Contracts Manager. Was macht der?

Simon: Genau, also das Data Contract CLI ist ja open source, mit mittlerweile auch ein paar hundert, über 400 GitHub-Stars und echt vielen Contributions. Also das ist richtig cool, was da entsteht und wie die Leute das weitertreiben und nutzen. Da sind wir auch ein bisschen stolz drauf. Das ist echt toll. Und der Data Contract Manager hingegen, das ist unser SaaS Offering, das ist ein Produkt, das INNOQ.

Simon: entwickelt hat, dass wir bereitstellen, dass wir anbieten. Da haben wir auch schon echt ein paar sehr namenhafte Kunden, ich leider nicht nennen darf, aber sehr große Konzerne aus Logistik und Pharma und so weiter. Also total spannend. Und darum geht es, da geht es halt darum, ich brauche also einen Ort, wo ich diese Contracts hinterlegen kann. Und diese Contracts bilden dann praktisch

Simon: den Kern eines Marktplatzes von Daten. Weil der Contract ist ja eigentlich alles, was ich meine Angebotsbeschreibung sozusagen meines Datenangebotes. Und das ist ja eigentlich die Produktdetailseite in dem Marktplatz oder im Online-Shop. Und dann kann ich darüber Zugriff beantragen. Der Eigentümer der Daten kann dann über den Approval Workflow das genehmigen und

Simon: Dann kann ich auch hinten raus automatisieren, dass dann noch echte, echten Zugriffsrechte erteilt werden. Und die Integration mit dem CLI-Tool ist so, dass das CLI-Tool ja die Prüfung machen kann, ob ein Contract zu den Daten passt. Oder ob die Daten zu dem Contract fassen, vielleicht eher so rum. Und das Prüfergebnis kann ich wiederum an den Data Contract Manager schicken. Dann sehe ich das im Marktplatz direkt neben meinem Contract sehe ich, ah, Prüfprotokoll, Haken dran, ist gut, kann ich vertrauen.

Simon: Und dann kann ich eben sagen, okay, wenn ich dem vertraue, dann kann ich auch Zugriff beantragen, dann kann ich mit gutem Gewissens mir da Request for Access klicken. Kriegen wir hin.

Sven: Nice, okay. Coole Sache. Ich brauche eine Demo.

Sven: Gut, also ich bin auf jeden Fall mit der Hälfte meiner Fragen durch. Ich weiß nicht, wie wir das machen. Wir müssen vielleicht irgendwann nochmal uns treffen. Ja, auf jeden Fall vielen, vielen Dank. Das war ziemlich insightful für mich.

Sven: Also meine Hauptmotivation war ja, also ich bin irgendwie so getriggert worden, diesen Podcast zu machen, weil ich bei einem Kunden war und die haben, die haben sozusagen als. Als. Unternehmens Mantra, also haben die so viele, die haben so viele Unternehmens Prinzipien, vielleicht ist er besser und eins von denen ist halt sozusagen. So wie damals in Holland, die haben gesagt, der Data ist ein New Oil, aber so ähnlich. Ja.

Sven: Und da habe ich gedacht, okay, irgendwie passt … Also, so wie die das machen, das macht für mich jetzt irgendwie Sinn, aber der Simon:, der hat mir damals beim INNOQ-Event beim Frühstück irgendetwas ganz anderes erzählt. Und da muss ich auf jeden Fall mehr wissen, wie man das geschickter anstellen kann. Mit Daten unternehmensweit teilen und analysieren.

Simon: Vielen Dank.

Sven: Daher auf jeden Fall vielen Dank für die ganzen Infos und vielen Dank an die Zuhörer, die bis hierhin durchgehalten haben und bis bald. Macht noch.

Simon: Ich glaube, bevor wir aufhören, mache ich noch eine kleine Prophezeiung. Und zwar, ich glaube, wenn wir uns anschauen, wie Swagger, Swagger kam so vor 11, 14 Jahren. Ich glaube, 2011, glaube ich, kam Swagger 1.0 raus. So um die Zeit. Und wenn wir gucken, wie sich das durchgesetzt hat, und das ist jetzt mit OpenAPI eigentlich überall.

Simon: Und jetzt ist gerade der Moment, wo Data Contracts angegangen sind. Swagger 1.0-Moment, aber jetzt mit Data Contracts. Und ich glaube, dass die Data Contracts genauso ubiquitär werden in der Datenwelt, wie jetzt OpenAPI in der operativen Welt. Und ich denke, es wird viel schneller gehen als in OpenAPI, weil der Druck viel größer ist.

Simon: Das ist meine Prophezeiung für die Zukunft. Also Data Contracts werden wir auch ganz viel davon hören. Ich glaube, die werden die Welt mit Sturm erobern in dieser Datenwelt, weil sie gebraucht werden.

Sven: Also ich meine, dass sie gebraucht werden oder ich sag mal, sie sind halt sehr sinnvoll. Also wenn ich so an meine Vergangenheit denke, naja, damit

Sven: Du arbeitest einfach viel besser, viel schneller, viel alles. Ich hätte auch gesagt, du sagst, der Druck ist so hoch, aber natürlich gibt es ja auch Referenzen. Also du hast Open API, du hast Async API. Die Leute sind auch schon dran gewöhnt. Jetzt kommt halt was Neues für Daten hinzu. Deswegen hätte ich auch aus dem Grund gedacht. Die Adaption geht schneller.

Simon: Man könnte auch sagen, dass die natürliche Fortsetzung, wenn man aus der operativen Welt kommt, dass das jetzt da auch kommt. Für die Welt der Daten ist das ganz schön revolutionär. Weil man es einfach nicht gemacht hat. Es ist ein bisschen wie das Einführen von klaren Schnittstellenspezifikationen, klaren APIs. Klaren Data APIs sozusagen.

Sven: Ja, also wenn wir gerade da sind, ich wollte ja Schluss machen, aber so eine Minute haben wir noch. Nicht der Kunde, den ich eben die ganze Zeit erwähnt hatte, ein anderer. Die hatten ein großes Problem mit Datenqualität.

Simon: Eigentlich nicht. Okay.

Sven: Und da haben wir gesagt, wir wollen Service Levels einführen. Da haben wir uns so unterschiedliche Datenqualitäten angeguckt, die problematisch sind und mit denen wir anfangen wollen, das zu sichern.

Sven: Und jetzt, dann habe ich mir so ein Buch von Google gekauft, also das habe ich eigentlich schon vorher gehabt. Ich muss das kaufen, ich habe es schon vorher gehabt. Da ging es um, also eigentlich um Service Level Objectives. Also, aber eigentlich eher, also hauptsächlich 80 Prozent von dem Buch sind ganz normal, Performance, Zuverlässigkeit. Und dann gab es halt ein Kapitel Service Level Objectives für Daten.

Simon: Gut.

Sven: Und meine Güte war das dünn.

Sven: Und ja, hier könnte man vielleicht das probieren, aber das ist eigentlich auch nicht so ganz klar. Und da könnte man das probieren. Und das ist auch nicht so dolle. Da habe ich mir gedacht, uff, also in der Datenwelt so Service Levels für Daten zu monitoren. Das kam mir schon, da musste ich ein bisschen schlucken.

Simon: Nö.

Sven: Aber ich höre jetzt auch raus, mit Data Contracts kann man natürlich schon ein bisschen, kann man zumindest mal in der Analytics Welt ein bisschen was tun. Die Frage ist halt wieder in der transaktionalen Welt, wie man da das noch machen kann. Wie siehst du das? Also gibt es da auch Bewegungen im Markt?

Simon: Die Welten wachsen zusammen. Also schauen wir uns zum Beispiel einen Kafka an. Wenn ich jetzt einen Kafka-Topic bereitsteige, ist das eigentlich das Kafka-Topic selber eher in der operativen Welt. Sag ich mal zu Hause, ich muss ganz schnell weiterverarbeiten. Jetzt wird Kafka in nächster Zeit so einen Zusatzfeature anbieten. Das heißt, du kannst auf die Daten eines Kafka-Topics auch einfach per SQL zugreifen.

Simon: über mittels Iceberg, das ist die Technologie drunter. Also die machen praktisch die, intern kann man es vereinfacht sagen, die speichern die als zwei Weisen ab, einmal im Topic und in Dateien. Und über Iceberg kann ich auf diese Dateien mit SQL zugreifen, wie mit ganz normal, wie du es in einer Datenbank tun kannst.

Simon: Und dann hast du ja beides. Dann kannst du ja Datenqualitätschecks auf diesen Daten machen und es ist eigentlich das Gleiche, es sind einfach nur zwei Zugriffsarten. Das ist vielleicht eine Möglichkeit, um solche Themen immer näher zu, weiter zu kombinieren. Genau, das ist einfach, das ist was, was wir halt sehen, dieser Trend zum Zusammenwachsen.

Sven:: Okay. Extrem, ja.

Simon: Vielleicht kommt das auch für die REST APIs, dass man sagt, ein REST Endpunkt, der einfach nur GET macht, den konnte ich ja auch mit einem Data Contract absichern. Der gibt mir halt paginated alle Daten zurück. Aber kann ich ja auch über alle Daten eigentlich iterieren. Ist halt nur umständlich. Aber konzeptionell würde das ja genauso dort gehen. Was wir vielleicht auch allgemein sehen, ist eben der Need für

Simon: Governance, also dass ich auch in meinen operativen Systemen halt sehr klar definiere, welche Felder haben denn welche Schutzklasse. Was sind personenbezogene Daten, das kommt ja auch immer mehr und dass ich dann auch Daten löschen muss und solche Themen. Und das habe ich auch noch nicht so oft gesehen, dass das dann an den Rest APIs

Simon: mit annotiert wird. Also ich denke, da sehen wir dann auch noch, dass in der Open-API-Spec definiert wird, diese Spalte ist ein PII-relevantes Feld. Ich glaube, dass wir da auch noch Innovation erleben, weil das muss ja auch passieren, wenn ich dann in der operativen Welt weiter arbeite und das dann vielleicht bei mir wieder speichere, dann muss ich das ja auch berücksichtigen. Also ich glaube, dass wir, dass wir darüber sagen, auf die Daten in der operativen Welt auch noch mal ein bisschen genauer schauen.

Sven: Ja, das hört sich auf jeden Fall nach einer logischen Evolution an. Okay, jetzt aber.

Simon: Ja, jetzt sag ich auch nichts mehr. Jetzt ist gut. Ciao.

Sven: Ich bedanke mich nochmal bei dir und bei den Zuhörern und hoffentlich bis zum nächsten Mal. Ciao, ciao!