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