Im Juli 2019 veröffentlichte Gartner® einen Bericht zum Thema Datenmanagement und platzierte das Thema „Data Lakes“ in ihrem Hype-Cycle auf dem „Tiefpunkt der Ernüchterung“ (“Trough of Disillusionment”). Zudem sollten gemäss ihrer Analyse weitere 5 bis 10 Jahre vergehen, bevor Data Lakes das „Plateau der Produktivität“ erreichen würden. Es müssten also einige Experimente und erste Implementierungen fehlgeschlagen sein, zudem mehrere Technologieanbieter gescheitert sind und sich aus dem Markt zurückgezogen haben.
Nun – aus unserer Erfahrung trifft diese Einschätzung so pauschal nicht zu. Wir sehen einige erfolgreiche Installationen bei Kunden sowie viele qualitativ hochwertige Data-Lake-orientierte Dienste, insbesondere auf der Google Cloud Platform. Diese beiden Fakten sprechen eine andere Sprache. So erwarten wir – insbesondere für die Schweiz – eine Nutzung von Data Lakes bei 20 bis 30% aller Unternehmen bereits in 2-3 Jahren. Beschleunigt wird diese Entwicklung zusätzlich durch die Präsenz von Google Cloud in der Schweiz, sowie deren weltweit als wegweisend anerkannten Dienste für Analytics, Machine Learning und Künstliche Intelligenz.
Wenn auch ein Data Lake gemäss akademischer Definition auf einen „Speicherort für Daten, in ihrem natürlichen/unformatierten Format“ beschränkt ist, so sehen wir doch die Grenzen zwischen „Data Lakes“, „Data Warehouses“, „Data Marts“ mehr und mehr verschwimmen. Ebenso die Erwartungen an Data Lakes: Unsere Kunden zeigen eine breite Interpretation der Value Proposition eines Data Lakes – und damit auch breit gefächerte Erwartungen. Wohlwissend, dass einige der Themen in diesem Artikel die enge wissenschaftliche Definition überschreiten, nutzen wir der Einfachheit halber den Begriff „Data Lake“ zur Abdeckung all dieser Erwartungen. Lassen Sie sich also nicht durch diese breitere Interpretation stören…
Egal, wie der Begriff auslegt wird – viele Unternehmen sind blockiert in ihrem Bestreben, fassbaren Mehrwert aus ihren Daten zu generieren. Diese Blockaden bestehen in mehreren Bereichen – so beispielsweise in der Verteilung von Daten auf mehrere Systeme (ERP, CRM, etc.) und in der Vielzahl an Formaten in denen diese vorgehalten werden. Dies kommt daher, dass die Daten in der Regel für bestimmte Geschäftsprozesse erhoben, strukturiert und verwendet werden. Und immer dann, wenn man beginnt, diese Daten übergreifend und ergebnisoffener zu analysieren, kommen die – den Systemen geschuldeten – Beschränkungen in den Weg: eingeschränkte Datenbasis, fehlende Funktionen für “freie” und nicht zweckgebundene Analysen, technische Limitationen wie knappe Rechenleistung und knapper Speicher – sowie unzureichende personelle Kapazitäten an Fachkräften, die auf den Quellsystemen geschult sind. Wir vernehmen daher ein zunehmendes – und immer deutlicher geäussertes – Bedürfnis von Data Analysts unterschiedlicher Bereiche nach einfachem und breiten Zugang zu besser auswertbaren Daten.
Der Weg dahin ist jedoch mit einigen Hürden gepflastert. Fragen der Technologiewahl, zu Sicherheitsbestimmungen und Daten-Governance stehen ebenso an wie kulturelle Diskussionen zur Annäherung verschiedener Standpunkte, wie sie bei vielen IT-Projekten vorkommen, welche verschiedene Anforderungen an eine neue (?) Plattform koordinieren müssen.
Daher sind beim Aufsetzen des eigenen Data-Lake-Projekts einige wichtige Themen zu beachten, die wir im Folgenden anreissen wollen.
Jedes CIO-Lehrbuch verlangt, Business und IT für grössere Projekte mit einander abzustimmen. Es überrascht kaum, dass dies auch für Data Lake-Initiativen gilt. Interessant wird die Herausforderung in Data-Lake-Projekten durch das Auftauchen eines dritten Exponenten: des Data Scientists.
Der Data Scientist arbeitet an der Schnittstelle zwischen Business und klassischer IT. Dort sucht er stets die „neuesten“ Daten, den einfachsten Zugriff und unbegrenzte Systemkapazität, um Analysen durchzuführen. Dazu kommt das Bedürfnis, die Möglichkeit und Freiheit zu haben, Datenstrukturen schnell und flexibel neu modellieren zu können.
Diese Idee widerspricht wiederum der Motivation des IT-Betriebs. Produktivsysteme werden mit maximaler Auslastung betrieben (jahrelang auf höchste Kosteneffizienz in der Infrastruktur getrimmt). Zudem haben diese Systeme viele Abhängigkeiten zu wichtigen Geschäftsprozessen. Jede Änderung erfordert somit eine sorgfältige Planung und Ausrichtung. Achja – und bitte, bitte! – stellt sicher, dass jede benötigte Änderung sicher, getestet, bestätigt, sicher und vollständig audit-konform ist.
In den von uns begleiteten Projekten konnten wir erfolgreich diesen Dialog zwischen den Parteien aktiv moderieren. Durch ein gutes Klima des gegenseitigen Verständnisses der unterschiedlichen Sichtweisen wurden plötzlich Wege geöffnet, den Data Lake so voranzutreiben, dass dieser nicht nur sicher und auditfähig umgesetzt, sondern auch wertstiftend, schlagkräftig und produktiv eingesetzt werden konnte.
Wo dieses gegenseitige Verständnis nicht erreicht wurde, bestand immer die Gefahr eines “Frozen Lake“: zu rigide aufgebaut, zu schwierig zu navigieren, zu vorsichtig und beschränkt nutzbar – und damit letztlich nahezu unbrauchbar.
Ein Data Lake umfasst verschiedene Bereiche, die im Laufe seines Lebenszyklus zu adressieren sind:
Ein gutes Data-Lake-Projekt sollte nicht versuchen, den “Ozean zu kochen”, sprich die komplette Komplexität auf einmal anzugehen. Es ist vielmehr ratsam, mit kleinen Schritten zu starten, die Lösung schrittweise zu erweitern – dann im Gleichschritt mit dem zunehmenden Wissen und der fortschreitenden Erfahrung der Organisation. Ein guter – wenn nicht sogar der beste – Ausgangspunkt und erste Phase ihres Projektes ist somit die Wahl eines MVP-Ansatzes (Minimum Viable Product).
Wählen Sie dafür einen ersten nützlichen, aber nicht zu komplexen Anwendungsfall aus. Starten Sie durchaus mit einer manuellen Übertragung der Quelldaten, richten Sie dafür eine erste Architektur ein mit lediglich „ausreichender Sicherheit“ – und testen Sie dann das Toolset. So können Sie schnell überprüfen, ob die Lösung so die erwarteten Ergebnisse liefert. Bestenfalls werden in dieser Phase bereits Konzepte für die finale Lösung skizziert und vorbereitet; es rät sich aber, die Umsetzung all dieser Ideen iterativ so zu planen, dass sie den ersten Test der Anwendung nicht blockieren.
Nach dem erfolgreichen “Proof of Value” – einem positiven Testergebnis ihres MVPs – werden Sie weitere Schritte in Angriff nehmen. So wird Automatisierung im Daten-Zufluss zunehmen, die Daten-Zugriffsverwaltung wird verfeinert – und dadurch können Sie Ihren Data Lake einer immer breiteren Community und immer weiteren Anwendungsfällen zur Verfügung stellen. Idealerweise erweitern sie die weiteren Phasen die von Ihnen erstellte MVP-Grundlage schrittweise – wobei sie zwischen Ihren Phasen jeweils Ihren eigenen Wissenszuwachs nutzen sollten, um einmal erstellte Konzepte mit Ihrem aktuellen Erfahrungsschatz abzugleichen und nötigenfalls zu adaptieren.
Fangen Sie also klein an, aber klar wertorientiert, und bauen sie schrittweise aus.
Hier sind die wichtigsten Erkenntnisse zusammengefasst:
… und – nicht zuletzt – holen Sie sich die Hilfe eines Profis, der das schon mehrfach gemacht hat.
Wie zum Beispiel uns.