Geek: Das ist Teil 1 von 2. Gemeinsam mit Daniel Kocot und Florian Rademacher spreche
Geek: ich über Daten als Produkt.
Geek: Ihr hört Ein Geek kommt selten allein, den Podcast rund um Digitalisierung.
Geek: Hallo und herzlich willkommen zu Ein Geek kommt selten allein,
Geek: Nein, dem Podcast mit Geeks, für Geeks und alle, die es werden wollen.
Geek: Mein Name ist Stephan und alle zwei Wochen spreche ich hier gemeinsam mit meinen
Geek: Gästen über ein ausgewähltes Thema im Bereich der Digitalisierung.
Geek: Mal wird es eher technisch, mal eher organisatorisch.
Geek: Ich mache eine Bestandsaufnahme, wo uns die letzten 40 Jahre Digitalisierung
Geek: in Deutschland hingebracht haben und wie es von hier aus weitergehen kann.
Daniel: In dieser Folge spricht der Geek mit. Hallo Stephan, mein Name ist Daniel Kocot,
Daniel: ich bin Head of API Consulting bei der codecentric und beschäftige mich in Kundenprojekten, bei Kunden,
Daniel: mit Daten und auch mit APIs natürlich. Das ist so das, was ich den ganzen Tag tue.
Florian: Hallo Stephan, hallo Daniel. Vielen Dank nochmal für die Einladung.
Florian: Ich bin erst das zweite Mal hier, freue mich sehr.
Florian: Mein Name ist Florian Rademacher, bin seit November Consultant bei der codecentric,
Florian: habe mich vorher viel in der Wissenschaft getummelt und habe mich im Rahmen
Florian: meiner Dissertation mit Microservices und Architekturmodellierung beschäftigt.
Florian: Domain Driven Design spielt auch mit da rein und tue jetzt ähnliche Dinge bei
Florian: der codecentric, beschäftige mich aber ebenso wie Daniel auch beim Kunden mit Daten.
Geek: Das Thema Ja, wir hatten ja alle schon zusammen das Vergnügen.
Geek: Freut mich, dass ihr es nochmal geschafft habt.
Geek: Heute ist eine etwas besondere Folge, weil erstens haben wir ein halbes Jahr geschafft.
Geek: Also der Geek hat ein halbes Jahr lang mit unterschiedlichen Leuten sprechen dürfen.
Florian: Glückwunsch.
Geek: Und andere mit euch. Vielen Dank.
Daniel: Sehr schön.
Geek: Und es wird immer wärmer, das merken wir heute auch. Hier sind ungefähr 98 Grad
Geek: in diesem wunderbaren Aufnahmestudio heute.
Geek: Deswegen machen wir Sommerpause. Das ist die letzte Folge vor der großen Sause,
Geek: vor der Sommerpause. Da müssen wir natürlich über ein Thema sprechen,
Geek: was ein bisschen besonders ist und eigentlich das Thema, was in allem drinsteckt.
Geek: Wir sprechen immer über EDV-Themen, elektronische Datenverarbeitung,
Geek: sprich wir sind mittendrin in dem ganzen Thema, also Daten stecken zwischen dem E und dem V,
Geek: also reden wir über Daten und nicht einfach nur so über Daten,
Geek: sondern speziell über das ganze Thema Daten als Produktverarbeitung.
Geek: Daniel, wir hatten es ja auch schon mal geschafft. Im Januar,
Geek: in der ersten Folge dieses ganzen Podcasts, haben wir darüber gesprochen,
Geek: was wollen wir gerne mehr sehen in diesem Jahr, was wollen wir gerne weniger
Geek: sehen, die Tops und Flops.
Geek: Und ich erinnere mich an einen der Tops, da hattest du gesagt,
Geek: Data Contracts sind für dich das Kernthema.
Geek: Vielleicht kannst du kurz nochmal was sagen zu Data Contracts und ob sich dieser
Geek: Top-Wunsch erfüllt hat, wie sich 2024 bislang mit Data Contracts entwickelt hat.
Daniel: Data Contracts sind im Endeffekt eine Art von Beschreibung, wie wir sie auch
Daniel: von Schnittstellen schon kennen, um einen Datenkontrakt zwischen zwei Parteien
Daniel: zu beschreiben, was bekommt derjenige und was liefert der andere auf der anderen Seite.
Daniel: Und was so passiert ist, ist, dass wir merken, dass es in Projekten halt mehr
Daniel: wird, dass die Kunden auch drüber reden wollen und dass man auch ganz klar sieht,
Daniel: man spricht über Datenprodukte, also Daten als Produkt.
Daniel: Das heißt, da gibt es dann auch entsprechende Beschreibungen und es tritt eigentlich
Daniel: das ein, was wir schon so gesehen im Januar, worüber wir gesprochen haben,
Daniel: was wir halt mehr sehen wollen, dass es passiert.
Geek: Wenn wir mehr Data Contracts haben, haben wir denn auch mehr Daten als Produkt?
Geek: Also hattest du gerade so im Nebensatz gesagt.
Daniel: Es hält sich so ein bisschen die Waage, weil es halt unterschiedliche Spezifikationsarten gibt.
Daniel: Die einen reden halt dann von der Datenprodukt-Spezifikation,
Daniel: die anderen reden von Datenkontakt-Spezifikation.
Daniel: Und es hält sich so ein bisschen die Waage, weil die Sicht, man sieht es auch
Daniel: aktuell in der Literatur, halt unterschiedlich ist.
Daniel: Entweder fange ich mit Datenkontrakten an, entwickle mich von dort aus zu Datenprodukten
Daniel: oder ich starte wirklich mit Datenprodukten und entwickle daraus Datenkontakte.
Daniel: Da gibt es halt kein Schwarz-Weiß gerade.
Daniel: Es ist beides irgendwie da und am Ende ist es eine Beschreibung von dem,
Daniel: was wir ausliefern wollen und erhalten wollen.
Geek: Wenn wir über Ausliefern und Erhalten sprechen, wir erinnern uns,
Geek: zurück im Mai hatten wir über Microservices gesprochen, Florian.
Geek: Und Microservices machen ja im Grunde genommen auch nichts anderes,
Geek: als die schieben Daten von einem zum nächsten Service und sagen, mach was anderes damit.
Geek: Ist das dann schon ein Datenprodukt? Also basieren Microservices auf Datenprodukten
Geek: oder wie würdest du das kategorisieren?
Florian: Typische Beraterantwort, it depends.
Geek: Auch das hatten wir schon.
Florian: Ich glaube, die Frage lässt sich pauschal so nicht beantworten.
Florian: Microservices sind ja erstmal nur ein Ansatz, wie ich meine Architektur schneiden kann.
Florian: Da hatten wir im Mai auch drüber gesprochen, dass es so diesen monolithischen
Florian: Trend im Moment gibt, dass ich halt meinen Monolithen vernünftiger und besser strukturiere.
Florian: Und das ist letztendlich, natürlich will ich immer irgendeine Funktionalität
Florian: meines Systems abbilden. Und wenn ich jetzt ein Datenprodukt an der Stelle abbilden
Florian: möchte, könnte ich das natürlich auch mit Microservices tun.
Florian: Letztendlich ist es aber nur eine Art der Realisierung des Ganzen.
Florian: Wir werden ja wahrscheinlich nachher noch über Data Mesh sprechen.
Florian: Data Mesh und Microservices haben so ein bisschen eine Gemeinsamkeit im Bereich Domain Driven Design.
Florian: Zumindest findet man viele Konzepte in beiden Ansätzen wieder.
Florian: Und darüber ergibt sich schon irgendwo eine Gemeinsamkeit.
Florian: Allerdings stellt sich auch die Frage, ist ein Data Mesh denn ein Datenprodukt?
Florian: Also die Frage könnte man sicherlich auch stellen.
Florian: Für mich ist es ein Ansatz, wie ich so ein Datenprodukt realisiere,
Florian: wie ich es anbieten kann vor allem.
Florian: Da kommen auch die Data Contracts ins Spiel, aber ich kann es nicht gleichsetzen, nein.
Geek: Nein. Ich versuche die Dinge irgendwie anfassbar zu machen und den Hubschrauber
Geek: langsam runtersteigen zu lassen.
Geek: Wenn wir über die Datenprodukte sprechen, reden wir ganz oft auch über Infrastrukturen.
Geek: Also wenn wir über eine Data Mesh beispielsweise sprechen oder über die Microservices,
Geek: die Infrastrukturen, die Dinge hin und her schieben.
Geek: Aber wir bleiben, glaube ich, erstmal nochmal bei dem ganzen Thema des Payloads,
Geek: also der Daten, der Produkte.
Geek: Warum will man das eigentlich und warum ist es eigentlich schwierig?
Geek: Ich habe letztens einen Report gelesen, da ging es darum, wie viele der Fortune
Geek: 1000 Unternehmen sind eigentlich in der Lage, Daten wirklich als Business Asset zu begreifen.
Geek: Und der Spruch, den ich wirklich schrecklich finde, deswegen wiederhole ich
Geek: das immer wieder, dieses Daten sind das neue Gold des 21.
Geek: Jahrhunderts, das niemand mehr sagen soll. Und ich sage es immer wieder,
Geek: deswegen ist das eigentlich schizophren.
Geek: Aber dieser Satz, der kommt ja immer wieder und trotzdem, obwohl dieser Satz
Geek: jetzt seit Jahren immer wieder mantraartig gebetet wird, haben Leute es noch
Geek: nicht so richtig geschafft, den heiligen Gral des Umgangs, des richtigen Umgangs mit Daten zu finden.
Geek: Was macht es eigentlich so schwierig, sich dem ganzen Thema zu nähern aus eurer Sicht?
Daniel: Ich glaube einfach, du hast so diese traditionellen Herausforderungen.
Daniel: Also wir haben ja jahrelang, seitdem ich mich damit einfach beschäftige,
Daniel: seit den 2010ern, es ist im Endeffekt ja immer Master Data Management.
Daniel: Das riesige Buzzword, was auch immer irgendwie durchschwingt so. Ja.
Daniel: Mit 2025, 2024 und irgendwie ist das auch noch nicht gelöst,
Daniel: weil das ist so diese Datenproduktdenke geht ja auch da so ein bisschen rein,
Daniel: dieses Silo irgendwie aufzulösen, weil es halt immer noch nicht gelöst ist.
Daniel: Man hat halt zwar irgendwelche Systeme angeschafft und versucht über diese Systeme
Daniel: Sachen halt zu lösen, aber im Prinzip ist halt immer noch für viele der heilige Gral zu gucken,
Daniel: was ist denn jetzt Master Data Management oder was heißt das überhaupt auf meine
Daniel: Daten bezogen, weil ich sie gar nicht so fassen kann.
Daniel: Die liegen halt im SAP und dann denkt man schon so, oh ja, das Thema ist jetzt
Daniel: abgeschlossen, aber eigentlich ist es gar nicht greifbar, weil ich gar nicht
Daniel: weiß, was teile ich da eigentlich mit Menschen oder beziehungsweise was habe
Daniel: ich überhaupt in meiner Unternehmung oder meiner Organisation für Datenstrukturen eigentlich vorhanden.
Daniel: Das ist das, was ich jetzt gerade mal so sehe.
Geek: Was heißt das für dich, Master Data Management, wie würdest du das griffig machen,
Geek: damit man es kommunizieren kann?
Daniel: Im Deutschen reden wir ja von Stammdaten. Also was ist Teil von meiner Organisation,
Daniel: von meiner Unternehmung? Was sind meine Stammdaten?
Daniel: Kundendaten, Produktdaten und so weiter und so fort.
Daniel: Orderinformation, all das, was irgendwie, je nachdem in welchem Kontext man
Daniel: unterwegs ist, dann wirklich zum Datenstamm der Organisation einfach gehört.
Daniel: Das ist für mich so dieses ganze Masterdata an der Stelle.
Florian: Das sehe ich auf jeden Fall auch beim Kunden, dass das auch ein Problem ist,
Florian: gerade auch, weil die Unternehmen teilweise überhaupt gar nicht wissen,
Florian: was für Daten liegen überhaupt vor und vor allem auch, auf was für Daten haben
Florian: wir eigentlich Zugriff.
Florian: Also ich habe ja nicht nur Daten irgendwo auf meinem SAP-System in meinem Unternehmen
Florian: liegen, sondern ich kann ja auch sehr viele Daten von außen beziehen.
Florian: Das tun Unternehmen natürlich auch.
Florian: Da stellen sich dann aber zum Beispiel so Fragen, wie gut ist die Qualität dieser Daten?
Florian: Muss ich die noch irgendwie nachbearbeiten? Kann ich die Qualität über einen
Florian: langen Zeitraum sicherstellen?
Florian: Das sind alles so Dinge, über die machen sich Unternehmen, habe ich so das Gefühl,
Florian: in der Regel nicht so oft explizit Gedanken, sondern das ist eher so ein implizites Ding.
Florian: Wir wollen jetzt irgendeine Funktionalität umsetzen, dafür brauchen wir Daten.
Florian: Dann guckt man das erste Mal wirklich auf die Daten und stellt fest,
Florian: okay, da haben wir jetzt irgendwie die letzten fünf Jahre nur Müll bekommen.
Florian: Hätten wir eigentlich anders verarbeiten müssen, müssen wir uns mal jetzt ein
Florian: bisschen auseinandersetzen, dann wird da was gebaut und dann lässt man das Thema wieder liegen.
Florian: Deswegen ist für mich so ein bisschen Daten sind das neue Öl,
Florian: das mag sein, aber ich glaube, es wird von vielen Unternehmen,
Florian: gerade auch von kleineren Unternehmen noch gar nicht so betrachtet,
Florian: weil man da auch gar nicht die Denkweise, gar nicht die Zeitung,
Florian: gar nicht den Invest sieht im Moment. Ich würde noch ergänzen wollen.
Florian: Thema Stammdaten ist ein Ding. Also ich habe irgendwie das Konzept Kunde ist
Florian: immer so ein schönes Beispiel.
Florian: Je nachdem, mit wem ich da rede oder Umsatz ist auch sowas. Je nachdem,
Florian: mit was für einer Abteilung ich rede, kriege ich verschiedene Definitionen ein und desselben Datums.
Florian: Aber Transaktionsdaten sind auch eine heiße Nummer, gerade in dem Sinne,
Florian: was für eine Frequenz kommen die an, auch wieder welche Qualität haben,
Florian: die sind die vollständig, muss ich nachbearbeiten, welche KPIs kann ich draus
Florian: berechnen, all diese Dinge müsste man sich eigentlich mal Gedanken zu machen.
Florian: Vielen Unternehmen habe ich das Gefühl, sie fühlen den Schmerz,
Florian: aber ihnen fehlt im Moment einfach noch die Zeit, da mal aufzuräumen.
Florian: Und da kommen wir auch bei den Produktgedanken hin.
Florian: Ich muss ja erstmal in Produkten denken und ich muss mich auf diese Denkweise einstellen.
Florian: Und das schließt auch wieder so ein bisschen den Kreis zu Microservice und dem
Florian: ganzen Kram, was wir hatten, eine Teamstruktur, Organisationsstrukturen.
Florian: Das hängt alles mit da drin und das ist schon ein riesen Invest und das macht
Florian: man nicht mal eben so nebenbei.
Geek: Mir gefällt besonders der Teil zu sagen, man muss explizit werden.
Geek: Also man macht vieles davon implizit. Und ich hatte diese Woche noch einen Workshop,
Geek: wo der lustige Satz gefallen ist, wenn unsere Abteilung wüsste,
Geek: was unsere Abteilung weiß.
Geek: Also gerade wenn du mehr als eine Person hast und du hast personengebundenes
Geek: Wissen oder personengebundene Daten, dann haben jeweils diese einzelnen Personen
Geek: diese Daten und wissen Bescheid, aber sie tun sich ein bisschen schwer, das mitzuteilen.
Geek: Und somit sind wir eigentlich relativ schnell bei Datenmanagement,
Geek: aus meiner Perspektive immer bei Wissensmanagement, also immer bei Dingen, die wir weitergeben.
Geek: Und ich versuche immer, dieses Daten als Öl umzudeuten in eigentlich sind Daten
Geek: der Treibstoff für Entscheidungen.
Geek: Und heute in jedem normalen Unternehmen werden schon Entscheidungen getroffen.
Geek: Kein Unternehmen trifft keine Entscheidung. Die machen ja was.
Geek: Bestelle ich jetzt mehr von diesem Rohmaterial?
Geek: Erhöhe ich meinen Preis? Stelle ich eine neue Hilfe in irgendeinem Bereich ein?
Geek: All diese Dinge passieren.
Geek: Die Frage ist jetzt, wie wie transparent sind mir eigentlich meine Entscheidungsgrundlagen?
Geek: Mache ich es aus dem Bauch heraus? Also bin ich so ein Oldschool-Unternehmer,
Geek: der sagt, das kann ich alles selber schütteln?
Geek: Oder bin ich jemand, der sehr Zahlen, Daten, Fakten getrieben ist und sagt,
Geek: ich gucke mir mal die Umsatzzahlen des Marktes im letzten Jahr an und erst dann
Geek: entscheide ich, ob ich ein neues Produkt auf den Markt bringen möchte?
Geek: Und da gibt es ja verschiedene, von Cowboy bis hin zu Hyperanalytiker gibt es alle Möglichkeiten.
Geek: Und in dem Bereich fehlt mir ganz oft das Mindset bei Unternehmen,
Geek: wie du auch gesagt hast, Florian, in der Abteilung weiß man nicht unbedingt, was man an Daten hat.
Geek: Und da kommt aus meiner Sicht diese Bewegung her, die wir vor ein paar Jahren
Geek: zum Glück ja verlassen haben, dass man gerne mal so ein paar Data Scientists
Geek: losgelassen hat und gesagt hat, ich habe hier einen großen Haufen Daten,
Geek: früher im Data Warehouse, dann im Data Lakehouse irgendwann.
Geek: Geht doch mal da durch und findet doch mal raus, was davon eigentlich wertvoll ist.
Geek: Post hum, also nachdem die Daten erhoben wurden, wo natürlich auch viele,
Geek: viele Probleme existieren.
Geek: Habt ihr solche Erfahrungen auch gemacht? Dieses als Data Scientist hier ist
Geek: ein Haufen Daten, viel Erfolg. Find doch mal was Spannendes für uns da drin.
Florian: Ja, tatsächlich habe ich das in letzter Zeit so ein bisschen mitbekommen,
Florian: dass genau das passiert.
Florian: Also da hat man jemanden für diese Position eingestellt.
Florian: Macht aus meiner Sicht auch total Sinn.
Florian: Aber dann ist immer so die Frage, auf was für einem Stand arbeitet diese Person dann?
Florian: Also was ist ihr Auftrag? Und an der Stelle, worüber ich jetzt rede,
Florian: befindet man sich gerade so auf so einer Transformation von implizit hin zu
Florian: explizit, hat also schon einen gewissen Datenbestand, weiß auch so ein bisschen,
Florian: wie dieser Datenbestand aussieht, entdeckt aber jeden Tag immer wieder neue Dinge,
Florian: auch gerade im Umgang mit SAP, weil wir das schon genannt hatten.
Florian: So und jetzt ist die Frage, wo setze ich diese Person jetzt ein?
Florian: Also ist sie Teil der Transformation oder sage ich, bitte schau dir doch mal
Florian: an, was wir noch so für Daten haben und versuch mal rauszufinden,
Florian: was wir Spannendes damit tun können.
Florian: Ich finde, das hängt auch ein bisschen mit der Unternehmensgröße zusammen tatsächlich.
Florian: Wenn ich in einem sehr großen Unternehmen unterwegs bin und sage und stelle
Florian: jetzt irgendwie zwei Data Scientists ein oder meinetwegen auch ein Team von
Florian: fünf Personen und sage, findet das mal raus und hier sind unsere Datentöpfe,
Florian: dann sind die wahrscheinlich erstmal ziemlich lange damit beschäftigt,
Florian: überhaupt sich diese Datentöpfe anzuschauen.
Florian: Wenn ich vielleicht ein bisschen kleiner unterwegs, ist es vielleicht ein bisschen einfacher.
Florian: Aber insgesamt halte ich es nicht für zielführend, wenn man diese Leute einfach
Florian: auf so einen Datensatz schmeißt oder Datentopf oder Datenschatz schmeißt und
Florian: sagt, seht mal zu und bitte auch so, dass das zu unserem Business passt. hast.
Florian: Das halte ich für schwierig tatsächlich und das ist eigentlich in meinen Augen
Florian: auch nicht diese Datenproduktdenke, sondern das ist halt, wie du schon gesagt
Florian: hast, so eine Oldschool-Bewegung eigentlich, wie man es früher gemacht hat und
Florian: wie man es in meinen Augen heute vielleicht besser nicht mehr tun sollte.
Geek: Im Grunde findest du da ja nur Dinge raus, die du mit statistischen Mitteln
Geek: irgendwie rausfinden kannst.
Geek: Also du kannst ein bisschen Ski-Quadrat machen oder gucken, korreliert da gerade
Geek: irgendetwas nett miteinander, kann ich da was Sinnvolles machen?
Geek: Und da sind wir beim Thema Ownership und Verstehen der Daten.
Geek: Und auch das kennen wir aus der Data Warehouse-Bewegung ja. Da gibt es immer
Geek: ein Team, das ist dedizit für alle Daten verantwortlich.
Geek: Bei den Data-Scientisten in diesem Fall haben wir ein ähnliches Problem.
Geek: Du schickst mehr oder weniger fachfremde oder abteilungsfremde Menschen da rein,
Geek: um abteilungsmäßig Daten auszuwerten. Kann das Erfolg haben?
Daniel: Ich würde sagen, nein. Wir haben es ja auch schon in Projekten gesehen.
Daniel: Für mich ist das ja immer so eine Historienbetrachtung.
Daniel: Es sind Daten irgendwie da und dann hat man die gespeichert.
Daniel: Wir hatten auch letztes Jahr so einen Workshop mit einem kleinen nachgelagerten
Daniel: Projekt ja auch gemacht mit einem Kunden, wo es ja ähnlich war.
Daniel: Also wo wir einfach gesehen haben, okay, das ist eigentlich eine Historienbetrachtung,
Daniel: die wir machen, um irgendwie zu verstehen, was ist über die Zeit passiert.
Daniel: Und wenn ich in der Produktdenke unterwegs bin, will ich ja auch aktuelle Daten
Daniel: halt einfach viel, viel schneller spiegeln können und zur Verfügung stellen
Daniel: können und sagen können, okay, das ist jetzt gerade das Aktuelle, was ich da habe.
Daniel: Und das bekommst du jetzt, wenn du genau dieses Datenprodukt,
Daniel: was ich dir baue, sozusagen benutzt, ja in Benutzung bringst und sozusagen für
Daniel: deine Analysen oder für dein Doing weiterverwendest.
Daniel: Und diese Betrachtung Data Scientist und gewisses Tooling so ein bisschen auf
Daniel: der Datenbank rumtun, ist halt immer, wie gesagt,
Daniel: so ein Blick in die Vergangenheit und zu überlegen, okay, ist das,
Daniel: was wir da an Daten vielleicht haben, immer noch so das, wo wir irgendwie eine
Daniel: Annahme, diese Predictions oder was auch immer auch für die Zukunft treffen können.
Daniel: Aber nicht wirklich aktuell, dass ich was durchschieße und sage,
Daniel: okay, ich brauche dafür diese Produktdenke, weil, wie Stephan,
Daniel: du hast es schon gesagt, Ownership und solche Geschichten sind ja da einfach entscheidend.
Daniel: Wer ist für dieses Produkt verantwortlich oder wer übernimmt die Verantwortung,
Daniel: dass das dann auch entsprechend stimmig ist von der Qualität und so weiter und so fort.
Geek: Ownership ist das eine, das andere, wie ist eigentlich die Darreichungsform?
Geek: Also in welcher Form kommen Daten eigentlich zu mir?
Daniel: Genau, so der nächste Punkt. Was liefere ich da eigentlich aus?
Daniel: Ist es das, was jemand erwartet?
Daniel: Und das ist ja das, worum ich Anfang des Jahres gedacht habe,
Daniel: dass diese Datenkontrakte oder Data Contracts halt, glaube ich,
Daniel: ein riesiges Ding nach vorne sind, weil klar definiert ist, was bekomme ich?
Daniel: Und ist es auch wirklich das, was ich angefordert habe? Ja, dass es sichtbarer
Daniel: wird und nicht, ich hätte gerne das und das und, naja, schmeiß mir das mal rüber,
Daniel: Darreichungsform ist nicht geklärt.
Daniel: Dann kommt das in der CSV-Datei, alle gucken sich ganz groß an,
Daniel: denken sich so, das halte ich eigentlich gar nicht, hätte das jetzt irgendwie anders erwartet.
Daniel: Und ich glaube, da hat man dann einfach über diese Produktdenke ganz klar definiert,
Daniel: was kommt denn da raus und in welcher Form kommt es überhaupt zu mir.
Daniel: Und das ist das, was ich da halt einfach so auch sehe.
Florian: Ja, es ist wieder so dieses alte Thema der Informatik, Schnittstellen denken.
Florian: Also wenn ich klar definierte, gute Schnittstellen habe, so schwer es auch ist,
Florian: da hinzukommen, aber wenn ich sie denn einmal habe, dann ist es eben gut, dass ich sie habe.
Florian: Und das gilt eigentlich an dieser Stelle auch. Oh, ich hätte noch zwei Punkte vielleicht.
Florian: Einmal zu dem, was du gerade sagtest mit, dann hole ich mir einen Data Scientist,
Florian: der macht so ein paar statistische Verfahren und dann fallen da Zahlen raus.
Florian: Das ist ja so, aber wenn ich jetzt natürlich eine schlechte Datenbasis habe,
Florian: dann fallen da Zahlen raus, die vielleicht nicht unbedingt die Aussagekraft
Florian: haben, die ich mir davon versprechen würde.
Florian: Und die andere Geschichte ist, es ist so ein bisschen, hat man da manchmal an
Florian: der Stelle das Gefühl, wie in den alten Tagen der Informatik auch wieder,
Florian: wo man gesagt hat, ja, wir haben jetzt Software, die müssen wir entwickeln,
Florian: also legen wir einfach mal los und gucken mal, was passiert.
Florian: Und über die Zeit, gutes altes Wasserfallmodell, schauen wir mal und hoffen
Florian: wir mal, dass wir da ankommen, wo wir am Anfang hinwollten.
Florian: Und das ist auch so ein bisschen das, was ich da sehe.
Florian: Dass man jemanden diesen Prozess reinwirft und sagt, wir bauen jetzt mal ein
Florian: Datenprodukt und dann gucken wir mal, was da am Ende rausfällt und dann stellt
Florian: man fest, ach, ist doch nicht so toll, weil es irgendwie blöd,
Florian: Datenprodukte bringen uns nichts, also verwerfen wir das Thema wieder.
Florian: Für mich ist es eigentlich eher, dass man wirklich am Anfang schaut,
Florian: welche Daten habe ich überhaupt so gut es geht katalogisiert auf eine vernünftige,
Florian: einheitliche Art und Weise und sich dann Gedanken macht, was kann ich eigentlich damit tun.
Florian: Das kostet natürlich Zeit, aber ist in meinen Augen immer noch zielführender,
Florian: als wenn man sagt, ja, schließt sich jetzt mal diesen Prozess an,
Florian: wir bauen da so ein Datenprodukt und dann gucken wir mal, was am Ende rausfällt.
Florian: Wir wissen aber gar nicht, wie gut sind unsere Daten eigentlich.
Florian: Also statistische Verfahren sagen vielleicht, die sind super toll,
Florian: aber sind sie vielleicht gar nicht, weil ich die falschen Verfahren angewendet
Florian: habe. Das ist ja auch immer so eine Frage an der Stelle.
Geek: Ich frage mich immer, ob wir auf der falschen Ebene beginnen.
Geek: Weil wir reden immer sehr viel über Daten und Unternehmen wollen was mit Daten
Geek: machen. Und dann gibt es Data-Scientisten und so weiter.
Geek: Aber das ist ja nicht der eigentliche Wert. Also der Wert steckt,
Geek: ich hatte es vorher schon angedeutet, eigentlich in der Entscheidung.
Geek: Und in der Entscheidungsqualität und in dem, was ich dann damit mache.
Geek: Und KI wird das Ganze jetzt nochmal hart beschleunigen und auch verstecken.
Geek: Weil es wird nicht erzählen, welche Daten es herangezogen hat,
Geek: um Entscheidungen zu treffen.
Geek: Wie, kauf jetzt neue Weihnachtsmänner für dein Lager ein. Nein,
Geek: das wird es einfach nicht offenlegen oder es wird schwierig sein, das rauszufinden.
Geek: Und deswegen wäre es vielleicht, ich habe auch über Data Catalogs und so weiter,
Geek: die ja immer wieder rumschwirren, stelle ich mir die Frage, ob man nicht eigentlich
Geek: eher Data Product Catalogs haben müsste.
Geek: Also was ist eigentlich das mehrwertbeinhaltende Produkt, was du gibst,
Geek: um eine Entscheidung zu treffen?
Geek: Und ob das jetzt eine Excel-Liste ist, ob es eine CSV-Datei ist,
Geek: ob es vielleicht die E-Mail ist vom Lieferanten, da steht sein Preis drin,
Geek: den er für die Weihnachtsmänner veranschlagt.
Geek: Das sind ja alles erstmal Daten. Und jetzt könnte ich hergehen und sagen,
Geek: ich strukturiere die alle, packe die in Data Ware aus, schaffe mir eine SQL-Tabelle
Geek: an und dann kann ich die auch sehr strukturiert ein- und ausspielen.
Geek: So funktioniert die Welt aber nicht. Also jetzt alles zu normalisieren und sagen,
Geek: ich will alles aber in meine strukturierte Denkweise bekommen, geht nicht.
Geek: Und vielleicht muss man sich dem nähern und nicht sagen, das sind die kleinsten
Geek: Bausteine, sondern das sind die Funktionen, die ich erfüllen möchte.
Geek: Ich möchte Preise von Lieferanten bekommen, ich möchte Compliance-Informationen
Geek: haben, ich möchte Adressdaten von Kunden haben.
Geek: All diese Dinge sind in anderen Formen. Und ich glaube, das Data Warehouse Team
Geek: hat uns irgendwann mal eingebläut, wir müssten mal alles über einen Kamm scheren
Geek: und es muss alles genau gleich funktionieren.
Geek: Und dieses eine Team aggregiert dann alle Daten auf. Mit derselben Technologie,
Geek: mit denselben Schnittstellen, weil total viele Synergien und so.
Geek: Damit verlierst du aber ja ganz viel. Und da gibt es ja im Moment Bewegungen,
Geek: die ja auch so ein bisschen sagen, diese uralten Gedanken, die hinter dem Data
Geek: Warehouse standen, die...
Geek: Sind überholungsbedürftig 2024?
Florian: Ist für mich eine Frage des Anwendungsfalls. Also auch Data Warehouses haben
Florian: ja nach wie vor ihre Berechtigung.
Florian: Viele Leute haben die auch eingeführt und betreiben sie auch bis heute und sehen
Florian: auch keinen Grund darin, das abzulösen.
Florian: Das ist so ein bisschen wie mit, warum sollte ich meinen Monolithen in Microservices
Florian: zerlegen, wenn das Ding ja gut funktioniert?
Florian: Das ist so ein bisschen das Gefühl, das ich da habe. Also diese Konzepte muss
Florian: man nicht unbedingt verwerfen.
Florian: Das Schöne bei den Datenprodukten, was die mir bieten, auch wieder jetzt in
Florian: Analogie zu Microservices, ist es eben,
Florian: oder ein wenig Moduliten, also dass man irgendwie sagt,
Florian: wie du schon gesagt hast, ich habe diese Funktion, die Funktion will ich umsetzen
Florian: und jetzt habe ich, denke ich, in Datenprodukten und ob jetzt hinter diesem
Florian: einen Datenprodukt, das ich jetzt vielleicht neu aufsetze, mein altes,
Florian: in Anführungszeichen, Data Warehouse steckt oder irgendwas, was anderes,
Florian: weil ich vielleicht Streaming-Technologien oder irgendwas, was modernes,
Florian: in Anführungszeichen, einsetzen will, kann mir ja in dem Moment egal sein,
Florian: wenn ich meine Data Contracts und meine Schnittstellen vernünftig definiert habe.
Florian: Also was dann dahinter steckt, ist eigentlich wurscht.
Florian: Und ich finde, es spricht jetzt nichts dagegen, auch weiterhin Warehouses zu betreiben.
Florian: Wenn man damit klarkommt, wenn sie Sinn machen und wenn sie mich in meiner täglichen
Florian: Arbeit nicht behindern, warum nicht?
Geek: Ich, dann will ich das ein bisschen verfeinern, weil ich wollte gar nicht bashen
Geek: gegen Data Warehouses. Das ist gar nicht meine Idee.
Geek: Ich glaube, was wir haben, wenn wir Unternehmen zu Daten getriebenen Unternehmen.
Geek: Umbauen wollen, offensichtlich haben wir eine Transformation oder einen Change.
Geek: Also wir müssen halt das Bewusstsein von Leuten ändern. Und wir haben ein Bewusstseinsgefälle.
Geek: Die Leute, die mit Data Warehouses arbeiten, die heute schon Dashboards bauen,
Geek: Business Intelligence Reports machen
Geek: und dergleichen, denen ist das mit strukturierten Daten alles schon klar.
Geek: Dann haben wir aber einen ganz großen anderen Bereich im Unternehmen,
Geek: denen ist das noch gar nicht klar, dass Daten ein Ownership haben,
Geek: dass Datenqualität sich runterbricht in, sind sie vollständig,
Geek: sind sie rechtzeitig da? Also was heißt Qualität überhaupt zum Beispiel?
Geek: Und ganz viel auf der runtergebrochenen Ebene erfordert eine Datenliterarität,
Geek: dass du also mit Daten dich ausdrücken kannst, dass du Daten verstehst,
Geek: was einfach im breiten Unternehmen gar nicht vorhanden ist.
Geek: Und deswegen glaube ich, dass Data Warehouses eigentlich Leute überfordern.
Geek: Also es ist halt wirklich der Maschinenraum der Daten.
Geek: Und das zu übersetzen in, ich habe sie anwendbar und ich kann sie in Kontexte
Geek: einbinden, das fällt den Leuten schwer.
Geek: Und wenn du keine Blaupausen hast, welche Entscheidung beantworte ich mit welchen Daten?
Geek: Die einfachste Antwort ist, du baust im DWH-Team oder im BI-Team,
Geek: baust du einen Dashboard und einen Report für ein bestimmtes Thema.
Geek: Dann können die da drauf gucken und können sehen, Umsatzzahlen mittlerer Westen,
Geek: im letzten Monat, Quartal und so weiter.
Geek: Und damit tun sie dann was. Aber das ist ja schon eine Aggregationsform.
Geek: Das ist ja schon eine In-Kontext-Setzung.
Geek: Und ich glaube, wir müssten eher dahin gucken, in welchen Kontexten existieren
Geek: Daten denn? Und was will ich damit tun?
Geek: Und klar musst du es dann wieder runterbrechen und klein machen.
Geek: Und dann ist es irgendwann wieder in einem Data Warehouse Lake, whatever.
Geek: Aber um viele Leute mitzunehmen, musst du es nicht erstmal auf eine informatische
Geek: Weise zerlegen und sagen, wir machen die kleinsten Bestandteile raus und jetzt
Geek: brauchst du aber Kompetenz, um sie zusammenzusetzen, sondern man muss den Leuten
Geek: mehr so Handreichungen geben, Rezepte.
Geek: Und da gibt es ja jetzt auch, speziell du sprachst es gerade schon an,
Geek: mit Data Mesh ja auch Bestrebungen, die so ein bisschen dahin gehen,
Geek: dass man sagt, es gibt nicht dieses eine Team, sondern es wird so ein bisschen vorgedacht.
Daniel: Genau, das ist ja so ein bisschen konzeptionelles Denken. Also Mesh ist ja so
Daniel: ein fast schon Buzzword irgendwie.
Daniel: Also wir haben es in der Infrastruktur, wir haben es jetzt bei den Daten, irgendwie ist es Mesh.
Daniel: Und wenn man da so ein bisschen genauer drauf guckt, ist der Mesh ja eigentlich
Daniel: nichts anderes, also auch von meinem Verständnis her, als zu sagen,
Daniel: okay, ich habe hier diese Datenprodukte, die ganz viel Technologie eigentlich beinhalten.
Daniel: Also all das, was wir irgendwie im Kontext, Kontext, ob wir jetzt Microservices
Daniel: entwickeln oder was wir auch immer tun.
Daniel: Bei APIs sage ich das immer, wir machen richtige Software Engineering.
Daniel: Wir machen wirklich das, was man tun muss, um diese Schnittstelle zu entwickeln.
Daniel: Und das findet ja auch bei diesen Datenprodukten statt. Da mache ich Transformationen,
Daniel: da muss ich gucken, wie das Logging funktioniert und so weiter und so fort.
Daniel: Und im Endeffekt ist ja dieser Mesh dann nichts anderes als eine Verkettung
Daniel: dieser Datenprodukte vielleicht sogar. Das hast du ja auch gerade gesagt,
Daniel: dass sie auf einmal eine ganz andere Bedeutung kriegen.
Daniel: Dass man wirklich Produkte, also diese Produkte anbietet und nicht sagt,
Daniel: ja, hier ist dieses Dashboard, da sind folgende Sachen schon mal direkt zu sehen,
Daniel: weil Repräsentation oder wie man es auch mal nennen will,
Daniel: sondern dass man wirklich sagt, okay, es ist einfach nur dieses Datenprodukt,
Daniel: das sind die Kundendaten, wir haben uns hier drauf geeinigt,
Daniel: der Datenowner hat gesagt, das Datenprodukt Kunde besteht aus Elementen und
Daniel: die stehen einfach zur Verfügung.
Daniel: Und dann komme ich irgendwann, wenn ich das so ein bisschen durchziehe,
Daniel: wenn ich in diesen Mesh-Gedanken bin, bin ich dann auch irgendwann beim.
Daniel: Platz, Katalog, whatever, wie wir das auch immer nennen wollen.
Daniel: Weil ich brauche eine Darstellungsform an der Stelle.
Daniel: Und da müssen wir halt irgendwie, glaube ich, den Weg finden,
Daniel: weil es viel Buzzword-Bingo ist.
Daniel: Ich sehe das auch gerade bei den Kunden, bei den Großen, die wir jetzt in der Cozentric betreuen.
Daniel: Es ist wirklich viel Buzzword und viel gucken, was brauche ich denn davon überhaupt?
Daniel: Weil Mesh ist halt viel, ist ein dickes Buch.
Daniel: Da gibt es auch noch weitere neue Bücher, die sich dann mehr mit Implementierung
Daniel: beschäftigen. Wie wende ich das eigentlich an?
Daniel: Und ich glaube, man muss viel adaptieren von dem. Und es wird nicht alles unbedingt
Daniel: für Organisationen und Unternehmungen an der Stelle passen.
Geek: Dann lass uns doch mal versuchen, Datamash konkreter zu machen.
Geek: Ich hatte jetzt letztens auch ein Gespräch, wo jemand sagte,
Geek: ich habe noch nie was von Datamash gehört.
Geek: Und wir werfen das herum, als wäre das das bekannteste ever.
Geek: Was ist so die Essenz von Datamash?
Florian: So für mich ist die Essenz von Datamash, aber weil ich auch wahrscheinlich aus
Florian: dieser Perspektive so ein bisschen komme und auch da drauf schaue,
Florian: erstmal, dass ich überhaupt meine Domäne mit einbeziehe.
Florian: Also dass ich mir wirklich meine Fachdomäne anschaue und gucke,
Florian: wie ist sie strukturiert, welche Daten habe ich da an dieser Stelle wirklich
Florian: zur Verfügung und dass ich da auch wieder schon in Produkten denke und versuche,
Florian: Organisationsstrukturen zu entdecken, die ich dann dekomponiere und zu so einem
Florian: Data Mesh zusammensetze.
Florian: Also das klingt jetzt wieder sehr hochtrabend oder sehr abstrakt, aber...
Florian: Dass ich im Endeffekt versuche, viele kleine Datenprodukte zu bauen,
Florian: die kann ich vielleicht noch aneinander chainen, dass ich den Teamgedanken habe,
Florian: dass ich aber vor allem auch diesen Produktgedanken, Verantwortlichkeit,
Florian: Qualität, diese Dinge eben dekomponiere und auf kleinere Einheiten verteile,
Florian: sprich Teil- und Herrscherprinzip.
Florian: Was wir gerade auch schon hatten, Thema Dashboards. Dashboards an sich finde
Florian: ich jetzt auch nicht schlimm.
Florian: Es gibt eben Unternehmen, denen helfe ich sehr damit, wenn ich denen ein Dashboard
Florian: da hinstelle und wenn da irgendwie KPIs draufstehen, solange ich garantieren
Florian: kann, dass diese KPIs auch stimmen und eineindeutig sind.
Florian: Das sollten sie sein, aber das ist vielfach eben auch nicht der Fall.
Florian: Bei einem Data Mesh guckt man, glaube ich, weniger auf diese eigentlichen Benutzerschnittstellen,
Florian: sondern eben vielmehr auf diese Data Contracts, auf die Schnittstellen an sich.
Florian: Und da spielt dann eben auch dieses Buzzword, da sind wir gerade wieder bei
Florian: Self Service, eine große Rolle.
Florian: Das heißt, wenn ich jetzt irgendwie ein Datenprodukt brauche,
Florian: dann gehe ich an meinen Data Mesh und sage, liebes Data Mesh,
Florian: ich brauche dieses Datenprodukt.
Florian: Dann gibt es das entweder schon, dann bin ich happy, dann kann ich damit Dinge
Florian: tun, was auch immer Dinge tun bedeutet. Vielleicht flansche ich mich da mit
Florian: einem Power BI dran an und kann dann da Auswertungen fahren.
Florian: Oder aber, und das ist auch ein Gedanke von Data Mesh, dass ich so eine Art
Florian: Feature Request auch stellen kann,
Florian: sodass die Menschen, die dieses Data Mesh vielleicht da in einem Architekturteam
Florian: sitzen oder in einem Anforderungsteam oder irgendwo an der Stelle Product Owner
Florian: sind, sehen, ach guck mal, hier möchte jemand ein Datenprodukt haben,
Florian: das soll wie folgt aussehen oder er wünscht sich folgendes.
Florian: Wie können wir das bereitstellen? Bitte kümmert euch darum.
Florian: Das ist dann auch so ein Gedanke, der hinter diesem Self-Serve steht.
Florian: Ja, und wir haben eben eine verteilte Governance. Das spielt eben auch an der Stelle eine Rolle.
Florian: Das heißt, ich habe global galaktisch Dinge auf einer Ebene,
Florian: die mir die Datenqualität und Sicherheit festlegen, aber verteile deren Umsetzung
Florian: an die lokalen Domänen oder an die Teams, die in meinem Data Mesh sind.
Florian: Das ist auch das, was man übrigens auch bei Microservices sieht,
Florian: wo wir damals im Mai nicht so intensiv darüber gesprochen haben,
Florian: Aber es ist halt eben diese Verteilung von Verantwortung auf kleinere Teams,
Florian: kleinere Strukturen, Teil- und Herrscherprinzip und das mache ich bei Data Mesh letztendlich auch.
Florian: Oder sollte ich tun, wenn ich denn Datamash mache?
Geek: Ich denke, damit haben wir Datamash einigermaßen nochmal eingekreist und sind
Geek: zufällig an dem zweiten Punkt gelandet, wo die meisten Dateninitiativen starten, die ich kenne.
Geek: Also das eine ist dieses, wir lassen die Data-Scientisten durchs Data Warehouse laufen.
Geek: Der andere Punkt ist das, wo man sich bewusst ist, dass es eine Art Spielregelkatalog
Geek: geben muss, wo man mit der Governance anfängt.
Geek: Also manche Leute fangen mit konkreten Dingen an, machen Leuchtturmprojekte.
Geek: Andere Leute fangen an und sagen, Moment, erstmal regeln wir,
Geek: welche Technologien wir einsetzen, wer darf eigentlich was.
Geek: Und den Betriebsrat fragen wir auch nochmal, ob man Daten überhaupt anzeigen
Geek: darf grundsätzlich bei uns.
Florian: Dann sind zwei Jahre ins Land gegangen und nichts ist passiert. Böse gesagt.
Geek: Da gehen erstmal viele, viele Jahre ins Land oder Monate oder zumindest Wochen,
Geek: in denen konkret nichts passiert.
Geek: Und es ändert sich auch gar nichts bei den Leuten, die damit arbeiten sollen.
Geek: Weil erstmal schaffst du nur einen Rahmen für etwas, was gar nicht fassbar ist.
Geek: Also wer weiß überhaupt irgendetwas über Daten? Ich glaube, das Kernproblem
Geek: bleibt weiterhin, was du gesagt hast, Florian.
Geek: Lass uns explizit machen, welche Daten wir überhaupt kennen und was wir mit
Geek: Daten tun und welche Daten wir für bestimmte Tätigkeiten heranziehen.
Geek: Und das regelt Governance nicht. Und ich glaube, Governance ist ein Skalierungsmerkmal.
Geek: Also wenn du schon rausgefunden hast, wie du mit Daten umgehen kannst,
Geek: ist es eigentlich der Schritt danach. nach.
Geek: Und der erste Schritt, den du gehen müsstest, wäre zu sagen,
Geek: wie kann ich denn eigentlich in Daten als Produkt denken?
Geek: Und die meisten Leute, die ich kenne, sagen bei Produkt, oh,
Geek: das hat ein Preisschild, das muss man bezahlen.
Geek: Und gerade wenn ich in ein großes Unternehmen denke und da sind verschiedene
Geek: Daten, Lieferantenpreise bezahle ich nicht.
Geek: Also das sind Daten, aber die haben keinen Preis. Sind sie deswegen kein Datenprodukt?
Geek: Nee, die sind schon irgendwie ein Datenprodukt. Auch um vergleichen zu können,
Geek: habe ich im letzten Jahr dasselbe bezahlt für Schrauben und Weihnachtsmänner,
Geek: die ich da im Lager habe? Oder ist der Preis gestiegen?
Geek: Wie vergleichen sich die Lieferanten untereinander?
Geek: Schwupps, bin ich eigentlich doch in etwas Wertvollem. Aber es hat halt keinen Preis, per se.
Geek: Und dieses ganze Governance-Thema ist ein Punkt, da starten ja viele oder die
Geek: bringen das relativ früh rein.
Geek: Das ist die Frage, bringen sie es zu früh rein, Data Governance,
Geek: und müsste man nicht eigentlich ein bisschen abwarten oder ein bisschen konkrete
Geek: Erfahrungen sammeln, um dann daraus sinnvolle Governance-Themen abzuleiten?
Daniel: Wenn ich das so aus meiner Praxis betrachte, ist ja das, was zuerst passiert,
Daniel: ist ja im Endeffekt immer Datenstrategie.
Daniel: Da versucht jemand irgendwie ein Papier aufzusetzen, da steht dann großtrabend
Daniel: Datenstrategie der Unternehmung drauf, aber eigentlich weiß man auch gar nicht, was man da macht.
Daniel: Also deswegen, was wir halt auch mehr sehen.
Geek: Und es macht eine Abteilung, die die Daten gar nicht nutzt, sondern es hat meist
Geek: eine Stabstelle, die sagt, wir machen eine Strategie, die die anderen machen sollen.
Florian: Ja, viel Glück dabei.
Daniel: Ich kenne jetzt Beispiele, wo sowas funktioniert, wo man dann aber auch ganz
Daniel: schnell gucken muss, dass man von dieser Strategie-Denke ins Doing reinkommt.
Daniel: Ja, weil, was sieht man in so Enterprises?
Daniel: Seien wir ehrlich, da wird halt irgendwann mal wieder was angeschafft wie ein
Daniel: Datenkatalog, weil man irgendwie vor zwei, drei Jahren gemerkt hat oder vier,
Daniel: fünf, ja, so ein Katalog wäre schon ganz toll, dass wir mal unsere Daten irgendwie klassifizieren.
Daniel: Da hat man noch keine Idee gehabt, was man da eigentlich reinpackt,
Daniel: aber das war irgendwie hip und toll Und dann hat man das jetzt und merkt dann
Daniel: so, weil man halt auch Dinge gelesen hat oder erzählt bekommen hat über die Zeit,
Daniel: ich muss strategisch, ich muss in Strategie denken,
Daniel: ich muss irgendwie diese Produkte hineinziehen und wie du schon sagst,
Daniel: dann kommt dieses Preisschild, dann kommt auch irgendwie Thema Monetarisierung
Daniel: kommt ja dann auch hoch, also nicht nur bei Schnittstellen, sondern auch bei
Daniel: Daten sieht man das sehr häufig.
Daniel: Und dann ist es so, diesen Absprung zu schaffen und zu überlegen,
Daniel: okay, was heißt das jetzt eigentlich konkret für mich?
Daniel: Was muss ich denn in Richtung Governance machen?
Daniel: Ja, dann muss ich erstmal überlegen, okay, so das Erste, was wir jetzt bei Kunden
Daniel: gesehen haben, sind Daten irgendwie confidential? Prudential,
Daniel: ja, können wir die in der Unternehmung einfach mal wild miteinander teilen oder was braucht es dafür?
Daniel: In der Regel hat man da irgendwelche Excel-Sheets, die man ausfüllen muss und
Daniel: dann ist man froh, wenn man sieben Seiten Excel einmal durch hat und dann hat
Daniel: man schon keine Lust, das weiterzumachen. Das ist dann so bei der Schnittstelle der Teil.
Daniel: Und ich glaube, das ist so das, was jetzt sukzessive einfach kommen muss, ein Verständnis.
Daniel: Es muss irgendwas da sein. Es muss auch zentral etwas da sein,
Daniel: was sich dann wieder verteilt.
Daniel: Also man hat ja zum einen diesen Begriff dezentrale Deichenarchitektur.
Daniel: Das ist alles ganz nett, aber ich brauche ja irgendwo von oben herab eine gewisse Steuerung.
Daniel: Ob ich dann anschließend dezentral bin und das Ganze wieder mit so einem Regenschirm
Daniel: nochmal zusätzlich abdecke, weil ich dann sage, okay, Governance gilt dann aber
Daniel: für alle, ihr könnt jetzt nicht machen, was ihr wollt,
Daniel: ist dann nochmal so ein Teil, aber man muss halt irgendwie anfangen,
Daniel: ohne sich darin zu verrennen, also das heißt, relativ früh in die Praxis reingehen.
Daniel: Und wirklich, ein Kunde, mit dem ich zusammenarbeite, nennt das Into-Production,
Daniel: also wirklich in die Produktion reinbringen und nicht einfach nur sagen,
Daniel: ja, wir können da jetzt drüber reden, wir bauen hier irgendwas und am Ende ist
Daniel: das ganz toll, sondern nein, direkt rein,
Daniel: damit man das auch wirklich nutzen kann, gerade diese Geschichte mit Datenprodukten
Daniel: oder auch Datenkontrakten, um halt schon was Beschriebenes zu haben,
Daniel: was wieder einen Mehrwert generiert, den man dann irgendwo darstellt.
Florian: Und vor allem, wo ich auch mit frühzeitig experimentieren kann und Erkenntnisse
Florian: und Erfahrungen sammeln kann.
Florian: Und da sind wir auch schon wieder bei Agilität oder zumindest iterativen Vorgehensmodellen,
Florian: die sich ja auch in der Informatik etabliert haben.
Florian: Also vieles von dem, was hier jetzt bei diesem Data Mesh Thema wieder aufkommt,
Florian: finde ich persönlich ist gar nicht so super neu, sondern es wird jetzt eben
Florian: auf das Datenthema angewandt. Macht auch total Sinn.
Florian: Aber diese Geschichte mit entwickle kleine Dinge, bring sie frühzeitig in die
Florian: Produktion, hol dir Feedback ein, verbessere.
Florian: All diese Dinge kennen wir ja eigentlich schon im Software Engineering.
Florian: Jetzt kommen sie in das Data Engineering. Finde ich persönlich sehr sinnvoll und sehr gut.
Florian: Und das spielt für mich auch, wenn wir jetzt beim Thema Governance wieder sind.
Florian: Ich finde, es gibt Governance-Themen, die sind halt offensichtlich und die sollte ich früh angehen.
Florian: Wenn ich jetzt irgendwie ein Datenprodukt entwickle, das mit sicherheitskritischen
Florian: Daten umgeht, dann wäre es schon gut, wenn ich eine Governance-Vorstellung davon hätte.
Florian: Aber es gibt bestimmt auch andere Governance-Dinge, weiß ich nicht,
Florian: sowas wie wenn ich Technologie-Entscheidungen festzuholen will,
Florian: dann experimentiere ich vielleicht erstmal mit Technologien und das lege ich
Florian: dann hinterher fest, wo man dann sagt, wir benutzen jetzt die folgenden, weiß ich nicht,
Florian: Transformations-Engines oder irgendwelche ähnlichen Dinge.
Florian: Und wenn man die Erfahrung gesammelt hat, legt man das eben fest.
Florian: Aber das ist jetzt nichts, wo jetzt ein Gesetzgeber zum Beispiel dankenswerterweise
Florian: auch drauf schaut und mir auf die Finger haut und sagt, oh, ihr habt jetzt aber
Florian: die Technologie genommen, das dürft ihr aber nicht.
Florian: Das sieht bei sicherheitskritischen Themen dankenswerterweise anders aus.
Florian: Also das ist für mich auch wieder so ein.
Florian: Je früher ich damit anfangen kann, desto besser. Je früher ich Erfahrung sammeln
Florian: kann, desto besser. Und dann kann ich diese Strukturen auch auf einer höheren
Florian: Ebene verankern, wenn sie sich bewährt haben.
Florian: Das ist das, was man in der Informatik an ganz vielen Stellen ja in vielen Dingen
Florian: auch tut und auch was sich heutzutage vielfach auch bewährt hat.
Geek: Man kann es ja so leicht sagen, die Governance, aber es gibt ja eine Multitude
Geek: von Governancen, weil ich habe meine Personaldaten, die dann irgendwie mit der DSGVO einhergehen.
Geek: Dann habe ich vielleicht wettbewerbsrelevante Daten mit Umsatzzahlen.
Geek: Dann habe ich wiederum andere Daten, die ich womöglich irgendwo einkaufe,
Geek: die völlig frei sind im weitesten Sinne.
Geek: Und ich finde es sehr schwierig, dass man sagt, es gibt halt diese eine Governance,
Geek: die regelt halt, was wir mit und wie wir mit Daten umgehen können und eigentlich
Geek: hängen die auch wieder an den einzelnen Datenprodukten.
Geek: Also wenn ich jetzt zum Beispiel einen Geburtstagskalender fürs Unternehmen
Geek: machen möchte und ich weiß,
Geek: Geburtstage beziehungsweise Jahre sind tabu, das darf man eigentlich gar nicht,
Geek: weil man es nicht braucht, um seinen Job zu erledigen, darf das im Unternehmen
Geek: nicht existieren, könnte man da auch sagen, brauchen wir eine bestimmte Governance für.
Geek: Also ihr dürft vielleicht das Das Datum, aber nicht das Jahr verwenden,
Geek: weil das diskriminierend wäre. Oder sein könnte zumindest.
Geek: Dann wiederum leitest du daraus gar nichts ab für die businessrelevanten Dinge
Geek: wie Umsatz. Also die haben gar keine Relevanz.
Geek: Und das ist sehr, sehr schwierig, finde ich, dieses Governance-Thema zu nehmen.
Geek: Es zeigt aber auch, wir haben auf einmal sehr, sehr viele Stakeholder.
Geek: Also gerade wenn wir über eine gesamte Datenstrategie für ein komplettes Unternehmen
Geek: reden, haben wir nicht nur von Management bis hin zu operativer Ebene,
Geek: haben wir alle, die einmal durch den Stack durchgehen, sondern wir haben auch
Geek: eine richtig große Breite.
Geek: Und die müssen wir jetzt halt alle irgendwie mitnehmen.
Geek: Und zumindest dafür, dass wir es schaffen, verschiedene Abteilungen,
Geek: also Konsumenten und Bereitsteller, aber auch das Management,
Geek: also auch das Doing mitzunehmen, haben wir uns ja mal zusammengesetzt und haben
Geek: diese Data Product Canvas,
Geek: haben wir das ja genannt, haben wir mal ein Data Product Canvas entworfen, um zu helfen,
Geek: dass man in dieser Kommunikation strukturiert alle wichtigen Bereiche umfasst
Geek: und nichts vergisst, wenn man versucht zu kommunizieren, was bauen wir da eigentlich gerade
Geek: oder wofür wollen wir eigentlich gerade eine Governance erstellen,
Geek: dass man sagt, wo kommen meine Daten eigentlich her, Wer sind meine Lieferanten?
Geek: Was tue ich damit? Wie speichere ich die? Wem liefere ich sie aus? Über welchen Weg?
Geek: Und was machen die dann ultimativ damit? Und was kostet das vielleicht sogar noch?
Florian: Vor allem auf einer Flughöhe, wo ich nicht sofort in die Technik gehen muss
Florian: und wo ich mir noch keine Gedanken über sehr feingranulare Governance machen
Florian: muss, wo ich aber vielleicht schon sehe,
Florian: hier könnte es eventuell Probleme geben, da sollten wir mal drüber sprechen,
Florian: finde ich persönlich hilfreich, gerade auch um unterschiedliche Menschen an einen Tisch zu bringen.
Florian: Weil auf dieser Flughöhe kann immer noch jeder mit jedem reden,
Florian: weil man nicht unbedingt super Spezialwissen braucht und das dann hinterher
Florian: feiner gliedern und dann zum Beispiel in Richtung von einem Software-Design oder ähnliches gehen.
Florian: Also sorry, dass ich da unterbreche, aber ich wollte nochmal diese Flughöhe
Florian: an der Stelle betonen, auf der man sich da befindet und dass es wichtig ist,
Florian: dass ich auf so einer Flughöhe bin, damit ich unterschiedliche Menschen an einen Tisch holen kann.
Geek: Du kannst da gerne direkt weitermachen. Ich wollte nämlich fragen,
Geek: was eure Erfahrung ist. Ihr habt es ja auch schon in Kundenkontexten verwendet.
Geek: Und die Frage ist, welche Dinge macht es leichter? Wobei hilft es tatsächlich?
Geek: Weiter geht es im zweiten Teil in zwei Wochen.