Die Self-Service-Daten-Roadmap

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Daten sind das neue Öl. Die Menge an strukturierten, halbstrukturierten und unstrukturierten Daten, die in Unternehmen gesammelt werden, ist exponentiell gewachsen. Die aus den Daten gewonnenen Erkenntnisse werden zu einem wertvollen Unterscheidungsmerkmal für Unternehmen in allen vertikalen Branchen, und Modelle des maschinellen Lernens (ML) werden sowohl für Produktmerkmale als auch für verbesserte Geschäftsprozesse eingesetzt.

Unternehmen sind heute reich an Daten, aber arm an Erkenntnissen. Gartner sagt voraus, dass 80 % der analytischen Erkenntnisse bis 2022 keine Geschäftsergebnisse liefern werden. Eine andere Studie unterstreicht, dass 87 % der Datenprojekte es nie bis zur Produktionseinführung schaffen. Sculley et al. von Google zeigen, dass weniger als 5 % des Aufwands für die Implementierung von ML in der Produktion auf die eigentlichen ML-Algorithmen entfallen (wie in Abbildung 1-1 dargestellt). Die restlichen 95 % des Aufwands entfallen auf das Data Engineering, d. h. auf das Ermitteln, Sammeln und Aufbereiten von Daten sowie auf das Erstellen und Einsetzen der Modelle in der Produktion.

In Data Lakes werden zwar enorme Datenmengen gesammelt, aber sie sind möglicherweise nicht konsistent, interpretierbar, genau, zeitnah, standardisiert oder ausreichend. Data Scientists verbringen viel Zeit mit technischen Aktivitäten, die mit der Ausrichtung von Systemen für die Datenerfassung, der Definition von Metadaten, der Aufbereitung von Daten für ML-Algorithmen, dem Einsatz von Pipelines und Modellen im großen Maßstab usw. zu tun haben. Diese Tätigkeiten liegen außerhalb ihrer Kernkompetenzen bei der Gewinnung von Erkenntnissen und werden durch die Abhängigkeit von Dateningenieuren und Plattform-IT-Ingenieuren behindert, denen in der Regel der notwendige Geschäftskontext fehlt. Die Komplexität der Technik schränkt den Zugang zu Daten auf Datenanalysten und Wissenschaftler ein, anstatt ihn für eine wachsende Zahl von Data Citizens im Produktmanagement, Marketing, Finanzwesen, in der Technik usw. zu demokratisieren. Es gibt zwar eine Fülle von Büchern über Fortschritte in der ML-Programmierung und vertiefende Bücher über spezifische Datentechnologien, aber es gibt nur wenig über operative Muster für die Datentechnik, die für die Entwicklung einer Self-Service-Plattform zur Unterstützung eines breiten Spektrums von Datennutzern erforderlich sind.

Abbildung 1-1. In der Studie von Sculley et al. wurde der Zeitaufwand für die Überführung von ML-Modellen in die Produktion analysiert. ML-Code beanspruchte 5 % der aufgewendeten Zeit, während 95 % der Zeit auf die restlichen Boxen für Data-Engineering-Aktivitäten entfielen.

Mehrere Unternehmen haben die Notwendigkeit erkannt, den Weg von den Daten zu den Erkenntnissen zu automatisieren und als Self-Service anzubieten. Googles TensorFlow Extended (TFX), Ubers Michelangelo und Facebooks FBLearner Flow sind Beispiele für Self-Service-Plattformen zur Entwicklung von ML-Insights. Es gibt keine allgemeingültige Strategie, die sich universell anwenden lässt. Jedes Unternehmen ist einzigartig, was die vorhandenen Technologiebausteine, die Qualität der Daten, die Art der unterstützten Anwendungsfälle, die Prozesse und die Fähigkeiten der Mitarbeiter angeht. Eine Self-Service-Plattform für eine Handvoll Data Scientists, die ML-Modelle mit sauberen Datensätzen entwickeln, unterscheidet sich beispielsweise stark von einer Plattform, die heterogene Datennutzer unterstützt, die Datensätze unterschiedlicher Qualität mit selbst entwickelten Tools für Ingestion, Zeitplanung und andere Bausteine verwenden.

Trotz erheblicher Investitionen in Datentechnologien gibt es meiner Erfahrung nach drei Gründe, warum Initiativen für Self-Service-Datenplattformen entweder fehlschlagen oder auf halbem Weg an Fahrt verlieren:

Echte Schmerzpunkte von Datennutzern, die in der Übersetzung verloren gehen

Datennutzer und Datenplattformingenieure sprechen unterschiedliche Sprachen. Dateningenieure kennen nicht den Kontext des Geschäftsproblems und die Schmerzpunkte, die in der Journey Map auftauchen. Datennutzer verstehen die Grenzen und Realitäten von Big-Data-Technologien nicht. Das führt zu Schuldzuweisungen und zum Hin- und Herschieben von Problemen zwischen den Teams, ohne dass eine dauerhafte Lösung gefunden wird.

Die Einführung "glänzender" neuer Technologien um der Technologie willen

Angesichts der Fülle von Lösungen investieren Teams oft in die nächste "glänzende" Technologie, ohne die Probleme zu verstehen, die den Weg zur Gewinnung von Erkenntnissen verlangsamen. Oftmals investieren Unternehmen nur in Technologie um der Technologie willen, ohne die Zeit bis zur Erkenntnis zu verkürzen.

Während des Transformationsprozesses zu viel anpacken

Mehrere Funktionen machen eine Plattform zur Selbstbedienung. Teams versuchen oft, an allen Aspekten gleichzeitig zu arbeiten, was dem Aufkochen des Ozeans gleichkommt. Stattdessen sollte die Entwicklung von Self-Service-Datenplattformen wie die Entwicklung von selbstfahrenden Autos sein, die verschiedene Stufen von Selbstfahrfähigkeiten haben, die sich im Grad der Automatisierung und der Komplexität der Implementierung unterscheiden.

Journey Map von Rohdaten zu Insights

Traditionell wurden in einem Data Warehouse Daten aus Transaktionsdatenbanken zusammengefasst und retrospektive Batch-Berichte erstellt. Warehousing-Lösungen wurden in der Regel von einem einzigen Anbieter mit integrierten Funktionen für die Katalogisierung von Metadaten, das Zeitplanungsprogramm für Abfragen, Ingestion-Konnektoren usw. angeboten. Die Abfrage-Engine und die Speicherung der Daten waren aneinander gekoppelt, wobei die Möglichkeiten der Interoperabilität begrenzt waren . In der heutigen Big-Data-Ära ist die Datenplattform ein Flickenteppich aus verschiedenen Datenspeichern, Frameworks und Verarbeitungsmaschinen, die eine Vielzahl von Dateneigenschaften und Erkenntnistypen unterstützen. Es gibt eine Vielzahl von Technologien für den Einsatz vor Ort, in der Cloud oder in hybriden Umgebungen, und die Entkopplung von Speicherung und Datenverarbeitung hat es möglich gemacht, Datenspeicher, Verarbeitungsmodule und Management-Frameworks beliebig zu kombinieren. Das Mantra der Big-Data-Ära lautet: "Das richtige Werkzeug für die richtige Aufgabe", abhängig von der Art der Daten, den Anforderungen des Anwendungsfalls, der Komplexität der Datennutzer und der Interoperabilität mit den eingesetzten Technologien. Tabelle 1-1 zeigt die wichtigsten Unterschiede.

Tabelle 1-1. Die wichtigsten Unterschiede bei der Gewinnung von Erkenntnissen aus traditionellen Data Warehouses im Vergleich zum modernen Big Data-Zeitalter

	Gewinnung von Erkenntnissen im Zeitalter des Data Warehousing	Gewinnung von Erkenntnissen im Zeitalter von Big Data
Datenformate	Strukturierte Daten	Strukturierte, halbstrukturierte und unstrukturierte Daten
Daten Merkmale	Großes Datenvolumen	Die 4 Vs der Daten: Volumen, Geschwindigkeit, Vielfalt und Wahrhaftigkeit
Katalogisierungsdaten	Definiert zum Zeitpunkt der Datenaggregation	Definiert zum Zeitpunkt des Ablesens der Daten
Frische der Erkenntnisse	Einblicke sind hauptsächlich rückblickend (z. B. was letzte Woche im Unternehmen passiert ist)	Einblicke sind eine Kombination aus retrospektiven, interaktiven, Echtzeit- und prädiktiven
Ansatz zur Abfrageverarbeitung	Abfrageprozessor und Speicherung von Daten in einer einzigen Lösung vereint	Entkoppelte Abfrageverarbeitung und Speicherung von Daten
Datendienste	Integriert als einheitliche Lösung	Mix-and-match, d.h. viele Kombinationsmöglichkeiten für die Auswahl des richtigen Werkzeugs für die jeweilige Aufgabe

Die Journey Map für die Entwicklung von Erkenntnissen kann in vier Schlüsselphasen unterteilt werden: Entdecken, Vorbereiten, Erstellen und Operationalisieren (siehe Abbildung 1-2). Zur Veranschaulichung der Journey Map betrachten wir das Beispiel des Aufbaus eines Dashboards für Geschäftseinblicke in Echtzeit, das den Umsatz, die Leistung von Marketingkampagnen, Kundenanmeldungen und -abgänge usw. verfolgt. Das Dashboard enthält auch ein ML-Prognosemodell für den Umsatz an verschiedenen geografischen Standorten.

Abbildung 1-2. Die Journey Map zur Gewinnung von Erkenntnissen aus Rohdaten.

Entdecke

Jedes Erkenntnisprojekt beginnt mit der Erkundung verfügbarer Datensätze und Artefakte sowie der Erfassung zusätzlicher Daten, die für die Entwicklung der Erkenntnis erforderlich sind. Die Komplexität der Datenermittlung ergibt sich aus der Schwierigkeit, Wissen innerhalb des Unternehmens zu skalieren. Datenteams fangen in der Regel klein an und verfügen über leicht zugängliches und zuverlässiges Teamwissen. Wenn die Daten wachsen und die Teams größer werden, entstehen Silos in den verschiedenen Geschäftsbereichen, so dass es keine einzige Quelle der Wahrheit gibt. Datennutzer müssen sich heute in einem Meer von Datenressourcen unterschiedlicher Qualität, Komplexität, Relevanz und Vertrauenswürdigkeit zurechtfinden. Im Beispiel des Echtzeit-Business-Dashboards und des Umsatzprognosemodells besteht der Ausgangspunkt für Datennutzer darin, die Metadaten für häufig verwendete Datensätze zu verstehen, d. h. Kundenprofile, Login-Protokolle, Abrechnungsdatensätze, Preise und Werbeaktionen usw.

Die Details der Metadaten eines Datensatzes entdecken

Der erste Meilenstein ist das Verständnis der Metadateneigenschaften, z. B. woher die Daten stammen, wie die Datenattribute erzeugt wurden und so weiter. Metadaten spielen auch eine wichtige Rolle bei der Bestimmung der Qualität und Zuverlässigkeit der Daten. Wenn das Modell zum Beispiel aus einer Tabelle erstellt wird, die nicht korrekt ausgefüllt ist oder Fehler in den Datenpipelines aufweist, ist das daraus resultierende Modell fehlerhaft und unzuverlässig. Datennutzer/innen beginnen mit dem Teamwissen, das von anderen Nutzer/innen zur Verfügung steht und das veraltet und unzuverlässig sein kann. Das Sammeln und Korrelieren von Metadaten erfordert den Zugang zu Datenspeichern, Zeitplannungsprogrammen, Metadatenkatalogen, Compliance-Frameworks und so weiter. Es gibt kein standardisiertes Format, um die Metadaten eines Datensatzes zu verfolgen, während er gesammelt und umgewandelt wird. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit bis zur Interpretation erfasst.

Suche nach verfügbaren Datensätzen und Artefakten

Mit der Fähigkeit, die Metadaten eines Datensatzes zu verstehen, besteht der nächste Meilenstein darin, alle relevanten Datensätze und Artefakte zu finden, nämlich Ansichten, Dateien, Streams, Ereignisse, Metriken, Dashboards, ETLs und Ad-hoc-Abfragen. In einem typischen Unternehmen gibt es Tausende oder Millionen von Datensätzen. Ein extremes Beispiel: Google hat 26 Milliarden Datensätze. Je nach Umfang können Datennutzer/innen Tage und Wochen brauchen, um relevante Details zu identifizieren. Heutzutage hängt die Suche stark von den Kenntnissen der Datennutzer im Team und den Anwendungsentwicklern ab. Die verfügbaren Datensätze und Artefakte entwickeln sich ständig weiter und müssen laufend aktualisiert werden. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit zum Finden erfasst .

Wiederverwendung oder Erstellung von Merkmalen für ML-Modelle

Um das Beispiel fortzusetzen, müssen für die Entwicklung von Umsatzprognosemodellen die historischen Werte der Umsatzzahlen nach Markt, Produktlinie usw. trainiert werden. Attribute wie der Umsatz, die in das ML-Modell einfließen, werden als Features bezeichnet. Ein Attribut kann als Merkmal verwendet werden, wenn historische Werte verfügbar sind. Bei der Erstellung von ML-Modellen probieren Data Scientists immer wieder neue Kombinationen von Merkmalen aus, um das genaueste Modell zu erstellen. Datenwissenschaftler/innen verbringen 60 % ihrer Zeit damit, Trainingsdatensätze zu erstellen, um Merkmale für ML-Modelle zu generieren. Die Wiederverwendung vorhandener Merkmale kann die Zeit für die Entwicklung von ML-Modellen radikal reduzieren. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik "Time to Featurize" erfasst .

Aggregieren fehlender Daten

Um das Business Dashboard zu erstellen, müssen die identifizierten Datensätze (z. B. Kundenaktivitäten und Rechnungsdatensätze) zusammengeführt werden, um einen Einblick in das Risiko der Kundenbindung zu erhalten. Datensätze, die sich in verschiedenen Anwendungssilos befinden, müssen oft in ein zentrales Repository wie einen Data Lake verschoben werden. Beim Verschieben von Daten müssen die Datenbewegungen zwischen heterogenen Systemen koordiniert, die Korrektheit der Daten überprüft und an alle Schema- oder Konfigurationsänderungen in der Datenquelle angepasst werden. Sobald die Erkenntnisse in der Produktion eingesetzt werden, ist die Datenbewegung eine fortlaufende Aufgabe und muss als Teil der Pipeline verwaltet werden. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit bis zur Datenverfügbarkeit erfasst.

Verwaltung von Clickstream-Ereignissen

Nehmen wir an, wir wollen im Business Dashboard die zeitaufwändigsten Workflows innerhalb der Anwendung analysieren. Dazu müssen die Aktivitäten des Kunden in Bezug auf Klicks, Ansichten und den zugehörigen Kontext analysiert werden, z. B. vorherige Anwendungsseiten, den Gerätetyp des Besuchers usw. Um die Aktivitäten nachzuverfolgen, können die Datennutzer/innen vorhandene Instrumente innerhalb des Produkts nutzen, die die Aktivitäten aufzeichnen, oder zusätzliche Instrumente hinzufügen, um Klicks auf bestimmte Widgets wie Schaltflächen aufzuzeichnen. Die Clickstream-Daten müssen aggregiert, gefiltert und angereichert werden, bevor sie für die Gewinnung von Erkenntnissen genutzt werden können. So muss z. B. Bot-generierter Traffic aus den Rohdaten herausgefiltert werden. Die Bewältigung einer großen Menge von Stream-Ereignissen ist eine große Herausforderung, vor allem in echtzeitnahen Anwendungsfällen wie der gezielten Personalisierung. Die Zeit, die benötigt wird, um diesen Meilenstein der Sammlung, Analyse und Aggregation von Verhaltensdaten zu erreichen, wird durch die Metrik "Zeit bis zum Klick" erfasst.

Vorbereitung

In der Vorbereitungsphase geht es darum, die Daten für die Erstellung der eigentlichen Geschäftslogik zur Gewinnung von Erkenntnissen vorzubereiten. Die Vorbereitung ist eine iterative, zeitintensive Aufgabe, die das Aggregieren, Bereinigen, Standardisieren, Transformieren und Denormalisieren von Daten umfasst. Dabei kommen mehrere Tools und Frameworks zum Einsatz. In der Vorbereitungsphase muss auch die Data Governance sichergestellt werden, um die gesetzlichen Vorschriften zu erfüllen.

Verwaltung aggregierter Daten in einem zentralen Repository

Um beim Beispiel zu bleiben: Die für das Business Dashboard und das Prognosemodell benötigten Daten werden nun in einem zentralen Repository (gemeinhin als Data Lake bezeichnet) zusammengefasst. Das Business Dashboard muss sowohl historische Batch-Daten als auch Streaming-Verhaltensdatenereignisse kombinieren. Die Daten müssen in Bezug auf Datenmodelle und Festplattenformat effizient aufbewahrt werden. Ähnlich wie bei der traditionellen Datenverwaltung müssen die Datennutzer Zugriffskontrolle, Backup, Versionierung, ACID Eigenschaften für gleichzeitige Datenaktualisierungen usw. sicherstellen. Die Zeit, die für die Umsetzung dieses Meilensteins benötigt wird, wird durch die Metrik "Zeit bis zum Data Lake Management" erfasst.

Strukturierung, Bereinigung, Anreicherung und Validierung von Daten

Da die Daten nun im Lake aggregiert sind, müssen wir sicherstellen, dass die Daten in der richtigen Form vorliegen. Nehmen wir zum Beispiel an, dass die Datensätze im Datensatz Fakturierung für Testkunden einen Nullwert haben. Als Teil der Strukturierung werden die Nullen explizit in Nullen umgewandelt. Ebenso kann es Ausreißer bei der Nutzung ausgewählter Kunden geben, die ausgeschlossen werden müssen, um die Gesamtanalyse des Engagements nicht zu verfälschen. Diese Aktivitäten werden als Data Wrangling bezeichnet. Die Anwendung von Wrangling-Transformationen erfordert das Schreiben eigenwilliger Skripte in Programmiersprachen wie Python, Perl und R oder eine mühsame manuelle Bearbeitung. Angesichts des wachsenden Volumens, der Geschwindigkeit und der Vielfalt der Daten benötigen die Datennutzer/innen Programmierkenntnisse auf niedrigem Niveau, um die Transformationen in großem Umfang effizient, zuverlässig und wiederkehrend anzuwenden. Diese Umwandlungen sind nicht einmalig, sondern müssen kontinuierlich und zuverlässig durchgeführt werden. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik "Time to Wrangle" erfasst.

Sicherstellung der Einhaltung von Datenrechten

Gehe davon aus, dass der Kunde nicht zugestimmt hat, dass seine Verhaltensdaten für die Gewinnung von Erkenntnissen verwendet werden. Datennutzer müssen verstehen, welche Kundendaten für welche Zwecke verwendet werden können. Compliance ist eine Gratwanderung zwischen der Verbesserung des Kundenerlebnisses durch Erkenntnisse und der Sicherstellung, dass die Daten im Einklang mit den Weisungen des Kunden verwendet werden. Es gibt keine einfachen Heuristiken, die universell zur Lösung dieses Problems angewendet werden können. Datennutzer/innen wollen eine einfache Möglichkeit haben, alle verfügbaren Daten für einen bestimmten Anwendungsfall zu finden, ohne sich Gedanken über Compliance-Verstöße machen zu müssen. Es gibt keine einheitliche Kennung, um anwendbare Kundendaten über die Silos hinweg zu verfolgen. Die Zeit, die benötigt wird, um diesen Meilenstein zu erreichen, wird durch die Metrik "Zeit bis zur Einhaltung" erfasst.

Baue

In der Build-Phase liegt der Schwerpunkt auf dem Schreiben der eigentlichen Logik, die für die Gewinnung der Erkenntnisse erforderlich ist. Im Folgenden sind die wichtigsten Meilensteine für diese Phase aufgeführt.

Entscheidung über den besten Ansatz für den Zugriff auf und die Analyse von Daten

Ein Ausgangspunkt für die Aufbauphase ist die Entscheidung über eine Strategie für das Schreiben und Ausführen der Insights-Logik. Die Daten im Data Lake können als Objekte persistiert oder in spezialisierten Serving-Layern gespeichert werden, z. B. in Key-Value-Stores, Graph-Datenbanken, Dokumentenspeichern usw. Die Datennutzer müssen entscheiden, ob sie die nativen APIs und Schlüsselwörter der Datenspeicher nutzen wollen, und sie müssen sich für eine Abfrage-Engine für die Verarbeitungslogik entscheiden. Kurze, interaktive Abfragen werden zum Beispiel auf Presto-Clustern ausgeführt, während lange Batch-Prozesse auf Hive oder Spark laufen. Im Idealfall sollte die Transformationslogik agnostisch sein und sich nicht ändern, wenn Daten in einen anderen Polyglot-Speicher verschoben werden oder eine andere Abfrage-Engine zum Einsatz kommt. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit für die Virtualisierung erfasst.

Transformationslogik schreiben

Die eigentliche Logik für das Dashboard oder die Modelleinblicke wird entweder als Extract-Transform-Load (ETL), Extract-Load-Transform (ELT), oder als Streaming Analysis Pattern geschrieben. Die Geschäftslogik muss in konkreten Code übersetzt werden, der performant und skalierbar sein muss und bei Änderungen einfach zu verwalten ist. Die Logik muss hinsichtlich Verfügbarkeit, Qualität und Änderungsmanagement überwacht werden. Die Zeit, die für die Umsetzung dieses Meilensteins benötigt wird, wird durch die Metrik "Zeit bis zur Transformation" erfasst.

Training der Modelle

Für das Beispiel der Umsatzprognose muss ein ML Modell trainiert werden. Zum Trainieren des Modells werden historische Umsatzwerte verwendet. Bei immer größeren Datensätzen und komplizierten Deep Learning-Modellen kann das Training Tage und Wochen dauern. Das Training wird auf einer Serverfarm durchgeführt, die aus einer Kombination von CPUs und Spezialhardware wie GPUs besteht. Das Training erfolgt iterativ, wobei Hunderte von Permutationen von Modellparametern und Hyperparametern angewendet werden, um das beste Modell zu finden. Die Modelle werden nicht nur einmal trainiert, sondern müssen bei veränderten Dateneigenschaften neu trainiert werden. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit für das Training erfasst.

Kontinuierliche Integration von ML-Modelländerungen

Nehmen wir im Beispiel des Business Dashboards an, dass sich die Definition für die Berechnung der aktiven Abonnenten ändert. ML-Modellpipelines werden ständig weiterentwickelt, indem Quellschemata, Funktionslogik, abhängige Datensätze, Datenverarbeitungskonfigurationen und Modellalgorithmen geändert werden. Ähnlich wie bei der traditionellen Softwareentwicklung werden auch ML-Modelle ständig aktualisiert, wobei täglich mehrere Änderungen in den Teams vorgenommen werden. Um die Änderungen zu integrieren, werden die Daten, der Code und die Konfiguration der ML-Pipelines nachverfolgt. Die Änderungen werden durch den Einsatz in einer Testumgebung und mit Produktionsdaten überprüft. Die Zeit, die für diesen Meilenstein benötigt wird, wird mit der Metrik Zeit für die Integration erfasst.

A/B-Tests von Erkenntnissen

Betrachte ein anderes Beispiel für ein ML-Modell, das die Immobilienpreise für Endkunden vorhersagt. Angenommen, es gibt zwei gleich genaue Modelle, die für diese Erkenntnis entwickelt wurden - welches ist besser? In den meisten Unternehmen ist es gängige Praxis, mehrere Modelle einzusetzen und sie verschiedenen Kundengruppen zu präsentieren. Ziel ist es, auf der Grundlage von Daten über das Nutzungsverhalten der Kunden das bessere Modell auszuwählen. A/B-Tests - auch bekannt als Bucket-Tests, Split-Tests oder kontrollierte Experimente - werden immer mehr zum Standard, um datengestützte Entscheidungen zu treffen. Es ist wichtig, A/B-Tests als Teil der Datenplattform zu integrieren, um sicherzustellen, dass konsistente Kennzahlendefinitionen für ML-Modelle, Geschäftsberichte und Experimente angewendet werden. Die korrekte Konfiguration von A/B-Testing-Experimenten ist nicht trivial und muss sicherstellen, dass es kein Ungleichgewicht gibt, das zu einem statistisch signifikanten Unterschied in einer Kennzahl von Interesse zwischen den Variantenpopulationen führen würde. Außerdem dürfen die Kunden keinen Wechselwirkungen zwischen den Varianten verschiedener Experimente ausgesetzt sein. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Kennzahl Zeit bis zum A/B-Test erfasst.

Operationalisiere

In der Operationalisierungsphase der Journey Map wird die Erkenntnis in der Produktion eingesetzt. Diese Phase dauert an, bis die Erkenntnisse aktiv in der Produktion genutzt werden.

Überprüfen und Optimieren von Abfragen

Um beim Beispiel des Business Dashboards und des Umsatzprognosemodells zu bleiben, haben die Datennutzer die Datenumwandlungslogik entweder als SQL-Abfragen oder als Big-Data-Programmiermodelle (wie Apache Spark oder Beam) geschrieben, die in Python, Java, Scala usw. implementiert sind. Der Unterschied zwischen guten und schlechten Abfragen ist beträchtlich. Erfahrungsgemäß kann eine Abfrage, die ein paar Stunden läuft, so eingestellt werden, dass sie in wenigen Minuten abgeschlossen ist. Datennutzer müssen die vielen Regler in Abfrage-Engines wie Hadoop, Spark und Presto verstehen. Für die meisten Datennutzer ist es nicht trivial zu verstehen, welche Regler eingestellt werden müssen und welche Auswirkungen sie haben. Es gibt keine Patentrezepte - die optimalen Reglerwerte für eine Abfrage variieren je nach Datenmodell, Abfragetyp, Clustergröße, gleichzeitiger Abfragelast und so weiter. Daher ist die Abfrageoptimierung eine fortlaufende Aktivität. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit für die Optimierung erfasst.

Pipelines orchestrieren

Die Abfragen, die mit dem Business Dashboard und den Prognose-Pipelines verbunden sind, müssen geplant werden. Was ist der optimale Zeitpunkt für die Ausführung der Pipeline? Wie stellen wir sicher, dass die Abhängigkeiten korrekt gehandhabt werden? Die Orchestrierung ist ein Balanceakt, um die Service Level Agreements (SLAs) der Pipelines und die effiziente Nutzung der zugrunde liegenden Ressourcen sicherzustellen. Pipelines rufen Dienste in den Bereichen Ingestion, Vorbereitung, Transformation, Training und Bereitstellung auf. Datennutzer müssen Pipelines auf Korrektheit, Robustheit und Pünktlichkeit in diesen Diensten überwachen und debuggen, was nicht trivial ist. Die Orchestrierung von Pipelines ist mandantenfähig und unterstützt mehrere Teams und Geschäftsanwendungen. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit für die Orchestrierung erfasst.

Einsatz der ML-Modelle

Das Prognosemodell wird in der Produktion so eingesetzt, dass es von verschiedenen Programmen aufgerufen werden kann, um den vorhergesagten Wert zu erhalten. Die Bereitstellung des Modells ist keine einmalige Aufgabe - die ML-Modelle werden regelmäßig auf der Grundlage von Umschulungen aktualisiert. Datennutzer verwenden nicht standardisierte, selbst entwickelte Skripte für die Bereitstellung von Modellen, die angepasst werden müssen, um eine breite Palette von ML-Modelltypen, ML-Bibliotheken und -Tools, Modellformaten und Bereitstellungsendpunkten (wie IoT-Geräte, Mobilgeräte, Browser und Web-API) zu unterstützen. Es gibt keine standardisierten Frameworks zur Überwachung der Leistung von Modellen und zur automatischen Skalierung je nach Auslastung. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Kennzahl Zeit bis zur Bereitstellung erfasst.

Überwachung der Qualität der Erkenntnisse

Da das Business Dashboard täglich genutzt wird, könnte es zum Beispiel für einen bestimmten Tag einen falschen Wert anzeigen. Mehrere Dinge können schiefgehen und zu Qualitätsproblemen führen: unkoordinierte Änderungen des Quellschemas, Änderungen der Eigenschaften von Datenelementen, Probleme bei der Dateneingabe, Quell- und Zielsysteme mit nicht synchronen Daten, Verarbeitungsfehler, falsche Geschäftsdefinitionen für die Erstellung von Kennzahlen und vieles mehr. Datennutzer müssen Datenattribute auf Anomalien hin analysieren und die Ursache von erkannten Qualitätsproblemen beseitigen. Datennutzer verlassen sich auf einmalige Prüfungen, die bei großen Datenmengen, die über mehrere Systeme fließen, nicht skalierbar sind. Das Ziel ist nicht nur, Datenqualitätsprobleme zu erkennen, sondern auch zu vermeiden, dass Datensätze mit geringer Qualität mit den restlichen Partitionen des Datensatzes vermischt werden. Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Metrik Zeit bis zur Erkenntnis der Qualität erfasst.

Kontinuierliche Kostenüberwachung

Wir haben jetzt Einblicke in die Produktion, die kontinuierlich überwacht werden, um die Qualität sicherzustellen. Der letzte Teil der operationalisierten Phase ist das Kostenmanagement. Das Kostenmanagement ist besonders wichtig in der Cloud, wo das Pay-as-you-go-Modell linear mit der Nutzung steigt (im Gegensatz zum traditionellen Buy-up-Front-Modell mit festen Kosten). Durch die Demokratisierung der Daten, bei der sich die Nutzer/innen selbst um die Gewinnung von Erkenntnissen kümmern können, besteht die Möglichkeit einer erheblichen Ressourcenverschwendung und unbegrenzter Kosten. Eine einzige fehlerhafte Abfrage, die auf High-End-GPUs läuft, kann innerhalb weniger Stunden Tausende von Dollar verschlingen - meist zur Überraschung der Datennutzer. Die Datennutzer müssen Fragen beantworten wie: a) Wie hoch sind die Ausgaben pro Anwendung? b) Welches Team wird voraussichtlich mehr als das ihm zugewiesene Budget ausgeben? c) Gibt es Möglichkeiten, die Ausgaben zu reduzieren, ohne die Leistung und Verfügbarkeit zu beeinträchtigen? und d) Werden die zugewiesenen Ressourcen angemessen genutzt? Die Zeit, die für diesen Meilenstein benötigt wird, wird durch die Kennzahl Zeit zur Kostenoptimierung erfasst.

Insgesamt verbringen Datennutzer heute in jeder Phase der Reise einen erheblichen Anteil ihrer Zeit mit Data-Engineering-Aufgaben wie dem Verschieben von Daten, dem Verstehen der Datenreihenfolge, dem Durchsuchen von Datenartefakten usw. Das ideale Nirwana für Datennutzer ist eine Self-Service-Datenplattform, die diese Aufgaben, die im Alltag anfallen, vereinfacht und automatisiert.

Definiere deine Time-to-Insight Scorecard

Die Zeit bis zur Erkenntnis ist die Gesamtkennzahl, die die Zeit misst, die benötigt wird, um die gesamte Reise von den Rohdaten bis zur Erkenntnis zu vollenden. Im Beispiel der Entwicklung des Business Dashboards und des Umsatzprognosemodells stellt die Zeit bis zu den Erkenntnissen die Gesamtzahl der Tage, Wochen oder Monate dar, um die Phasen der Journey Map abzuschließen. Aufgrund meiner Erfahrung mit der Verwaltung von Datenplattformen habe ich die Journey Map in 18 wichtige Meilensteine unterteilt, wie im vorherigen Abschnitt beschrieben. Jedem Meilenstein ist eine Kennzahl zugeordnet, so dass sich die Gesamtzeit bis zur Erkenntnis aus der Summe der einzelnen Meilensteinkennzahlen ergibt.

Jedes Unternehmen hat andere Probleme im Zusammenhang mit der Journey Map. Im Beispiel der Entwicklung des Business Dashboards könnte ein Unternehmen aufgrund mehrerer Silos und fehlender Dokumentation einen Großteil der Zeit für die Interpretation von und die Suche nach aufwenden, während für ein Unternehmen in einer regulierten Branche die Einhaltung von ein wichtiger Schmerzpunkt in der Journey Map ist. Im Allgemeinen unterscheiden sich die Unternehmen in ihren Schmerzpunkten aufgrund des unterschiedlichen Reifegrads der bestehenden Prozesse, der Technologie, der Datenbestände, der Fähigkeiten des Datenteams, der Branchenzugehörigkeit und so weiter. Um den aktuellen Status der Datenplattform zu bewerten, verwenden wir eine Time-to-Insight-Scorecard, wie in Abbildung 1-3 dargestellt. Ziel der Übung ist es, die Meilensteine zu bestimmen, die in der gesamten Journey Map am meisten Zeit in Anspruch nehmen.

Abbildung 1-3. Scorecard für die Metrik "Zeit bis zur Einsicht" als Summe der einzelnen Meilensteinmetriken innerhalb der Journey Map.

Jedes Kapitel im Rest des Buches entspricht einer Kennzahl in der Scorecard und beschreibt die Entwurfsmuster, um sie zur Selbstbedienung zu machen. Im Folgenden findest du eine kurze Zusammenfassung der Metriken:

Zeit zum Dolmetschen

Damit verbunden ist der Meilenstein, die Details der Metadaten eines Datensatzes zu verstehen, bevor man ihn für die Entwicklung von Erkenntnissen nutzt. Falsche Annahmen über den Datensatz führen oft zu falschen Erkenntnissen. Der vorhandene Wert der Metrik hängt von dem Prozess zur Definition, Extraktion und Aggregation von technischen Metadaten, operativen Metadaten und Teamwissen ab. Um den Zeitaufwand für die Interpretation zu minimieren und sie in einen Self-Service umzuwandeln, werden in Kapitel 2 Implementierungsmuster für einen Metadatenkatalogdienst vorgestellt, der Metadaten durch Crawling von Quellen extrahiert, die Herkunft abgeleiteter Datensätze verfolgt und das Teamwissen in Form von Tags, Validierungsregeln usw. zusammenfasst.

Zeit zu finden

Verbunden mit dem Meilenstein der Suche nach verwandten Datensätzen und Artefakten. Ein hoher Zeitaufwand für die Suche führt dazu, dass Teams das Rad neu erfinden, indem sie Klone von Datenpipelines, Dashboards und Modellen im Unternehmen entwickeln, was zu mehreren Quellen der Wahrheit führt. Der Wert der Metrik hängt von den bestehenden Prozessen zur Indexierung, Einordnung und Zugriffskontrolle von Datensätzen und Artefakten ab. In den meisten Unternehmen werden diese Prozesse entweder ad hoc durchgeführt oder sind manuell vom Datenplattformteam abhängig. Um die Zeit für die Suche zu minimieren und sie zu einem Self-Service zu machen, werden in Kapitel 3 Implementierungsmuster für einen Suchdienst vorgestellt.

Zeit zum Featurisieren

Verbunden mit dem Meilenstein der Verwaltung von Merkmalen für das Training von ML-Modellen. Data Scientists verbringen 60 % ihrer Zeit mit der Erstellung von Trainingsdatensätzen für ML-Modelle. Der vorhandene Wert der Metrik hängt vom Prozess der Feature-Berechnung und der Feature-Bereitstellung ab. Um den Zeitaufwand für die Feature-Berechnung zu minimieren und sie zur Selbstbedienung zu machen, befasst sich Kapitel 4 mit den Implementierungsmustern eines Feature Store Service.

Zeit bis zur Datenverfügbarkeit

Verbunden mit dem Meilenstein des Verschiebens von Daten über die Silos hinweg. Datennutzer verbringen 16% ihrer Zeit mit dem Verschieben von Daten. Der bestehende Wert der Kennzahl hängt vom Prozess der Verbindung mit heterogenen Datenquellen, dem Kopieren und Überprüfen von Daten und der Anpassung an Schema- oder Konfigurationsänderungen in den Datenquellen ab. Um die Zeit bis zur Datenverfügbarkeit zu minimieren und sie zum Self-Service zu machen, werden in Kapitel 5 die Implementierungsmuster eines Datenverschiebungsdienstes behandelt.

Zeit zum Klicken auf Metriken

Verbunden mit dem Meilenstein des Sammelns, Verwaltens und Analysierens von Clickstream-Datenereignissen. Der bestehende Wert der Metrik hängt vom Prozess der Erstellung von Instrumentation Beacons, der Aggregation von Ereignissen, der Anreicherung durch Filterung und dem ID-Stitching ab. Um den Zeitaufwand für die Erstellung von Klickmetriken zu minimieren und sie zu einem Self-Service zu machen, werden in Kapitel 6 Implementierungsmuster eines Clickstream-Dienstes behandelt.

Zeit für Data Lake Management

Verbunden mit dem Meilenstein der Datenverwaltung in einem zentralen Repository. Der bestehende Wert der Kennzahl hängt vom Prozess der Verwaltung primitiver Datenlebenszyklusaufgaben, der Sicherstellung der Konsistenz von Datenaktualisierungen und der gemeinsamen Verwaltung von Batching und Streaming von Daten ab. Um den Zeitaufwand für das Data-Lake-Management zu minimieren und es zu einem Self-Service zu machen, behandelt Kapitel 7 die Implementierungsmuster eines Data-Lake-Management-Dienstes.

Zeit zum Streiten

Mit dem Meilenstein der Strukturierung, Bereinigung, Anreicherung und Validierung von Daten verbunden. Der bestehende Wert der Metrik hängt vom Prozess der Identifizierung der Anforderungen an die Datenkuratierung eines Datensatzes, der Erstellung von Transformationen zur Kuratierung von Daten in großem Umfang und der operativen Überwachung der Korrektheit ab. Um den Zeitaufwand für die Datenpflege zu minimieren und sie zum Self-Service zu machen, werden in Kapitel 8 die Implementierungsmuster eines Datenpflege-Dienstes beschrieben.

Zeit zu erfüllen

Verbunden mit dem Meilenstein, die Einhaltung der Datenrechte sicherzustellen. Der Wert der Kennzahl hängt von dem Prozess ab, mit dem Kundendaten über die Anwendungssilos hinweg verfolgt werden, mit dem Anfragen nach Datenrechten für Kunden ausgeführt werden und mit dem sichergestellt wird, dass die Anwendungsfälle nur die Daten verwenden, denen die Kunden zugestimmt haben. Um den Zeitaufwand für die Einhaltung der Vorgaben zu minimieren und sie in einen Self-Service umzuwandeln, werden in Kapitel 9 Implementierungsmuster für einen Data Rights Governance Service beschrieben.

Zeit zum Virtualisieren

Verbunden mit dem Meilenstein der Auswahl des Ansatzes zum Aufbau und zur Analyse von Daten. Der Wert der Metrik hängt vom Prozess der Formulierung von Abfragen für den Zugriff auf Daten in polyglotten Datenspeichern, von Abfragen zum Zusammenführen von Daten in den Datenspeichern und von der Verarbeitung von Abfragen im Produktionsmaßstab ab. Um den Zeitaufwand für die Virtualisierung zu minimieren und sie zum Self-Service zu machen, werden in Kapitel 10 die Implementierungsmuster eines Datenvirtualisierungsdienstes beschrieben.

Zeit für Veränderung

Verbunden mit dem Meilenstein der Implementierung der Transformationslogik in Daten- und ML-Pipelines. Die Umwandlung kann als Batch, nahezu in Echtzeit oder in Echtzeit erfolgen. Der bestehende Wert der Metrik hängt von dem Prozess ab, mit dem die Transformationslogik definiert, ausgeführt und betrieben wird. Um die Zeit für die Transformation zu minimieren und sie zu einem Self-Service zu machen, werden in Kapitel 11 die Implementierungsmuster eines Datentransformationsdienstes behandelt .

Zeit zum Trainieren

Verbunden mit dem Meilenstein des Trainings von ML-Modellen. Der Wert der Metrik hängt von dem Prozess ab, mit dem das Training, die Abstimmung der Modellparameter und die kontinuierliche Anpassung an neue Datenproben organisiert werden. Um den Zeitaufwand für das Training zu minimieren und es zu einem Self-Service zu machen, behandelt Kapitel 12 die Implementierungsmuster eines Modelltrainingsdienstes.

Zeit für Integration

Verbunden mit dem Meilenstein der Integration von Code-, Daten- und Konfigurationsänderungen in ML-Pipelines. Der Wert der Kennzahl hängt von dem Prozess ab, mit dem die Iterationen der ML-Pipelines verfolgt, reproduzierbare Pakete erstellt und die Pipeline-Änderungen auf ihre Korrektheit überprüft werden. Um den Zeitaufwand für die Integration zu minimieren und sie zur Selbstbedienung zu machen, werden in Kapitel 13 Implementierungsmuster für einen kontinuierlichen Integrationsdienst für ML-Pipelines behandelt.

Zeit für A/B-Tests

Verbunden mit dem Meilenstein der A/B-Tests. Der bestehende Wert der Metrik hängt vom Prozess der Planung eines Online-Experiments, der Durchführung im großen Maßstab (einschließlich der Analyse der Metrik) und der kontinuierlichen Optimierung des Experiments ab. Um den Zeitaufwand für A/B-Tests zu minimieren und sie zur Selbstbedienung zu machen, werden in Kapitel 14 Implementierungsmuster eines A/B-Testing-Dienstes als Teil der Datenplattform behandelt.

Zeit zum Optimieren

Verbunden mit dem Meilenstein der Optimierung von Abfragen und Big-Data-Programmen. Der bestehende Wert der Metrik hängt von dem Prozess ab, mit dem die Überwachungsstatistiken aggregiert, die überwachten Daten analysiert und auf der Grundlage der Analyse Korrekturmaßnahmen eingeleitet werden. Um den Zeitaufwand für A/B-Tests zu minimieren und sie zu einem Self-Service zu machen, behandelt Kapitel 15 die Implementierungsmuster eines Abfrageoptimierungsdienstes.

Zeit zum Inszenieren

Verbunden mit dem Meilenstein der Orchestrierung von Pipelines in der Produktion. Der Wert dieser Kennzahl hängt von dem Prozess ab, mit dem die Abhängigkeiten zwischen den Aufträgen entworfen, die Aufträge effizient auf den verfügbaren Hardwareressourcen ausgeführt und ihre Qualität und Verfügbarkeit überwacht werden, insbesondere bei SLA-gebundenen Produktionspipelines. Um den Zeitaufwand für die Orchestrierung zu minimieren und die Orchestrierung zum Self-Service zu machen, werden in Kapitel 16 die Implementierungsmuster eines Pipeline-Orchestrierungsdienstes behandelt.

Zeit zum Einsatz

Verbunden mit dem Meilenstein des Einsatzes von Erkenntnissen in der Produktion. Der bestehende Wert der Kennzahl hängt von dem Prozess ab, mit dem die in Form von Modell-Endpunkten verfügbaren Erkenntnisse verpackt und skaliert werden, um die Modelldrift zu überwachen. Um den Zeitaufwand für die Bereitstellung zu minimieren und sie zu einem Self-Service zu machen, werden in Kapitel 17 Implementierungsmuster für einen Modellbereitstellungsdienst beschrieben.

Zeit zur Einsicht Qualität

Verbunden mit dem Meilenstein, die Korrektheit der gewonnenen Erkenntnisse sicherzustellen. Der bestehende Wert der Metrik hängt von dem Prozess ab, mit dem die Richtigkeit der Daten überprüft, die Dateneigenschaften auf Anomalien untersucht und proaktiv verhindert wird, dass Datensätze von geringer Qualität den Data Lake verschmutzen. Um die Zeit bis zum Erreichen der Insight-Qualität zu minimieren und sie zum Self-Service zu machen, werden in Kapitel 18 die Implementierungsmuster eines Qualitätsbeobachtungsdienstes behandelt.

Zeit zur Kostenoptimierung

Verbunden mit dem Meilenstein der Kostenminimierung, insbesondere beim Betrieb in der Cloud. Der bestehende Wert der Kennzahl hängt vom Prozess der Auswahl kosteneffizienter Cloud-Dienste, der Konfiguration und dem Betrieb der Dienste sowie der laufenden Kostenoptimierung ab. Um den Zeitaufwand für die Kostenoptimierung zu minimieren und sie zur Selbstbedienung zu machen, werden in Kapitel 19 Implementierungsmuster eines Kostenmanagementdienstes behandelt.

Das Endergebnis dieser Analyse ist eine Scorecard, die dem aktuellen Stand der Datenplattform entspricht (ähnlich wie in Abbildung 1-4). Jede Kennzahl ist farblich gekennzeichnet, je nachdem, ob die mit der Kennzahl verbundenen Aufgaben in der Größenordnung von Stunden, Tagen oder Wochen erledigt werden können. Eine Kennzahl, die in der Größenordnung von Wochen liegt, steht typischerweise für Aufgaben, die heute ad hoc mit manuellen, nicht standardisierten Skripten und Programmen ausgeführt werden, und/oder für Aufgaben, die eine Koordination zwischen Datennutzern und Datenplattformteams erfordern. Solche Kennzahlen zeigen, dass das Unternehmen in die Selbstbedienung der Datennutzer investieren muss.

Die Komplexität, die mit jeder der Scorecard-Kennzahlen verbunden ist, ist von Unternehmen zu Unternehmen unterschiedlich. In einem Startup mit einer Handvoll Datensätzen und Datenteammitgliedern kann die Zeit für die Suche und die Zeit für die Interpretation in wenigen Stunden bewältigt werden, wenn man sich ausschließlich auf das Wissen des Teams verlässt, auch wenn der Prozess ad hoc erfolgt. Stattdessen kann die meiste Zeit für die Datenverarbeitung oder die Überprüfung der Qualität der Erkenntnisse aufgewendet werden, wenn die Qualität der verfügbaren Daten schlecht ist. Außerdem unterscheiden sich die Unternehmen in den Anforderungen, die mit den einzelnen Diensten der Datenplattform verbunden sind. Ein Unternehmen, das beispielsweise nur einmal im Quartal offline trainierte ML-Modelle einsetzt (anstelle eines kontinuierlichen Online-Trainings), legt vielleicht keine Priorität auf die Verbesserung der Trainingszeit, auch wenn dies einige Wochen dauert.

Abbildung 1-4. Beispiel einer Scorecard, die den aktuellen Stand der Datenplattform eines Unternehmens darstellt .

Erstelle deine Self-Service Daten Roadmap

Der erste Schritt bei der Entwicklung der Self-Service-Daten-Roadmap ist die Definition der Scorecard für den aktuellen Zustand der Datenplattform, wie im vorherigen Abschnitt beschrieben. Die Scorecard hilft dabei, eine kurze Liste der Kennzahlen zu erstellen, die den Weg von Rohdaten zu Erkenntnissen verlangsamen. Jede Kennzahl in der Scorecard kann auf einer anderen Self-Service-Ebene angesiedelt sein und in der Roadmap nach dem Grad der Verlangsamung der Gesamtzeit bis zur Erkenntnis priorisiert werden.

Wie bereits erwähnt, werden in jedem Kapitel Entwurfsmuster behandelt, um die entsprechende Metrik zur Selbstbedienung zu machen. Wir gehen davon aus, dass Self-Service mehrere Stufen hat, analog zu den verschiedenen Stufen von selbstfahrenden Autos, die sich darin unterscheiden, wie viel menschliches Eingreifen erforderlich ist, um sie zu bedienen (wie in Abbildung 1-5 dargestellt). So beschleunigt, lenkt und bremst ein selbstfahrendes Auto der Stufe 2 unter Aufsicht des Fahrers selbst, während Stufe 5 vollautomatisch ist und keine menschliche Aufsicht erfordert.

Abbildung 1-5. Verschiedene Automatisierungsstufen in einem selbstfahrenden Auto (aus DZone).

Unternehmen müssen systematisch den Fahrplan für die Verbesserung des Automatisierungsgrades für jede der ausgewählten Kennzahlen planen. Die Design Patterns in den einzelnen Kapiteln sind wie die Maslowsche Bedürfnispyramide aufgebaut. Die unterste Ebene der Pyramide zeigt das zu implementierende Pattern an und wird von zwei weiteren Ebenen gefolgt, die jeweils auf der vorherigen aufbauen. Die gesamte Pyramide innerhalb eines bestimmten Kapitels steht für die Selbstbedienung, wie in Abbildung 1-6 dargestellt.

Abbildung 1-6. Maslows Hierarchie der Aufgabenautomatisierung wird in jedem Kapitel befolgt.

Zusammenfassend lässt sich sagen, dass dieses Buch auf der Erfahrung bei der Implementierung von Self-Service-Datenplattformen in mehreren Unternehmen basiert. Um den größtmöglichen Nutzen aus dem Buch zu ziehen, empfehle ich den Leserinnen und Lesern, bei der Umsetzung ihrer Self-Service-Roadmap den folgenden Ansatz zu verfolgen:

1. Beginne damit, die aktuelle Scorecard zu definieren.

2. Identifiziere auf der Grundlage von Umfragen unter den Datennutzern zwei oder drei Kennzahlen, die die Journey Map am stärksten verlangsamen, und führe eine technische Analyse durch, wie die Aufgaben derzeit umgesetzt werden. Beachte, dass die Bedeutung dieser Metriken für jedes Unternehmen unterschiedlich ist, je nach den aktuellen Prozessen, den Fähigkeiten der Datennutzer, den Technologiebausteinen, den Dateneigenschaften und den Anforderungen der Anwendungsfälle.

3. Beginne bei jeder Kennzahl mit der Maslowschen Hierarchie der zu implementierenden Muster. Jedes Kapitel ist einer Kennzahl gewidmet und behandelt Muster mit zunehmendem Automatisierungsgrad. Anstatt bestimmte Technologien zu empfehlen, die im Zuge der rasanten Big-Data-Entwicklung bald veraltet sein werden, konzentriert sich das Buch auf Implementierungsmuster und liefert Beispiele für bestehende Technologien, die sowohl vor Ort als auch in der Cloud verfügbar sind.

4. Verfolge eine schrittweise "Crawl, Walk, Run"-Strategie mit dem Schwerpunkt, die ausgewählten Kennzahlen jedes Quartal zu verdoppeln und sie zur Selbstbedienung zu machen.

Schließlich versucht das Buch, die Perspektiven sowohl der Datennutzer als auch der Datenplattform-Ingenieure zusammenzubringen. Die Schaffung eines gemeinsamen Verständnisses der Anforderungen ist entscheidend für die Entwicklung einer pragmatischen Roadmap, die das Mögliche mit dem Machbaren angesichts des Zeitrahmens und der verfügbaren Ressourcen verbindet.

Fertig! Fertig! Los!