Webinar – Daten, untersucht Nr. 1 – Die große Debatte über die Medaillon-Architektur

Vielen Dank an alle für Ihre Teilnahme. Es ist mir eine Freude, Gastgeber zu sein.

Ich bin Chief Evangelist bei Actian. Mein Name ist Ole Olesen-Bagneux, und in dieser großen Medaillon-Debatte werde ich Piethein Strengholt interviewen, den Autor von – mal sehen, ob ich es hier finde – „Building Medallion Architectures”. Außerdem ist Martin dabei, der uns herausfordern wird.

Chesbrough, spricht man das richtig aus als Chesbro? Ja, das ist perfekt. Chesbrough Chesbrough Und er war tatsächlich einer der Gründe, warum wir gerade diese Debatte führen, denn ich habe auf LinkedIn über Medaillon-Architekturen geschrieben, und der Beitrag wurde viral, weil ich einen Nerv getroffen habe, als ich sagte, dass ich nicht glaube, dass Medaillon-Architekturen jemals verschwinden werden.

Unabhängig davon, wie modern unsere Datenarchitekturen sein werden, werden wir über mehrschichtige Architekturen verfügen, um Daten für die analytische Nutzung vorzubereiten. Also, ohne weitere Umstände, die Tagesordnung dieses Treffens, bzw. dieser Veranstaltung, sieht so aus, dass ich Piethein interviewen werde. Ich habe einige detaillierte Fragen zu seinem neu erschienenen O'Reilly-Buch „Building Medallion Architectures” vorbereitet.

Es ist ein großartiges Buch, und es wird etwa 20, 25 Minuten dauern, in denen Sie alles über die Medaillon-Architektur erfahren werden. Und ich werde einige kritische Fragen stellen. Aber die Idee ist, dass Martin in etwa 20, 25 Minuten an der Debatte teilnimmt.

Er hat eine sehr detaillierte, sehr präzise Liste kritischer Punkte vorbereitet, die er in Bezug auf die Medaillonarchitektur und die Vor- und Nachteile dieser Architektur untersuchen möchte. Wir werden also später im Gespräch näher auf diese Debatte eingehen. Und natürlich sind alle Teilnehmer der Telefonkonferenz herzlich eingeladen, Fragen zu stellen.

Also, ohne weitere Umstände, Martin, ich denke, an dieser Stelle... Ja, ich wollte gerade sagen, dass die Teilnehmer ihre Fragen über das Q&A-Feld unten in ihrem Zoom-Fenster einreichen sollen, und dann werden wir diese Fragen aufgreifen, wenn wir in die Debatte einsteigen. Ist das die Idee? Genau.

Ja. Perfekt. Danke.

An diesem Punkt werde ich mein Video ausschalten, euch euer Interview führen lassen und später wiederkommen, es sei denn, ich gehe schlafen. Bitte bleibt wach. Bitte trinkt einen heißen Kaffee.

Guter, starker, guter, starker Kaffee dort drüben. Ich habe meinen Kaffee, ja. Entschuldigung.

Perfekt. Vielen Dank. Ich möchte wirklich, der Grund für den Scherz ist übrigens, dass es für mich früh am Morgen ist und ich gerade aus dem Flugzeug komme.

Es liegt also nicht an Langeweile oder Ähnlichem, ich finde dieses Gespräch tatsächlich faszinierend, also legen Sie los. Ich kann Ihnen gar nicht genug dafür danken, dass Sie hier sind, Martin, vielen Dank. Und bitte bleiben Sie wach.

Wir brauchen dich für die Debatte später. Okay Peter, ich habe eine Menge Fragen vorbereitet. Wie du bei der Vorbereitung dieses Treffens gesehen hast, habe ich dein Buch noch einmal gelesen, und zwar sehr, sehr sorgfältig.

Ich habe also viele verschiedene Fragen vorbereitet, aber ich möchte das Niveau relativ hoch halten. Einige davon werden so detailliert sein, wie es auch Ihrem großartigen Buch entspricht. Aber für die Teilnehmer dieses Webinars möchte ich die Fragen mit einer offensichtlichen Frage beginnen.

Warum wollten Sie dieses Buch schreiben, Peter? Was hat Sie dazu motiviert, es zu schreiben, und warum war das so? Ja, bevor ich darauf antworte, möchte ich mich kurz vorstellen.

Ja, natürlich. Ich bin natürlich der Autor dieses Buches, habe Medaillonarchitekturen entwickelt und die gesamte Diskussion verfolgt. Ich habe auch ein weiteres Buch mit dem Titel Datenmanagement Scale” geschrieben.

Einige Leute, die ich im Chat sehe, kennen mich vielleicht von Microsoft, wo ich in den Niederlanden als Chief Data Officer gearbeitet habe. Ich habe lange für ABN AMRO gearbeitet. Vor kurzem bin ich zu einem anderen Unternehmen namens NN Group gewechselt, einer großen nationalen Versicherungsgesellschaft.

Um auf Ihre Frage zurückzukommen: Warum habe ich ein Buch über Medallian-Architekturen geschrieben? Dieses Thema hat mich während meiner Arbeit bei Microsoft fasziniert. Viele Kunden kommen zu Microsoft, weil sie mehr Wert aus ihren Daten schöpfen möchten, nicht wahr?

Ähm, und dann lautet die Antwort oft: Nun, wenn Sie mit Daten arbeiten und einen Mehrwert generieren möchten, müssen Sie als Erstes eine Plattform aufbauen. Also einen Datendienst, einen Plattformdienst. Und dann kommt die nächste Frage.

Was soll ich dann tun? Nun, diese Architektur aufbauen. Und dann ist die beste Vorgehensweise, die oft empfohlen wird, dass man sich den Aufbau einer Medallian-Architektur anschauen sollte.

Aber ehrlich gesagt hört die Anleitung dort oft auch schon auf. Es gibt also einige allgemeine Anleitungen für Unternehmen, worum es bei diesen Ebenen geht. Und es gibt Bronze, Silber und Gold, und es gibt einige allgemeine, verbindliche Anleitungen.

Aber im Grunde genommen läuft es darauf hinaus, die richtigen Nuancen zu treffen. Und ja, es geht auch um Empathie, und die Leute finden es auch sehr schwierig, diese Designmuster präzise zu interpretieren. Da ich hier einen Mangel an Anleitung sah, motivierte mich das, ein Buch zu schreiben.

Und als ich dieses Buch schrieb, habe ich, bevor ich mit dem Schreiben begann, viele potenzielle Leser befragt, was sie von mir hören wollen. Der Unterschied, die Schwierigkeit dabei ist, dass es so viele unterschiedliche Erwartungen gibt. Und das ist auch eine sehr meinungsstarke Architektur.

Also habe ich es auf diese Weise gemacht. Es gibt also einen eher theoretischen Teil. Was ist ein Medaillon und woher kommt es genau, die Schichtung usw.

Dann gibt es ein Tutorial, ein Handbuch, das Sie Schritt für Schritt durch das eigentliche Design führt, mit Code-Schnipseln, Screenshots, Anweisungen und einer genauen Beschreibung, wie Sie diese Medaillon-Architektur aufbauen. Dann gibt es Fallstudien, in denen ich mit verschiedenen Kunden aus unterschiedlichen Branchen und unterschiedlicher Größe zusammenarbeite. So erfahren Sie, warum sie diese Architektur implementiert haben und wie sie ihre Medaillon-Architekturen gestaltet haben.

Und schließlich spule ich vor und versuche, Verbindungen zu anderen Bereichen des Datenmanagement der KI herzustellen. So ist das Buch also grob aufgebaut. Ja, diese Struktur gefällt mir sehr gut.

Wenn man das Buch liest, bekommt man eine Einführung in die Vorgehensweise und wird dann aufgefordert, diese umzusetzen. Anschließend sieht man, wie andere vorgegangen sind. Schließlich geht das Buch auf ein komplexeres Muster mit mehreren Medaillonarchitekturen ein, die unterschiedliche Aufgaben erfüllen und unterschiedlich skalieren.

Und ich, ich bevorzuge den letzten Teil ganz klar. Und ich denke, weißt du. Außerdem, natürlich Piethein, tut es mir leid, dass ich dich nicht formeller vorgestellt habe.

Ich gehe einfach davon aus, dass jeder hier am Telefon Sie kennt.

Natürlich kennt Sie nicht jeder, aber Sie sind ein sehr bekannter Autor, O'Rielly-Autor, mit vielen Lesern. Okay, lassen Sie uns ein wenig in die Medaillon-Architektur selbst eintauchen. Was sind die drei Ebenen, Bronze, Silber und Gold, kurz erklärt?

Ja, kurz gesagt ist es wichtig, vorwegzunehmen, dass diese Schichten als logische Schichten interpretiert werden sollten. Es handelt sich um ein logisches Designmuster. Ein Fehler, den ich oft bei Unternehmen sehe, mit denen ich zusammengearbeitet habe, ist, dass sie diese als physische Schichten betrachten.

Das ist also falsch. Es handelt sich um logische Ebenen, mit denen Sie Ihre Daten logisch organisieren können. Sie überwachen also eine End-to-End-Architektur, aber innerhalb dieser logischen Grenzen sind sie bestimmten Verantwortlichkeiten und Aufgaben zugeordnet.

In der ersten Schicht geht es meiner Meinung nach hauptsächlich darum, die Daten zu erfassen, die Rohdaten, die Daten zu validieren und sie in der nächsten Schicht zu archivieren, in Silber, so sehe ich das hauptsächlich. Es geht also darum, Daten zu standardisieren, Daten zu bereinigen, Daten zu korrigieren und Daten leicht anzupassen. Aber da gibt es bereits viele Diskussionen.

Müssen Sie bereits über Quellsysteme hinweg Daten kombinieren und zusammenführen? Erstellen Sie beispielsweise in dieser Ebene Datenprodukte? Das hängt also sehr stark vom Einzelfall ab.

Ja. Und dann, in Gold, diese Ebene, die ich dort sehe, ist das der Punkt, an dem man die Daten zweckmäßig aufbereitet. Also für den späteren Verbrauch.

Also die geschäftliche Nutzung der Daten, da gibt es wieder viele Diskussionen. Braucht man eine klassische Integrationsschicht? Wenn man überlappende Anliegen in verschiedenen Benutzergruppen hat, oder hält man sie getrennt?

Welche Rolle spielen Datenprodukte und was sind diese „Dense“? Auch hier gibt es viele Diskussionen auf diesen Ebenen. Aber so sehe ich es ungefähr.

Ja, ja, absolut. Das wird auch beim Lesen des Buches sehr deutlich. Für diejenigen, die sich mit Medaillonarchitektur nicht so gut auskennen, um den Rahmen zu stecken: Wenn Sie davon sprechen, dass diese Schichten logisch und nicht physisch sind, was bedeutet das konkret?

Was für eine Architektur ist das Ergebnis davon? Ist die Frage klar? Ja, die Frage ist klar.

Die physische Implementierung kann also sehr stark von der logischen, sagen wir mal, Abstraktion abweichen, also davon, wie Sie Ihre Daten über diese drei Schichten hinweg organisieren. Sie könnten sich beispielsweise für ein Muster entscheiden, sagen wir, Sie haben drei physische Schichten implementiert. Richtig?

Ein weiteres Designmuster könnte beispielsweise sein, dass ich jetzt mehr physische Ebenen habe und innerhalb dieser Ebenen wiederum bestimmte Aspekte voneinander trenne. Die erste Stufe besteht also beispielsweise bei Bronze darin, diese Rohdateien zu erfassen und sie im ursprünglichen Dateiformat zu behalten.

Dann kopieren Sie innerhalb von Bronze in eine andere innere Ebene und wandeln die Daten in das Datenformat um. Möglicherweise kopieren Sie sie dann erneut in eine andere Ebene, wo Sie sie mit bereits vorhandenen Daten zusammenführen, die zu diesem Zeitpunkt noch roh und technisch sind. Dies ist also ein Beispiel für drei physische Ebenen innerhalb einer vertikalen Ebene.

Ja. Danke, dass du darauf hingewiesen hast. Genau das habe ich gemeint, denn ich denke, zumindest ein Teil der Medaillonarchitektur wird sehr heiß, weil die Leute wirklich nicht über diesen Unterschied zwischen der logischen und der physikalischen Schicht nachdenken.

Denn wenn Sie, wenn Sie sagen, und ich sollte Ihnen Fragen stellen, aber ich habe nur gesagt, stimmen Sie zu, inwieweit würden Sie dieser Annahme zustimmen, dass die Leute das ein bisschen missverstehen, aber dann, ja, Für mich war die Motivation, dieses Buch zu schreiben, dass ich so viele Kundengespräche geführt habe, während ich bei Microsoft gearbeitet habe, wo die Leute die Medallian-Architektur als rein drei physische Schichten interpretiert haben. Ja, ich musste ihnen wirklich die Augen öffnen. Nun, nein, es geht um die Entkopplung von Belangen.

Und deshalb können Sie so viele Schichten haben, wie Sie möchten. Lassen Sie mich Ihnen ein paar Fragen zu den Schichten selbst stellen. Zunächst einmal, warum, ich habe also eine Frage zu jeder Schicht.

Warum sollte man abfragen Bronzeschicht nicht abfragen ? Warum sollte man abfragen nicht abfragen ? Ich meine, viele Leute denken darüber nach, aber warum sollte man das nicht tun?

Das wäre möglich, aber es ist unausgereift und daher sind Sie eng an die ursprüngliche Struktur der Quellsysteme gebunden, die Sie beispielsweise auf der linken Seite Ihrer Architektur haben. Wenn sich diese Strukturen auf der Seite des Quellsystems plötzlich ändern, könnte dies störende Auswirkungen auf die Struktur dieser Bronze-Schicht haben. Wenn Sie beginnen, Berichte und Agenten auf Ihrer Bronze-Schicht zu operationalisieren, werden Sie Schwierigkeiten haben, mit all diesen Änderungen Schritt zu halten.

Also noch einmal: Eine bewährte Vorgehensweise wäre es, sich von der Struktur der Quellsysteme zu lösen und dann zur nächsten Ebene überzugehen, die für dieses Anliegen relevant ist. Also zwei Fragen zur Silber-Ebene, die miteinander verschmolzen sind. Zunächst einmal: Warum ist die Silber-Ebene einfach?

Sie bezeichnen es im gesamten Buch als einfach. Und zweitens, warum möchten vor allem ML- und KI-Ingenieure abfragen Silver-Schicht abfragen ? Ich sage einfach, weil ich empfehle, noch nicht damit zu beginnen, Quellsysteme zu kombinieren, zu mischen und zu integrieren.

Die Bedenken sollten daher sehr stark auf das zugeschnitten sein, was Sie auf der Ebene des Quellsystems vorfinden. Meiner Meinung nach sollten die Daten auf dieser Ebene bereinigt und korrigiert werden. Also auf der Ebene des Quellsystems.

Weil es immer noch den authentischen Kontext weiterführt. Es ist ideal für den Aufbau von operativen Agenten, die operative B-Ports aufbauen, da der Kontext weitgehend dem entspricht, den Sie in Ihrem Quellsystem sehen würden. Wenn Sie meiner Meinung nach bereits in dieser Phase damit beginnen, Daten aus verschiedenen Quellsystemen zu kombinieren und zu integrieren, müssen Sie den Kontext anpassen.

Und ja, Sie verlieren den authentischen Kontext oder den ursprünglichen Kontext , wie Sie es von der Quellsystemseite erwarten würden. Und das macht es schwierig. Wenn Sie also einen operativen Bericht erstellen oder operationalisieren möchten, müssen Sie ihn sozusagen wieder in den ursprünglichen Kontext zurückführen.

Nicht ideal. Ich würde den Zuhörern daher empfehlen, diese Sorge auf eine spätere Ebene zu verschieben. Ja.

Und aber noch einmal, hier sieht man also viele Ich kommentiere auch, Bitte fahren Sie fort. Entschuldigung. Ja, also manche Leute, sie, sie befürworten zum Beispiel die Anwendung von Datenfehlern innerhalb dieser silbernen Schicht, oder bereits zu diesem Zeitpunkt beginnen die Kombination und die Integration von Quellsystemen, Ihre Daten bereits zu integrieren.

Ja, das hängt wieder davon ab, also schauen Sie sich Ihre eigenen Anforderungen und Bedürfnisse an. Es ist nicht falsch. Es ist nicht richtig.

Aber ja, ich bevorzuge das Designmuster, das wir besprochen haben. Also ja, die Cross-Source-Systemintegration zurückstellen und auf die letzte Verbindung zum Gold verschieben. Ja.

Einverstanden. Einverstanden. Nun, ich möchte nicht sagen, dass ich zustimme, weil ich mir nicht sicher bin, ob ich damit einverstanden bin, aber jedenfalls ist es das, was Sie in dem Buch argumentieren, dem ich zustimme.

Ähm, also zur Goldschicht: Meine Frage zur Goldschicht ist, dass Sie sagen, sie sei extrem kompliziert, insbesondere im Vergleich zur Silberschicht. Warum ist die Goldschicht kompliziert? Ja, weil ich oft sehe, dass es gegensätzliche Bedenken gibt.

Sie möchten also Daten vielleicht auf Unternehmensebene oder für einen bestimmten Anwendungsbereich harmonisieren, um Beständigkeit Daten in den verschiedenen Anwendungsfällen sicherzustellen. Dann besteht die Notwendigkeit, die Daten ganz spezifisch auf use case des use case abzustimmen. Ja, auch hier stehen Sie wieder vor einem Dilemma.

Diese Bedenken lassen sich nicht so leicht ausräumen. Hinzu kommt die Notwendigkeit, Daten möglicherweise über verschiedene Domänen und Teams hinweg an externe Datenverbraucher zu verteilen. Diese sind auf stabile, in hohem Maße wiederverwendbare Daten angewiesen.

Auch hier sieht man wieder diese Problematik. Wenn man also einen use case hat use case flexibel sein möchte und spontan viele Änderungen vornehmen möchte, steht dies im Gegensatz zu der Notwendigkeit, verschiedenen Verbrauchern hochzuverlässige wiederverwendbare Daten zur Verfügung zu stellen. Daher sehe ich oft, dass man innerhalb von Gold beginnt, diese unterschiedlichen Belange wieder voneinander zu trennen, und daher könnte man wiederum verschiedene physikalische Schichten innerhalb dieser einzigen Goldschicht sehen.

Absolut. Kommen wir nun zu dem Teil des Buches, der mir am besten gefallen hat, und ich denke, wir werden etwas Zeit haben, darüber zu diskutieren. das war der vierte Teil des Buches, und dort öffnen Sie sich wirklich, denn ich habe das Gefühl, dass eine weitere Sache, die die Leute an der Medaillon-Architektur nicht mögen, ist, dass sie sie als eine Art unternehmensweite Autobahn für den Datentransport betrachten, der jeder einzelne use case entsprechen und durchlaufen use case , um Anwendungsfälle für Analysen bereitzustellen, richtig? Was mir an Teil vier Ihres Buches wirklich gefällt, ist, dass Sie sich wirklich öffnen und sagen, genau wie in Ihrem ersten Buch Datenmanagement Scale”, bieten Sie diese Perspektive der Flexibilität und Scalability, die wirklich Kernstücke jeder modernen Datenarchitektur, sogar der Softwarearchitektur sind, richtig?

Sie öffnen sich also wirklich und sagen: Okay, wir können mehrere Medallion-Architekturen in einem Unternehmen haben. Und tatsächlich geben Sie sogar zu, dass die meisten Unternehmen mehrere Medallion-Architekturen haben. Eine der Ebenen, die mich in diesem Zusammenhang sehr interessiert, ist die von Ihnen so bezeichnete Produktdesign- und Vertriebsebene.

Ich stelle hier also sehr detaillierte Fragen. Ich hoffe, du kannst dich an all das erinnern, Piethein. Kannst du also ein wenig näher darauf eingehen, worum es bei dieser Schicht geht?

Weil ich denke, dass das eine vielversprechende Ebene ist. Ja. Um auf Ihren vorherigen Punkt zurückzukommen: Ich denke, das ist keine Annahme.

Wenn Sie groß sind, werden Sie mit Sicherheit viele dieser Medaillon-Architekturen haben. Und das Design dieser Architekturen wird sich je nach Größe, Anzahl der Quellsysteme und je nachdem, ob Sie eher provider- oder verbraucherorientiert sind, unterscheiden. In meinem Buch definiere ich daher verschiedene Archetypen, je nach Art des Bereichs und wie Sie sich am besten organisieren und ausrichten können, einschließlich dieser verschiedenen Ebenen.

In dieser Multi-Medallion-Architektur möchten Sie jedoch, wenn Sie beginnen, Daten nahtlos auszutauschen, auf hochwertige, wiederverwendbare und stabile Daten zurückgreifen können. Daher wird Ihr Datenmodell meiner Meinung nach viel mehr zu einem Schnittstellenmodell. Und genau dafür ist diese Datenproduktschicht da.

Um diese robusten, stabilen Daten bereitzustellen, kommen hier viele Richtlinien für die Datenmodellierung ins Spiel, beispielsweise wie mit Referenzdaten umgegangen werden soll. Um ein einfaches Beispiel zu nennen: Stellen Sie sich vor, Sie haben mehrere Domänen, mehrere dieser Medallian-Architekturen, die alle isolation voneinander isolation, ihre Datenstrukturen überarbeiten und diese Datenprobleme verursachen. Sie stimmen sich jedoch nicht auf Datenstandards oder Referenzdaten ab.

Für die Verbraucher wird es dann letztendlich sehr schwierig sein, Daten einfach zu kombinieren, da sie beispielsweise mit unterschiedlichen lokalen Referenzwerten und nicht konformen Datentypen zu kämpfen haben. In meinem Bereich sollten daher all diesen verschiedenen Teams zahlreiche Leitlinien zur Datenmodellierung zur Verfügung gestellt werden. So modellieren und formulieren sie ihre Daten auf eine bestimmte Weise neu.

All diese verschiedenen Teams können diese Daten leicht interpretieren, verarbeiten, kombinieren und so weiter. Ja, wie Sie in dem Buch gelernt haben, ist das Thema ziemlich umfangreich. Es sollte also jede Menge Anleitung vorhanden sein.

Nein, aber in der Tat, aber ich betrachte diese Ebene als eine wirklich wichtige Ebene für Menschen, die bestrebt sind, dezentralere Ansätze für die Datenarchitekturen insgesamt voranzutreiben. Richtig? Ja.

Vielleicht, vielleicht haben wir noch Zeit für eine weitere Frage, denn bevor ich das Mikrofon an Martin übergebe, werde ich meine Kamera eingeschaltet lassen und vielleicht ein oder zwei Worte sagen, aber ich möchte wirklich Martin die Gelegenheit geben, seine Fragen zu beantworten. Sie sind ausgezeichnet. Also, eine letzte Frage für mich lautet: Sie haben ein Konzept, das Sie „Medallion Mesh“ nennen.

Wir können kurz darüber sprechen, bevor ich das Mikrofon an Martin übergebe. Was ist das Medaillon-Netz? Kennen Sie das Daten-Netz?

Äh, richtig? Also und verteilte föderierte Architektur, verschiedene Teams, sie alle betreiben ihre eigenen, sagen wir mal, kleinen Datenarchitekturen, und sie verteilen Daten über wenn Sie Ihre Daten gemäß der gerade besprochenen Medaillon-Schichtung schichten. Und alle diese Teams machen das auf ähnliche Weise.

Das nenne ich eine Medaillon-Netzwerkarchitektur. Aber wichtig ist hier, und ich denke, dass es nicht per se so sehr um die Schichtung geht. Ich denke, es geht mehr um die Schichtung auf Unternehmensebene.

Es handelt sich um ein Kommunikationsmuster. Und oft sehe ich, dass dabei Fehler auftreten, weil Teams voneinander ableiten, wie die Schichtung innerhalb dieser verschiedenen Architekturen erfolgt. Daher empfehle ich, die Medaillon-Schichtung als Kommunikationsmuster zu verwenden.

Alle diese Teams halten sich also eher an die gleiche Art und Weise, wie sie ihre Daten innerhalb dieser verschiedenen Architekturen organisieren, was die Verteilung und den Austausch von Daten zwischen diesen verschiedenen kleinen Architekturen erleichtert. Ich finde, das ist eine wunderbare Aussage, um das Wort an Martin weiterzugeben. Martin und ich sind noch wach.

Hat der Kaffee gewirkt? Ja, ja, ich bin da. Wunderbar, Martin.

Ich habe nur im Hintergrund mitgelauscht. Das war also eine großartige Interviewreihe. Großartige, großartige Fragen.

Zunächst einmal möchte ich sagen: Ja, Ole, vielen Dank für die Einladung. Als Einleitung möchte ich sagen, dass es mir eine Ehre ist, hier in Anwesenheit von zwei O'Reilly-Autoren zu sein. Ihr wisst, ihr seid sehr geehrt und allesamt Persönlichkeiten in der Welt der Daten.

Äh, ich denke, ich bin hier als Datenarchitekt tätig bei einem kleinen Ingenieurbüro in Melbourne, Australien. Und ich werde einfach die Rolle übernehmen, den Laien-Datenarchitekten in dieser ganzen Angelegenheit zu vertreten. Ja.

Ähm, hoffentlich kann ich auch die Fragen, die möglicherweise noch kommen werden, angemessen beantworten. Nur zum Kontext: Ich möchte meine Position damit beginnen, dass ich, als Ole Pietheins Buch auf LinkedIn lobte, ihm in einem Kommentar halb im Scherz sagte: „Oh, ich glaube, ich muss mich ernsthaft mit dir unterhalten. Ole, ich respektiere deine Meinung und hoffe, dass du mich vom Gegenteil überzeugen kannst.“

Aber Medaillon-Architekturen sind seit etwa 20 Jahren meine größte Frustration als Datenarchitekt. Das soll das Ganze etwas relativieren. Und das hatte auch einen ernsten Hintergrund, eine Art Anstoß, ich hoffe, ich kann dich als Freund bezeichnen, weißt du?

Ähm, ich denke, hier kommt Pietheins Buch ins Spiel, denn ich habe das geschickt, ohne Pietheins Buch gelesen zu haben, richtig? Also dachte ich mir, ich sollte das Buch besser lesen, damit ich, wenn man einmal angefangen hat, sich damit zu beschäftigen, sagen kann: Ja, wir sollten darüber diskutieren. Ähm, und ich fand, es ist ein ausgezeichnetes Buch.

Wissen Sie, wie Sie schon sagten, gibt es meiner Meinung nach nicht allzu viele Bücher, die Medaillonarchitekturen erklären. Und tatsächlich stammt dieser Begriff aus der Welt von Databricks und Lakehouse. Oder, genauer gesagt, aus der Daten-Lake .

Und ich denke, das war eine der Herausforderungen, dass es von verschiedenen Menschen unterschiedlich interpretiert wird. Und es gibt kein Forum, um darüber zu diskutieren. Dieses Buch bietet uns ein Forum für Diskussionen.

Jetzt fällt mir gerade ein, während ich Ihnen zuhöre, Ole Frage Piethein, dass eine weitere mögliche Verbesserung des Buches tatsächlich darin bestehen könnte, vielleicht einige der verschiedenen Verwendungsmöglichkeiten von Medaillons einzubeziehen und fast so etwas wie einen Ansatz mit Mustern und Anti-Mustern zu verfolgen. Ja. Ja.

Denn ich bin mir sicher, dass wir uns wahrscheinlich auf einige der Anti-Muster einigen könnten, die wir sehen. Ja. Aber wie auch immer, ich wollte als Einleitung meine Ausführungen wirklich auf drei Argumentationsbereiche konzentrieren.

Und meistens geht es eher darum, nach vorne zu schauen als zurück. Richtig? Anstatt also zu erklären, wie wir hierher gekommen sind – was Pietheins Buch meiner Meinung nach hervorragend leistet –, sollten wir lieber darüber nachdenken, wie es jetzt weitergeht.

Ja. Angesichts dessen, dass wir wissen, dass Unternehmen meiner Meinung nach größere Herausforderungen denn je bewältigen müssen, um herauszufinden, wie sie ihre Architekturen weiterentwickeln können. Und ich denke, ein Teil dieser Herausforderungen besteht interessanterweise darin, dass das Wort „Daten” an Bedeutung gewonnen hat, weil es mit KI in Verbindung gebracht wird.

Ich sehe das sogar in meiner kleinen Ingenieursberatung, dass ich plötzlich eine Reihe von Softwareentwicklern oder Ingenieuren habe, die KI-Anwendungen entwickeln wollen und sich dann fragen: Okay, wie komme ich an die Daten dafür? Sie brauchen also eine Quelle. Lassen Sie mich zunächst meine drei Argumente zusammenfassen.

Mein erstes Argument war also eine allgemeine Kritik an mehrschichtigen Architekten, mehrschichtigen Architekturen im Allgemeinen, die nicht wirklich etwas mit Medaillons zu tun hat. Und eigentlich stimme ich dir zu, Ole, in dem Sinne, dass ich denke, dass mehrschichtige Architektur nie aus der Mode kommen wird. Aber ich denke, mein Punkt ist, dass, wenn man sich den Anwendungsbereich ansieht, ich mich noch an Client-Server-Architekturen erinnern kann, und dann sind wir zu drei Schichten übergegangen.

Man hat eine Benutzeroberfläche, eine Geschäftslogik und eine Datenspeicherschicht oder so etwas in der Art. Und das gibt es immer noch. Wenn ich mir die GitHub-Projekte der meisten Leute anschaue oder die Git-Projekte, die wir als Everest erstellen, dann gibt es wahrscheinlich drei Schichten innerhalb der Dateistruktur.

Ja. Und man kann sie sehen, man wird eindeutig darauf hingewiesen. Aber interessanterweise sind wir als Anwendungsentwickler meiner Meinung nach darüber hinausgegangen, obwohl das bereits integriert ist.

Wir haben gesagt: Okay, ja, ja, schau mal, wir haben die drei Schichten. Ähm, wissen Sie, die interessieren uns nicht, denn was uns interessiert, ist vielleicht die hexagonale Architektur, die saubere Architektur, vielleicht schauen wir uns eher einige von, sagen wir, Martin Fowlers Patenten für Unternehmensanwendungen, Patenten für Unternehmensarchitektur-Anwendungen an, oder wir schauen uns einen AWS- oder Azure-Architekturstil für Anwendungsarchitekturen an. Und dann gibt es eine Debatte über all diese Nuancen des Architekturmodells, die dann, um das Problem zu lösen, in gewisser Weise über die Ebene hinausgehen.

Richtig? Es ist keine Entweder-oder-Diskussion. Es ist ein Ja und, richtig?

Und das ist, glaube ich, das Thema, mit dem wir uns im Zusammenhang mit Daten beschäftigen müssen, worauf Sie, Piethein, in Ihrem Buch ohnehin schon anspielen, wenn Sie auf das erste der drei Beispiele eingehen, die wirklich sehr gut sind. Ich denke, die Fallstudien sind es wert, dass jeder, der das Buch liest, sie durchgeht, denn es sind Beispiele aus dem realen Leben von Unternehmen, die die Medaillon-Architektur einsetzen. Ja.

Aber ich denke, hinter diesen Fallstudien steckt eine Art Ja-und-Diskussion. Ja. Ja, wir haben Medaillons, aber, sorry, nicht aber, und wir wollen mehr tun und wir wollen einen größeren Mehrwert bieten, und wie sollen wir das machen? Ja.

Das ist also eine Art Marktzahl. Das war wirklich schön. Äh, ich habe es am meisten genossen, sie zu interviewen, weil sie die Mendel'sche Architektur verwendet haben, aber sie haben auch schnell erkannt, dass wir sie durch viel mehr ergänzen müssen. Also gibt es die ereignisgesteuerte Architektur.

Wir möchten eine Anwendungsintegration durchführen und datenintensive Anwendungen erstellen. Wie lässt sich das mit der Medallian-Architektur vereinbaren? Wo ziehen wir die Grenzen zwischen einer Anwendung und der Verteilung von Daten auf verschiedene Teams?

Ja, es war wirklich ein nettes Gespräch, das ich mit ihnen geführt habe. Ja, perfekt. Ich meine, und das ist eigentlich die Anwendung, die ich, das ist das Gespräch, das ich mit Unternehmen führe, nämlich: Okay, Sie haben vielleicht ein Databricks-Setup oder ein Snowflake- oder ein Azure-Setup, aber wie wollen Sie das dann wieder in die Anwendungsschicht integrieren?

Denn genau dort schöpfen Sie Wert aus Ihren Daten, weil Sie Entscheidungen getroffen haben und diese Entscheidungen nun tatsächlich umsetzen. Ja. Und ja, ich habe einen Favoriten, nämlich das umgekehrte Muster.

Nun ja, manchmal ist es umgekehrtes ETL, aber es ist einfach die Integration, wenn man so will, der Entscheidungsfindung, nennen wir es den Entscheidungsteil und den Handlungsteil. Ja. Ja.

Ähm, das war also mein erstes Argument. Das zweite Argument war eigentlich das KI-Argument. Und das führt uns zu dem Punkt, über den wir am Anfang schon ein wenig gesprochen haben.

Und das hängt damit zusammen, dass ich denke, dass in vielen Unternehmen, die ich derzeit beobachte, die Datenverantwortlichen plötzlich über die Köpfe der Technologieabteilung hinausragen, weil der CEO plötzlich etwas im Bereich KI erreichen möchte. Sie möchten, ich weiß nicht, KI-Agenten oder etwas in der Art, richtig? Und wie die erste Frage aufkommt, habe ich bereits erwähnt: Der Anwendungsentwickler fragt: Woher bekomme ich die Daten?

Richtig? Wie soll ich, weißt du, du hast mir gesagt, ich muss ein Gestell bauen. Wie baue ich dieses Gestell?

Richtig? Woher kommt der Kontext für die Organisation? Richtig?

Der Kontext wird irgendwo innerhalb der Data Layer gespeichert. Anstatt also diesen, sagen wir mal, Monolithen zu haben, der einfach nur von einer ausgewählten Anzahl von Datenteams kuratiert wird, fühlt es sich so an, als würde er in die Anwendungsarchitektur des Unternehmens hineingezogen. Und ich denke, dass uns das dann auch von einer reinen Medaillonstruktur wegführt und uns mehr dazu bringt, darüber nachzudenken, wie die operativen und analytischen Ebenen eines Unternehmens beginnen, sich zu integrieren, um KI zu bedienen.

Und dann ist da noch das dritte Argument, nämlich das altbekannte Argument der Daten-Mesh-Datenprodukt-Ausrichtung. Tatsächlich haben Sie dies in Ihrem Buch angesprochen, als ich es schließlich gelesen habe. In Teil vier des Buches, ich glaube, es ist Kapitel 12 oder 13, haben Sie tatsächlich ein...

Ähm, 12, nein, ich glaube, es ist 13. Nein, nein, 13 ist die generative ai, und vielleicht ist 11 die skalierende, wo man anfängt, über Daten-Mesh zu sprechen. Und ich denke, dass man tatsächlich beginnt, die Domäne und die föderierte Struktur in den Vordergrund zu stellen und die Schichtstruktur in gewisser Weise in den Hintergrund, damit beantworten Sie eigentlich meine Frage, denn Sie sagen plötzlich, wissen Sie, Sie sagen gewissermaßen, dass eine der Zukunftsvisionen, die wir uns vorstellen können, darin besteht, dass das Datenprodukt und eine polyglotte Art der Datenmodellierungsarchitektur innerhalb von Organisationen eine dominierende Rolle einnehmen.

Und tatsächlich sieht man das in gewisser Weise auch in vielen großen Organisationen. Ja. Das sind also meine drei Argumente, die vor allem auf die Zukunft ausgerichtet sind. Es ist also fast so, als würden wir sagen: „Okay, wir wollen Medaillen lernen, weil ich denke, dass sie ein wichtiger Teil unserer Geschichte sind, aber ich glaube nicht, dass wir uns zu sehr auf Medaillen konzentrieren sollten.“

Auf jeden Fall. Ja. Wenn ich darüber nachdenke, dann denke ich an das letzte Kapitel, in dem ich den Teil über KI vorgestellt habe. Ich glaube, ich würde es jetzt wahrscheinlich komplett umschreiben, auf eine andere Art und Weise, da ich weiß, dass sich die Dinge wahnsinnig schnell entwickeln.

Aber eine meiner Entdeckungen, über die wir uns zuvor kurz unterhalten haben, ist, dass wir hier in der Organisation, in der ich derzeit arbeite, bereits mit Agenten experimentieren. Wir haben eine ganze Reihe von Agenten in der Produktion, aber wir sehen zwei Arten von Agenten, Agenten, die eher datenorientiert sind, wie ich sie nenne. Also gewöhnliche Chatbots oder ein Agent, der, ich weiß nicht, eine Datenbank durchsucht oder eine Suche durchführt oder sich beispielsweise ein historisches Profil ansieht oder Customer 360 macht.

Dort könnte die Medallian-Architektur meiner Meinung nach Sinn machen. Wir haben also eine Richtung festgelegt, in der wir Agenten und Zeitbereiche vorsehen, die der Mendelian-Architektur nahekommen, aber wir sehen auch Agenten, die wahrscheinlich den operativen Quellsystemen nahekommen, innerhalb der Anwendungsdomäne. Diese bezeichnen wir als operativ ausgerichtete Agenten.

Und diese sind kontextsensitiv und arbeiten mit geringer Latenz und hohen Volumina. Und dort brauchen wir meiner Meinung nach eine andere Art von Architektur. Wahrscheinlich benötigen Sie also operative Datenspeicher oder datenintensive Anwendungen.

Also, andere Muster und das ist ein Risiko, das ich sehe. Und vielleicht ist es gut, dass Sie das erwähnt haben und wir sollten das mitnehmen, dass Leser oder Zuhörer das vielleicht interpretieren könnten. Nun, die Medaillon-Architektur macht das alles, und ich halte das für ein falsches Argument.

Es deckt einen bestimmten Bereich ab, aber Sie müssen es durch die Dinge ergänzen, die Sie bereits erwähnt haben. Ja. Okay.

Nein, das macht durchaus Sinn. Ähm, ich meine, eine der Erkenntnisse, die ich dabei gewonnen habe, ist, dass die meisten Leute, die meisten Implementierungen, die ich gesehen habe, innerhalb der Silber-Schicht eine Kombination von Kontexten vornehmen. Ich meine, vielleicht nennt man das ein Anti-Muster, aber ich habe häufiger gesehen, dass verschiedene Kontexte kombiniert werden.

Würden Sie das als Anti-Muster bezeichnen? Ja, ich denke, es ist eine verpasste Gelegenheit, wenn man den authentischen Kontext nicht in historisierter Form bewahrt. Viele Anwendungsfälle erfordern die Historisierung authentischer Daten in einer sich langsam verändernden Dimension, weil man trainieren Maschinelles Lernen für operatives Maschinelles Lernen oder operative Berichte trainieren möchte.

Wenn man zu schnell mit der Kombination und Integration beginnt, verliert man diese Möglichkeit, was man natürlich mit einem zusätzlichen operativen Datenspeicher überwinden kann. Sie laden die Daten in eine andere Architektur aus. Aber ich denke, dass sich hier eine Chance bietet, und nein, damit werden sicherlich nicht alle operativen Anforderungen erfüllt, aber Sie könnten es in dieser Hinsicht nutzen, und deshalb schlage ich vor, diese Maßnahme der Querschnittskombination und -integration auf die letzte Ebene zu verschieben.

Aber Sie haben Recht, ich sehe viele Organisationen, die bereits in Silver damit beginnen, es zu kombinieren, zu verschmelzen und zu integrieren. Man kann auch beides machen, oder? Man kann also diesen eher operativen Datenspeicher-Typ aufbauen und diese Daten in Silver aufbewahren, und daneben hat man diese Integration, die klassische Integration.

Das ist in Ordnung. Zumindest, dass Sie diese Bedenken mitnehmen und sich damit befassen. Das ist richtig.

Das klingt, als wäre es besonders, wissen Sie, ich glaube, ich habe es vorhin erwähnt oder Sie haben data vault erwähnt, wissen Sie, es fühlt sich so an, als wäre die Silver Layer der Ort, an dem data vault, oder zumindest der Hauptteil des data vault , vielleicht den Business Vault einrichten data vault . Würden Sie sagen, dass der Business Vault dann die Gold Layer ist? Ja.

Es ist eher die Goldschicht und die Rolle des Vaults oder die Integrationsschicht, die man oft bei Silver sieht. Ähm, ich bin ehrlich gesagt kein großer Fan von data vault. Nicht wegen der Methodik oder den Designprinzipien.

Sie bieten Ihnen sicherlich viel Flexibilität, aber es ist die zugrunde liegende Technologiearchitektur, die diese Art der Datenmodellierung nicht wirklich erleichtert. Deshalb arbeiten wir bei Lakehouse mit einer verteilten Architektur, in der die Speicherung und die Berechnung voneinander entkoppelt sind. Wenn Sie also Tausende oder Millionen winziger parquet erstellen, die über alle Server im Rechenzentrum verteilt sind, werden Sie mit Sicherheit mit dem Netzwerk zu kämpfen haben.

In meiner früheren Position habe ich mit vielen Unternehmen zusammengearbeitet, die sich für Daten für das Design entschieden hatten oder ursprünglich dafür entschieden hatten, aber sie mussten damit aufhören, weil sie die Netzwerkprobleme nicht überwinden konnten. Sicher. Das ist interessant.

Ich meine, ja, möchtest du mit einigen der Fragen einsteigen, die du siehst, Ole? Ähm, entschuldige bitte. Ich glaube, es gibt nur eine Verzögerung von ein oder zwei Sekunden.

Äh, entschuldigen Sie bitte, dass ich Sie unterbrochen habe, Martin. Ähm, bitte fahren Sie fort.

Ich habe mir die Fragen im Chat angesehen, und sie sind großartig. Vielen Dank an alle für die ausführlichen Diskussionen, Ratschläge und Standpunkte. Natürlich sind sich hier nicht alle einig, worüber ich sehr froh bin.

Ich denke, wir sollten weitermachen, aber Martin, ich wollte dir nicht ins Wort fallen. Also, möchtest du noch mehr Fragen stellen oder sollen wir eine Frage entgegennehmen? Ist alles in Ordnung?

Nein, Nein. Du, du übernimmst Ole. Okay.

Okay. Um darauf weiter einzugehen, ich glaube, ich habe noch eine Frage, die ich zum Abschluss Ihres Gesprächs, Martin, mit Piethein stellen möchte. Ich würde gerne wissen, wo die Grenzen der Medaillonarchitektur liegen, also was außerhalb der Medaillonarchitektur liegt. Ich würde das gerne klarer definiert sehen, aber vielleicht beenden wir das Gespräch mit dieser Frage.

Ich denke, einige der Teilnehmer dieser Telefonkonferenz verdienen es, ihre Fragen zu stellen. So fragt beispielsweise Anyana – ich hoffe, ich spreche das richtig aus – ob wir wirklich eine Landing Zone vor der Bronze-Ebene brauchen. Wie sehen die Szenarien aus?

Vielleicht sollten wir uns Gedanken über die Landezone machen, bevor wir uns überhaupt mit Bronze beschäftigen. Ja. Mach du das.

Sie heben diesen Punkt in Ihrem Buch hervor und diskutieren ihn. Ja, absolut. Es gibt sogar viele Seiten, auf denen Sie die Nuancen und Kompromisse in diesem Zusammenhang beschreiben.

Zunächst einmal geht es um weitere Auslegungsfragen. Manchmal haben einige Leute die Landezone zu einem Teil ihrer Medaillonarchitekturen gemacht. Andere zeichnen und positionieren sie eindeutig außerhalb.

Zunächst müssen Sie sich also darauf einigen, wie die Bereitstellung der Medaillon-Architektur zu interpretieren ist. In einigen Fällen habe ich jedoch beobachtet, dass es ratsam sein kann, die Daten vorübergehend zu speichern oder irgendwo abzulegen, bevor sie in die formelle Bronze-Schicht übertragen werden, wenn Sie keine robusten oder sicheren Erfassungsmuster haben. Auch dies hängt davon ab, wie Sie die Bronze-Schicht gestalten, aber dies ist meiner Erfahrung nach für viele Unternehmen ein Anreiz, eine zusätzliche Zwischenablagezone einzurichten.

Es ist nicht verpflichtend. Es ist eher eine optionale Sache. Das sollte man auch erwähnen.

Auf jeden Fall. Ja. Fahren wir fort.

Es gibt also eine Frage von John O'Gorman, die tatsächlich in die Fragerunde aufgenommen wurde. Ich frage mich nur, ob wir Prioritäten setzen sollten, was in die Fragerunde aufgenommen wird, oder ob Sie möchten, dass... Nein, nein, bitte. Nehmen wir sie einfach nach Interesse auf.

Lassen Sie uns John O's Frage hören. Es ist toll, dass er hier ist. Er fragt also, ob die Existenz von Medaillon-Architektur von der fortgesetzten Verwendung von ETL-Prozessen abhängt.

Anders ausgedrückt: Wird eine alternative Architektur wie datenzentriert in Kombination mit dem Einsatz von KI zum Erstellen von Anwendungen eine Rolle spielen? Ich muss sagen, ich bin mir nicht ganz sicher, ob ich die Frage verstehe, aber nicht ich. Gleiches gilt für mich.

Willst du es annehmen, Piethein? Ich denke, dass die Schichtung meiner Meinung nach immer da sein wird, und das ist nichts Neues. Richtig.

Ich habe auch am Anfang des Buches erklärt, dass wir aus traditionellen klassischen Unternehmensdatenlagern kommen. Die Schichtung hat gute Gründe, und das wird sich nicht ändern, und dieser Teil wird nicht verschwinden. Man könnte natürlich fragen, ob man das virtuell machen könnte, Echtzeit?

Was wird KI irgendwann für die Schichtung bedeuten?

Kannst du einen bestimmten Teil überspringen? Ich weiß es nicht. Aber die Dinge werden sich auf jeden Fall ändern.

Vielleicht ist das meine Sichtweise auf die Antwort auf diese Frage. Ich meine, Ihre derzeitige Arbeit mit den Agenten, mit den KI-Agenten, beantwortet meiner Meinung nach den zweiten Teil von Johns Frage. Ja.

Was effektiv nicht der Fall ist, da ich Agenten wie viele Anwendungen sehe, wissen Sie, das sind viele Code-Teile, die Daten aus einer Medaillon-Architektur abrufen können, aber sie könnten genauso gut Daten direkt aus einer Anwendung oder einem Quellsystem abrufen. Wenn Sie die genauesten Daten benötigen, werden Sie sich natürlich direkt an das Quellsystem wenden, oder? Sie rufen einen API-Endpunkt auf und verwenden keine Daten aus der Medaillon-Architektur.

Aber für vielleicht asynchrone Anwendungsfälle könnte man durchaus in Betracht ziehen, diese Daten zu verwenden. Auch hier gibt es wieder viele Nuancen. Aber dieser Teil wurde in dem Buch nicht wirklich gut beschrieben.

Ich musste mich einschränken und mich auf maximal 300 Seiten beschränken. Ja. Ja.

300 Eigentlich war das das andere Gespräch, das wir geführt haben, bevor alle anderen dazukamen, nämlich dass man, wenn man wirklich alles in Medallion ansprechen wollte, vielleicht ein 600-seitiges Buch schreiben müsste. Ja. Ja.

Und das ist für O'Reilly nicht praktikabel zu veröffentlichen. Ja. Nein, nein.

Es gibt so viele Dinge, die auch... Ich denke, es ist eine Herausforderung, ein Buch über Technik zu schreiben, das nicht schnell veraltet. Und ich denke, je länger es dauert, desto schwieriger wird es.

Aber es gibt eine Frage von Tia, ich hoffe, ich spreche das wieder richtig aus. Als Product Owner einer Organisation, die ein Medaillon aufbaut, waren wir gezwungen, Bronze zu nehmen, weil Silber nicht verfügbar war. Dann haben sie Silber eingeführt und die Namen der Dinge in geschäftsfreundliche Namen geändert.

Nach zwei Jahren Arbeit an unserem Datenprodukt hatten wir eine große Entdeckung für die Umgestaltung des Zwecklagers zu Silber gemacht. Würde es sich lohnen? Hast du die Frage kopiert, Piethein?

Das ist wieder eine schwierige Frage, aber ja, das ist es. Es tut mir leid, das zum ersten Mal zu hören. Ähm, ja, ich hoffe für Sie, dass die Dinge einfacher waren, aber ja, bitte sehen Sie sich die Anleitung an und versuchen Sie, so gut wie möglich die dortigen Best Practices und Empfehlungen zu befolgen.

Aber ja, Gold als direkte Ebene für die direkte Eingabe von Datenprodukten zu verwenden, gefällt mir persönlich nicht, weil man dadurch wieder eng an die Strukturen des Quellsystems und die Anwendung gebunden ist, die man auf der linken Seite als Eingabe findet. Ich bin daher viel mehr dafür, die Dinge zu entkoppeln. Also wieder eine zusätzliche Ebene zu haben und dann die Daten aus der Silber-Ebene zu ziehen.

Und was Datenprodukte angeht, so gibt es, wie ich auch in meinem Buch geschrieben habe, verschiedene Arten von Datenprodukten. Ich unterscheide dabei eher zwischen operativ ausgerichteten Datenprodukten. Ich denke, Silver ist dafür ein perfekter Kandidat.

Und Sie haben eher analytische Datenprodukte, bei denen Daten kombiniert und zusammengetragen, kuratiert und wahrscheinlich die Goldschichtenkandidaten dafür sind.

Ja, ich finde Tias Frage sehr gut. Ich würde hier einwerfen, dass ich, wenn ich mit Tia zusammenarbeiten würde, versuchen würde, mich auf die Zusammenarbeit innerhalb der Organisation zu konzentrieren, anstatt mich strikt an Medaillen und Gold, Silber und Bronze zu halten. Denn es scheint, als sei die Herausforderung weniger darin zu bestehen, sich an eine Architektur zu halten, sondern vielmehr darin, den Stakeholdern einen geschäftlichen Mehrwert zu bieten.

Zumindest lese ich hier vielleicht zwischen den Zeilen, aber das ist das Gefühl, das ich habe. Ja. Und es ist auch das Ist das Dilemma.

Auch das halte ich für ein Dilemma. Ich habe bereits im ersten Kapitel darauf hingewiesen, dass es einen ständigen Druck seitens des Unternehmens gibt, diese Dinge schnell zu liefern. Im Gegensatz dazu möchten wir unsere Modelle sorgfältig entwerfen, dokumentieren, gut ausführen, entkoppeln und so weiter.

Und ja, diese beiden Dinge gehen nicht Hand in Hand. Deshalb sehe ich oft, dass Teams Abkürzungen nehmen, um das Geschäft mit seinen hohen Anforderungen zu erleichtern. Und daran anknüpfend, Piethein, gibt es eine Frage von Floris, die wirklich das weiterführt, was Sie gerade gesagt haben.

Wie würden Sie mit organisatorischen Herausforderungen, insbesondere mit Veränderungen auf Vorstandsebene, bei der Anwendung einer Medaillonarchitektur umgehen? Wie würden Sie diese verkaufen? Ich weiß, dass sie manchmal als zu simpel angesehen wird, als reines Marketing.

In gewisser Weise schon, aber ich habe im Laufe der Zeit gelernt, dass es wirklich funktioniert. Insofern könnte man meiner Meinung nach abstrakt von verschiedenen Ebenen und Schwerpunkten sprechen; man könnte Personas entwickeln und argumentieren, dass beispielsweise Datenverwalter eher im Bereich Silber, vielleicht auch Gold, arbeiten, während sich die Business-Analysten beispielsweise mit Gold befassen würden.

Es handelt sich also um geschäftsfreundliche Bezeichnungen, richtig? Bronze, Silber, Gold. Sie ersetzen all die verschiedenen Bezeichnungen, die wir für die klassischen Ebenen hatten, wie Staging-Umgebung, Landing Zone, kuratierte Ebene, Integrationsebene.

Es ist geschäftsfreundlicher. Das ist genau die andere Frage, die ich hatte, richtig? Denn es gibt etwas, das ich in dem Text gesehen habe und fragen wollte.

Ähm, wo ist es?

Ähm, ja, das ist von Heni. Ich bin ein großer Befürworter des Architekturmodells, aber ich versuche, das wachsende Interesse an der Medaillon-Architektur zu verstehen und wie sie sich von herkömmlichen Data-Warehouse-Schichten wie der Staging-Schicht, der Basisschicht und der Datenmodellierung unterscheidet. Vielleicht könnten Sie ein wenig näher darauf eingehen, was Sie bereits gesagt haben, Piethein.

Das ist eine ausgezeichnete Frage. Ehrlich gesagt unterscheidet es sich nicht wirklich von dem, was wir früher mit Enterprise Data Warehousing gemacht haben oder wie wir verwalten einem Daten-Lake verwalten würden. Es ist eher so, dass diese Anbieter die Verwendung dieser geschäftsfreundlichen Labels fördern.

Und sie arbeiten mit den Führungskräften und auf Managementebene zusammen. Und aus der Ferne betrachtet scheint das alle Probleme zu lösen, denn jetzt haben wir geschäftsfreundliche Labels, und diese Anliegen sind gut aufeinander abgestimmt. Aber in der Praxis unterscheidet sich das nicht von der wirklich harten Arbeit , die man beispielsweise in den Aufbau eines fantastischen Data Warehouse investieren musste.

Ja. So wie Sie, bitte, Martin, fahren Sie fort. Ich wollte mich einmischen, weil ich in der Praxis gesehen habe, dass dies passiert, wenn ein bestimmter Anbieter hereinkommt und sagt: Nein, wissen Sie was?

Ihre Datenarchitekten machen alles falsch. Sie haben diese Staging-Ebenen und solche Dinge, es sollte alles Medaillon, Bronze, Silber, Gold sein, richtig? Lassen Sie uns unsere Berater schicken, um Ihre Aufgaben zu übernehmen.

Und wissen Sie, zumindest in dem konkreten Beispiel, an das ich denke, fand ich das sehr respektlos gegenüber den Leuten in der Organisation, die – ich war übrigens ein externer Berater, richtig? Also, wissen Sie, ich habe eine Entscheidung getroffen, aber mit diesem bestimmten Anbieter war ich nicht besonders zufrieden. Wir kombinieren jetzt auch, was ich sehe, zum Beispiel in meiner Organisation, wir haben viele verschiedene Medallian-Architekturen.

Wir verwenden also die geschäftsfreundlichen Bezeichnungen, um abstrakt die Anliegen und Vorgänge zu beschreiben. Darunter gibt es dann eher physische Ebenen, die unterschiedliche Namen haben. Es gibt eine Rohzone, eine kuratierte Zone, eine Anreicherungszone, eine integrierte Zone, was auch immer.

Und wir überlassen es den Technikern, wie sie diese Bedenken eher auf physikalischer Ebene beschreiben. Ja. Ich sehe, dass wir uns wieder der Stunde nähern, die Zeit ist schneller vergangen, als ich erwartet hatte.

Ich meine, natürlich ist das eine technische Diskussion, und ich dachte, wir hätten Zeit, über mehr Dinge zu sprechen, als wir bereits besprochen haben. Aber die Zeit ist um. Ich meine, bevor Sie die Zeit abrufen, Ole, gibt es noch eine Frage, die ich gerne kurz ansprechen möchte, die eigentlich keine Medaillon-Frage ist, sondern von Juan Cecada stammt, der sagt: dringend versus wichtig, kurzfristig versus langfristig.

Das ist das große Dilemma: Wie soll man es ausdrücken, wie soll man es richtig in Anreizstrukturen einbauen? Wie bringen wir die Menschen dazu, ihr Gemüse zu essen und ins Fitnessstudio zu gehen? Und ich wollte eine Antwort darauf vorschlagen.

A, wissen Sie, eine Art Ansatz mit kleinen Gewohnheiten. Ja. Und die Idee, dass man nicht über Nacht 20 Kilo abnehmen kann.

Man kann 20 Kilo abnehmen, wenn man jeden Tag sich verbessert oder, wissen Sie, gute Gewohnheiten praktiziert, gute Essgewohnheiten, gute Bewegungsgewohnheiten usw., und fast jeden Tag wieder von vorne anfängt. Und so, wissen Sie, ich denke, das ist die Antwort auf viele Fragen, Dinge wie eine allgemeine Antwort, um zu sagen: Okay, Sie lösen Ihr Medaillon-Problem nicht, indem Sie einfach alles wegwerfen. Und neu anfangen und sagen: Jetzt machen wir eine neue Fitness-Diät.

Richtig? Löse die Probleme durch kleine Gewohnheiten jeden Tag. Versuche, besser darin zu werden, Dinge zu erklären, und verbessere deine Disziplin bei der Art und Weise, wie du Dinge tust.

Besser darüber nachdenken, wie es sich an die Zukunft anpassen wird.

Zumindest wäre das mein Vorschlag gewesen, um zu versuchen, diese Debatte zu beenden. Vielen Dank. Einverstanden.

Vielen Dank an alle. Es gibt eine kleine Verzögerung. Es tut mir leid, dass ich dich nicht unterbreche, Piethein, und das ist nur ein kleiner Ausschnitt aus dem heutigen Tag.

Vielen Dank, Juan, für diesen letzten Kommentar. Sehr gut. Und vielen Dank, Martin, dass Sie so spät in der Nacht bei uns zugeschaltet haben.

Das ist sehr, sehr freundlich von Ihnen. Vielen Dank für die ausführlichen Fragen. Und natürlich, Piethein, vielen Dank, dass Sie sich heute Zeit genommen haben, um bei uns zu sein und Fragen zu beantworten.

Ich hoffe, es wurde heiß genug diskutiert. Wenn nicht, können die Leute gerne online weiterdiskutieren. Äh, Jano, bitte stellen Sie Ihre Frage.

Es ist schön, wieder von Ihnen zu hören. Und alle im Chat, Sie können sich jederzeit an uns wenden. Wir sind auf LinkedIn, Medium und Substack vertreten, sowohl Piethein als auch ich, Martin natürlich auch.

Also Piethein, vielen Dank. Danke Ole für die Organisation, vielen Dank. Gerne.

Danke. Danke euch beiden und allen anderen Teilnehmern. Danke.

Prost. Vielen Dank. Prost.

Tschüss. Cheer, take.