00:00:08 Data lakes und ihre Bedeutung.
00:00:39 Data lakes definiert und ihr Zweck im Geschäftsleben.
00:02:13 Entwicklung von Data lakes aus Data warehouses.
00:04:15 Wandel in der Denkweise und Philosophie rund um Data lakes.
00:07:43 Sicherstellung der Datenpräzision in Data lakes.
00:10:06 Wie die Technologie das Data warehousing vor 20 Jahren verbessert hat.
00:12:14 Die Vorteile von On-Demand-Systemen in Data lakes.
00:13:31 Einschränkungen der Business Intelligence und ihr veralteter Ansatz.
00:15:22 Vergleich von Business Intelligence und Data lakes und wie sie Entscheidungsprozesse unterstützen.
00:16:49 Implementierungskomplexität: Zugriff auf Datenquellen und die Auswirkungen auf multinationale Unternehmen.
00:18:32 Einführung von Data lakes: Vorteile für technologiegetriebene Unternehmen und deren Einsatz in funktionsübergreifender Optimierung.
00:20:08 Die Zukunft von Data lakes: Steigende Zugänglichkeit und Implementierung, nächste Schritte mit APIs.
00:22:45 Abschließende Bemerkungen und Fazit.

Zusammenfassung

Im Interview diskutieren Kieran Chandler und Joannes Vermorel, Gründer von Lokad, Data lakes und ihre Rolle in der supply chain optimization. Data lakes sind zentrale Repositorien roher Daten, die es maschinellen Lernanwendungen ermöglichen, intelligente Entscheidungen zu treffen. Vermorel hebt die Einschränkungen traditioneller business intelligence Tools hervor und betont, dass Data lakes eine effizientere und automatisierte data analysis bieten. Er ist der Meinung, dass technologiegetriebene Unternehmen bereits Data lakes eingeführt haben und sich nun der Implementierung von Application Programming Interfaces (APIs) für ihre Subsysteme zuwenden, was eine End-to-End-Automatisierung ermöglicht. Vermorel prognostiziert, dass große Unternehmen in den nächsten fünf Jahren vermehrt Data lakes und APIs einsetzen werden, um datenbasierte decision-making zu verbessern.

Erweiterte Zusammenfassung

Im Interview spricht Kieran Chandler mit Joannes Vermorel, dem Gründer von Lokad, einem Softwareunternehmen, das auf supply chain optimization spezialisiert ist. Sie beginnen damit, Data lakes und deren Ursprünge zu definieren. Data lakes sind eine Art Datenbank, die darauf ausgelegt ist, alle zentralen Transaktionsdaten eines Unternehmens zu konsolidieren, wie z.B. Verkäufe, Einkäufe und stock levels. Diese Datenbanken sind für den Einsatz durch Anwendungen und nicht durch Menschen gedacht, sodass domänenspezifische, datengetriebene Apps intelligente Entscheidungen für Marketing, supply chain, Personalwesen und mehr treffen können.

Data lakes haben eine Geschichte, die bis zu Data warehousing und Data marts vor über 20 Jahren zurückreicht. Vermorel erklärt, dass der Hauptunterschied zwischen Data lakes und data warehouses in der Technologie und der dahinterstehenden Philosophie liegt. Data lakes sind effizienter im Speichern und Bereitstellen großer Datenmengen, während cloud computing sie zugänglicher und erschwinglicher gemacht hat.

Vor zwanzig Jahren musste ein Unternehmen ein teures Gerät, beispielsweise von Oracle, kaufen, um sein Data warehouse unterzubringen. Heute können Unternehmen dank Cloud-Computing-Plattformen Pay-as-you-go Data lakes nutzen, die skalierbar und zu aggressiven Preisen verfügbar sind. Diese Flexibilität ermöglicht es Unternehmen, ihre Datenspeicherstrategie bei Bedarf problemlos anzupassen.

Auch die Philosophie hinter Data lakes hat sich im Vergleich zu Data warehouses weiterentwickelt. Der ältere Ansatz setzte IT departments erheblich unter Druck, um Daten ordnungsgemäß zu organisieren und zu verwalten. Data warehouses wurden mit Data marts für unterschiedliche Bereiche wie Marketing, supply chain und Finanzen entworfen. Dies führte zu Herausforderungen bei der Verwaltung und dem Zugriff auf Daten über verschiedene Abteilungen hinweg.

Data lakes zielen darauf ab, Daten zentralisierter und zugänglicher zu konsolidieren, sodass Anwendungen sie einfacher verarbeiten und intelligente Entscheidungen treffen können. Dieser Wandel in der Denkweise hat eine höhere Effizienz und Flexibilität im Datenmanagement und -einsatz ermöglicht.

Vor zwanzig Jahren war Data warehousing eine beliebte Methode zur Verwaltung und Organisation von Daten. Dieser Ansatz erforderte einen hohen technischen Aufwand, um verschiedene Datentabellen zu verknüpfen, und ein einheitliches Modell der Unternehmensdaten. Allerdings führte diese Methode oft dazu, dass IT-Abteilungen von der schieren Menge an Arbeit überfordert wurden, was zu zahlreichen gescheiterten Projekten führte.

Heute haben sich Data lakes als schlankere, effizientere Methode des Datenmanagements etabliert. Data lakes fungieren als Repository für rohe Daten, die aus verschiedenen Systemen wie CRM, ERP und Web-Plattformen extrahiert werden. Anstatt zu versuchen, die Daten zu organisieren oder zu kombinieren, werden sie einfach in den Data lake eingefüllt, der problemlos große Datenmengen verarbeiten kann.

Eine der Herausforderungen bei der Nutzung von Data lakes besteht darin, sicherzustellen, dass die Daten korrekt und aktuell sind. IT-Abteilungen sind dafür verantwortlich, dass der Data lake eine genaue Wiedergabe der Originalsysteme enthält, müssen jedoch die geschäftlichen Implikationen der Daten nicht verstehen. Die Verantwortung, die Daten im CRM zu interpretieren, liegt beispielsweise bei den Abteilungen, die sie nutzen, wie Vertrieb oder Marketing. Dieser Ansatz ermöglicht eine problemlösungsbezogenere Interpretation der Daten, da verschiedene Abteilungen unterschiedliche Bedürfnisse und Perspektiven hinsichtlich der Daten haben können.

Die Technologielandschaft hat sich seit den Tagen der Data warehouses erheblich verändert, wodurch Data lakes zu einer praktikableren Option geworden sind. Zum einen hat sich die Qualität der Werkzeuge zum Übertragen von Daten über das Internet verbessert, was die Konsolidierung von Daten aus verteilten Systemen, wie supply chains, erleichtert. Zudem hat sich die Internetinfrastruktur verbessert, sodass auch kleinere Unternehmen große Datenmengen problemlos bewegen können.

Des Weiteren haben Cloud-Computing-Plattformen Data lakes zugänglicher und kosteneffektiver gemacht. Diese Plattformen ermöglichen schnelle Iterationen und on-demand Nutzung, sodass Unternehmen mit Data lakes experimentieren können, ohne ein signifikantes finanzielles Risiko einzugehen.

Während Business Intelligence Tools für Unternehmen nützlich waren, um Einblicke in ihre Daten zu gewinnen, sind sie grundsätzlich für den menschlichen Gebrauch gedacht. Das bedeutet, dass Unternehmen Mitarbeiter bezahlen müssen, um die Daten zu analysieren, anstatt den Prozess zu automatisieren. Data lakes hingegen ermöglichen eine effizientere und automatisierte Datenanalyse, was sie zu einer attraktiven Option für multinationale Unternehmen macht, die ihr Datenmanagement verbessern möchten.

Vermorel erklärt die Einschränkungen traditioneller Business Intelligence (BI) Tools, die Vorteile von Data lakes und die Zukunft des Datenmanagements in der supply chain optimization.

Vermorel beschreibt BI als eine veraltete Technologie, die nur grundlegende Datenanalysen in gewisser Echtzeit liefert. Diese Technologie war vor 30 Jahren revolutionär, da sie Unternehmen den Zugang zu ihren Daten und deren Aggregation ermöglichte, bietet jedoch keine umsetzbaren Erkenntnisse oder Entscheidungen. Im Gegensatz dazu sind Data lakes Teil eines größeren Ganzen und dienen als Speicherdepot für rohe Daten aus verschiedenen Quellen. Maschinell lernende Anwendungen können diese Daten dann effizient verarbeiten, um umsetzbare Entscheidungen zu generieren, die das Unternehmen beeinflussen und greifbaren Mehrwert schaffen.

Die Implementierung eines Data lakes hängt von der Komplexität des Zugriffs auf die Datenquellen eines Unternehmens ab. Für große multinationale Unternehmen kann dies ein schwieriger Prozess sein, da jedes Land sein eigenes System haben könnte. Es gibt jedoch keine Alternativen, wenn ein Unternehmen Einblicke gewinnen und datenbasierte Entscheidungen treffen möchte. Vermorel ist der Ansicht, dass kleine, technologiegetriebene Unternehmen bereits Data lakes eingeführt haben und sogar darüber hinausgegangen sind, indem sie Application Programming Interfaces (APIs) für ihre Subsysteme implementiert haben. Dies ermöglicht funktionsübergreifende Optimierung und intelligente Entscheidungsfindung.

Vermorel rechnet damit, dass große Unternehmen in den nächsten fünf Jahren vermehrt Data lakes einführen werden, da sie zugänglicher und erschwinglicher werden. Unternehmen, die keine Data lakes implementieren, laufen Gefahr, von jenen überholt zu werden, die dies bereits getan haben. Allerdings sind Data lakes nicht der letzte Schritt im Datenmanagement. Vermorel schlägt vor, dass APIs die Zukunft sind, die es Unternehmen ermöglichen, nicht nur Daten zu lesen und zu analysieren, sondern auch darauf zu reagieren. APIs können eine End-to-End-Automatisierung ermöglichen, indem sie automatisch Entscheidungen generieren und diese im System implementieren.

Joannes Vermorel betont die Bedeutung, über traditionelle BI Tools hinauszugehen und Data lakes einzuführen, um eine effizientere, datengetriebene Entscheidungsfindung in der supply chain optimization zu erreichen. Er stellt sich eine Zukunft vor, in der große Unternehmen Data lakes und APIs implementieren, um ihre Prozesse zu automatisieren und klügere Entscheidungen zu treffen.

Vollständiges Transkript

Kieran Chandler: Heute bei Lokad TV werden wir ein wenig mehr über das Konzept von Data lakes sprechen und verstehen, warum diese Unternehmen ihnen mehr Aufmerksamkeit schenken sollten. Also Joannes, wie immer, sollten wir vielleicht einfach damit beginnen, etwas genauer zu definieren, was Data lakes sind und woher sie kommen.

Joannes Vermorel: Ein Data lake ist in der Regel eine Art Datenbank mit einigen Besonderheiten, die dazu gedacht ist, nahezu alle Kerndaten Ihres Unternehmens zu konsolidieren, insbesondere alle Transaktionsdaten wie verkaufte Artikel, eingekaufte Waren, Ihre Lagerbestände und so weiter. Der Zweck und die Endanwendung des Data lakes besteht darin, dass er für Apps und nicht für Menschen gedacht ist. Die Idee ist, einen Data lake einzurichten, damit domänenspezifische, datengetriebene Apps, die Unmengen an Daten aus dem Data lake nutzen können, intelligente Entscheidungen für Marketing, supply chains, Personalwesen oder Ähnliches generieren können. Grundsätzlich ist es ein Ort, an dem alle Daten konsolidiert werden, um sie in Batches an intelligente Apps zu liefern. Was den zweiten Teil Ihrer Frage betrifft, haben Data lakes eine lange Geschichte, die bis auf das Konzept des Data warehousing und der Data marts zurückgeht.

Kieran Chandler: Data warehouses waren wohl vor über 20 Jahren ein Trend. Was hat sich also seitdem verändert, und was sind die wesentlichen Unterschiede?

Joannes Vermorel: Das ist interessant. Heutzutage sind die Schlagworte “data lake” und “data scientist”, während es vor zwanzig Jahren noch “data warehouse” und “data mining” waren, was im Grunde die gleiche Evolution derselben Ideen ist, nur 20 Jahre später neu aufgelegt. Was sich geändert hat, ist einiges. Zuerst hat sich die Technologie der Data lakes verändert, sodass sie viel effizienter darin sind, große Datenmengen zu speichern und bereitzustellen. Dann kam das Cloud Computing ins Spiel, was bedeutet, dass man heutzutage vollkommen on-demand Data lakes mit Pay-as-you-go-Preisgestaltung pro Terabyte haben kann. Das ist ein ziemlicher Unterschied zu vor 20 Jahren, als man ein sehr teures Gerät, zum Beispiel von Oracle, kaufen musste, um alle seine Daten unterzubringen. Heutzutage kann man mit Cloud-Computing-Plattformen Pay-as-you-go Terabytes nutzen und ist dabei äußerst aggressiv in der Preisgestaltung.

Kieran Chandler: Das ist sozusagen die technische Seite der Dinge. Wie sieht es mit der Philosophie aus? Was hat sich in der Denkweise und in der Nutzung von Data lakes im Vergleich zu Data warehouses verändert?

Joannes Vermorel: Es hat in der Tat eine beträchtliche Entwicklung stattgefunden. Das Problem bei Data warehouses, wie sie vor 20 Jahren konzipiert wurden, war, dass sie die IT stark unter Druck setzten, die Daten ordnungsgemäß zu organisieren. Man hatte sogar ein Data warehouse, das Data marts organisieren sollte, wobei für jede Art von Abteilung, wie Marketing, supply chain, Finanzen und so weiter, ein eigener Data mart vorgesehen war. Die Data marts waren wie Teilmengen oder Subsistenz innerhalb des Data warehouses. Das Problem dieses Ansatzes, der in gewisser Weise dem Geist der heutigen Data lakes ähnelte, bestand darin, dass er von der IT viel Organisation und Management erforderte.

Kieran Chandler: Bei Business Intelligence wurde so vorgegangen, dass ein hoher Grad an Erwartungen bestand, dass es bereits eine Art vorbereitete, organisierte Verbindung zwischen beispielsweise Kunden, Verkäufen und Retouren geben würde. Man hat also alles zusammengeklebt. All die Dinge, die zusammengehören, erfordert tatsächlich viel Aufwand. Technisch gesehen geht es darum, Tabellen zu verknüpfen, alle diese Tabellen mit ordnungsgemäßen Joins zu verbinden. Vor 20 Jahren bestand die Philosophie darin, viel zu tun, was damals etwa dem entsprach, was im Bereich BI und bei relationalen Systemen natürlich praktiziert wurde. Das Problem dieses Ansatzes war, dass der erforderliche Arbeitsaufwand völlig enorm war, sodass IT-Abteilungen typischerweise von der schieren Menge an Anforderungen, die aufgrund dieser Data warehousing-Projekte auf sie zukamen, völlig überfordert waren. Infolgedessen scheiterte es häufig, weil die IT einfach nicht liefern konnte. Aber wie sieht es heute aus? Ich meine, jetzt wo es diese Data lakes gibt, wird es sicherlich etwas chaotisch.

Joannes Vermorel: Data lakes sind, was die Philosophie angeht, wesentlich schlanker, da der Gedanke dahinter ist, dass ein Data lake nur ein Empfänger für eine saubere Extraktion, einen sauberen Dump aller Daten, die in anderen Systemen liegen, ist. Man versucht also nicht, die Daten aus dem CRM, aus dem ERP und von Ihrer Web-Plattform aufwändig umzukombinieren. Sie extrahieren diese Datenquellen einfach und werfen sie in den Data lake. Und der Data lake verhält sich dank der Technologie sehr zuverlässig, was bedeutet, dass Sie eine enorme Datenmenge einfüllen können, die Last ohne Probleme bewältigt. Wenn Sie in der Cloud sind, werden Ihnen dafür Gebühren berechnet.

Kieran Chandler: Wie wissen Sie, dass die Daten, die Sie tatsächlich verwenden, gute Daten sind? Wie behalten Sie den Überblick darüber, welche Daten aktuell sind? Wenn Sie sie also alle in diesen Lake einwerfen, wie behalten Sie den Überblick?

Joannes Vermorel: Die Verantwortung der IT bei einem Data lake besteht darin, sicherzustellen, dass der Data lake eine genaue Wiedergabe dessen enthält, was in den Originalsystemen vorhanden ist. Das erfordert jedoch kein Verständnis dafür, was geschäftlich vor sich geht. Sie haben einfach ein CRM mit 200 relationalen Tabellen, die Sie in den Data lake spiegeln, und das war’s. Es ist nicht notwendig, das, was im CRM passiert, zu verstehen.

Kieran Chandler: Also, wer muss verstehen, was im CRM vor sich geht?

Joannes Vermorel: Es stellt sich heraus, dass es die Sparten selbst sind, die die Daten nutzen wollen, und das Problem ist, dass die Interpretation der Daten sehr problemspezifisch ist. Zum Beispiel ist die Betrachtung der Verkaufszahlen anders, je nachdem, ob man ein Marketingproblem oder ein supply chain Problem lösen will. Deshalb – und das war auch einer der Hauptgründe – sind vor zwanzig Jahren viele dieser Data-Warehousing-Initiativen gescheitert. Die Vision war, ein einheitliches Modell des Unternehmens zu erstellen, aber dann stellte sich heraus, dass es für jede Sparte sehr frustrierend war, weil das Marketing sagte: “Oh, es passt nicht genau in die Vision, die ich von meinem Bereich habe,” und das supply chain ebenso, und Finance würde dasselbe sagen. Im Gegensatz dazu ist die Idee nun, dass es mehr die Sparten selbst sind, wie supply chain, Marketing, Finance, Human.

Kieran Chandler: Heißt, sie werden heute nicht scheitern. Ich meine, es gibt ja wieder unzählige Änderungen. Eine besondere Herausforderung, vor allem im supply chain, besteht darin, dass wir per Design mit verteilten Systemen arbeiten. Was meine ich mit verteilt? Ich meine, nicht alles befindet sich an einem Ort, denn per Definition, wenn Sie mehrere Lagerhäuser haben, sind diese nicht am selben Ort. Ihre Lieferanten befinden sich nicht am selben Ort wie Ihre Lagerhäuser, und auch Ihre Kunden nicht. Also betrachten wir per Definition Systeme, die verstreut sind, und Sie möchten all diese Daten an einem Ort konsolidieren, was Ihr Data Lake ist – technisch gesehen über das Netzwerk.

Joannes Vermorel: Offensichtlich wurde das Internet schon vor zwanzig Jahren erfunden. Es gab es, aber die Qualität der Werkzeuge, um Daten über das Internet zu übertragen, war völlig anders als das, was wir heute haben. Und auch das Netzwerk, sprich die Qualität des Netzwerks selbst, war ganz anders. Heutzutage, wenn Sie etwa als nicht allzu großes Unternehmen – sagen wir ein 1.000-Mitarbeiter-Unternehmen, also beträchtlich, aber keine Megakorporation – ein Gigabyte an Daten pro Tag über das Internet bewegen möchten, war das vor zwanzig Jahren kompliziert.

Ihr brauchte beispielsweise in Paris Zugang zu Glasfaser. Vor zwanzig Jahren gab es in Paris nur einen Ort, an dem man Zugang zu Glasfaser hatte, nämlich das Gebiet in der Nähe der Börse. Es gab so ungefähr einen Quadratkilometer, in dem man leicht Zugang hatte. Überall sonst musste man seine eigene Glasfaser verlegen, wenn man sie haben wollte. Megakorporationen konnten das, aber selbst ein beträchtliches Unternehmen mit 1.000 Mitarbeitern nicht. Das hat sich geändert. Jetzt ist es sehr unkompliziert. Die Werkzeuge sind besser, und man kann buchstäblich Gigabytes ohne großen Aufwand bewegen.

Und die Tatsache, dass Sie On-Demand-Systeme haben, bedeutet, dass diese Data Lakes nicht nur sehr günstig sind – dank der economies of scale dieser Cloud-Computing-Plattformen – sondern dass sie On-Demand verfügbar sind, was es erlaubt, durch Trial-and-Error zu lernen. Wenn Sie beispielsweise versuchen, einen Data Lake einzurichten und es ein völliger Fehlschlag ist, können Sie ihn einfach löschen und neu starten, und Sie zahlen nur für das, was Sie nutzen. So können Sie schnell iterieren. Es ist nicht wie vor zwanzig Jahren, als Sie sich daran binden mussten, ein sehr teures System zu kaufen, und wenn Sie es falsch gemacht haben, war das ein großes Problem.

Kieran Chandler: Und ich wette, diese Finanzbereiche haben wahrscheinlich immer noch das schnellste Internet. Was würden Sie zu einem großen multinationalen Unternehmen sagen, das seine Daten bereits gut im Griff hat und die Zusammenhänge mit Business-Intelligence-Tools versteht? Ich meine, warum sollten sie an einem Data Lake interessiert sein?

Joannes Vermorel: Das Problem mit Business Intelligence ist, dass es im Grunde für Menschen gedacht ist. Es ist gut, aber das bedeutet, dass jede einzelne Minute, in der Menschen sich diese Zahlen anschauen, eine Minute ist, in der Sie tatsächlich einem Mitarbeiter dafür bezahlen, Zahlen zu betrachten, statt etwas anderes zu tun. Sie können sehr leicht Millionen von Zahlen erzeugen, deren Verarbeitung Tausende von Arbeitsstunden erfordert, was extrem teuer ist.

Also, das Problem ist, dass Business Intelligence, wie ich es sehe, eine Technologie ist, die ziemlich veraltet ist. Es war ein Weg, um eine grundlegende Analyse Ihrer Daten nahezu in Echtzeit durchzuführen. Es war sehr interessant, denn wenn wir 30 Jahre zurückgehen – als Business Objects gegründet wurde – konnten Sie einfach nicht wissen, dass synchronisierte Abfragen, die Ihnen Informationen wie die Anzahl der täglich pro Produkt verkauften Einheiten liefern, nicht möglich waren. Plötzlich war es möglich, diesen Würfel zu haben, man kann sogar Hyperwürfel haben – und noch besser, es ging sehr schön. Aber letztlich sehen Sie nur eine super grundlegende Aggregation Ihrer Daten, und diese Aggregation ist keine Entscheidung. Sie sagt nicht, ob Sie Ihren Preis erhöhen oder senken sollten, sie sagt nicht, ob Sie mehr oder weniger produzieren sollten, sie sagt nicht, ob Sie aus einer Produktionscharge von 1.000 Einheiten 100 Einheiten für eine schnellere Lieferung in ein Flugzeug geben sollten. Fundamentaler geht es also darum, quantitative Erkenntnisse zu gewinnen. Der große Unterschied zwischen BI und Data Lake besteht also darin, dass der Data Lake mit der Einsicht einhergeht, dass er im Grunde ein Zahnrad in einem größeren Ganzen ist – wobei typischerweise vor dem Data Lake eine machine learning–getriebene App sitzt, die die vom Data Lake super effizient bereitgestellten Daten verarbeitet, um automatisch Entscheidungen zu generieren. Und diese Entscheidungen haben einen physischen Einfluss auf Ihr Unternehmen und schaffen auf diese Weise greifbaren Mehrwert.

Kieran Chandler: Also, wenn wir uns einig sind, dass Business-Intelligence-Tools ihre Grenzen haben, und wenn es um die Implementierung eines Data Lake geht, wie einfach ist das eigentlich? Ist es einfach eine Frage des Hochladens all dieser Daten in die Cloud, und dann ist alles in Ordnung?

Joannes Vermorel: Die Komplexität der Implementierung eines Data Lake ist streng proportional zur Komplexität des Zugriffs auf Ihre Datenquellen – also dem buchstäblichen Zugriff darauf, ohne dass etwas Intelligentes damit gemacht wird. Das bedeutet für große multinationale Unternehmen, dass, wenn jedes Land in Ihrem Unternehmen sein eigenes System hat, Sie so viele unterschiedliche Data Lakes einrichten müssen, um die Daten aus jedem einzelnen Land in den Data Lake zu bringen. Es ist leider so, dass Sie keine Alternative haben, denn die einzige Alternative wäre eine direkte Integration mit den Ländern, und das ist noch kostspieliger, denn wenn Sie zwei Sparten haben – sagen wir Marketing und supply chain – die auf die Verkaufsdaten zugreifen wollen, zahlen Sie für diese Integration doppelt. Die Idee hinter einem Data Lake ist also, dass Sie es einmal machen, und dann stehen die Daten im Data Lake zur Verfügung, was es sehr geeignet macht für den Rest des Unternehmens, auf die Daten zuzugreifen. Die Komplexität hängt also vollkommen davon ab, was Sie haben. Aber nochmals: Wenn wir auf Ihr ursprüngliches Zitat zurückkommen, wenn Sie keine Daten haben, sind Sie nur ein Mann mit einer Meinung. Sie haben einfach keine Alternative, diese Daten irgendwo abzurufen, wenn Sie irgendwelche Messungen durchführen möchten.

Kieran Chandler: Fassen wir also mal zusammen. Wenn es so viele Vorteile von Data Lakes gibt und sie recht simpel erscheinen – am Ende ist es nur ein großes Behältnis für Daten –, warum wird es dann momentan nicht von der Industrie breit angenommen?

Joannes Vermorel: Es stellt sich heraus, dass sehr kleine technologiegetriebene Unternehmen Data Lakes schon vor einiger Zeit übernommen haben, und sie gingen sogar noch einen Schritt weiter mit – ich würde sagen – der API-fication ihres Unternehmens, was bedeutet, dass in jedem Teilsystem eine API (Application Programming Interface) vorhanden ist, was der nächste Schritt nach dem Data Lake ist. Also würde ich sagen, dass beispielsweise smartes E-Commerce seine Daten bereits konsolidiert hat, und so weiter.

Kieran Chandler: Man muss sich heute beide Seiten anschauen: Zum einen, was von der Website kommt – wofür man für suchmaschinenbasiertes Warenmarketing, wie Google AdWords und dergleichen, bezahlt – und Cross-Orders. Sie sind in der Lage, intelligente Entscheidungen im Hinblick auf Direktmarketingmaßnahmen zu treffen. Was reine technologiegetriebene Unternehmen wie Microsoft oder Google angeht, so machen sie das schon buchstäblich seit Jahrzehnten. Ich meine, Google gibt es erst seit zwei Jahrzehnten, aber andere Tech-Unternehmen machen das schon seit geraumer Zeit. Wenn sie das also seit Jahrzehnten tun, wie sieht es mit der Zukunft aus? Was kommt als Nächstes? Werden wir irgendwann in einen Daten-Ozean eintauchen?

Joannes Vermorel: Ja, ich meine, was ich als Nächstes sehe, ist, dass Unternehmen, die sehr supply chain–orientiert sind, jetzt, wo Data Lakes sehr zugänglich und sehr günstig geworden sind, diese Data Lakes implementieren werden. Wir sehen bei unseren Kunden, dass viele Kunden, die vor einem Jahr noch keinen Data Lake hatten, jetzt einen haben. Ich würde sagen, in den letzten zwei Jahren gab es einen Wendepunkt in Sachen Data Lake. Deshalb vermute ich, dass die meisten großen Unternehmen innerhalb der nächsten, vermutlich fünf Jahre, wirklich ihre eigenen Data Lakes implementiert haben werden, denn andernfalls würden sie von all den großen Unternehmen, die das bereits für sie getan haben, komplett abgehängt werden.

Aber es gibt auch Grenzen; insbesondere ist ein Data Lake lediglich eine schreibgeschützte Kopie aller Daten, die in anderen Teilsystemen liegen. Deshalb sagte ich, dass der nächste Schritt darin besteht, dass alle Teilsysteme APIs (Application Programming Interfaces) bereitstellen, denn genau das hat Amazon getan. Diese APIs erlauben Ihnen noch mehr – plötzlich sind Sie nicht mehr nur schreibgeschützt, sondern können auch aktiv werden. Die Idee ist, dass Sie alle Daten konsolidieren, lesen, verarbeiten, all diese Entscheidungen treffen, und was machen wir dann mit den berechneten Entscheidungen? Die Antwort lautet, dass Sie die Excel Tabellenkalkulation an die richtige Sparte senden können, damit diese Ihre Entscheidungen – wie beispielsweise den Einkauf – umsetzen. Aber wenn es eine API gibt, können Sie diese API direkt aufrufen, um einfach die Bestellung für dieses Produkt in dieser Menge von diesem Lieferanten zu übermitteln, wobei auch der Transport spezifiziert wird und was sonst noch dazugehört. So können Sie tatsächlich, wenn Sie APIs haben, End-to-End-Automatisierungen realisieren, bei denen Sie nicht nur die Entscheidung automatisch generieren, sondern diese Entscheidung auch physisch automatisch umsetzen, weil sie in eines der Systeme zurückgeführt wird.

Kieran Chandler: Okay, wir müssen es hier belassen, aber danke für Ihre Zeit heute. Das war also alles für diese Woche. Vielen Dank fürs Einschalten, und wir sind beim nächsten Mal wieder dabei. Auf Wiedersehen fürs Erste.