Kommentar von Kiran Prakash und Lucy Chambers, ThoughtWorks Vor dem Data Lake stehen die Use Cases

Künstliche Intelligenz (KI) und Machine Learning sind derzeit in aller Munde. Zahlreiche Unternehmen wollen auf diesen Zug aufspringen und von ihren Datenreserven profitieren.Tatsächlich bietet diese Technologie ein enormes Potenzial – aber nur ein sinnvoller Einsatz bringt echten Mehrwert.

Anbieter zum Thema

Confluent Germany GmbH

Fivetran Germany GmbH

Xpand Solutions GmbH

Thoughtworks Deutschland GmbH

Unternehmen wollen häufig ihre KI-Initiativen durch den Aufbau eines Data Lakes schnell vorantreiben. Oft wird diese Vorgehensweise ausschließlich als ein Infrastruktur-Projekt 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.“

Software sollte jedoch am besten in vertikalen Schichten entwickelt und unbedingt an Anwendungsfälle gekoppelt werden, die jeweils einen klaren Mehrwert für den Nutzer liefern. Das gilt auch für datenintensive Projekte. 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“ der bessere Weg für Data-Lake-Projekte?

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. So könnten sie Machine-Learning-Anwendungen mit ihren eigenen Darstellungen (Lake Shore Marts) entwickeln, die speziell auf ihren Anwendungsfall zugeschnitten sind.

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. Das kann verschiedene Gründe haben:

Oft gehören Data Scientists und Data Engineers zu getrennten 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 und verstärken die Tendenz, einen Data Lake lediglich als ein Infrastrukturproblem zu betrachten.

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.

Oft wird argumentiert, Data Lakes sollten für eine große Bandbreite an Use Cases verwendbar sein. Sicherlich sollte ein Data Lake mehr als nur einen Anwendungsfall unterstützen. Aber es sollte nicht zu viel in Up-front-Architektur und Design investiert werden, bevor Use Cases identifiziert werden.

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ösung. Und ohne praktische Modelle aus den Daten zu entwickeln und sie in der realen Welt auszuprobieren, um aus dem Feedback 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 Entwicklungsaufwands 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 Anwendung 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 bestimmt sind.

Hier ein hypothetisches Beispiel: Ein Versicherer plant einen Data Lake. Das Ziel ist, Data Scientists neue Möglichkeiten zu bieten, Daten abzurufen und zu analysieren, um das Geschäft voranzutreiben. Die Firma ist über die Jahre durch Übernahmen gewachsen und hat deshalb keine einheitliche Kundensicht. Die Kundendaten sind auf etwa 20 Subsysteme verteilt, je nach Produktlinie (Krankenversicherung, Autoversicherung etc.).

Im Zusammenhang mit der Data-Lake-Initiative möchte das Unternehmen nun eine einheitliche Sicht auf die Kundendaten schaffen. Monate lang wird nach einer durchgängigen Definition der Kunden gesucht, die für alle zukünftigen Anwendungsfälle gültig ist. Das Ergebnis ist nur mittelmäßig zufriedenstellend. Wo liegen die Ursachen?

• 1. Es gibt möglicherweise keine einheitliche Definition des Kunden, die für alle zukünftigen Use Cases gleich gut passt.

• 2. Die Kundendaten aus 20 verschiedenen Systemen zu bündeln, abzugleichen und zu deduplizieren erfordert einen hohen Koordinationsaufwand zwischen den verschiedenen Produktteams.

Ohne zu wissen, wie die zusammengeführten Kundendaten eingesetzt werden, kann dies zu einer Mammutaufgabe werden. Das Unternehmen ist nicht in der Lage zu priorisieren und gut informierte Entscheidungen zu treffen, wenn Trade-offs involviert sind.

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 (Data Swamp) wird – also ein Abladeort für Daten jeglicher Qualität. Dies ist kostenintensiv und hat wenig Nutzen für das Unternehmen.

Product Thinking für Data Lakes

Wir empfehlen, den Data Lake mit einem Bottom-up-Ansatz anzugehen, indem eine vertikale Schicht nach der 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 auszuwählen. Das Ziel ist, Betrugsfälle im laufenden Jahr um fünf Prozent zu reduzieren.

• Vorhersage des Wetterverlaufs, sodass der Versicherer Kunden empfehlen kann, ihre Autos bei einer Sturmwarnung unterzustellen. Auf diese Weise sollen Kfz-Versicherungsfälle um zwei Prozent verringert werden.

• Zusatzverkäufe anderer Versicherungsprodukte an Kunden, auf Basis der aktuellen Produkte. Das Ziel: Onlinezusatzverkäufe um drei Prozent erhöhen.

Ausgangssituation

Es besteht eine komplexe IT-Architektur und eine Governance-Struktur, die Dokumentationsstandards, Richtlinien für die notwendige Datenspezifikation, Rückwärtskompatibilität, Versionierung etc. umfasst.

Vorab werden schon einige Entscheidungen getroffen, z. B. ob man on-premises oder lieber in-cloud arbeiten möchte oder welcher Provider und welcher Datenspeicher gewählt wird. 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 sicher, dass die Architektur geeignet ist und die Governance-Strukturen beachtet werden, während sich die Plattform weiterentwickelt und Anwendungen entwickelt werden. Ein interdisziplinäres Delivery-Team, in dem Product Owner, Data Scientists und Data Engineers vertreten sind, stellt die Anwendungsfälle produktiv.

Anwendungsfälle entwickeln

Das Projektteam beginnt mit der kleinsten Komponente und implementiert deshalb den Anwendungsfall zur Betrugserkennung als erste vertikale Schicht. 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 eine erste Version des Modells zur Betrugserkennung produktiv ist, identifiziert das Team zusätzliche Datenfelder zur Ergänzung. Die Data Scientists arbeiten eng mit den Data Engineers zusammen und geben relevante Informationen umgehend weiter. Auf Feedback lässt sich so schnell reagieren. Gemeinsam suchen sie nach dem besten Weg, Daten aus den neu erschlossenen Feldern zu sammeln und das Modell anzupassen. Das neue Modell ist nun deutlich besser als das erste. Dieser Ansatz hat den Vorteil, 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 begrenzten 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 Rohdaten nutzt und zusätzlich noch eine weitere Quelle benötigt: Wetterdaten in Echtzeit.

Einige der Kundenrohdaten 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.

Natürlich müssen nicht alle Arbeiten an anderen Use Cases warten, bis ein Use Case abgeschlossen ist. Doch die Anwendungsfälle sollten klar definiert sein.

Fazit

• Es gibt keinen einheitlichen „So-funktioniert-ein-Data-Lake"-Ansatz. Um möglichst schnell ans Ziel zu kommen, sollte das zu lösende Problem so präzise wie möglich beschrieben werden.

• Arbeiten Sie mit klar definierten Anwendungsfällen und messbaren Geschäftszielen. Testen Sie diese und berücksichtigen Sie Feedback. Datenprojekte als Produkte und nicht nur als Infrastruktur zu betrachten, erspart viel Arbeit.

• Data Scientists und Data Engineers sollten eng zusammenarbeiten. Das bringt schnellere und bessere Ergebnisse. Die gemeinsame Verantwortung hat außerdem den Vorteil, dass der Wartungsaufwand leichter zu koordinieren ist.

Ergänzendes zum Thema

Die Autoren

Kiran Prakash

Kiran Prakash ist Principal Engineer bei ThoughtWorks

Lucy Chambers

Lucy Chambers ist Product Consultant bei ThoughtWorks

(ID:45947424)