Künstliche Intelligenz und Machine Learning sind derzeit in aller Munde. Zahlreiche Unternehmen wollen auf diesen Zug aufspringen und von ihren Datenreserven profitieren.
Bei Thoughtworks sind wir der Meinung, dass diese Technologie ein enormes Potenzial bietet – aber Erfolge feiern nur diejenigen, die die Technologie wertschöpfend einsetzen.
KundenInnen treten oft mit dem Wunsch an uns heran, ihre Entwicklung im Bereich der künstlichen Intelligenz mittels eines Data Lakes voran zu treiben. Oft wird diese Herangehensweise ausschließlich als ein Bestreben nach optimierter Infrastruktur betrachtet, ohne vorher Anwendungsfälle und Ziele zu definieren. Die Annahme ist: “Wenn wir eine robuste Dateninfrastruktur aufbauen, werden sich später schon Anwendungsfälle dafür ergeben”.
In diesem Artikel möchten wir erklären, warum man Software unserer Meinung nach am besten in dünnen, vertikalen Scheiben entwickelt und sie unbedingt an Anwendungsfälle koppelt, die jeweils einen klaren Mehrwert für die NutzerInnen liefern. Auch datenintensive Projekte bilden keine Ausnahme. Es kann verlockend sein, eine Plattform mit nur einer horizontalen Ebene (manchmal als Data Lake bezeichnet) zu entwickeln – besonders für Anwendungsfälle mit umfangreichen Datenmengen in unterschiedlichen Formaten. Es stellt sich die Frage: Ist der Ansatz des "Product Thinking" vielleicht der bessere Weg für einige Data-Lake-Projekte?
Eine ungenaue Definition führt meist zu einer ungeplanten Erweiterung des Projektumfangs, zu Budgetüberschreitungen und zu "technischer Überentwicklung". Je nach Zielsetzung kann es sein, dass ein Amazon S3 Bucket mit der richtigen Zugriffsberechtigung als Data Lake schon ausreicht, um unverarbeitete Daten zu speichern. Aus diesem Grund ist es wichtig, am Anfang des Projektes ein gemeinsames Verständnis vom Umfang und Nutzen des Data Lakes im Unternehmen zu etablieren.
Die meisten großen Unternehmen würden davon profitieren, wenn sie den Umfang der Data Lakes auf das Speichern von Rohdaten beschränken und funktionsübergreifende Produktteams bilden würden, um Machine Learning-Anwendungen mit ihren eigenen Darstellungen (Lake Shore Marts) zu entwickeln, die speziell auf ihren Anwendungsfall zugeschnitten sind. Ein Zitat aus Martins Blogbeitrag:
Ein einziges, einheitliches Datenmodell ist für alle unpraktisch, außer für kleine Organisationen. Um einen annähernd komplexen Sachverhalt darzustellen, benötigt man mehrere abgegrenzte Kontexte, jede mit einem eigenen Datenmodell. Wir werden später an einem Beispiel erklären, wie so ein Ansatz aussehen könnte.
Oft gehören Data Scientists und Data Engineers zu verschiedenen Teams. Data Scientists sind näher an der Business-Perspektive, während Data Engineers sich mehr mit der Infrastruktur und IT befassen. Getrennte Teams erschweren den Informationsfluss zwischen relevanten Parteien durch Wissens-Silos und verstärken die Tendenz einen Data Lake lediglich als ein Infrastrukturproblem zu betrachten. Conways Gesetz trifft hier schon wieder zu.
Es ist nicht leicht, spezifische Anwendungsfälle und die Wertschöpfung eines Data Lakes zu ermitteln. Hierfür ist es notwendig, die Anwender einzubeziehen; die unterschiedlichen Parteien müssen sich auf ein gemeinsames Ziel einigen. Es ist verlockend, dieses komplexe Problem mit einem materiellen Problem zu ersetzen, das nur die technischen Aspekte betrachtet.
Eines der gängigsten Argumente von VertreternInnen der "erstmal machen, der Rest ergibt sich von alleine"-Mentalität ist, Data Lakes sollten für eine große Bandbreite an Use Cases verwendbar sein und nicht durch ein spezifisches Ziel begrenzt werden. Der Voraussetzung, dass ein Data Lake mehr als nur einen Anwendungsfall unterstützen soll, stimmen wir zu. Wir sind aber der Meinung, dass oft zuviel Up-Front-Architektur und Design geschehen, bevor überhaupt über Use Cases nachgedacht wird.
Und ohne praktische Modelle aus den Daten zu entwickeln und sie in der realen Welt auszuprobieren, um aus Wiederholungen und Feedbacks zu lernen, ist es schwer, die beste Lösung für ein Problem zu finden.
Die Bereinigung und Formatierung der Daten für einen Use Case machen 70 bis 80 Prozent des Aufwandes der Entwicklung einer Anwendung für Machine Learning aus.
Deshalb ist es nicht sinnvoll, viel Arbeit in die Aufbereitung der Daten zu stecken, ohne sich über deren Annwendung im klaren zu sein. Die Personen, die an dem Modell arbeiten, werden wahrscheinlich noch einmal so viel Arbeit investieren müssen, sobald die Anwendungsfälle erst bestimmt sind.
Betrachten wir das an einem hypothetischen Beispiel:
Ein Versicherer plant die Erstellung eines Data Lakes. Hierbei soll die Art und Weise, wie Data Scientists oder Business Analysts Daten abrufen und analysieren, revolutioniert werden, um Ergebnisse für ihr Unternehmen zu erhalten. Die Firma ist über die Jahre durch Übernahmen und Zusammenschlüsse mit kleineren Versicherern gewachsen und hat deshalb keine einheitliches Kundensicht. Die Kundendaten sind auf etwa 20 Subsysteme aufgeteilt, die sich nach der Produktlinie richten (Krankenversicherung, Autoversicherung, Haustierversicherung, etc.)
Im Zusammenhang mit der Data Lake-Initiative möchte das Unternehmen nun ein einheitliches Bild seiner KundenInnen generieren. Es verbringt Monate damit, eine durchgängigen Definition seiner KundenInnen zu finden, die für alle zukünftigen Anwendungsfälle gültig ist. Das Ergebnis ist nur mittelmäßig zufriedenstellend. Wo liegen die Ursachen?
Einige Data Lake-Projekte sind noch ungenauer und komplexer als das eben genannte Beispiel. Sie verfolgen das Ziel, alle Geschäftsbereiche und Vorgänge in einer zentralen Datenstruktur zu bündeln.
Wenn die Nutzer des Data Lakes nicht früh genug sicherstellen, dass die gespeicherten Daten auch genutzt werden, besteht die Gefahr, dass aus dem Data Lake ein Datensumpf wird – also ein Abladeort für Daten jeglicher Qualität. Dies ist kostenintensiv und der Nutzen für das Unternehmen ist gering.
Fangen wir mit den folgenden Use Cases an:
Im Vorhinein werden bis dato schon einige Entscheidungen getroffen, z. B. ob man on-premise oder lieber in-cloud arbeiten möchte oder welchen Provider und welchen Datenspeicher man verwenden möchte. Diese Entscheidungen lassen sich später im Projekt nicht mehr so leicht ändern, deshalb müssen sie auf ein Minimum reduziert werden.
Ein Architekturteam stellt die sicher, dass die Architektur geeignet ist Governance-Strukturen beachtet werden, während sich die Plattform weiterentwickelt und Anwendungen entstehen.
Ein interdisziplinäres Delivery-Team, in dem Product Owner, Data Scientists und Data Engineers vertreten sind, bereitet den Software Prototyp für die Produktion vor.
Nachdem sich eine erste Version des Modells in Produktion befindet, beobachtet das Team, durch welche zusätzlichen Bereiche das Modell ergänzt werden kann. Die Data Scientists arbeiten eng mit den Data Engineers zusammen und geben relevante Informationen umgehend weiter. Feedback kann so schnell verarbeitet werden kann. Zusammen suchen sie nach dem besten Weg, Daten aus den neu erschlossenen Bereichen zu sammeln und das Modell anzupassen. Das neue Modell ist nun deutlich besser als das erste.
Dieser Ansatz bringt den Vorteil mit sich, dass nur zwei von 20 Datenquellen genutzt werden (müssen). So wird viel Arbeit gespart und noch effektiver auf das Fünf-Prozent-Ziel hingearbeitet.
Wenn das Betrugsermittlungssystem läuft und bereits einen Mehrwert für das Unternehmen generiert, kann sich das Unternehmen darauf konzentrieren, die Kundendaten für das Zusatzverkaufsziel wirksam einzusetzen. Hierfür werden Produktdaten und Kundendaten über Gebäudeversicherungen zum Data Lake hinzugefügt. Sie bilden zusammen mit bestehenden Kundendaten eine neue Darstellung in ihrem eigenen abgegrenzten Kontext. So kann auf produktive und effektive Weise auf das Ziel “zwei Prozent Zusatzverkäufe” hingearbeitet werden.
Jetzt kann sich das Unternehmen dem Use Case "Benachrichtigungen" zuwenden. In diesem Fall handelt es sich um ein komplexes Modell, das alle bisher verwendeten Daten mit einschließt und zusätzlich noch eine weitere Quelle benötigt: Wetterdaten in Echtzeit.
Einige der unformatierten Kundendaten müssen für den Anwendungsfall neu aufbereitet werden. Doch welcher Vorteil liegt darin, die Daten im nachhinein aufzubereiten und nicht direkt zu Anfang? Das Team versteht mittlerweile die Anforderungen der ersten beiden Anwendungsfälle besser und kann deshalb mit dem entsprechenden Arbeitseinsatz den gewünschten Mehrwert schaffen, ohne viel Zeit mit Spekulationen zu verschwenden.
Nur damit keine Missverständnisse aufkommen: Der Prozess kann bis zu einem gewissen Grad auch parallel ablaufen. Uns geht es darum, zu vermitteln, dass nicht alle Arbeiten an anderen Use Cases warten müssen, bis ein Use Case abgeschlossen ist.
Fazit:
Bei Thoughtworks sind wir der Meinung, dass diese Technologie ein enormes Potenzial bietet – aber Erfolge feiern nur diejenigen, die die Technologie wertschöpfend einsetzen.
KundenInnen treten oft mit dem Wunsch an uns heran, ihre Entwicklung im Bereich der künstlichen Intelligenz mittels eines Data Lakes voran zu treiben. Oft wird diese Herangehensweise ausschließlich als ein Bestreben nach optimierter Infrastruktur betrachtet, ohne vorher Anwendungsfälle und Ziele zu definieren. Die Annahme ist: “Wenn wir eine robuste Dateninfrastruktur aufbauen, werden sich später schon Anwendungsfälle dafür ergeben”.
In diesem Artikel möchten wir erklären, warum man Software unserer Meinung nach am besten in dünnen, vertikalen Scheiben entwickelt und sie unbedingt an Anwendungsfälle koppelt, die jeweils einen klaren Mehrwert für die NutzerInnen liefern. Auch datenintensive Projekte bilden keine Ausnahme. Es kann verlockend sein, eine Plattform mit nur einer horizontalen Ebene (manchmal als Data Lake bezeichnet) zu entwickeln – besonders für Anwendungsfälle mit umfangreichen Datenmengen in unterschiedlichen Formaten. Es stellt sich die Frage: Ist der Ansatz des "Product Thinking" vielleicht der bessere Weg für einige Data-Lake-Projekte?
Was sind überhaupt Data Lakes?
Wenn wir den Begriff Data Lake hören, beschreibt er normalerweise:- Einen zentralen Datenspeicher (operative, kundenbezogene oder verhaltensspezifische Daten) mit einer angemessenen Dokumentation und fein differenzierter Zugangskontrolle / Zugriffsberechtigungen.
- Etwas, das von Data Engineers gebaut und erhalten wird, sodass es von Data Scientists ausgewertet und zu konkreten Anwendungsfällen für Machine Learning weiterverarbeitet werden kann.
Eine ungenaue Definition führt meist zu einer ungeplanten Erweiterung des Projektumfangs, zu Budgetüberschreitungen und zu "technischer Überentwicklung". Je nach Zielsetzung kann es sein, dass ein Amazon S3 Bucket mit der richtigen Zugriffsberechtigung als Data Lake schon ausreicht, um unverarbeitete Daten zu speichern. Aus diesem Grund ist es wichtig, am Anfang des Projektes ein gemeinsames Verständnis vom Umfang und Nutzen des Data Lakes im Unternehmen zu etablieren.
Die meisten großen Unternehmen würden davon profitieren, wenn sie den Umfang der Data Lakes auf das Speichern von Rohdaten beschränken und funktionsübergreifende Produktteams bilden würden, um Machine Learning-Anwendungen mit ihren eigenen Darstellungen (Lake Shore Marts) zu entwickeln, die speziell auf ihren Anwendungsfall zugeschnitten sind. Ein Zitat aus Martins Blogbeitrag:
"Die meisten großen Organisationen würden von einer Beschränkung des Umfanges eines Data Lakes für Rohdaten profitieren und sollten stattdessen lieber interdisziplinäre Projektteams aufstellen, die Anwendungsfälle für Machine Learning aus spezifischen Daten entwickeln."
Ein einziges, einheitliches Datenmodell ist für alle unpraktisch, außer für kleine Organisationen. Um einen annähernd komplexen Sachverhalt darzustellen, benötigt man mehrere abgegrenzte Kontexte, jede mit einem eigenen Datenmodell. Wir werden später an einem Beispiel erklären, wie so ein Ansatz aussehen könnte.
Erstmal machen, der Rest ergibt sich von alleine
Data Lakes scheinen besonders anfällig für die "erstmal machen, der Rest ergibt sich von alleine"-Mentalität zu sein. Dies kann verschiedene Gründe haben:Oft gehören Data Scientists und Data Engineers zu verschiedenen Teams. Data Scientists sind näher an der Business-Perspektive, während Data Engineers sich mehr mit der Infrastruktur und IT befassen. Getrennte Teams erschweren den Informationsfluss zwischen relevanten Parteien durch Wissens-Silos und verstärken die Tendenz einen Data Lake lediglich als ein Infrastrukturproblem zu betrachten. Conways Gesetz trifft hier schon wieder zu.
Es ist nicht leicht, spezifische Anwendungsfälle und die Wertschöpfung eines Data Lakes zu ermitteln. Hierfür ist es notwendig, die Anwender einzubeziehen; die unterschiedlichen Parteien müssen sich auf ein gemeinsames Ziel einigen. Es ist verlockend, dieses komplexe Problem mit einem materiellen Problem zu ersetzen, das nur die technischen Aspekte betrachtet.
Eines der gängigsten Argumente von VertreternInnen der "erstmal machen, der Rest ergibt sich von alleine"-Mentalität ist, Data Lakes sollten für eine große Bandbreite an Use Cases verwendbar sein und nicht durch ein spezifisches Ziel begrenzt werden. Der Voraussetzung, dass ein Data Lake mehr als nur einen Anwendungsfall unterstützen soll, stimmen wir zu. Wir sind aber der Meinung, dass oft zuviel Up-Front-Architektur und Design geschehen, bevor überhaupt über Use Cases nachgedacht wird.
Fallstricke
Ohne die finalen Use Cases im Auge zu behalten, führt die Top-Down-Planung eines Data Lakes fast zwangsläufig zu einer mangelhaften ProblemlösungUnd ohne praktische Modelle aus den Daten zu entwickeln und sie in der realen Welt auszuprobieren, um aus Wiederholungen und Feedbacks zu lernen, ist es schwer, die beste Lösung für ein Problem zu finden.
Die Bereinigung und Formatierung der Daten für einen Use Case machen 70 bis 80 Prozent des Aufwandes der Entwicklung einer Anwendung für Machine Learning aus.
Deshalb ist es nicht sinnvoll, viel Arbeit in die Aufbereitung der Daten zu stecken, ohne sich über deren Annwendung im klaren zu sein. Die Personen, die an dem Modell arbeiten, werden wahrscheinlich noch einmal so viel Arbeit investieren müssen, sobald die Anwendungsfälle erst bestimmt sind.
Betrachten wir das an einem hypothetischen Beispiel:
Ein Versicherer plant die Erstellung eines Data Lakes. Hierbei soll die Art und Weise, wie Data Scientists oder Business Analysts Daten abrufen und analysieren, revolutioniert werden, um Ergebnisse für ihr Unternehmen zu erhalten. Die Firma ist über die Jahre durch Übernahmen und Zusammenschlüsse mit kleineren Versicherern gewachsen und hat deshalb keine einheitliches Kundensicht. Die Kundendaten sind auf etwa 20 Subsysteme aufgeteilt, die sich nach der Produktlinie richten (Krankenversicherung, Autoversicherung, Haustierversicherung, etc.)
Im Zusammenhang mit der Data Lake-Initiative möchte das Unternehmen nun ein einheitliches Bild seiner KundenInnen generieren. Es verbringt Monate damit, eine durchgängigen Definition seiner KundenInnen zu finden, die für alle zukünftigen Anwendungsfälle gültig ist. Das Ergebnis ist nur mittelmäßig zufriedenstellend. Wo liegen die Ursachen?
- Es gibt möglicherweise keine einheitliche Definition der Kundenschaft, die für alle zukünftigen Use Cases gleich gut passt.
- Die Kundendaten von 20 verschiedenen Systemen zu bündeln, ordnen und duplizieren ist keine einfache Aufgabe. Es erfordert einen hohen Koordinationsaufwand zwischen den verschiedenen Produktteams.
Einige Data Lake-Projekte sind noch ungenauer und komplexer als das eben genannte Beispiel. Sie verfolgen das Ziel, alle Geschäftsbereiche und Vorgänge in einer zentralen Datenstruktur zu bündeln.
Wenn die Nutzer des Data Lakes nicht früh genug sicherstellen, dass die gespeicherten Daten auch genutzt werden, besteht die Gefahr, dass aus dem Data Lake ein Datensumpf wird – also ein Abladeort für Daten jeglicher Qualität. Dies ist kostenintensiv und der Nutzen für das Unternehmen ist gering.
Product Thinking für Data Lakes
Wir empfehlen, den Data Lake mit einem Bottom-up-Ansatz anzugehen, indem ein vertikaler Schnitt nach dem anderen gebaut wird. Wie würde das am Beispiel des Versicherers aussehen?Fangen wir mit den folgenden Use Cases an:
- Identifikation betrügerischer Ansprüche, um diese für eine eingehendere, manuelle Untersuchung auswählen zu können. Das Geschäftsziel besteht darin, Betrugsfälle in diesem Jahr um fünf Prozent zu reduzieren.
- Vorhersage des Wetterverlaufs, sodass der Versicherer KundenInnen empfehlen kann, ihre Autos bei einer Surmwarnung unterzustellen. Auf diese Weise sollen Kfz Versicherungsfälle um zwei Prozent verringert werden.
- Zusatzverkäufe anderer Versicherungsprodukte an KundenInnen, auf Basis der aktuellen Produkte. Das Ziel: Onlinezusatzverkäufe um drei Prozent erhöhen.
Bevor es los geht
Es besteht eine komplexe Architektur, eine Governance-Struktur, die Dokumentationsstandards, Richtlinien für die notwendige Datenspezifikation, Rückwärtskompatibilität, Versionierung, etc. umfasst.Im Vorhinein werden bis dato schon einige Entscheidungen getroffen, z. B. ob man on-premise oder lieber in-cloud arbeiten möchte oder welchen Provider und welchen Datenspeicher man verwenden möchte. Diese Entscheidungen lassen sich später im Projekt nicht mehr so leicht ändern, deshalb müssen sie auf ein Minimum reduziert werden.
Ein Architekturteam stellt die sicher, dass die Architektur geeignet ist Governance-Strukturen beachtet werden, während sich die Plattform weiterentwickelt und Anwendungen entstehen.
Ein interdisziplinäres Delivery-Team, in dem Product Owner, Data Scientists und Data Engineers vertreten sind, bereitet den Software Prototyp für die Produktion vor.
Anwendungsfälle entwickeln
Das Projektteam beginnt mit der kleinsten Komponente und implementiert deshalb die Betrugsfälle als ersten vertikalen Schnitt. Mit dem Wissen, dass Krankenversicherung und Autoversicherung den Großteil der Ansprüche ausmachen, fokussiert sich das Team außerdem zuerst auf diese beiden vertikalen Ebenen. Für diese beiden Bereiche werden nun die unverarbeiteten Kundendaten und die Daten über Schadensersatzansprüche in den Data Lake gezogen. Anschließend werden sie bereinigt, akkumuliert und in einem Data Mart für die verschiedenen Use Cases aufbereitet. Als nächsten Schritt würde man ein Betrugsermittlungssystem aus den Daten entwickeln.
Nachdem sich eine erste Version des Modells in Produktion befindet, beobachtet das Team, durch welche zusätzlichen Bereiche das Modell ergänzt werden kann. Die Data Scientists arbeiten eng mit den Data Engineers zusammen und geben relevante Informationen umgehend weiter. Feedback kann so schnell verarbeitet werden kann. Zusammen suchen sie nach dem besten Weg, Daten aus den neu erschlossenen Bereichen zu sammeln und das Modell anzupassen. Das neue Modell ist nun deutlich besser als das erste.
Dieser Ansatz bringt den Vorteil mit sich, dass nur zwei von 20 Datenquellen genutzt werden (müssen). So wird viel Arbeit gespart und noch effektiver auf das Fünf-Prozent-Ziel hingearbeitet.
Wenn das Betrugsermittlungssystem läuft und bereits einen Mehrwert für das Unternehmen generiert, kann sich das Unternehmen darauf konzentrieren, die Kundendaten für das Zusatzverkaufsziel wirksam einzusetzen. Hierfür werden Produktdaten und Kundendaten über Gebäudeversicherungen zum Data Lake hinzugefügt. Sie bilden zusammen mit bestehenden Kundendaten eine neue Darstellung in ihrem eigenen abgegrenzten Kontext. So kann auf produktive und effektive Weise auf das Ziel “zwei Prozent Zusatzverkäufe” hingearbeitet werden.
Jetzt kann sich das Unternehmen dem Use Case "Benachrichtigungen" zuwenden. In diesem Fall handelt es sich um ein komplexes Modell, das alle bisher verwendeten Daten mit einschließt und zusätzlich noch eine weitere Quelle benötigt: Wetterdaten in Echtzeit.
Einige der unformatierten Kundendaten müssen für den Anwendungsfall neu aufbereitet werden. Doch welcher Vorteil liegt darin, die Daten im nachhinein aufzubereiten und nicht direkt zu Anfang? Das Team versteht mittlerweile die Anforderungen der ersten beiden Anwendungsfälle besser und kann deshalb mit dem entsprechenden Arbeitseinsatz den gewünschten Mehrwert schaffen, ohne viel Zeit mit Spekulationen zu verschwenden.
Nur damit keine Missverständnisse aufkommen: Der Prozess kann bis zu einem gewissen Grad auch parallel ablaufen. Uns geht es darum, zu vermitteln, dass nicht alle Arbeiten an anderen Use Cases warten müssen, bis ein Use Case abgeschlossen ist.
Fazit:
- Es gibt keinen einheitlichen "so funktioniert ein Data Lake"-Ansatz. Um möglichst schnell ans Ziel zu kommen, beschreibe das zu lösende Problem so präzise wie möglich.
- Arbeiten Sie mit gut formulierten Anwendungsfällen und messbaren Geschäftszielen. Testen Sie diese und erhalten Sie Feedback. Datenprojekte als Produkt und nicht nur als Infrastruktur zu betrachten, erspart viel Arbeit.
- Ermöglichen Sie Ihren Data Scientists so eng wie möglich mit den Data Engineers zusammenzuarbeiten. Die Chancen stehen gut, dass Sie schneller zu Ergebnissen kommen und besser zur Problemlösung passen. Eine geteilte Verantwortung hat außerdem den Vorteil, dass der Wartungsaufwand leichter zu koordinieren ist.
Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.