Der Weg ins Data Mesh – Diese Möglichkeiten gibt es

Hallo Stephan, hallo Roland, herzlich willkommen zum IoT Use Case Podcast. Ich freue mich mega, dass ihr heute mit dabei seid. Ich bin schon sehr gespannt auf die ganzen Insights, die ihr heute mitbringt. Stephan, wie geht’s dir und wo erreiche ich dich gerade?

Stephan

Hallo, Madeleine. Vielen Dank für die Einladung. Du erreichst mich heute mal wieder im Büro in München.

Sehr schön. Roland, wo bist du unterwegs? Bist du auch in München unterwegs oder wo erreiche ich dich gerade?

Roland

Hallo, Madeleine. Ich freue mich, hier zu sein. Ich bin heute in meinem Homeoffice, auch in der Nähe von München, zu finden.

Shoutout nach München an der Stelle. Ich bin beim nächsten Mal auch wieder in München. Da müssen wir uns mal vor Ort zum Kaffee zusammensetzen. Lasst uns doch mal ins Thema starten. Stephan, ihr von Steadforce seid ein IT-Systemberatungshaus, ihr macht viele Individualprojekte, habt aber ein ganz konkretes Offering. Ihr fokussiert euch auf das Thema Data Acquisition, also mit verschiedenen Datentypen die Daten in ein nächstes Level heben. Ihr beschäftigt euch sehr stark mit dem Thema Data Use: wie kann ich Anwendungen auf diesen Daten bauen? Das Thema Data Need: was mache ich eigentlich mit den Daten? Was ist so eine Use-Case-Entwicklung dahinter? Das Thema Data Management und Operations, also wie diese Kundenlösung dann betrieben wird und auf welcher Infrastruktur. Ihr seid, glaube ich, über 100 Expertinnen und Experten bei euch. Habe ich das erst mal so richtig gesagt?

Stephan

Ja, das klang schon mal sehr gut. Ich kann es tatsächlich nochmal etwas detaillieren. Wir beschäftigen uns damit, unseren Kunden zu helfen, datenbasierte Software-Lösungen zu bauen und damit Mehrwert zu generieren. Eine meiner Aufgaben in dem Kontext ist eben auch, unser gesamtes Service-Portfolio weiterzuentwickeln. Wir sind gerade dabei, das nochmal etwas zu verengen, einfach auf zwei Teilbereiche. Einmal den ganzen Bereich Data Management, wo es von der Datenstrategie losgeht, Use-Case-Entwicklung, bis hin zu einer Infrastruktur, beispielsweise in der Cloud oder mit einer Streaming-Lösung aufzusetzen. Wie kann ich die Daten beschaffen und bereitstellen? Auf der anderen Seite dann aber Use Cases darauf zu bauen, die in den Analytics-Bereich reingehen oder auch KI-basiert sind. Das mit einem Schwerpunkt in den Branchen Healthcare, Automotive und im Bereich Industrie, Manufacturing, Chemie. Das sind so die Kernbereiche.

Sehr schön. Ich weiß nicht, ob du wirklich Firmen nennen kannst, aber ihr seid sozusagen auch branchenübergreifend unterwegs in ganz verschiedenen Industrien und auch in der Wirtschaft. Je nach Kundensegment seid ihr da recht breit unterwegs wahrscheinlich, oder?

Stephan

Genauso ist es. Es ist natürlich immer ein bisschen schwierig Kunden zu nennen, es sind tatsächlich auch ganz unterschiedliche Größen, von kleinen Start-up-Unternehmen, wo wir auch so ein bisschen Business Enabler sind, bis hin zu ganz großen Konzernen, die im DAX notiert sind. Sehr, sehr breit an der Stelle.

Ein paar Referenzen kann man bei euch auf der Homepage sehen. Ich verlinke es mal in den Shownotes. Wirklich spannend, mit welchen Kunden ihr dort arbeitet. Jetzt hast du Roland mitgebracht. Wie kommt ihr eigentlich zusammen? Gibt es da eine persönliche Story oder wie arbeitet ihr zusammen?

Roland

Ja, wir sind als Starburst ein Softwareanbieter und wir stellen eine Data Access Plattform zur Verfügung. Dadurch, dass wir uns auf die Technologie fokussieren, benötigen wir kompetente Geschäftspartner, die uns dabei helfen, die Lösungen bei den Kunden einzusetzen. Wir arbeiten dort mit Unternehmen wie Steadforce zusammen, die mit ihren Expertisen im Datenumfeld und auch in der Architektur bei Kunden unsere Software mit einbauen, mit verwenden und somit aus der Technologie für den Kunden den Mehrwert generieren.

Stephan

Für uns ist es immer wichtig, dass wir nicht bei jedem Kunden das Rad neu erfinden müssen. Deswegen ist es gut, wenn wir strategische Partnerschaften mit Werkzeuganbietern haben, wie jetzt Starburst beispielsweise. Wir kommen eigentlich an der Stelle rein, wo es wirklich um das Thema Beratung geht. Denn wir kennen die Systemlandschaft beim Kunden, wir kennen die Use Cases, wir haben Überblick über die Daten und was damit gemacht werden soll. Wir sind an der Stelle in der Beratung und Integration unterwegs und da ergänzt sich das dann hervorragend.

Sehr schön. Jetzt hast du mir schon die perfekte Überleitung gegeben. Was für Use Cases bedient ihr gemeinsam mit Roland und dem Team von Starburst Data? Was für Use Cases sind das heute?

Stephan

Grundsätzlich geht es darum, dass wir Data-Mesh-Lösungen aufbauen. Das heißt, das ist erstmal per se unabhängig von einem konkreten fachlichen Use Case, sondern es geht letztlich darum, eine Dateninfrastruktur aufzubauen, um Analytics Lösungen zu ermöglichen.

Dieses Thema Data Mesh ist ja ein Konzept, erstmal ein großes Schlagwort. Ich glaube, einige Hörerinnen und Hörer haben davon schon mal gehört, andere vielleicht noch gar nicht. Roland, was hat es mit Data Mesh auf sich?

Roland

Data Mesh ist ein neues Konzept mit Daten umzugehen. Das wurde von Zhamak Dehghani entwickelt. Es geht darum, die Herausforderungen, die monolithische, zentralisierte Datenstrukturen mit sich bringen, aufzubrechen und das Thema Daten von einer neuen Perspektive aus zu betrachten. Da gibt es letztendlich vier grundsätzliche Prinzipien. Das ist die Domain Ownership, sprich, dass die Verantwortung für die Daten nicht mehr in der IT liegt, sondern dort, wo man die fachliche Verantwortung für die Daten hat. Dann Daten als ein Produkt zu betrachten, die sinnvoll sein müssen, vertrauenswürdig, verständlich, strukturiert, dann auch die Daten leicht zur Verfügung zu stellen, sprich den Self-Service-Gedanken zu unterstützen. Wer die Daten braucht, nutzt sie. Last but not least, gibt es bestimmte Regeln, an die man sich halten muss, Standards, die dann in der geförderten Governance, die also übergreifend über die Daten gilt, geregelt werden. Ich habe in einem Unternehmen unterschiedliche Bereiche. Den Vertrieb oder die Entwicklung und dir dort unterschiedlich anfallenden Daten. Der Vertrieb hätte dann die Ownership für seine Vertriebsdaten, sprich wer ist der Kunde, Kundenstammdaten. Die Entwicklung zum Beispiel hat die Ownership der Daten über die Produkte. Wie ist ein Produkt aufgebaut? Wofür wird es verwendet? Wenn man das dann zusammenführt, kann ich in einem Data Mesh bei einem Kunden die Produktdaten abholen und diverse Use Cases realisieren, in denen es sinnvoll ist, die Daten miteinander zu kombinieren. Sprich, wenn ich wissen will, welcher Kunde welche Produkte hat und wie diese gewartet sind.

Ich habe es kurz im Intro schon mal gesagt, aber es ist natürlich auch spannend zu erfahren, was ihr eigentlich macht und welche Kompetenzen ihr mitbringt. Ganz kurz zu euch. Ihr von Starburst seid ja 2017 in Boston gegründet. Ihr habt euch sehr stark auf Open Source SQL Engines fokussiert, was das ist, das erfahren wir noch. Ihr ermöglicht es Daten aus unterschiedlichen Quellen, die entweder lokal gehostet sind oder in der Cloud liegen, abzufragen und zusammenzuführen. Es geht immer um verschiedene Systeme, wo dann auch ein Stück weit das Thema Ownership eine große Rolle spielt. Was ist denn jetzt hier eure Vision? Wie spielt das Ganze zusammen?

Roland

Unsere Vision ist es, unseren Kunden den Zugriff auf die Daten so einfach wie möglich zu machen und größtmöglichen Nutzen herauszuziehen. Was unsere Analytics-Plattform erlaubt, die besonders performant in DataLakes funktioniert, die es auch ermöglicht andere Datenquellen mit einzubinden. Daten, die ich zum Beispiel in einem Data Warehouse, in einem CRM-System oder in anderen Datenbanken zusammenbringen, in einer schnellen, effektiven Art und Weise, ohne die Daten zu bewegen. Das heißt, ich muss nicht erst lange die Daten aus den Systemen herausnehmen, transformieren und irgendwo anders hinschreiben. Wir lesen stattdessen die Daten dort, wo sie sind und stellen sie dann dem Kunden für die Analytics-Zwecke zur Verfügung.

[11:12] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Die Daten direkt an ihrer Quelle abrufen und ohne vorherige Transformation nutzen zu können, ist ein wesentlicher Vorteil. Könntest du näher auf die Herausforderungen eingehen, denen eure Kunden im Alltag ohne diese Lösung gegenüberstehen? Welche typischen Probleme müssen IT-Abteilungen oder andere Teams bewältigen, wenn sie nicht über diese Lösung verfügen?

Roland

Ja, sehr gerne. Unsere Kunden verschieben und kopieren im Schnitt 4–5-mal ihre Daten nach einer Erhebung, bis sie tatsächlich in der Lage sind, diese Daten auch zu analysieren. Diesen Prozess können wir deutlich abkürzen, indem wir es nicht benötigen, dass die Daten aus den Systemen herausgelesen werden, um dann woanders hingeschrieben zu werden, sondern dass wir die Daten dort lesen, wo sie vorhanden sind. Das bringt auch den Nutzen der Aktualität. Ich muss nicht warten, bis der nächste Batchlauf stattgefunden hat, sondern ich nehme die aktuellen Daten, die dort verfügbar sind. Der Zugriff ist wesentlich schneller bereitgestellt, als wenn ich die Daten erst in so eine Datenpipeline verschieben muss. Da gewinnen die Kunden in der Umsetzung der Projekte Wochen und Monate an Zeit. Das sind also nicht nur ein paar Stunden, um die es geht, bis ich den Zugriff auf die Daten habe. Damit bekomme ich auch Flexibilität. Ändern sich meine Daten, ändern sich meine Anfragen, meine Analysen, die ich habe. Dann kann ich das deutlich schneller abbilden, als wenn ich sonst erst wieder diesen ganzen Datentransformationsprozess durchführen muss. Natürlich gibt es Systeme, wie Data Warehouses, die sehr sinnvoll sind und dem Kunden helfen und in die man die Daten auch in dieser klassischen Art und Weise reinschreibt. Diese Systeme werden oft dazu benutzt, mehr damit zu machen als für das, was sie eigentlich benötigt werde, was dann für den Kunden Inflexibilität und hohe Kosten bedeutet. Wir helfen dabei, zum Beispiel auch ein Data Warehouse mit anzubinden. Der Kunde muss seine Datenquellen nicht abschalten oder umstrukturieren. Wir nehmen das, was vorhanden ist, integrieren es und helfen dem Kunden somit auch zu optimieren, was auf der Kosten- wie auch auf der Zugriffsseite ist. Die Steadforce hilft uns dabei, das zu planen und umzusetzen.

Stephan

Genau, und was wir da halt immer wieder beobachten, das sind halt einfach beim Kunden gewachsene IT-Systemlandschaften, wo ein Haufen verschiedener Systeme mit unterschiedlichen Datentöpfen unterwegs sind. Diese Sachen dann zusammenzubringen und mal zu gucken, ob es denn zum Beispiel Duplikate in bestimmten Datenbanken gibt. Ist inhaltlich, was ich in einer Datenbank habe, dieselbe semantische Information gemeint wie in einer anderen Datenbank? Die Infrastruktur drumherum ist ebenfalls eine Herausforderung. Selbst wenn ich die Daten erstmal verfügbar mache, brauche ich immer noch Werkzeuge, um zum Beispiel Datenzugriff-Sicherheit festzustellen, wer überhaupt auf die Daten zugreifen und auswerten darf. Dieser ganze Komplex Data-Governance ist dann ziemlich wichtig. Da ist natürlich der Data-Mesh-Ansatz und auch die SQL-Engine, die dann auch in dem Starburst-Produkt mit drin steckt, ein ganz wichtiges und hilfreiches Werkzeug.

Das, was du jetzt gesagt hast, würde ich ganz gerne noch mal so ein bisschen in die Praxis übersetzen. Du hast gerade dieses schöne Beispiel gebracht mit dem Thema Ownership der Daten. Wenn wir zum Beispiel den Entwicklungs- und Vertriebsbereich betrachten, können wir die Herausforderungen, die Sie gerade beschrieben haben, näher beleuchten, bei denen Unternehmen heutzutage Zeit und Geld verlieren. Es kommt zu Duplikaten von Daten, die dann transformiert werden müssen. Um Analysen durchzuführen, benötigt man eine gewisse Skalierbarkeit, auch im IT-System dahinter. Diese Systeme sind historisch gewachsen und weisen entsprechende Komplexitäten auf. Könnten Sie das anhand eines konkreten Beispiels erläutern, zum Beispiel warum die Daten überhaupt transformiert werden müssen?

Stephan

Jetzt stellen wir uns mal vor, ich habe eine Sales Datenbank, über die ich Vertrieb mache und da ist der Herr Meyer mit drin. Das ist ein Datensatz und gleichzeitig auch eine Produktionsdatenbank. Da werden Schrauben produziert und da gibt es einen Auftrag und der Kunde ist Herr Meyer. Jetzt kann mir aber tatsächlich niemand sagen, ist der Herr Meyer in der Datenbank der Produktionssteuerung der gleiche Herr Meyer wie in der Datenbank für den Vertrieb? Das ist ein ganz klassisches Problem, wenn ich zwei voneinander getrennte Datentöpfe habe. Das daraus folgende Problem ist, dass ich, diese Informationen nicht so einfach miteinander korrelieren kann. Ich könnte jetzt zum Beispiel schauen, wie viele Aufträge von dem Herr Meyer am Ende tatsächlich produziert wurden. Dementsprechend kann ich keine Analytics darauf machen. Mit Hilfe eines Data Mesh, kann ich jetzt beide Informationen auf der einen Seite kuratiert bereitstellen. Das bedeutet, dass die Fachabteilungen, im Rahmen der Domain Ownership, ihre Daten kennen und verstehen, welche Semantik dahintersteckt. Sie können die Daten entsprechend aufbereiten, um eine gewisse Qualität sicherzustellen. Das ist der erste Schritt. Mit dem Starburst-Produkt bin ich jetzt in der Lage, diese beiden Datenquellen so zu korrelieren, dass ich darauf einfach SQL-Abfragen durchführen kann und dann entsprechende Reports erstellen kann.

Vielen Dank für das Beispiel. Wie machen Kunden das ohne eure Lösung? Muss ich dann quasi diese einzelnen Daten dann wirklich nehmen, Übersetzungsarbeit leisten und die im System anlegen? Wie machen das Firmen ohne euch?

Stephan

Ein klassischer Ansatz oder besser gesagt, ein Ansatz, der sich in den letzten Jahren zum Standard entwickelt hat, ist es, alle Daten aus verschiedenen Datenquellen zu extrahieren und mithilfe von Data Pipelines an einen zentralen Ort zu übertragen, wie zum Beispiel einen Data Lake oder ein Data Warehouse. Dies bedeutet jedoch auch, dass jemand diese Pipelines entwickeln muss, was in der Regel die interne IT-Abteilung ist. Diese IT-Abteilung ist jedoch oft nicht so eng mit den Daten vertraut wie die Fachabteilungen, was zu Engpässen führen kann. Das bedeutet, je mehr Anforderungen im Unternehmen bestehen, Daten an diese zentrale Stelle zu übertragen, desto mehr Personal ist erforderlich, um dies zu tun. Roland kann aus seiner Erfahrung sicherlich noch etwas dazu sagen. Ein weiteres Problem ist, dass bei Fehlern in diesen Pipeline-Systemen, die im Laufe der Zeit immer komplexer werden, oder bei erforderlichen Änderungen erheblicher Aufwand und Kosten entstehen. Im Vergleich dazu ermöglicht die Data Mesh-Lösung die Verbindung von Daten, ohne sie zu verschieben, was effizienter sein kann.

Ja, genau. Das ist ein wichtiger Punkt, den ich gerne betonen möchte. Viele Unternehmen haben historisch gewachsene Systeme und stehen vor der Herausforderung, diese auf skalierbare Weise zu modernisieren. Einige versuchen dies intern zu lösen, während es auch Lösungen auf dem Markt gibt, die bereits die Skalierbarkeit und Integration von Daten ermöglichen. Dies ist tatsächlich ein Bereich, in dem euer Unternehmen tätig ist und Lösungen anbietet.

Roland

Der Kunde kann auch seine bisherige Vorgehensweise beibehalten, so wie er es bisher getan hat. Das bedeutet, wenn ein Kunde Änderungen vornehmen und sich in Richtung eines Data Mesh-Ansatzes bewegen möchte, muss er nicht von Grund auf neu beginnen. Es ist nicht so, dass er von heute auf morgen umschaltet und am nächsten Tag alles anders ist. Es handelt sich um einen schrittweisen Prozess. Wir können auf die vorhandenen Datenquellen zugreifen, die derzeit verwendet werden, und gleichzeitig dem Kunden die Möglichkeit geben, den neuen Data Mesh-Ansatz schrittweise einzuführen. Dies beinhaltet die Änderung der Datenverantwortlichkeiten und die schrittweise Einführung einer neuen Governance. Zum Beispiel, wenn ein Kunde beschließt, seine Daten in der Cloud zu speichern und ein übergreifendes Data Mesh aufzubauen, das verschiedene Länder umfasst, können wir den Zugriff auf die Daten an dem Ort herstellen, an dem sie sich derzeit befinden. Wir wissen auch, wo der Kunde plant, seine Daten in Zukunft zu speichern. Wir stellen den Zugang zu den Daten für die Analyse transparent dar, ohne genau wissen zu müssen, wo sie am Ende des Tages liegen werden. Auf diese Weise können wir den Kunden bei seinem schrittweisen Übergang in ein Data Mesh unterstützen.

Ja, es ist interessant, und um auf den Business Case zurückzukommen, sprechen wir oft über geschäftliche Anwendungsfälle, die auf den ersten Blick beeindruckend klingen. Es ist jedoch wichtig zu verstehen, dass die Umsetzung solcher Anwendungsfälle eine skalierbare Infrastruktur erfordert. Wenn wir beispielsweise den Use Case „Product Carbon Footprint“ betrachten, müssen wir Daten aus verschiedenen Quellen wie dem ERP-System und der Produktion zusammenführen. Eine Herausforderung besteht darin, unterschiedliche Datentypen und Bezeichnungen in den verschiedenen Quellen zu berücksichtigen, um die Daten für solche geschäftlichen Anwendungen nutzbar zu machen. Eine skalierbare Infrastruktur und die Fähigkeit, Daten aus verschiedenen Quellen zu integrieren und zu harmonisieren, sind entscheidend, um solche geschäftlichen Anforderungen erfolgreich umzusetzen, oder?

Stephan

Genau, das Bereitstellen dieser Daten ist auf jeden Fall entscheidend. Hierbei kann es auch hilfreich oder notwendig sein, ein Metadatenschema zu erstellen, das in den verschiedenen Fachabteilungen verwendet werden kann. Dadurch wird festgelegt, wie die Daten am Ende zusammenpassen müssen. Die Verknüpfung der Daten aus verschiedenen Quellen ist jedoch besonders wichtig für viele Use Cases, da sie neue Erkenntnisse in der Analyse ermöglicht und möglicherweise zu Prozessänderungen führt, die zuvor nicht berücksichtigt wurden. Es kann beispielsweise zu Korrelationen führen, die zuvor nicht erkannt wurden.

Ja, vollkommen. Das Thema Data Mesh, wenn man es als Technologie oder als das betrachtet, was ihr gemeinsam anbietet, mag zwar abstrakt klingen, aber es stellt tatsächlich die notwendige Infrastruktur und Skalierbarkeit bereit, um solche Projekte umzusetzen. Vielleicht kannst du, Roland, näher erläutern, welche Arten von Daten für eure Projekte von Bedeutung sind. Hierbei handelt es sich wahrscheinlich weniger um Echtzeitdaten von Geräten oder Maschinen, sondern eher um bestimmte Datentypen. Könntest du das genauer erläutern?

Roland

Ja, sehr gerne. Im Bankenumfeld wird man mit großer Wahrscheinlichkeit nicht auf das kontoführende System direkt zugreifen, in dem die Transaktionen durchgeführt werden, um diese Daten dann zu lesen. Diese Daten werden aber auch für andere Zwecke von den Banken schon in Systeme ausgelagert, um sie dann für die weitere Bearbeitung zur Verfügung zu stellen. Die Daten, die wir nutzen, sind zum einen strukturierte Daten, also Daten aus relationalen Datenbanken. Es können aber auch semi-strukturierte Daten sein. Das können zum Beispiel Temperaturdaten sein. Die liegen auch in unterschiedlichen Formaten vor und die können wir zusammenführen. Auch Streaming-Daten können wir verwenden, die ein bestimmtes Event anzeigen und dort auch eine Dynamik erlauben, um das auch mit den statischen Daten, die eben zum Beispiel in Datenbanken liegen, dann kombinieren zu können.

Confluent ist ja zum Beispiel auch einer unserer Partner, die auf den Apache-Kafka-Standard aufsetzen. Ist das für euch eine Datenquelle, wo ihr halt aussagt, okay, da liegen halt Streaming-Daten vor für einen bestimmten Use Case, der einfach notwendig ist, und greift ihr das dann ab? Also sind das dann eher so Partner für euch? Wie arbeitet ihr mit solchen Technologien, die jetzt zum Beispiel in Confluent oder auch aus dem Streaming-Umfeld reinkommen?

Roland

Absolut. Confluent, beziehungsweise Kafka ist ein System, zu dem wir einen Connector haben. Das heißt, wir können genau diese Daten anbinden. Das ist für uns wie eine Datenquelle, die wir nutzen, um daraus in dem Fall die Event-Informationen für Analysen zur Verfügung zu stellen oder auch eventgetriggert bestimmte Dinge zusammenzuführen. Wenn der Temperatursensor einen bestimmten Wert übersteigt, ist es nicht nur wichtig, den Alarm auszulösen, sondern auch zu untersuchen, welcher Sensor betroffen war, in welcher Maschine er sich befindet, bei welchem Kunden die Maschine steht, und welchen Rahmenvertrag oder Wartungsvertrag dieser Kunde hat. Auf diese Weise kann eine umfassende Übersicht erstellt werden, die auf Daten sowohl aus dem System als auch aus dem Umfeld des Sensors sowie auf den spezifischen Ereignissen basiert, die stattgefunden haben.

Bei Confluent sind es wahrscheinlich auch Massen an Echtzeitdaten. Das sind dann wahrscheinlich hochfrequente Daten, die so Use Cases beinhalten, wie wenn ich einen Schadensfall analysieren will oder vielleicht in Echtzeit reagieren will. Das heißt, auch solche Datentypen könnt ihr da anbinden, die relevant sind für diese Use Cases.

Roland

Ja, absolut. Kafka und Confluent sind Quellen, die wir nutzen.

Stephan

Diese ganzen Daten, die Quellen werden angebunden und was ich dann eben mit Hilfe der Lösung machen kann, ist auf diese Datenquellen mit SQL-Queries draufzugehen, und zwar unabhängig von der Frage, ob das tatsächlich relationale Daten sind oder semi-strukturierte Daten. In dem Moment, wo ich die mit drin habe, kann ich mit einem relativem Standardmittel Auswertungen darüber fahren.

Das sind wie so Trigger oder was ist eine Query genau an der Stelle?

Stephan

Query ist nur eine Abfrage. Wenn ich jetzt mal als Beispiel eine Excel-File als Datenquelle habe und eine Datenbank, dann kann ich ja nicht einfach so eine SQL-Query schreiben. In dem Moment, wo wir die aber über Konnektoren an das System anbinden, da werden wir sicher nachher noch dazu kommen, kann ich dann die trotzdem mit Hilfe von SQL auswertbar machen.

Was sind technologische Anforderungen an solche Lösungen, die vor allem von euren Kunden kommen und auch in der Zusammenarbeit mit Stephan und Steadforce? Was sind technologische Anforderungen an solche Lösungen wie die Eure?

Roland

Die technologischen Anforderungen sind sicherlich die Möglichkeit, auf die Daten überhaupt zugreifen zu können. Natürlich muss die Infrastruktur es auch erlauben, dass man zugreifen kann. Neben den technologischen Anforderungen gibt es auch organisatorische Anforderungen, die wir berücksichtigen müssen, wie das Recht auf die Daten zugreifen zu können, die Freigaben dafür zu bekommen. Das sind Themen, die wir auf alle Fälle angehen und lösen müssen im Rahmen der Projekte.

[26:56] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Stephan, was ist denn wichtig bei der Umsetzung? Du hast schon erzählt, es sind häufig historisch gewachsene Systeme, ihr könnt verschiedenste Daten dort anbinden, aber wie geht man wirklich vor?

Stephan

Wenn man es genauer betrachtet, ist unser Data Mesh zunächst ein umfassendes Konzept, und wie Roland bereits zu Beginn erwähnt hat, ist die Umsetzung ein schrittweiser Prozess. Das bedeutet, dass es nicht möglich ist, von heute auf morgen ein Data Mesh-Projekt zu starten und sofort abzuschließen. Was sich da bewährt hat, ist tatsächlich mal mit einem Use Case anzufangen mal ein, zwei solche Datenprodukte aufzubauen, mal einen ersten MVP aufzusetzen, um zu zeigen, dass ich damit jetzt Mehrwert generieren kann. Da kann die Organisation entsprechend lernen, wie sie das bei sich implementieren. Ich meine das nicht nur von der technologischen Seite her, sondern auch von den Verantwortlichkeiten, die da unter Umständen mit dranhängen. Das ist der erste Schritt von der Fachseite her. Das zweite ist dann die Frage, wie kann ich das technisch umsetzen? Es ist gut, wenn man dann nur einen kleinen Use-Case hat, mit dem man startet. Da gibt es dann einfach zwei Möglichkeiten. Entweder ein Partner wie uns, in diesem Fall Starburst, übernimmt die Umsetzung, oder die interne IT wird befähigt, das Projekt durchzuführen, möglicherweise in Zusammenarbeit mit externen Experten. Wir bieten Unterstützung in Form von Schulungen und Architekturberatung, um sicherzustellen, dass das Projekt erfolgreich umgesetzt wird.

So ein Use Case wäre dann zum Beispiel, was ich gesagt habe mit diesem Thema Product Carbon Footprint oder was du sagtest mit diesem Thema: Du willst von dem Herr Meyer mal auch einen Abgleich machen. Ist das der gleiche Kunde? Was hat er bestellt und so weiter? Solche Use Cases sind das dann. Wahrscheinlich macht es keinen Sinn zu sagen, ich will jetzt Condition Monitoring von einem Sensor machen, weil es um übergreifende Systemdaten geht, die ihr dort braucht.

Stephan

Genau, weil das Thema Korrelation dieser Datenquellen schon im Mittelpunkt steht. Ein ganz wichtiger Teil ist am Anfang, da machen wir zum Beispiel auch mit unseren Kunden entsprechende Workshops, um diesen Use Case zu entwickeln oder den auch mal zu bewerten und zu sagen, ist das was, was wir jetzt in einem vernünftigen Zeitraum auch umsetzen können? Wie sind die Erfolgswahrscheinlichkeiten an der Stelle und was will ich damit tatsächlich erreichen?

Wir haben schon über konkrete Daten gesprochen. Zum Beispiel habe ich jetzt Entwicklungsdaten oder eben im CRM Daten von Herrn Meyer oder ich habe bestimmte Vertragsdaten, wo die Ownership zum Beispiel im Vertrieb liegt oder auch in der Produktion. Wie funktioniert jetzt diese Datenaufnahme für den Use Case aus diesen einzelnen IT-Systemen, also aus den Datenhaltungssystemen, wenn man so will? Wie geht das mit eurer Lösung?

Roland

Ja, wir können uns, wenn wir die entsprechenden Freigaben haben, über unsere Konnektoren in die einzelnen Systeme verknüpfen. Wir bieten dort die Möglichkeiten, das Regelwerk, die Zugriffsrechte, diese ganzen Themen um Sicherheit mit abzudecken, die der Kunde schließlich braucht. Es darf womöglich nicht jeder alle Daten sehen und dort beliebig reinschauen. Wir bieten weiterhin die Möglichkeit in unserer Plattform bestimmte Datenprodukte zusammenzustellen, um die für Auswertungen verfügbar zu machen.

Stephan, sind das so Konnektoren, die immer standardmäßig schon da sind? Es sind ja so viele verschiedene, unterschiedliche IT-Systeme da draußen. Gibt es da schon alles fertig oder wie läuft das?

Stephan

Natürlich gibt es nicht für alles bereits vorgefertigte Lösungen. Es ist jedoch erwähnenswert, dass Starburst eine umfangreiche Auswahl an vorgefertigten Konnektoren bietet, die sich sehr gut für die ersten Schritte eignen und bereits viele Anforderungen abdecken können. Dennoch können individuelle Anforderungen auftreten, die maßgeschneiderte Konnektoren erfordern. In solchen Fällen können wir sowohl beratend tätig sein als auch bei der Umsetzung der individuellen Konnektoren helfen.

Du hast vorhin von dieser SQL-Abfrage-Engine gesprochen, um diese Daten zu bekommen. Was ist das für eine Technologie dahinter? Auf was baut ihr da auf, was sind das für Konnektoren?

Stephan

Die Technologie, die da dahintersteckt, nennt sich Trino und das ist eben tatsächlich eine Federated Query Engine, mit der man solche Abfragen machen kann. Das kannst du ein bisschen vergleichen mit Kafka und Confluent, weil wir es vorher gerade angesprochen haben. Also Kafka als Streaming-Lösung, Open Source, die dann eben, wenn es in den Enterprise-Bereich hereingeht, von Confluent bereitgestellt wird. Ähnlich ist das auch hier mit Trino und Starburst. Das heißt, Trino ist die Open Source Engine, die da letztlich verwendet wird und Starburst ist dann der Hersteller letztlich für die Enterprise Lösung.

Ist das hierarchisch drunter oder drüber bei Kafka? Kafka baut ja immer auf Data in Motion auf, also Daten in Bewegung. Das sind dann bestimmte Daten-Pipelines, wo man diese Standards abruft. Ist das dann hierarchisch gleich, weil es einfach verschiedene Systeme sind und das ist vom Use Case abhängig oder hängt das drüber oder drunter?

Stephan

Ich würde sagen, es sind unterschiedliche Use Cases. Bei Kafka geht es darum, Daten in Bewegung zum Streaming zu bringen. Auf unserer Data-Mesh-Seite geht es eher um Auswertung, oder wenn wir jetzt bei dem Trino bleiben, wo ich dann wirklich Queries drauf stellen will. Dann kann Kafka eine Datenquelle sein, die man direkt anbinden kann, muss aber eben nicht. Oder ich kann eben Kafka als Datenquelle haben und noch drei andere und mache dann eine übergreifende Query um eine bestimmte Auswertung zu machen.

Roland, du hattest vorhin gesagt, ihr lasst die Daten da liegen, wo sie sind. Das heißt, ihr greift sozusagen über diesen Abfrage-Mechanismus genau da auf die Daten zu, wo sie liegen. Das heißt, die Datenaufnahme funktioniert über den Connector und ihr greift auf die Daten zu und da bleiben die auch.

Roland

So ist es. Wir lesen die Daten, wir stellen sie für die Analytics zur Verfügung. Wir fassen sie auch zusammen, indem wir unterschiedliche Quellen connecten können, aber die Daten werden nicht irgendwo hin kopiert. Zumindest nicht im Normalfall, sondern wir lesen die.

Genau, so wird es so skalierbar wie möglich, und man kann die Architektur entsprechend gestalten, ohne sie vielleicht in ein Data Warehouse oder Data Lake zu verschieben. Habe ich das so richtig verstanden? Das ist ja auch irgendwie eine andere Architekturart, die ihr da schafft, oder?

Roland

Ja, genau, wir nutzen die Data Lakes, wir nutzen die Quellen, die da sind, aber wir verschieben die Daten eben nicht. Das bringt dem Kunden dann die Flexibilität, die Geschwindigkeit, die er haben will. Trino, wir haben den Open Source Bereich gerade angesprochen, ist ja die Query Engine. Trino ist auch der Kern von Starburst. Starburst setzt auf Trino auf. Trino ist unser Kern und wir erweitern. Trino ist die Query Engine, die ist eine sogenannte NPP Query Engine. Das heißt, wir haben dort eine eigene Rechenpower drin und sind damit hoch performant und können auch sehr, sehr große Datenmengen durchforsten und analysieren. Das heißt, wir skalieren im Petabyte-Bereich. Trino ist aus Presto heraus entstanden und Presto wurde ursprünglich bei Facebook genau für diesen Zweck entwickelt, um über Standard SQL sehr, sehr große Datenmengen in Data Lakes analysieren zu können.

Die letzte Frage für heute würde ich ein bisschen in Richtung der Datenanalyse stellen. Wir haben jetzt mal zwei Use Cases angesprochen, also dieses Thema Product Carbon Footprint zum Beispiel oder das mit dem Herr Meyer. Wie macht ihr jetzt diese Auswertung, die Analytics zu den einzelnen Use Cases? Wie analysiere ich die Daten, wie funktioniert das?

Roland

Wenn ich es jetzt aus einer Starburst-Sicht betrachte, habe ich hier unterschiedliche Rollen, die mit den Daten arbeiten. Sprich, ich habe zum Beispiel den Data and Business Analyst, ich habe den Data Scientist etc. Ich habe unterschiedliche Personen, unterschiedliche Profile, die mit den Daten arbeiten. Dadurch, dass wir einen Standard SQL haben, geben wir dann denjenigen Profilen oder den Mitarbeitern auch die Möglichkeit mit dem Analysetool ihrer Wahl, wenn es unsere Standard SQL-Schnittstellen unterstützt, auch arbeiten zu können. Damit haben die Kunden die Freiheiten, das zu nutzen, was ihnen an für die jeweilige Rolle als Tools ideal erscheint.

Stephan

Genau, da sind wir dann eben an der Schnittstelle. Das heißt, mit dem Produkt und mit dem Data Mesh Ansatz baue ich letztlich die Datenbasis auf, damit ich Daten in entsprechenden Qualität habe für Use Cases, die darauf folgen. Aber wie und was ich da drauf mache, da bin ich da natürlich zunächst mal frei. Das können einfache Reportings sein, Auswertungen und Dashboards und was auch immer man da brauchen kann, bis hin zu komplexeren AI basierten Use Cases, wo man die Daten für Modelltraining hernehmen kann und dann da eigene Anwendungen wieder darauf bauen kann.

Fragen, die jetzt aufgetaucht sind, oder auch vielleicht Diskussionspotenziale, könnt ihr natürlich gern mit Roland und mit Stephan dann klären. Ich würde eure LinkedIn-Kontakte entsprechend in den Shownotes verlinken. Aber erstmal für heute danke ich euch für diese spannende Darstellung, wie das Ganze in der Praxis funktioniert. Das was euch besonders macht, auch im Zusammenspiel, ist, dass ihr eine gewisse Data-Ownership-Situation schafft. Das heißt, ihr habt die Möglichkeit, auf verschiedene Systeme zuzugreifen und zum Beispiel die Entwicklung, die Produktion oder eben der Vertrieb hat die Möglichkeit, seine Daten eigens aufzubereiten. Man könnte fast schon von so einer Markplatzsituation sprechen. Jeder hat die Hoheit über seine Daten, bereitet sie dort auf, wie er sie braucht. Ihr habt aber die Möglichkeit, auf diese Systeme zuzugreifen, die Daten dort zu lassen, wo sie sind, und dann eben die Analytics für diese Use Cases durchzuführen. Eben gemeinsam auch mit Steadforce, um dann die verschiedenen geschäftlichen Use Cases zu ermöglichen. Vielen Dank, dass ihr auch dargestellt habe, was der Business Case ist, also was ich mir an Zeit und Geld spare, weil am Ende ist ja immer so eine Fragestellung, mach ich selber oder kauf ich es ein. Ich fand das hat man sehr schön verstanden. Deswegen herzlichen Dank von meiner Seite. Ihr könnt es gerne noch mal ein bisschen ausführen oder ergänzen und das letzte Wort würde ich damit aber für heute an euch übergeben.

Roland

Vielen Dank, Madeleine. Die Zusammenfassung trifft es aus meiner Sicht sehr, sehr gut. Vielen Dank dafür. Die Daten spielen weiterhin eine große und wachsende Rolle für die Kunden. Durch das Data Mesh Konzept, die Data Ownership in den Domains, glaube ich, bieten sich auch für viele Anwender, für viele Kunden die Möglichkeit, die Daten gewinnbringender fürs Unternehmen zur Verfügung zu stellen. Du hattest sogar kurz erwähnt, einen Marktplatz für diejenigen anzubieten, die einen Nutzen davon haben. Da wird man dann auch sehr schnell feststellen, welche Daten hilfreich sind und welche vielleicht weniger. Somit kann das Unternehmen sich natürlich auch sukzessive anhand der Daten weiter optimieren.

Stephan

Danke auch von meiner Seite, Madeleine. Ich denke, das gesamte Konzept der Dezentralisierung ist etwas, das wir auch in der Softwareentwicklung sehen, insbesondere im Kontext von Microservices. Es gibt eine gewisse Parallele zwischen diesen Konzepten, und das Data Mesh-Konzept zielt darauf ab, die Datenprodukte zu dezentralisieren, anstatt auf eine zentrale Datenquelle zu setzen.

Das war doch eine schöne Zusammenfassung zum Ende. Danke schön und ich wünsche euch noch eine schöne Restwoche. Macht’s gut, ciao!