Deep Dive 201 –

Data-Aware Architecture mit Matthias Niehoff

17.02.2026

// Podcast
// Deep Dive 201

Shownotes

In dieser Folge spricht Jan mit Matthias Niehoff über das Konzept der Data-Aware Architecture. Matthias, Head of Data und Principal Data Architect bei Codecentric, erklärt, dass es sich hierbei weniger um ein fest definiertes Architektur-Pattern handelt, sondern um einen Denkansatz: Daten von Anfang an in die Architekturprozesse einzubeziehen, insbesondere für analytische Zwecke, ohne dass die Entwickler:innen ihre Anwendungskomplexität unnötig erhöhen müssen. Die Methode hilft, die Nutzung von Daten strukturierter, nachvollziehbarer und verlässlicher zu gestalten, ohne interne Implementierungen unnötig zu überfrachten.

Matthias geht detailliert darauf ein, wie Data-Aware Architecture in der Praxis aussieht: von der frühzeitigen Einbindung von Analytics-Teams über die Definition von Data Contracts bis hin zu Data Products, die als Schnittstellen zwischen Entwicklung und Datenkonsumenten fungieren. Ziel ist es, stabile, dokumentierte und validierbare Datenflüsse zu schaffen, die auch bei Änderungen im System konsistent bleiben. Dabei betont er die Bedeutung pragmatischer Lösungen statt Overengineering – große Tools oder Plattformen allein lösen das Kernproblem nicht, die Organisation und die Abstimmung zwischen Teams sind entscheiden.

Besonders spannend wird es im Umgang mit Legacy-Systemen: Matthias beschreibt, wie man bestehende, oft veraltete Schnittstellen analysiert, Verantwortlichkeiten klärt und Schritt für Schritt Data Contracts implementiert - und das alles skalierbar.

Abgerundet wird die Folge durch einen Blick auf die Rolle von KI im Kontext von Data-Aware Architecture. Matthias erläutert, wie KI-gestützte Tools die Datennutzung unterstützen können, zum Beispiel durch semantisches Kontext-Engineering oder als direkte Konsumenten von Daten.

Download

/transkript/programmierbar/deep-dive-201-data-aware-architecture-mit-matthias-niehoff

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Heute wie immer für euch im Studio einmal der Jan und wir haben einen ganz besonderen Gast dabei, denn wir widmen uns heute mal wieder einem richtig technischen Thema. Das ist auch mal wieder was Schönes, wenn's mal so richtig ans Eingemachte geht und wir nicht mehr so an der Oberfläche von irgendwelchen Frameworks oder so was kratzen, sondern uns nitty grity mit den Ups und Downs von irgendwelchen Patterns beschäftigen können. Wir haben heute am Start den Matthias Niehoff. Hallo Matthias, schön, dass Du da bist.
Matthias: Hallo Jan.
Jan: Wir wollen heute sprechen über Data Awaren Architecture. Und ich muss sagen, bevor Du mir mit dem Thema über den Weg gelaufen bist, hab ich davon, zumindest mit dem Branding noch nie was gehört. Ist das 'n neueres Thema? Ist das 'n neueres Phänomen?
Matthias: Also ich würde sagen, wahrscheinlich wirst Du's auch unter diesem Thema selten hören. Und ich glaub, wenn man's googelt, gibt's nicht allzu viel, geborene ich auch dazu zu. Aber worum geht's jetzt? Es also neu ist relativ. Ich glaub, für mich war das mal son Schlagwort, alles zusammenzufassen, was so Datennutzung aus 'ner Anwendungssicht oder für analytische Nutzung ist. Und ja, irgendwie muss man dafür was tun und auch architekturmäßig was tun. Und das war so. Aber ich glaub, es ist kein wirklich feststehender Begriff, der weit versprechend ist.
Jan: Wenn man dein LinkedIn Profil aufmacht, dann schwappt einem gleich ganz viel Data ins Gesicht, denn dein offizieller Jobtitel ist Head of Data und Princeple Data Architect bei CodeCentric. Jetzt hab ich den Begriff Head of Data schon öfter gehört, aber ehrlicherweise immer mehr in Firmen, die 'n eigenes Produkt haben, die halt eben auch mit eigenen Daten irgendwie arbeiten. Was macht ein Head of Data in der Consultingbude?
Matthias: Ich glaub, da gibt's auch die Antwort, was macht ein in 1 typischen Consultingbude und was ist bei Codezentrric? Bei uns ist Ja.
Jan: Ich bin so, ich bin
Matthias: so der, würd ich sagen, wenn's Datenthemen geht, der sehr schnell angesprochen wird, der auch auch relativ viel mit Kunden drüber sitzt, redet, Workshops macht, Konzeption macht, aber auch im Projektgeschäft tatsächlich unterstützt ist. Meistens, da ist es eher diese principle Rolle, die's ja auch noch da ist. Genau, aber das ist total Vielleicht als kleiner Akten, bei denkt man häufig an, jo, ich hab eine große Abteilung unter mir, die ich verantworte oder Ähnliches. Das ist in diesem Fall Nichts
Jan: Gegenteiliges sagen, einfach den Eindruck stehen lassen. Wir glauben alle, Du hast Nee, der der eine 200 Mann Mannschaft.
Matthias: Genau, ich, also die 200 Mann Mannschaft sind alle höchstens meine KI Agenten.
Jan: Und wunderbar. Ich hab bei dir auch im LinkedIn Profil gesehen, ich bin immer, ich hab ja so was ganz Banales studiert, ja, weil ich ehrlicherweise von Studieren auch nicht viel Ahnung hatte, als ich angefangen hab damit. Und ich bin immer positiv überrascht, wenn ich Menschen treffe, die irgendwelche coolen Studiengänge haben, wo ich dachte, boah, ich wusste gar nicht, dass es so was, ich bin nicht ausgefallen, aber so was Spezifisches halt schon, ne, dass es so was irgendwie auch gab und mir das irgendwie alles gar nicht über den Weg gekommen ist damals. Du hast Information Management studiert. So. Ich hab mich von dem Managementteil nicht abschrecken lassen, aber ich bin immer noch neugierig. Was macht man da?
Matthias: Es ist ein Wirtschaftsinformatikstudium gewesen. Also am Ende klingt es dann doch wieder 'n bisschen langweiliger. Also es es war halt ein Buch.
Jan: Also doch 'n bisschen Management.
Matthias: Ja, also wie wie das ist, bei Wirtschaftsinformatik ist auch BWL dabei und VWL dabei, was ich grundsätzlich spannend finde und ich auf jeden Fall nicht missen möchte. Also mal auch einfach nur raus, nicht nur den ganz technischen Blick, sondern auch mal andere Betrachtung da drauf. Also sone Totalkurs auf Onlineshop rechnen oder auch mal 'n paar Sachen, was BWL ist zu können, hilft. Aber am Ende war's Wirtschaftsinformatik und ich, am Ende hat sich dann doch der Techi durchgesetzt. Immer wenn's was zum Wählen und Auswahlmodule gab, war's tendenziell doch das Tech Tech Modul bei mir. Genau.
Jan: Schön. Sonst wärst Du vielleicht heute nicht hier gelandet.
Matthias: Vielleicht Sonst
Jan: müsstest Du jetzt im OMR Podcast sprechen oder so was.
Matthias: Oh Gott. Da wär ich verloren, glaub ich.
Jan: Wir sind über dich und das Thema ja gestolpert, weil Du auch einen Talk eingereicht hattest bei der Defland Conference. Und ich weiß, Du musstest dir mittlerweile zurückziehen und hast gesagt, ich glaub, Terminkonflikt gab's als Komfort. Aber ich würde die Gelegenheit trotzdem einmal nutzen und fragen, wie suchst Du für dich so Konferenzen und Veranstaltungen aus? Ja, ich mein, da gibt's ja sehr viele da draußen, die freuen sich alle immer über coole Beiträge und man könnte im Prinzip jede Woche irgendwo anders unterwegs sein. Aber Zeit ist ja ein begrenztes Gut und dementsprechend würd mich einmal nur ganz kurz persönlich so interessieren, so wie wie findest Du da für dich die die wertvollen Veranstaltungen?
Matthias: Also a muss man sagen, mit meinem Fokus auf, es muss irgendwas zumindest mit Data anknüpfungsmäßig sein. Viele, viele Konferenzen, wo ich dann war, sind am Ende jetzt keine Datakonferenzen, aber haben zumindest einen, ich sag mal, Datatrack oder offen für datanahe Themen. Das reduziert tatsächlich die Auswahl der, ich sag mal, Entwicklerkonferenzen schon. Es gibt sehr viele Entwicklerkonferenzen, wo's halt wirklich Softwareentwicklung geht und wo man mit Data tendenziell son bisschen esoterisch am Rand steht. Das ist jetzt nicht so, da fühl ich, also ich fühl mich da jetzt nicht unwillkommen, aber ist jetzt nicht so, wo ich sag, da muss ich unbedingt hin. Genau, also das ist sicherlich der eine Kriterium und am andere, ich ich Leute, wo einfach relativ, wo man weiß, das ist jetzt keine Verkaufsveranstaltung, wo die Vendoren alle kommen, sondern wo sich wirklich, es muss nicht Community sein, aber es müssen sein, so Leute, die wirklich auch was tun und arbeiten und und und hands on was tun. Also die anderen arbeiten auch, will ich jetzt nicht behaupten. Aber das ist für mich 'n mich 'n Kriterium mal so. Und dann ist es für mich der Austausch. Und natürlich gibt's natürlich so 2, 3 Konferenzen, wo man einfach so seit Langem schon ist und wo man auch immer Leute kennt. Und das ist einfach auch ein jährliches schönes Netzwerken und Wiedertreffen.
Jan: Was sind so deine deine Highlight, deine Lieblingskonferenzen? Wo gehst Du gerne hin?
Matthias: Also für mich die relevantesten sind alles, was datanahe Konferenzen sind. Und das sind, ich bin seit Jahren auf der Data Today von Heise. Das ist so mein mein Ding. Dann ist relevant ist die TDWI, das ist so von der deutschen Data Warehouse BI Geschichte. Ich vermute, viele Entwickler sagen jetzt so, ah, die BI Data Warehouse kommen mir vielleicht gleich auch noch zu. Und ja, in in Databeich ist nun mal Python 'n Riesenthema Thema, also ist alles, was so Pion, Pi Datakonferenz, das sind so, würd ich sagen, in Deutschland die 3, wo ich sag, das sind für mich die wirklich Kerne. Da versuch ich auch jedes Jahr hinzukommen.
Jan: Das hör ich tatsächlich auch häufiger von den Leuten aus unserem BI Team. Grade so Pikon, PIDATA, hatten wir schon mal hier bei uns auch gehört. Okay, aber wir wollen heute, ich wollt grad sagen, nicht über Python sprechen, sondern über Data Awaren Architektur. Und Du hast ja selber schon gesagt, der Begriff ist jetzt vielleicht noch nicht so der feststehende Begriff. Deshalb einmal der Versuch, was ist so der 30 Sekunden Elevator Pitch? Wie würdest Du jemandem erklären, was Data Awaren Architecture ist?
Matthias: Also für mich ist Data Awaren Architecture der Versuch, Daten tatsächlich im Architekturprozess, wo wir uns über sehr, sehr viele Gedanken Sachen Gedanken machen, Security, alle möglichen, also und Co, wo auch einfach mal Data mit einfließen zu lassen. Und die Nutzung von Daten auch insbesondere für eine nötige Zwecke. Und das 'n bisschen anfassbar zu machen, was was sind das für Das sind so unfassbare Sachen wie wie speicher ich denn Daten, damit es überhaupt in der Analytisch sind. Was ist das für eine Storische Implementierung? Geht hin zu, wie geh ich denn mit Wie bild ich das ab, auch wenn ich Umsysteme habe? Wie bild ich diese Umsysteme auch an? Vielleicht nicht nur mit 'ner REST API- und Kafka Schnittstellen, das ist häufig gar nicht so für Massendaten so das Optimale öfters mal. Und auch so Themen wie Privacy, wie krieg ich denn Privacy rein? Analytische Datennutzung ist zwar schön und gut, aber wir haben auch noch eine DSGVO, die wir zu beachten haben. Und so was wie Dokumentation, Datenqualität, wie stell ich denn die sicher? Aber alles Sachen, die in mein Gefühl und so, ich hab 'n Softwareengineering background, wo man häufig gesagt hat, ja, das Erst mal muss die Anwendung laufen.
Jan: Das ergibt sich halt so einfach dann, ne?
Matthias: Genau. Erst mal läuft die Anwendung und dann kommt irgendjemand, wo die Datennutzung haben, das kriegen wir schon hin.
Jan: Ja. Also das son bisschen in in Textspeak zu fassen, so so Daten als First Class Citizen, so ungefähr. Den
Matthias: den Satz hab ich sicherlich auch schon Power genutzt. Würde ich sofort unterschreiben, ja.
Jan: Ja. Ich glaub, ich hab verstanden, was Du meinst, aber gefühlt ist die Ausdifferenzierung von dem 'n bisschen schwer zu greifen. Weil ich glaub schon, dass viele Leute, die das jetzt da draußen gehört haben, so deine Erklärung sagen würden, na ja, natürlich denk ich irgendwie darüber nach, wenn wir so auf der grünen Wiese anfangen und das das Projekt so grob skizzieren, natürlich denkt man darüber nach, was da für Daten anfallen und wie wir die speichern. Vielleicht kannst Du noch mal genauer erklären so, was denn so dieses in Anführungszeichen richtige drüber Nachdenken unterscheidet von dem, das Daten einfach mitzudenken.
Matthias: Genau. Also ich nehm mal das Beispiel. Also der der der ein Beispiel, ein klassischer Thema ist, man baut eine Anwendung, man natürlich macht man sich übers Topwich Gedanken, wie speichern wir's unten ab, wie man versucht sich über 'n Datenmodell Gedanken zu machen und so. Und dann kommt irgendjemand an und sagt, hey, wir bräuchten diese Daten mal für eine Auswertung. BI, Marketing, Sales, was auch immer, aber irgendwelche Daten, die Du in deiner Anwendung erhebst. Und dann fängst Du an und denkst Du, ja, also wir haben hier eine Rest API, da könntest Du rangehen. Rest API ist Einzelsatzebene. Wir haben eine Datenbank, da liegen alle drin. Ja, ich könnte 'n User auf die Datenbank geben. Wie jeder weiß schon, oh, ist nicht so richtig cool. Wir haben auch 'n Kafka Topic, da publishen wir immer die Events rein, aber wenn Du die Events hast, dann musst Du immer noch an die Rest API geben, die zusätzlichen Daten für jedes Event zu holen. Und irgendwie ist so, ja, aber ich brauch eigentlich nur einen Abzug der Daten, und zwar meinetwegen möglich täglich aktualisiert. Und zwar in dieses System, was typischerweise nicht im klassischen Data im im klassischen Software Engineering ist, das ist meistens so, da ist 'n ganz schöner Gap, da ist son Bruch drin. Das das ist das, was ich sage, hey, das von Anfang an mitzudenken, da zu überlegen, hey, wie kommen wir kriegen wir denn, wenn die Daten mal für analytische Zwecke genutzt werden? Wie kriegen wir das hin? Wie was haben wir da für Wege und Mechanismen? Was müssen wir vielleicht jetzt schon vorsehen, damit das passiert? Da ist der der das, was es versucht zu adressieren.
Jan: Und wenn ich das richtig verstanden hab, dann ist Data Awaren Architecture jetzt nicht ein Architektur Pattern, das Nein. Zu lösen, sondern ja eigentlich vielmehr ein ein ein Denkansatz oder eine Methodik. Also bei dem Namen mal da noch son bisschen drauf rumzureiten, ist vielleicht so sozusagen da da das das der bessere Begriff, weil es vielmehr den den kontinuierlichen Prozess geht, als diesen einen Zustand, den es irgendwie zu erreichen gilt.
Matthias: Es es gibt es gibt nicht die Dataware Architecture, die ist eine hexagonale Architektur.
Jan: Genau, das wär jetzt 'n Nageliger. Genau, nein, nein.
Matthias: Genau, also und fairerweise muss man sagen, Architecture ist, also am Ende ist Architecture ist ein Teil, am Ende geht's auch noch viel den Implementierungsteil und es geht auf auf der anderen Seite sehr viel Prozesse und Organisation dazu. Also ich kann meine, ich kann mir technologisch alles übernehmen, wenn die ganze Org dadrauf getrimmt ist, Feature App, App für die Features, Features, dann brauch ich mit Data Warrior Architektur auch nicht mehr viel tun. Ja, also es ist deutlich größer, aber Data Warrior Architektur ist 'n schönes Schlagwort.
Jan: Okay, dann lass uns mal ganz vorne vielleicht anfangen. Wir sind jetzt also in einem fiktiven Team, das solche anfangen. Und weil unsere Stakeholder alle große Datenfans sind, haben sie gesagt so, mach das doch mal hier Data Awaren. Wir wollen das ja alles richtig machen. Jetzt sitzen wir in unserer kleinen illustren Runde zusammen und planen dieses neue Projekt auf der grünen Wiese. Wer trägt denn jetzt hier den Data Awaren Architeure Hut und wer ist denn dafür verantwortlich?
Matthias: Also im Optimalfall ist, wer auch immer im Unternehmen analytische Datennutzung macht, das ist häufig irgendwie 'n BI Team oder ein ein Analytics Team oder was auch immer man da hat, das können von Riesenabteilung bis, jo, das ist halt der eine Werkstudent sein fairerweise, muss man sagen, ist irgendwie beteiligt, zumindest mal Anforderungen und Requirements reinzugehen. Was glauben wir denn, was Ihr baut eine Anwendung. Was glauben wir denn, was wir perspektivisch mit diesen Daten, die ihr da sammelt, die ihr irgendwie erhebt, nutzen können. Also erst mal nur 1 Schritt, diese Requirements überhaupt mal mit berücksichtigen bei der Architektur. Das ist Nummer 1. Und da hilft es massiv, eine Unterstützung zu haben auch auf Managementseite. Weil fairerweise, ich hab viele gesehen, wo das versucht wurde, die Ideen da waren, wo vielleicht Analytics auch sich bemüht hat, da möglichst früh mit reinzukommen. Und am Ende gab's das Bettblock, da standen ganz viele Items drin und irgendwo, ja, ganz unten standen dann auch son paar Sachen, die Analytics betroffen haben, ja. Also ich, das das ist der erste Teil. Son bisschen Shift left im Sinne von dem Anforderungsprozess. Genauso wie wenn Shift left heutzutage mit Security machen oder so was, was man auch nicht, wir bauen die App und am Ende machen wir sie sicher, sondern man denkt es am Anfang mit, sollte man auch Daten am Anfang bedenken. Mhm.
Jan: Jetzt sitzen da draußen vielleicht 'n paar Zuhörerinnen und denken sich so, na ja, wenn der Matthias das hier erzählt und der ist dann mit Cozentrric immer in großen Projekten drin, für die ist bestimmt alles megaentscheidend. Aber ich hier mit meiner kleinen Crad Anwendung oder so, brauch ich das überhaupt? Oder ist das hier mit Kanonen auch schwarzen geschossen? So, für wen ist das relevant oder gar kritisch und für wen vielleicht auch nicht?
Matthias: Also ich hätte jetzt gesagt, relevant für alle. Die Frage ist der Ausprägung. Also natürlich, wenn also wir haben jetzt Kunden, die halt große Enterpriseanwendungen bauen, sehr verteilte Microservices Landschaften haben, die dann irgendwie einen Verkaufsprozess oder sonst was abbilden. Und natürlich ist das für die absolut relevant, diesen ganz diese ganze Customer Journey irgendwie in Analytics zu haben und auszuwerten oder zu sehen oder in 1 Versicherung da halt Reporting drüber zu machen. Das ist da ist auch mehr Analytics Power, Analytics Kapazität hinter. Versus, ich bau eine kleine Anwendung. Und das, was sich Analytics macht, ist Google Analytics einbinden für meine Anwendung, damit ich weiß, wo die Leute hinklicken. Und ab und zu lad ich noch mal 2 2 weitere Tabellen und so in ein Data Warehouse und mach 'n SQL dadrüber. Natürlich gibt es da Unterschiede und es ist jetzt nicht so, also wir kommen vielleicht nachher noch auf son paar Konzepte zu sprechen, die man nimmt. Das ist nichts, was jetzt eine 15 Mann Softwareanwendungsentwicklung jetzt zwingen tun muss. Aber Datennutzung insgesamt mehr mitdenken ist, glaub ich, für alle relevant.
Jan: Okay. Jetzt versuchen wir also, unsere Daten mehr mitzudenken. Wie könnte sich denn das jetzt ausprägen?
Matthias: Wenn wir
Jan: jetzt so, okay, wir haben jetzt hier im Team einmal überlegt, was fallen für Daten an? Wo kommen die her? Wie könnten die aussehen? Aber was heißt das denn dann für uns konkret in der in der Implementierung?
Matthias: Sie für analytische Nutzung hingespuckt werden soll. Also da gibt's Software, ich glaub, eine der sehr, sehr Populären, die man immer wieder findet, ist Databricks. Da ist man vielleicht auch schon mal irgendwann drüber gestolpert, hat man als Entwickler so gedacht, na ja, irgendwie ist da Databricks oder Snowflake ist die andere sehr bekannte, was so die Cloud Varianten gibt. Aber am Ende sind sind's unterschiedliche Sachen, die da möglich sind. Und in der Implementierung ist dann häufig tatsächlich die Frage, okay, wie kriegen wir denn die Daten jetzt da rüber? Und tatsächlich sind die Zieltechnologien, wo's hingeht, da geht's dann so Eisen und und Slowly Changing, wo man als Entwickler erst mal denkt, bitte was? Also ich hab hier eine Lambda, da läuft Tapescript drin. Und Du würdest mir jetzt, dass ich Eisberg schreibe und die Daten in Databirgs als externer Table, weil das da, Moment. Genau und da ist, sehen wir an vielen Stellen halt einfach diesen diesen Bruch, so was wie baut man da jetzt eine sinnvolle Abstraktion hin, dass die Daten rübergehen ohne, und das ist es wichtig, dass die Entwickler jetzt auf einmal noch eine Datenplattform lernen. Weil sie müssen grad auch noch Security machen, sie müssen Fin Ops machen am besten noch, die Kosten in der Cloud Entwicklung zu halten. Dann müssen sie Dev Ops ja sowieso, machen sie alle schon. Und jetzt sollen's auch noch Data machen, vergiss es, wird nicht klappen. Genau also, da ist in der Implementierung dann die Herausforderung, die die da anstehen, rein wirklich in der Technik.
Jan: Und wie begegnet man dem, wenn die die Gefahren, die Du aufgezeigt hast, das ist ja alles irgendwie real, ja. Ich will nicht, dass meine Entwickler jetzt anfangen müssen, noch jede andere Plattform, die eigentlich das BI Team owned, irgendwie auch, noch jede andere Plattform, die eigentlich das BI Team owned, irgendwie auch mitzuverstehen und mitzudenken. Aber was was ist denn dann die Lösung? Weil am Ende hast Du ja schon recht, irgendwie müssen die Daten da ja hinkommen. Genau. Wie wie wie gelingt dieser Brückenschlag am Ende?
Matthias: Also das Erste ist, und da muss man vor allen Dingen das Data Team auch anfassen, also das ich stell das Data Team jetzt vielleicht son bisschen als immer oder die Data Analytics Leute son bisschen als die Opfer dar an. Die Entwickler denken nie an sie. Nein, nein. Also man muss auch schon 'n bisschen auf die Entwickler zugehen. Also es kann, man kann jetzt nicht sagen, hier ist Databricks, lad die Daten dahin, sondern man muss schon auch überlegen, okay, was haben die Entwickler denn fürn Tooling? Was haben sie auch für Ansprüche an Code Qualität? Überraschung, die sind meistens höher als als bei der Analyteseite. Ich ich bin auf beiden Seiten. Ich kann's
Jan: Ich hab nichts gesagt, das wohl. Ich hab zur Kenntnis. Ich kann das
Matthias: Und also was wir konkret machen ist, wir bauen, also am Ende geht's besonders bei größeren Projekten und größeren Gründen zu, dass Du Abstraktionen baust, die es den Entwicklern einfach machen, das zu tun. Das kann von Abstraktionen sein wie, Du baust 'n Du baust selbst den Loader und die Entwickler konfigurieren im Endeffekt nur noch hier diese Tabelle oder diese API musst Du auf oder so und dafür gibt's 'n d und die constrainst noch. Es ist wichtig, dass Du das Tooling der Entwickler nutzt. Wenn die brauchen nicht jetzt, wenn die jetzt noch mal 'n CICD Prozess zusätzlich machen sollen, neben dem, den sie jetzt schon haben, werden wird die Akzeptanz massiv singen. Also das das sind so so Themen. Und auf 'ner konzeptuellen Ebene gibt's noch dann die die Idee des Data products und Data Contractcts, was ganz spannend ist in dem Zusammenhang, das 'n bisschen besser zu beschreiben. Ich weiß nicht, schon mal gehört. Data Product, Data Contract
Jan: hab ich schon mal gehört, aber vielleicht für alle da draußen kannst Du's gerne noch mal erklären.
Matthias: Genau. Also am Ende ist einfach eine Beschreibung 1 1 Datenschnittstelle, würd ich sagen, wo neben dem Schema, das ist sicherlich so das das Zentrale, also welche Daten sind da drin, was ist Datentyp und Ähnliches, Auch so Sachen festgehalten werden, wie wie oft wird es denn aktualisiert, wer ist verantwortlich dafür?
Jan: Es ist im Prinzip wie 'n API Contract mit 'n bisschen mehr Workflow beschreiben. Exakt.
Matthias: Wenn wer wer jetzt sagt, hör mal, das ist doch genau das Gleiche wie 'n API Contract, der ist auf genau dem richtigen Weg unterwegs. Also ist 'n API Contract mit 'n bisschen mehr. Genau, ist auch häufig in der Jammel beschrieben. Genau, das ist jetzt auch nicht unüblich. Genau. Und son Contract beschreibt halt sone Datenschnittstelle nenn ich's mal. Und wenn man das jetzt noch bisschen weiterdeckt, neben dem Contract gibt es auch noch 'n Product, ne. Ich stelle ein Datenprodukt bereit. Und dieses Produkt sind wirklich die Daten selbst, die irgendwie in Tabellen liegen, Json Files auf 'nem Storage Account, 'n Paket File irgendwo oder 'n Kafka Topic. Das ist macht das, ist jetzt erst mal völlig egal. Aber es gibt ein Produkt, wo Daten bereitgestellt werden und ich als Entwicklerteam bin für dieses Produkt verantwortlich. Warum ist das so wichtig? Ich mache meine Anwendung in eine Änderung. Dadurch ändern sich 'n Datenformat oder es ändert sich in die Logik in den Daten. Vorher wurde das Fleck so interpretiert, jetzt aufgrund des Prozesses wird das anders interpretiert oder es wird wird in andere Form reingeschrieben. Und jetzt bin ich dafür verantwortlich, die Schnittstelle nach außen für die analytische Datennutzung auch zu verantworten. Und das ist so dieses Thema. Im Vergleich zu früher, häufig war's so, die Entwickler sagen, jo, ich hab die Daten und dann kam das kam das eine Analysetheam und hat gesagt, okay, ich hol die jetzt mal ab. Und ich hol sie zu mir für die analytischen Zwecke. Und die Entwickler haben irgendwann fröhlich weiterentwickelt, haben neue Features umgesetzt, neue Sachen gemacht. Es gab Anpassungen an der Datenbank, es gab Anpassungen an der Schnittstelle. Anders, dass das Datenteam darauf benachrichtigt werden muss, ist schnell mit Hunden hochfahren. Und so dreht man son bisschen die die Verantwortlichkeit
Jan: Ist das dann auch sone Stelle, wo sich so was wie Contract Testing anbieten würde, halt sagen, okay, wir stabilisieren halt diese Schnittstellen irgendwie, zumindest nach außen, wie das Datmodell innen aussieht, ist ja davon erst mal entkoppelt?
Matthias: Genau. Also es gibt eine Tendenz dazu, im Datenbereich Sachen, die im Softwareentwicklungsbereich waren, noch mal neu zu empfinden. Deswegen keiner spricht im Datenbereich von Contract Testing, auch wenn das
Jan: Ah, okay.
Matthias: Semantisch natürlich komplett Aber im Endeffekt, die dieses das Contract der Contract ist nicht umsonst in der Jammer definiert. Wenn eine Jammer ist schön Maschinen lesbar, es gibt Tooling, zu sagen können, hey, hier ist eine Datenbank oder Tabelle oder 'n Topic oder sonst was. Hier ist 'n Contract, matcht das. So, das zu validieren. Genau, also genau diese diese Sachen passieren. Und dieses Validieren kann man natürlich an unterschiedlichen Stellen machen. Man kann's beim CICD machen, ne. Wenn ich das jetzt, ich lass das mal testweise laufen, jetzt schmeiß ich den Contract gegen, darf ich das noch deployen? Oder man kann es auch auf Konsumentenneben in Sachen. Hey, ich konsumiere Daten und bevor ich die konsumiere, guck ich mal, ob die überhaupt noch so sind, wie ich sie erwarte. Bevor ich mir jetzt irgendwie falsche Daten reinschiebe, guck ich jetzt
Jan: Ist natürlich potenziell zu spät dann, ne?
Matthias: Also. Genau, dann sind zumindest als als Konsument hast Du zumindest mal gewonnen, dass Du dir nicht die fehlerhaften Daten reinschmeißt und jeden 12 wieder rausholen musst. Aber natürlich umso ehrlich, umso früher umso besser. Also ist die ICD, ist der erste Place, wo's passieren sollte, keine Frage.
Jan: Gibt es da, weil als Du gesagt hast, na ja, ist die ICD, dacht ich, ja, vielleicht kann man das ja sogar linden, ne, wenn man das sauber beschrieben hat, dann zu sagen, okay, wenn ich eine statische Codeanalyse mach oder Linter laufen lasse, zu sagen, okay, Du hast dir was an deinem Model verändert oder so, ne, und damit brichst Du vielleicht schon den Contract. Also vielleicht kann man sogar noch 'n Schritt früher ansetzen, ne?
Matthias: Genau, es Genau, also die die Frage ist ja einfach, wo man den Linder läuft laufen lässt, ob man den Manche Ich kenn genug Leute, die die lassen den ersten CICD laufen, manche machen's wirklich 'n bisschen früher, ne. Ich hätt's umso früher, umso besser, also. Ja. Genau, aber es gibt zum Beispiel 'n Tooling, die Data Contract SealI, die hat das grad nicht mehr, aber aus aus aus internen Gründen, aber wo man einfach sagen kann, hier ist 'n Contract, linde den mal, gibt's. Mhm. Genau, genau diese diese Validierung frühzeitig zu machen.
Jan: Und jetzt wieder auf das Wording zurückzukommen. Dataware Architecture versteh ich jetzt immer mehr so, dass es viel weniger auch die konkrete Architektur jetzt vielleicht in meinem einen Produkt geht, sondern ja auch in die Zusammenarbeit, das das ganze Ökosystem da sozusagen, ja, die Systemarchitektur. Das heißt, selbst wenn ich als Team 'n Data Awaren Architecture betreiben will und das vielleicht auch alles gut macht, heißt das ja gar nicht zwangsläufig, dass ich mich auch das alles kümmern kann, muss, darf, sondern das können ja durchaus auch zumindest technisch nachgelagerte Systeme sozusagen sein, ja? Also niemand muss da draußen jetzt quasi den großen Schreck bekommen, wenn er Data War Architecture machen will, dass er sein ganzes System auf links drehen muss. Es kann auch einfach eine bessere Integration gehen.
Matthias: Genau, am am Ende geht es darum, es geht den gesamtheitlichen Blick auf eine Anwendungslandschaft. Wie krieg ich's hin, dass der Austausch von Daten untereinander für analytische Zwecke, das ist der wichtige Teil. Natürlich jeder wird jetzt sagen, ja, aber Systeme tauschen doch jetzt schon Daten aus. Das ist doch alles kein Problem. Aber für analytische Zwecke besser funktioniert. Und analytische Zwecke meistens 'n bisschen mehr Massendaten, meistens 'n bisschen nicht nicht Real Time, häufig auch wenn viele einem einreden wollen, Du musst alles Real Time haben. Oft ist es gar nicht so real time. Das ist eigentlich viel mehr dieses Data Bay Architektur. Es ist nicht meine Anwendung ist Architektur und sich mach hexagonal oder wie Du's auch immer aktuell gestrichen hast, das widerspricht sich in keiner Frage. Mhm. Ja.
Jan: Und es gibt ja viele Pragmatiker da draußen, die, wenn sie irgendwas mit Architecture hören, schon immer direkt Angst vor Overengineering bekommen, so, ja? Was ist denn die Overengineering Ausprägung in der Data Awaren Architecture? Also wie würde das aussehen? Woran erkenn ich, dass es da jetzt jemand vielleicht übertrieben hat?
Matthias: Sehr gute Frage. Ich glaub, also ich nehm mal das Beispiel, weil Du's erst gesagt hättest, brauch ich jetzt als jedes Unternehmen einen sone Data Awaren Architecture. Ich nehm mal das Beispiel, ich bin eine ein Mann Entwickler, eine ein Team Entwicklerbude in Anführungsstrichen. Bin 6, 7 Leute, ich hab 'n ein Produkt, das ist super, das funktioniert, das ist erfolgreich, das funktioniert, ne. Und auf der anderen Seite denk ich mir jetzt, aber ich muss Data Awaren nehmen und jetzt bau ich nebenan einen riesen Data Lake auf und baue ganz viel Prozesse, die Daten darüber zu bekommen und Ähnliches. Und ich geborene richtig viel Geld aus für eine möglichst geil abstraierte Plattform, wo ich sag, weißt Du was, stell dir den Postscester nehmen und mach da 'n bisschen Analytics drauf und such dir einen vereinfachen Weg, aber einen dokumentierten, einfachen, pragmatischen Weg, die Daten darüber zu laden. Also Dataware Architecture erreicht man nicht, indem man einen der großen Produkte einen kauft. Das würde ich sagen, das ist sehr häufig diese. Ja. Son bisschen wie Databricks ist son bisschen inzwischen im Bereich so wie früher IBM war. Niemand macht was falsch, wenn eine IBM kauft.
Jan: Und dann wird gefeuert. Ja, ja, genau.
Matthias: Genau. Inzwischen ist es so, niemand wird gefeuert für, wir machen haben Databricks schon mal gekauft für Data oder Snowflake. Genau. Und damit ist ja schon mal der erste Haken gesetzt und damit haben wir auch die Datenarchitektur gelöst. Na, das glaub ich nicht. Ist jetzt nicht unbedingt overengineert, aber ja, aber eine Tendenz ist, man braucht nicht immer diese riesen Riesenthemen. Und genauso, wenn ich ein Ein Mann Team hab oder ein Team habe in meiner Software Entwicklung, vielleicht auch 2, dann brauch ich keine Contracts, dann brauch ich keine. Das kann ich machen in gewisser Art und Weise. Aber Du brauchst auch keinen Marketplace, weil das kommt nämlich das Nächste. Die Products findest Du in einem Marketplace wieder. Wenn deine deine Entwickler IT aus 10 Leuten besteht, dann brauchst Du kein Marketplace, dann können die Leute miteinander reden. Ja. Umso größer natürlich 'n Unternehmen wird, klar, umso mehr Anforderungen hast Du dann da auch vielleicht.
Jan: Mhm. Das ist alles schon in die richtige Richtung. Was ich eigentlich erwartet hätte als Antwort, ja, ist, dass Du jetzt so was sagst wie, na ja, wer jetzt anfängt, weiß ich nicht, in seiner SQL Datenbank alles nur noch in JSON Felder zu speichern, weil er da semaalas ist und quasi auf jegliche Änderungen im Datenmodell vorbereitet ist oder so, der hat's vielleicht auch irgendwie übertrieben, ja.
Matthias: Also Genau, genau. Also vor allen Dingen, eine Data oder Data oder Data sagt nichts dadrüber aus, wie Du dein Datenmodell in der Anwendung machst. Du baust das Datenmodell in der Anwendung so, dass die Anwendung vernünftig funktioniert. Und Du modellierst es so. Du solltest dir nur Gedanken darüber machen, was ist eine Schnittstelle nach außen? Hab ich vielleicht eine andere Schnittstelle als eine Rest API, wo ich Einzusetzen bekomme? Ja, also am Ende ist die die intern mach ich immer noch, das interessiert mich nicht als Analytics Mensch, wie Du das machst. Aber gib mir einen Weg, wie vernünftig, wie entweder Du mir vernünftig die Daten rüberschickst oder ich sie vernünftig von dir bekommen kann.
Jan: Das ist, glaub ich, 'n superwichtiger Punkt, ja, weil da weil ich glaube, wenn die meisten Leute jetzt, weiß nicht, die gucken auf das Podcast Cover jetzt und da steht Dataware Architektur. Und die denken dann wahrscheinlich eher an das, was Du grade eben nicht beschrieben hast, so, ne, sondern Genau. So wie bau ich das in meiner Anwendung auf? Und man sagt ja auch immer oder zumindest ist es eine von meinen Lieblingsformulierungen so, Architektur ist der Schmerz, den Du spürst, wenn Du irgendwie Änderungen in deine Software bringen willst, ja? Ja. Und in dem Fall bezieht sich das dann eben auch nur in Anführungszeichen auf den Schmerz an deinen Schnittstellen und Schnittpunkten punkten sozusagen, ja? Aber wenn Du also wenn dir intern was auf die Füße fällt, weil Du irgendwie 'n Feld oder 'n Datenmodell ändern musst, jo, dann ist das irgendwie dein Problem. Sozusagen die Schnittstelle nach außen stabil bleibt, hat das erst mal nichts mit diesem Thema hier irgendwie zu tun. Und andersrum positiver formuliert sozusagen, ja, ist gute Data Awaren Architecture nicht das, was es dir erlaubt, irgendwie alles zu speichern und sondern irgendwie Änderungen auch später einfach in diese Schnittstelle reinzubringen, ohne irgendwie was kaputtzumachen. Genau. Und wer jetzt
Matthias: sagt, alles nichts Neues, sag ich, ja, es ist auch nicht vieles Neues. Ich mach das, die gleichen Gedanken mach ich mir heutzutage, wenn ich eine Restabi desig Oder ich muss hab Breaking Change Ist
Jan: auch nur eine Ausprägung davon, so.
Matthias: Genau. Es ist auch, hab ich vielleicht auch Breaking Change. Muss ich mir auch drüber Gedanken machen, wie ich das mache. Ja, also es darum geht's nur. Aber das nach draußen geben für analytische Zwecke anders machen als die API für operative Zwecke. Ja.
Jan: Jetzt seid ihr ja als als Consultants im Prinzip immer in einem von 2 Fällen irgendwie am Start. So, der eine ist der der Greenfeed Fall, so ist, wir wollen hier was Neues aufsetzen und hier, Matthias, komm doch mal vorbei und helft uns, das hier von Anfang an ordentlich zu denken, damit's uns später nicht wehtut. Das ist ja eigentlich der angenehme Fall. So. Ja. Der der andere Fall, das ja der mindestens genauso spannende, ist ja der, wenn die Leute bei dir anrufen, Matthias, bei mir brennt's. Wir haben hier diese Anwendung, die ist 25 Jahre alt und alle 2 Tage gehen hier unsere Schnittstellen kaputt, weil sich irgendwelche Felder ändern oder fehlen, nichts funktioniert. Man kann sich auf nichts verlassen. Wir brauchen Data Oware Architecture, komm vorbei und hilf uns. So. Und das ist ja der zumindest aus dem Stand erst mal schwerere Case, so. Wie geht ihr denn da vor, wenn ihr jetzt so was habt und eigentlich schon das nicht die Katze fällt in den Wer fällt in den Brunnen? Das Kind, keine Ahnung. Also irgendjemand ist in den Brunnen gefallen. Das
Matthias: Genau, das Kind ist jetzt.
Jan: Irgendjemand, ich weiß, dass ich auf Katze gekommen bin. Anyway, irgendjemand ist in den Brunnen gefallen und jetzt steht ihr da von ihrem Salat. Und wie wie geht ihr da vor? Wo fangt ihr überhaupt an?
Matthias: Genau. Genau. Also es ist auf jeden Fall der spannendere Fall und ich kann dir sagen, die meisten kommen nicht mit, wir brauchen Dataware Architecture. Die meisten kommen eher mit, hey, unsere Analytik ist, da kannst Du echt nichts drauf geben. Das ist immer ist immer Quatsch. Die Daten stimmen nie und die sagen uns mal, heute war was anderes als morgen und außerdem alles viel zu lange. Das ist typischerweise eher das das das ist dem toben, was da kommt.
Jan: Ja, wie das wie das so ist.
Matthias: Genau. Aber die die Frage war ja, was machen wir jetzt? Der typische, meistens gucken wir uns die die Schnittstellen an. Wir gucken uns an, wie wie wie sind denn Verantwortlichkeiten geregelt? Wer ist dafür verantwortlich, dass Daten rüber geschaffen werden? Wie sind die Prozesse? Wo kommen die Quellen her? Was sind das für Quellen? Welche widerspricht sich auch? Also erst mal klassisch Bestandsaufnahme. Und zwar wirklich auf Architektur, aber auch auf Prozess- und Organisationsebene. Also auch das immer sehr, sehr wichtig. Und das meiste, was dann da rauskommt, ist erst mal 'n Sensibilisieren, auch von Management und Product Ownern, hey, das das kann man nicht mit Tech lösen, ne. Auch häufig kommt dann noch dazu, ja, wir wollen das jetzt machen und wir haben schon mal Databirgs gekauft. Ich ich bin 'n großer Databirgs Fan an sich, aber es ist halt ein Symptom. Das heißt, erst mal Bestandsaufnahme sensibilisieren, beschreiben, was sind denn die Probleme? Und häufig kriegt man's durch sehr unfassbare Beispiele hin zu zeigen, hey, die Schnittstellen sind das Thema. Und was man dann häufig macht, ist anhand von wirklich Use Cases, die das Analytics Team hat, Schritt für Schritt diese Schritt Schnittstellen aufzubrechen, explizit zu machen, managbar zu machen. Das das kann in dem ersten Schritt erst mal nur sagen, okay, wir haben klar dokumentiert, das Team hier ist dafür verantwortlich, dass die Daten bereitgestellt werden und Sie müssen halt bei Änderung auch diese Schnittstelle mit bedienen. Dann kommt man häufig dazu, dass man sagt, ja, häufig kommen dann auch aus Engineering Sicht häufig die Sache, ja, es wär irgendwie schon cool, wenn wir das automatisiert testen können, dass wir da nicht immer dran denken müssen, sondern dass wir einfach einen aufn Deckel kriegen, wenn das nicht mehr klappt. Dann kommen diese Contracts ins Spiel. Das ist son son Bottom up Ansatz tatsächlich, der dann häufig passiert. Wohingegen das Greenfield häufig so ein ist, ist, also wenn's Greenfield, ist es häufiger so, die Organisation wird entschieden, wir wollen das jetzt tun und wir wollen's dezentral tun. Das ist nämlich ja auch noch so die Idee, nicht mehr dieses eine zentrale Datenteam, was sich überall die Daten herholt, sondern ein dezentrales Team, wo alles hinkommt. Genau. Dann ist es häufig eher nicht son, sondern eher 'n Top Down. Und dann geht's eher darum, die Entwickler zu, ja, tatsächlich auch davon zu überzeugen, dass es nicht nur Mehrarbeit ist, wenn sie die Daten bereitstellen, sondern dass es für sie auf lange Sicht auch einfacher wird. Jetzt hast
Jan: Du ja eben auch schon wieder dieses Contracts Thema angesprochen, weil natürlich, oder ich stell mir das auch als Herausforderung vor, je grade je größer die Firma ist, ne? Das ist son bisschen das Paradoxe. Die Kleinen brauchen das nicht und die die Großen haben ganz andere Probleme eigentlich, nämlich keine technischen Probleme, sondern ja eher organisatorische Probleme. In dieser Bestandsaufnahme überhaupt erst mal erfolgreich zu sein, braucht man ja superviel institutionelles Wissen. Wenn man Glück hat, gibt's noch so vereinzelte Mitarbeiter, die Arno, Dominik dabei waren, das gebaut haben und das irgendwie alles wissen. Und ja, diese eine Schnittstelle, die wollte der Hans Günther aus dem BI Team irgendwie haben, weil er diese paar Daten da noch extra braucht und so was, ja. Also wenn man Glück hat, gibt's die Leute noch, wenn man Pech hat, sind die schon weg. Aber wenn man jetzt diese Bestandsaufnahme gemacht hat, das Contract Testing verhindert, dass ich das technisch wieder kaputtmache. Aber wie schaff ich es denn, diese dafür nachhaltig irgendwie aufzubauen, dass auch so Sachen, ne, wie Prozessbeschreibung, Dokumentationen und so, dass das dann auch irgendwie alles aktuell bleibt. Weil sonst hab ich ja in 3, 5, 10 Jahren genau dasselbe Problem wieder. Da sind vielleicht meine Schnittstellen stabil, aber keiner weiß mehr warum und wieso und weshalb überhaupt, so. Also was was macht ihr da mit den Teams, die son bisschen da dahin zu erziehen, würd ich schon fast sagen? Oder gibt's da auch technische Möglichkeiten?
Matthias: Na ja, also technische Möglichkeiten haben immer sind sind da halt ein Werkzeug, was hilft, ne. Also ob jetzt Contracts oder dann halt explizit, diese Produkte auch zu managen und zu verwalten und dann Übersicht zu schaffen, diese Produkte auch zu beschreiben, auch abzukündigen und so was. Das das ist alles etwas, was man in 'nem großen Scale macht. Aber am Ende ist es, ich am Ende, man kann da sehr oft die Analogien ziehen und ich hatte schon gesagt, Data ist immer son bisschen hinterher. Am Ende, was wie macht man's mit Microservices? Wie macht man's mit Schnittstellen von Microservices? Man guckt sich sehr, sehr viel davon ab. Und das also es es ist alles keine Rocket Science. Es ist jetzt nicht so, dass Data sagt, wir machen das jetzt alles neu und anders. Und hier ist so. Es sind vorhandene Mechanismen. Es gibt ja diese Idee des Data Mesh, ist 'n bisschen älter schon, ist der Hype durch ist durch, ist 'n paar bisschen was von Substanz geblieben. Aber ohne jetzt mal Data Mesh gehört zu haben, wenn ich sag, das ist DDD für Daten, dann sagen alle sofort, ah, okay, verstanden, warte willst. Ja, das ist im Wesentlichen in die Richtung. Ja. Mhm. Genau. Und wie gesagt, es ist viel Gleiches, was dann bei der Data immer noch zukommt. Wir haben irgendwie andere Technologien, wir haben andere Begriffe, wir haben andere Herangehensweisen. Das macht es manchmal son bisschen reibungmäßiger.
Jan: Dann hatte
Matthias: ich sogar gesagt, CICD testen und so was. Umso mehr so Richtung Data gehst, umso mehr Du auch Richtung dann nicht Data Engineering, sondern Data Analyse gehst, umso mehr ist es auch UI klicken und so was, wo man als Entwickler schnell so denkt, ah, das ist nicht 'n Git. Ja, also da das das sind dann so die kulturellen Unterschiede, die dann noch reinkommen. Mhm.
Jan: Woran merk ich denn am Ende, dass ich mit dieser ganzen Data Awaren Architecture erfolgreich war? Wo schlagen sich tatsächlich die Unterschiede nieder? Wenn ich jetzt mit meinen Stakeholdern, Product Managern, Odern, wie auch immer irgendwie sprechen muss und denen sagst so, na ja, das sind die Vorteile. Oder in 3 Jahren werdet ihr merken, dass, wie macht sich das bezahlt am Ende des Tages?
Matthias: Am Ende, ganz am Ende ist der Techkram alles egal. Geht nur darum, Du kannst datengetrieben arbeiten und datengetrieben eine Entscheidung treffen. Und für dich zum Beispiel als P o, wenn wir das hier vernünftig machen und vernünftig aufsetzen, dann hast Du die Datengrundlage, zu sagen, welches Feature ist wichtig, welche nicht? Welche bringen Geld? Welche bringen wie viel Geld? Was kostet uns zu viel Geld? Und wir können Businessentscheidungen machen, mal den Vertriebsprozess beim Vertriebsprozess zu bleiben. Am Ende ist es fürn P o oder für wer auch immer noch über einem P o ist und Interessen hat und das Business vertritt. Mit dieser Data Aware Architektur schaffen wir die dir die Basis dafür, dass Du oben 'n vernünftiges Reporting über deinen Vertriebsprozess bekommt, genau siehst, was wo von wem in welcher Form verkauft wurde, das, das ist das. Also wir machen Data ja nicht zum Selbstzweck, sondern Data immer für Entscheidungen. Und das Wesentliche ist, durch eine bessere Daten Datenstruktur, Datenarchitektur untendrunter wird die Verlässlichkeit und die Zuverlässigkeit der Daten einfach viel besser und Du kannst viel bessere Entscheidungen treffen. Du guckst von 3 Sichten drauf und die Daten sind die gleichen, anstatt jeder kommt mit den Daten die Ecke, die er grad irgendwo her von ihm jemand bekommen hat. So. Das ist die High Level Business Sicht, zu sein. Das ist erfolgreich.
Jan: Ja. Okay. Jetzt verfolgst Du das Thema ja schon länger. Und auch wenn wir am Anfang und mehrfach zwischendrin gesagt haben, es geht eigentlich weniger jetzt konkrete technische Implementierungen in den Anwendungen und in der Datenbank oder vielleicht sogar in der in der, wie die Schnittstelle selbst gebaut ist. Und auch da kommt's ja am Ende nur drauf an, was kommt hinten bei raus so, ja? Mhm. Aber gibt es trotzdem son paar etablierte Best Practices Softwarearchitekturen, wo Du sagst, na ja, das hab ich schon ganz oft gesehen und dann ist das eigentlich schon mal 'n Zeichen dafür, dass man gut aufgestellt ist? Oder immer wenn's brennt, sind meistens so diese ein, 2, 3 Sachen irgendwie dran schuld. Was sind so die ein, 2 Best- und Worst Practices, die Du vielleicht schon mal gesehen hast?
Matthias: Ja. Also vorneweg, was also kein Einzige, es gibt kein Tool. Wenn ich das sehe, sag ich sofort, ja oder nein. Also Mhm. Uols sind, man kann mit Uols richtig Gutes bauen und man kann mit den gleichen Tools auch wirklich die größte Grütze bauen, es mal so zu sagen.
Jan: Ich hab neulich gelesen, jedes Gerät ist ein Defibrillator, wenn man das noch falsch genug benutzt. Zum Beispiel hab ich noch
Matthias: viel Geld, ja. Genau. Ich hab früher immer den Spruch, so ist, genau, der. Genau. Also es ist jetzt kein kein Tool, sondern es sind, was was bei mir ist, ist so häufig dieses, wenn jemand sagt, hey, wir haben jetzt 1, wir haben Tool x gekauft und jetzt müssen wir das doch alles viel besser machen. Vergiss es. Wer hat das konkrete Kernproblem, ist aber nicht das Tool, sondern das Problem ist die Organisation. Wenn jemand sagt, ja, wir haben jetzt hier 2 Leute eingestellt, die machen jetzt Daten. Vergiss es, dann ist es das zentrale Datenteam am Ende, was den Bottlenack macht. Also das das sind das sind sichere Zeichen für, okay, hier muss man wirklich ganz am Anfang. Was gut ist, ist, wenn jemand kommt und sagt, hey, wir haben verstanden, das ist zentral, das funktioniert nicht. Wir haben technologischer an Bord, wir können da vielleicht auch noch was nachlegen, wenn Bedarf ist. Aber wir, was wir brauchen, ist, wir müssen wissen, wie kriegen wir diese diesen Gap aufgebrochen? Das ist für uns das, was sich sperrt wird. Die Daten, auch eine Datenplattform bauen ist ein gelöstes Problem. Also nimm welches Tool auch immer, Du kriegst eine Datenplattform damit gebaut. Aber die Welten zusammenzubringen, das ist unser Problem, das haben wir nicht verstanden. Da brauchen wir Hilfe. Dann weiß ich, ah, ihr seid auf dem richtigen Weg, ihr habt's vielleicht noch nicht gelöst, aber ihr habt das Kernproblem verstanden. Ja. Das das so würd ich würd ich zusammenfassen. Mhm.
Jan: Und wenn wir den Blick jetzt noch mal 'n bisschen größer auch auf der Zeitdimension machen, Du machst das jetzt ja auch schon 'n paar Jahre länger. Wie würdest Du sagen, entwickelt sich das generell vom Verständnis her? Ist das eher was, was tendenziell besser geworden ist in den letzten 5 bis 10 Jahren? Ja, Du sagst, okay, da gibt es mehr Verständnis bei den Dev Teams, was BI Teams brauchen. Da gibt's mehr Verständnis bei den BI Teams, wie Dev Teams arbeiten. Oder sagst Du, na ja, dadurch, dass halt diese ganzen Teams immer spezialisierter werden und immer eigene Tools quasi brauchen, ist dieser, ne, wird diese Kommunikation, diese Empathie dazwischen immer schwieriger eigentlich?
Matthias: Nee, also es es wird besser, auf jeden Fall. Also ich nehm mal als Beispiel mal gerne, als ich damals meine Ausbildung beendet hab, dann hieß es so, Matthias, hätt ich mich Glückwunsch, studierst übernommen. Und ich war da im Architektur, Software Architekturteam, irgendwie so was. Und dann hieß es, ja, aber Du bist bei Data Warehouse jetzt. Und das war für mich so Weltuntergang. Keine Ahnung, was machen die? Das ist doch irgendwie, stellte sich raus, war 'n Spaß. Ich bin da nicht im Data Warehouse gelandet. Heutzutage ist es ein, ah, okay, Data Warehouse macht Sinn. Und das kann man auch verstehen. Warum? Weil man sich mal überlegt. Früher war so, wir haben eine Anwendung gebaut und wir haben die Daten für Analyse irgendwo anders gegeben. Heutzutage erwarten viele Nutzer eine Anwendung, dass sie selbstverständlich auch Analysemöglichkeiten haben in dieser Anwendung. Also viele Leute bauen ja eine Anwendung heutzutage oder viele Teams mit eingebauten Analysemöglichkeiten, wo Du filtern kannst, wo Du was auswerten kannst und Ähnliches. Also Datenanalyse ist ja auch nach links gewandert. Dann kamen die ganzen EM Machine Learning, reden wir nicht mal über KI Sachen. Recommender Systeme. Commender Systeme funktionieren, indem Daten aus 'ner App kommen, aus diesen Daten irgendwas gelernt wird und dann wird das wieder in die App eingespielt. Also es ist ja nicht mehr ein, geht raus aus der App, geht woanders hin und dann passiert nichts mehr. Ja, allein deswegen sind es natürlich deutlich mehr zusammengewachsen. Und KI ist jetzt natürlich der nächste nächste große Enabler. Alle haben relativ früh für meine Verhältnisse verstanden, ja, es ist nicht nur Modelle und sonst was und Agenten. Das funktioniert alles dann gut, wenn die Daten da sind und Daten vernünftig da sind und aufbereitet da sind. Die müssen nicht zwingend in der Tabellenform liegen, das kann auch unstrukturiert sein, ne. Aber Datenqualität zahlt sich aus. Das ist das, was. Und dementsprechend ist das Verständnis dafür grundsätzlich viel, viel besser da, dass dass man da zusammenarbeiten muss und nicht so, ja, hier ist unsere Welt und das ist die Softwarevelt, da ist die Data Welt. Zum Beispiel, ich hab vor vor einigen Jahren auch mal gehört, da hat jemand aus dem Software Engineering Bereich, mit dem man zusammengehört der hat über die Data Welt immer nur als Mordor gesprochen. Ja, da ist so, da ist da ist da ist auf jeden Fall gar nichts mehr los so. Und also die testen ja auch nicht und da ist keins die ICD und alles nur klicken und ah. Also die, das das Verständnis wird besser inzwischen.
Jan: Ah, das ist, ich muss nur nur, ich hatte ein ganz, ganz komisches Bild im Kopf. Ja. Grüße gehen raus an unser BI Team, die jetzt hoffentlich zur nächsten Faschingsfeier alle im Ork Kostüm kommen oder so was. Find ich lustig. Wie wie würdest Du generell den den Impact von AI beziffern. Also jetzt gar nicht mal so auf auf Tool und an Entwicklungsseite, sondern eher den Impact an auf den Bedarf an Data Awaren Architecture. So, ja, Du hast eben grade schon gesagt, es wird jetzt auf einmal viel mehr Daten irgendwie benötigt oder den Leuten fällt auf, dass sie damit sogar richtig was anfangen können irgendwie. Und auf einmal wird auch die Form weniger relevant, ja? Also wo früher eine Schnittstelle dann gute Arbeit geleistet hat, wenn sie irgendwie tolles CSV oder JSON ausgespuckt hat so, geht's halt heute darum, irgendwie 'n maximal breiten Kontext irgendwie ausgeben zu können. Und grade das ist ja wieder wahrscheinlich son Punkt, wo wir dann an das Thema kommen, Architektur ist das, was Du mir, sind die Schmerzen, die Du merkst, wenn Du was ändern willst, weil ja den den Kontext aus der Anwendung zu kriegen wahrscheinlich viel, viel schwieriger ist, als irgendwie das Format anzupassen oder so was, ja? Wenn man jetzt auf einmal merkt, boah, ich brauch noch diese 3 Daten dazu und ich muss hier noch 5 Querverbindungen aufmachen und hier noch 'n paar Joints und hier alles dazuschmeißen und so. Wie wie sehr schlägt das bei euch auf so?
Matthias: Also was auf jeden Fall Aufschlag ist, auf einmal der Bedarf an Daten ist ist groß. Aber man muss aber auch fairerweise sagen, Softwareentwicklung war ja immer schon so, wenn wenn es irgendwie Bedarf an Daten gibt, ich nehme jetzt auch dieses Self Service Analytics, was man in Anwendungen baut, dann hat Softwareentwicklung das gelöst. Und da sind die meistens nicht zum Data Team gegangen, das zu lösen. Sondern die haben halt das selber gebaut auf oft häufig spannend ganz anderen Technologistiksticks. Ein Beispiel ist für mich, Klickhouse ist in der Softwarervelt superbekannt in Anführungsstrichen, also vergleichsweise bekannt, spielt in der Analyticswelt kaum eine Rolle. Spannenderweise, es also es gibt fachlich inhaltlich gar nicht so extrem viele Gründe dafür, aber es ist irgendwie in 'ner anderen Blase genannt. Deswegen Software hat's immer gelöst und das jetzt auf KI zu zu machen, Software löst es ja trotzdem. Meistes Beispiel ist MCP. Kein Mensch steht jetzt irgendwie hin und sagt, ich brauch die zusätzlichen Daten, aber Data Analytics Team oder BI Team oder wie auch immer, helft uns mal, sondern die Softwareteams entwickeln halt implementieren halt MCP Server in ihrer Software. So, jetzt wird KI bedient, ja. Also der Bedarf an Daten steigt auch, das merkt man auch in Analytics. Und die Wichtigkeit und Leute erkennen ja, datengetrieben arbeiten ist mit KI noch mal wichtiger. Aber es heißt nicht, dass jetzt alles nur noch ist, Analytics, wir brauchen die Daten für KI, sondern Software und im im Softwarebereich passiert auch sehr, sehr viel dadurch. Ja. Aber
Jan: Und und wie, vielleicht habt ihr das ja sogar schon mal gemacht, wie kann KI helfen, in, jetzt machen wir den den Bogen wieder zurück, in diesem ganzen Prozess aufsetzen überhaupt, ja? In der Discovery, in der Planung, in der Dokumentation, in Schnittstellengestaltung, in Habt ihr da schon mal Erfahrungen gesammelt oder ist das eher was, wo man sagt, so, boah, das ist, also da kann man viel reinschmeißen, aber da kommt noch nicht wirklich viel Brauchbares raus?
Matthias: Weder noch, also aber es ist ein spannendes Thema aktuell, wo wo wo viel viel Ideen passieren. Also was was was man da machen kann, ist von von, wir haben Erfahrungen gesammelt mit, hey, wir bauen jetzt keinen großen Data Engineering Prozess mehr, irgendwie Daten aufzubereiten. Wir geben das einfach eine KI. So, solche Sachen. Dann das Thema, hey, abfragen, warum muss ich denn alles genau definieren und Dashboards machen, dass die Leute doch einfach per Text die Frage stellen und das beantworten. Das da sind so Sachen, aber es ist alles, also ich sag gar nicht, dass das nicht funktioniert, Gottes Willen. Das ist superspannende Sachen, die da jetzt passieren und der Einfluss von KI auf dieses ganze Analytiktikthema, auf das Thema auch, wie wie wie groß ist die Lücke noch? Wie Du sagtest, brauch ich noch immer die perfekt definierten, die am Ende tabulare Daten zurückgeben, wenn ich eine KI als Konsumenten habe? Weiß ich nicht, ja. Natürlich müssen sie Qualität haben, aber Struktur, das muss vielleicht nicht mehr tabuar sein. Ich hab ja am Ende nicht mehr ein Power BI oder Tableau oder sonst was dann, was zwingend tabulare Daten braucht. Vielleicht hab ich 'n Agenten, der sich einfach passt und mir 'n schönen Graf rausmacht. Vielleicht noch 'n bisschen was hinzuendichtet, aber ja. Also sehr spannende Entwicklung auch, also was was da passiert.
Jan: Das wär jetzt meine letzte ganz persönliche Frage nämlich noch gewesen, wenn ihr da schon son bisschen mit KI Erfahrung sammelt. Wie verlässlich ist es denn, ne? Also ich stell mir allein vor, wenn ich jetzt so was frage nach, weiß ich nicht, gib mir den Turn von unseren Usern die letzten paar Monate oder so was, ja. Da da gibt's ja eigentlich eine relativ klare Antwort drauf. So. Wie kreativ ist denn da sone KI in der Antwortfindung irgendwie noch?
Matthias: Sagen wir's so, umso besser die Domäne verstanden ist, ich sag mal, und zwar öffentlich verstanden ist, umso besser wird natürlich auch die KI, weil das natürlich in den Trainingsdaten drin ist und dementsprechend eher es relativ gut dazu antworten kann. Umso spezieller die Domäne und die Nische ist, umso schwieriger wird es manchmal für die KI. Und was so im Datenbereich grade schon so so sehr viel Thema ist, ist das Thema Semantik Layer. Brauchen wir jetzt 'n semantisches Layer überall drauf? Müssen wir jetzt beschreiben, so werden alle Metriken berechnet und das hier hängt so übrigens zusammen und wie viel Kontext braucht sone KI? Und da gibt das eine Team, die sagen, Du brauchst ganz viel, Du musst das alles beschreiben und es gibt Pooling da drumherum und so. Und es gibt die Leute, die sagen, weißt Du was? Gibt der KI Zugriff auf deine Datenbank Lesezugriff. Und der verhält sich halt wie 'n Junior Engineer. Wenn er nicht weiß, dann macht er 'n paar Keubis, guckt mal 'n bisschen rum, probiert hier mal aus, holt sich den Kontext selber zusammen und kommt zu guten Ergebnissen. War das irgendwie so
Jan: Also ich muss sagen, ich bin da persönlich son bisschen skeptisch in dem Feld, grade bei dieser Junior Engineering Analogie. Weil wenn ich jetzt in meinem Product Team irgendwie 4 Leute hab und die fragen alle nach, na, wie groß ist denn meine User Base? Und jedes Mal wird der Agent halt irgendwie Userbase anders definieren, dann hab ich da nichts gewonnen irgendwie so, ja? Und das ist so immer 'n bisschen meine meine Sorge, die ich hab. Also ich bin 'n Freund von dieser, also Du hast es grade Semantik Layer genannt, für mich sind wir wieder bei diesem Thema Naming und so unterscheidet sich vielleicht einfach. Für mich ist das so einfach Kontext Engineering so, ja. Gib halt mehr rein so, mehr mehr Basiswissen schon irgendwie mit. Ich mein, mittlerweile haben wir Kontext Windows über 1000000 Token oder so. Da kann man sehr, sehr, sehr viel reingeben mit. Aber ja, spannend, wenn das schon so gut funktioniert, ja.
Matthias: Genau, also vielleicht dazu noch, Kontext für Engineering ist für mich das gesamte, was geborene ich 1 1 KI mit? Semantik Layer ist eher sone eine eine Beschreibung. Also am Ende funktioniert das auch über Kontext Engineering, was ich dann halt 1 KI gebe. Das ist schon das Gleiche. Aber Semantik Layer sind so wirklich so Sachen, die ich wie ich in Code definiere oder in 1 strukturierten Form definiere. Das ist übrigens die Metrik, so hängt das zusammen. Manche Leute, die jetzt vielleicht ausm BI Bereich zuhören und sagen, Matthias, das hättest Du jetzt hier, ist doch nix Neues, Power BI macht das seit Ewigkeiten. Ja, genau. Also bei Power BI hast Du auch einen Summantiklayer zum Beispiel, was Du definierst. Ist relativ proprietär. Genau, aber das sind so Informationen, die dann im Rahmen des Kontext Engineering halt 1 KI mitgegeben werden können und der weiß, ah, ich soll die Meta User Base immer so berechnen, dann mach ich das halt auch so. Ja. Ja, ja. Genau.
Jan: Cool. In Anbetracht der Zeit gibt es eine Frage, von der Du dir denkst, so wieso hat der Jan mich das überhaupt gar nicht gefragt? Ich war so gut auf das Thema vorbereitet, wollt unbedingt über XYZ sprechen und keiner hat mich danach gefragt, dann ist jetzt deine Chance.
Matthias: Nee, Du hast die, Du hast Du hast auch einige Fragen gestellt, die ich nicht erwartet habe, was ich sehr gut fand. Das challenged auch immer son bisschen. Ich fand's sehr gut dieses Architecture als, es geht mir gar nicht so sehr was in der Anwendung passiert. Das hilft hilft mir als Feedback, auch wenn ich dadrüber erzähle, das klarzumachen. Aber es gab jetzt gar keine, gab jetzt nichts so, wo ich sag, die Frage hätte ich auf jeden Fall auf jeden Fall noch noch erwartet. Nö.
Jan: Alles absolut. Wunderbar. Dann wär das ja fast schon wieder 'n gutes Schlusswort geworden, aber wir sind ja noch gar nicht am Schluss. Wir haben ja noch unsere Picks of the day, über die wir sprechen wollen. So Matthias und weil Du Gast bist, darfst Du natürlich gerne bei uns anfangen. Was hast Du als Pick of the day für uns dabei am Start?
Matthias: Wir sind grade schon so in die Richtung gegangen. Also alles dieses Thema Text, Sprache zu Datenabfragen, find ich grad superspannend, so neben was im Gender AI Bereich passiert, neben den ganzen AI assistted, AI Driven, wie auch immer, Vibe Coding, find ich so dieses Vibe Analysen. Wie mach ich das denn? Wie wie Also da gibt's viele Sachen, womit ich mich grad, was ich grad angucke. Klar, MCP Service ist das eine. Brauche ich Kontextlayer? Brauche ich Semantiklayer? Das sind spannende Sachen. Es gibt zwischen, ich mach relativ viel. Das ist eine eine kleine schmale, nette Datenbank, die sehr mächtig ist. Da gibt's auch 'n dann auch 'n Premiumprodukt zu, die auch MotherDAX, die dann auch eine eine MCP Schnittstelle bereitstellen. Da hab ich sehr viel jetzt in letzter Zeit mit ausprobiert. Also das sind so so so Sachen Copilot mal draufschmeißen oder den Clay draufschmeißen oder Open Open Code draufschmeißen und einfach mal gucken, wie wie fühlt es sich an da. Und auch auch in dem Prozess nicht nur ich, ein Analyst will die Frage beantworten, sondern auch, hey, ich als Data entwickele entwickel Pipelines. Was wie hilft es mir denn, wenn er auf einmal Zugriff auf die Daten hat? Ja. Sehr spannend.
Jan: So. Ich ich ich muss sagen, ich hab, also wir nutzen bei uns zum Beispiel NHN auch intern für so was. Und das lässt sich ja auch wunderbar irgendwie mit KI zusammenschrauben, ja. Ich muss sagen, ich hab von dem Tool per se eigentlich gar nicht so viel Ahnung und nutz das für son paar kleinere Cases. Aber dann einfach hier zu Cloud oder GPT zu gehen und sagen, hey, ich hab hier sone End nach End Instanz. Das ist mein Problem. Was muss ich da fürn Workflow zusammenschrauben, dass das irgendwie geht? Und das freut sich schon ganz gut. Aber gibt's da für dich son son Tooling oder 'n Framework, wo Du sagst so, damit kann man schon viel von diesen Analysesachen abfrühstücken oder das nimmt einem da viel Arbeit ab, mal mit was anzufangen mit sonem kleinen Proof of Concept vielleicht?
Matthias: Also ich bin da relativ bär. Ich gar nicht viel draufschmeißen, eine Datenbank oder irgendeine Lösung, die 'n MCP Server hat, was inzwischen ja geführt alle haben. Dein favourite Agent client dagegenhauen, mit dem MCP Server rein, los geht's. Also das, ich bin der, braucht da jetzt nicht viel noch an an anderen Sachen. Also damit kommt man, das ist so meine Erkenntnis. Man kommt erstaunlich weit ohne ein Semantiklayer, ohne irgendwie zusätzliches Tooling einfach nur Agent Gegendaten. Der macht, der findet sich schon zurecht.
Jan: Mhm. Und das heißt, gut, also wenn, Du hast ja Duck DB angesprochen, da ist dann 'n MCP Server schon drin und für klassische Datenbanken bei soner Postgress oder so was, da gibst Du ihm da einfach sonen read only Zugang, dass er sich son bisschen Sciema angucken kann und dass sich so selber erarbeitet oder wie ist da das das Vorgehen?
Matthias: Ich Postquest müsste ich passen, weil ich nicht mehr wüsste, also ich Host selbst hat, glaub ich, keinen MCP Server. Ich würd mir würd mich aber wundern, wenn es nicht mindestens 10 unterschiedliche Projekte gibt, die jeden MCP Server bereitstellen.
Jan: Ja, neuneinhalb davon in geschrieben.
Matthias: Genau. Plus noch die ganzen, also managed Postkris ist ja auch ein Riesending, ob wir jetzt Neon oder so, die ja gekauft wurden, die werden wahrscheinlich auch noch alle haben. Also man wird MCP Server bekommen. Also am Ende ist es klar, der MCP Server sollte vielleicht jetzt, wenn man vernünftig ist und auf Produktionsdaten ab, keinen Schreibzugriff haben. Wer weiß, was der Agent so macht? Ja, aber also Databricks bietet einen MCP Server, Snowflake wird was bieten. Also MCP Server ist ja so, es gab ja die Zeit, hast Du keinen MCP Server, was Du raus? Von daher haben wir allein.
Jan: Ja, dieses MCP Server sind die neuen Rest APIs so.
Matthias: Ja, aber es gibt es gibt auch schon jetzt die, die wo Du sagen, ja, MCP ist eigentlich gar nicht so cool, loat den Kontext zu sehr. Eigentlich sind Skills das Ding und einfach Kommandozeile ausführen und das doch wieder nicht so so fassy machen. MCP ist ja sehr fassy und der A2 macht's schon, sondern doch wieder 'n bisschen streamland und sehr explizit zu machen, weil der Kontext bloat. Mal gucken, was dann als Nächstes kommt. Cool.
Jan: Dann danke da einmal für die Insights. Ich hab was ganz anderes dabei. Ich hab ein Problem. Und zwar sammle ich leidenschaftlich gerne so Rucksäcke, Taschen, irgendwas. Also gefühlt für jede Konferenz, für jeden Trip, den ich so unternehmen, kauf ich einfach son neuen Ruckstage. Ich sag so, das das ist jetzt son ganz anderer Use Case und eine ganz andere Nische und irgendwie brauch ich eine andere Größe und 'n anderes Format und keine Ahnung was. Und ich hab mir wieder was Neues geholt.
Matthias: Jetzt bin ich gespannt.
Jan: Wieso? Suchst Du auch grade was?
Matthias: Ich bin das ganz andere Thema. Ich hab einen Rucksack, den ich jetzt 10 oder 11 Jahre hab, aber er muss ersetzt werden und deswegen bin ich jetzt gespannt, Du scheinst Ahnung zu haben, was muss man Also ich hab 'n ganz viele Rucksäcke,
Jan: die ich seit 10 oder 11 Jahren hab. Die meisten davon noch in sehr gutem
Matthias: meine nicht mehr.
Jan: Ja, also das hier ist der Chrome Kadett Max 15 Liter. Das ist 'n bisschen kleiner. Und das ist kein Rucksack, das ist sone Sling Quertasche. Also früher hat man mal so Messengerback gesagt, ne. Also Ja. Und eine Sling Tasche hängt da son bisschen höher. Und hat den Vorteil, mit 15 Litern passt die genau in dieses 40 mal 30 mal 15 Format, was nicht Handgepäckgröße ist im Flugzeug, sondern dieses, wie heißt das immer, Personal Additional Item,
Matthias: Schicht tot.
Jan: Das heißt, ich kann nämlich meinen kleinen Reisetrolly irgendwie noch mitnehmen, wo dann Klamotten und bla. Also wenn ich reise, reise ich gerne nur mit Handgepäck, dann verliert man schon Ja. Weniger und ist schneller irgendwie durch, grade bei Kurztrips. Und so kann ich den Trolli irgendwie vollstopfen mit allem, was ich so wirklich brauch und hab das kleine Ding noch dabei für Laptop, Tablet, Kopfhörer, Mikrofon, was man halt so alles braucht, wenn man so wie ich unterwegs ist. Und das ist eine coole Größe. Es trägt sich auch ganz angenehm. Es passt leider nicht meinen 16 Zoll Laptop rein. Das ist 'n bisschen ärgerlich, aber ich plane auf die 14 Zoll Größe umzusteigen bei nächster Gelegenheit. Von daher schauen wir mal,
Matthias: Das ist das so ergibt. Das ist 'n guter Impuls, weil ich hab auch immer so, ich den den den den normalen Handgepäckskoffer halt und so und dann ist aber noch, ja, was ist mit dem Laptop? Und ich hab son Leuther Gigarrucksack, der ist
Jan: Ja, die darfst Du halt nicht nehmen zusätzlich. Also ich mein, ich Ja. Auch viel Glück gehabt so, ne. Meistens sagen sie
Matthias: ja nichts, aber ich
Jan: hab halt immer so Respekt vor diesem Tag, wo sie sagen so, nee. Ja. Und jetzt musst Du diesen Rucksack abgeben und da ist so, okay, no fucking way Air. Da ist irgendwie mein mein Laptop und mein halbes Leben drin. So niemals verlässt er mich und geht in diesen Flugzeugbauch. Und das ist Ja,
Matthias: sehr gut nachvollziehbar. Sehr gut nachvollziehbar. Gut gut guter erhöhter Ding, ja.
Jan: Aber ich hab das Problem,
Matthias: ich hab 16 Zoll und ich will auch eigentlich nicht mal weg. Da muss ich dann schauen, was geht.
Jan: Also Ja. Der ist, den gibt's auch noch in 1 Größe, vielleicht passt da 16 Zoll rein. Und grade wenn Du 'n auch 'n 16 Zoll MacBook hast, ja. Ja. Die sind ja relativ dünn dank des schmalen Rahmens. Die passen auch oftmals noch bei anderen 15 Zoll Rucksäcken rein. Also kann man mal probieren vielleicht auch. Ich kann jetzt keinen Live Test machen, weil wenn ich die Kiste hier zuklapp, ist die Aufnahme vorbei. Das wär ärgerlich, aber ich kann mich noch mal melden im Nachgang. Aber ja, also wie gesagt, ich kann ja auch, ich kann nicht zuwerfen mit Rucksäcken, so. Also überhaupt gar kein Thema. Ich hab, Du siehst hier vielleicht bei mir hinten so diesen Schrank da so. Ja. Du siehst dieses Schwarze, was da und da und so überall rausguckt, so. Das sind überall mit Rucksäcken so, ja. Reingestopft, ja. Ja, und ich hab da Haken reingeschraubt extra, damit die alle so ordentlich an Ort und Stelle bleiben und so. Also und ich hab den halben Dachboden voll damit, so. Ich werd regelmäßig genötigt, irgendwie da mal auszusortieren oder so, aber man kann sich ja nun sehr schwer von so was trennen. Ja. Ja. Ich kann mich auch sehr
Matthias: schwer trennen, deswegen hab ich sehr lange, aber ja. Verstehe. Aber interessanter Input.
Jan: Ja. Wunderbar. Das als Konsumempfehlung ja am Ende für Leute, die auch Rucksäcke sammeln. Wunderbar, wunderbar. Dann 1000 Dank dir, Matthias, für die Zeit und für das interessante Gespräch und die tollen Diskussionen rund Data War Architecture.
Matthias: Ja, danke für die Einladung. Danke für die Fragen, für die spannenden Fragen. Auf jeden Fall auch nicht, bisschen was Spannendes mal für mich auch, was was so son bisschen mal mich auch gechallenged hat. Fand ich cool.
Jan: Wenn ihr da draußen noch Fragen, Anmerkungen, Kritik habt, dann immer gerne eine E-Mail an Podcast at Programmier Punkt bar oder ihr schreibt uns auf Social Media. Oder ihr lasst uns einfach direkt aus dem Podcast Player eurer Wahl ein Like mit dem Thumps-up oder Thumps Down Link da, den ihr da in den Shownotes findet. Das erreicht uns dann auch ganz direkt. Ansonsten bleibt mir gar nicht so viel mehr zu sagen, bis auf. Wir sehen uns nächste Woche. Hören uns nächste Woche und bis bald. Tschau Matthias.
Matthias: Tschau.

Data-Aware Architecture mit Matthias Niehoff

Shownotes

Picks of the Day

Chrome Kadet Max Sling 15L

Speaker Info

Matthias Niehoff