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.

Business & IT-Ausrichtung

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.

Strukturen eines Data Lake

Ein Data Lake umfasst verschiedene Bereiche, die im Laufe seines Lebenszyklus zu adressieren sind:

• Data Ingestion – Daten-Zufluss
  Eine erste wichtige und offensichtliche Aufgabe ist es, das Hochladen von Daten aus Quellsystemen und die Speicherung im Data Lake sauber zu definieren. Dabei müssen Datenklassifizierung, technische Anbindungen und Performance-Einflüsse ebenso berücksichtigt werden wie mögliche Lizenz-Auswirkungen auf die Quellsysteme: viele Systeme sind viel mehr auf das Aufnehmen von Daten als auf deren Herausgabe getrimmt. Auch die zeitliche Planung von Datentransfers und deren Automatisierung und Orchestrierung sind teilweise komplexe Aufgaben. Nicht selten beherrschen diese Themen bereits zu Beginn eines Data-Lake-Projektes die Diskussion – lässt man sich von der technischen Komplexität abschrecken, so werden unter Umständen Business Cases bereits verworfen, bevor sie überhaupt die Chance hatten, ihren Wert zu beweisen. HIer ist es wichtig, pragmatische Ansätze zu finden – mehr dazu weiter unten.

• Sichere Cloud-Einrichtung
  Die Google Cloud Plattform bietet eine Vielfalt an Diensten – Managed Services, Serverless, usw. – um viele Anwendungsfälle für und rund um einen Data Lake einfach und reibungslos zu implementieren. Es ist jedoch wichtig, dass die Cloud bereits zu Beginn richtig und im Einklang mit Unternehmensrichtlinien eingerichtet wird, damit sie kompatibel, sicher und verwaltbar ist – und damit auch intern akzeptiert ist. Sollte es sich bei Ihrem Data Lake-Projekt also um Ihr erstes Cloud-Projekt handeln, so tun Sie gut daran, dafür zusätzlich Zeit zum eigentlichen Data-Lake-Setup einzuplanen.
  Die gute Nachricht ist, dass Googles Sicherheitsprinzipien ebenso wie die einzelnen Services alle Möglichkeiten bieten, auch für Ihr Unternehmen die passende Balance zwischen Komplexität und ihren Anforderungen zu Sicherheit und Auditfähigkeit zu finden – egal ob Finma-reguliert oder mit nur geringen Anforderungen an Audits.

• Transformation
  Auch wenn das „Transformieren“ der Daten strenggenommen nicht mehr im akademischen Perimeter eines Data Lake liegt: Daten sind immer nur dann nützlich, wenn sie möglichst einfach weiterverwendet werden können. In robusten Strukturen angelegt und mit Strategien für allfällige Schemaänderungen ausgerüstet sowie einer einheitlichen Metadatenverwaltung legen Sie den Grundstein für einen einfachen und zielgerichtet nutzbaren Data Lake, an dem ihre Data Analyst-Community Freude haben wird.

• So generieren Sie Mehrwert…
  Es gibt unzählige Möglichkeiten, Daten gewinnbringend einzusetzen: Tabellen verbinden, Trends und Ereignisse analysieren, mit Deep Learning Vorhersage-Modelle generieren und eine Spielwiese für ungebundenes, innovatives Experimentieren mit den Daten bereitstellen – all dies steht möglicherweise auf Ihrer Wunschliste. Stellen Sie jedoch sicher, dass die Nutzung mit einer klaren Zugriffsrichtlinie geregelt ist (z.B. nach dem „least privilege“ Prinzip für sensitive Daten) und dann technisch so konfiguriert ist, dass diese Richtlinien auch unterstützt werden.

• Kontinuierliche Modellentwicklung
  Sobald Data Scientists Daten zur Wertschöpfung verwenden, überschreiten sie oft erstmalig eine Grenze: sie werden von einem häufig eher unbeachteten Bereich zum Teil der produktiven IT. Und dort regieren viele „traditionell” ausgestaltete Prozesse. Es ist daher sinnvoll, für Modell- und Daten-Artefakte eine CI/CD-Pipeline (Continuous Integration/Continuous Delivery) zu erstellen, um eine einfache – und mit den bestehenden produktiven Prozessen kompatible – Verwendung in den Produktionssystemen zu ermöglichen.

• Daten-Rückfluss: den Kreis schliessen
  Wenn auch auf den ersten Blick eine vielleicht einfachere Aufgabe, so hält dieser Teil eines Data Lake trotzdem immer wieder Überraschungen bereit. Die Daten-Rückübertragung sollte Konsistenzprüfungen und potenziellen Compliance-Anforderungen für produktive Systeme standhalten, und die zusätzliche Datenverarbeitung kann die Komplexität auf den Kernsystemen steigern. Also auch hier: Vorausplanung hilft…

So weit so gut – aber wie setzen wir das nun um?

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.

Data Lake – auf den Punkt gebracht

Hier sind die wichtigsten Erkenntnisse zusammengefasst:

• Ihnen ist also klar, dass ein Data Lake ein wesentlicher Wegbereiter für eine agile, moderne Wertschöpfung aus Daten ist. Dann möchten wir Sie dringend bitten nicht zu warten, bis Sie alle möglichen Fragestellungen gesammelt, analysiert und gelöst haben – womöglich kommt es nie dazu. Legen Sie lieber frühzeitig ihr Fundament!
• Starten Sie früh und ignorieren kleinere Lücken, um ihren internen Lernprozess so schnell wie möglich anzukurbeln. Iterativ werden Sie immer schneller und besser sein.
• Beschleunigen Sie ihr Projekt und reduzieren Sie Diskussionen zur Basistechnologie: Nutzen Sie wo immer möglich spezialisierte Cloud Services der Cloud Provider, insbesondere jene der Google Cloud Platform. Es ist heute nicht mehr erforderlich, on-premise zu arbeiten.
• Überprüfen Sie Ihre Governance-Prozesse – und passen Sie diese an die neu geschaffene Datenfreiheit an – im besten Fall erweitern Sie sie sinnvoll.
• Adressieren und integrieren Sie die verschiedenen Kulturen in Ihrem Unternehmen – die flinken Ideen der Data Scientists und die hochstrukturierten Prozesse der Data System Operations müssen zusammenwachsen.
• Planen Sie Ihre Lösung so, dass sie schrittweise wächst. Beginnen Sie jedoch klein und mit einer Mehrwertorientierung.
• Wählen Sie einen MVP-Ansatz, der schon in frühen Phasen alle Beteiligten involviert und ihnen einen Mehrwert schafft.

… und – nicht zuletzt – holen Sie sich die Hilfe eines Profis, der das schon mehrfach gemacht hat.

Wie zum Beispiel uns.