Inside Data Lake (Teil 7)

Spielerischer Umgang mit Daten bei Use Cases im Grenzbereich

Um die Innovationskraft und das Entwicklungstempo eines Data Lake zu fördern, wird auch Raum für Use Cases benötigt, die einer hohen Flexibilität und Umsetzungsgeschwindigkeit bedürfen. So wie in unserem Anglerparadies ein Bereich zum Üben und Ausprobieren existiert, muss auch im Data Lake eine Art „Spielwiese“ geschaffen werden, in der einerseits neue Techniken ohne große Einschränkungen und Gefahren ausprobiert und verfeinert sowie andererseits kurzfristig benötigte Datenanforderungen umgesetzt werden können. Dies möchten wir im Folgenden näher betrachten.

Data Management - manchmal darf es die Überholspur sein

Der Data Lake stellt aufgrund seiner umfangreichen Zusammenstellung unterschiedlicher Datenbereiche eine Basis für die Belieferung vieler fachlicher Methoden und Berichte dar. Eine wesentliche Herausforderung bei der (Weiter-) Entwicklung solcher fachlichen Anwendungskomponenten, insbesondere im Umfeld steuerungsrelevanter Daten, sind häufig die stringenten Prozesse bei der Softwareentwicklung. Die release-orientierte Implementierung der zugrundeliegenden Datenbestände (Data Marts, Cubes etc.) sowie der zugehörigen Bewirtschaftungsprozesse (Schnittstellen, Mapping, Transformationen etc.) innerhalb und außerhalb des Data Lake – egal ob klassisch oder agil – birgt häufig die Gefahr einer zu geringen Umsetzungsgeschwindigkeit. Dies gilt insbesondere vor dem Hintergrund bisweilen volatiler fachlicher Anforderungen sowie zeitlicher Einschränkungen durch die Einbeziehung der IT.

So wie im See einerseits Angler unter Beachtung der „Seeordnung“ ihrem Hobby nachgehen und andererseits Kinder im seichten Wasser auch mal „ungeregelt“ mit einem Kescher den Fischen nachjagen dürfen, sind auch für die Nutzer eines Data Lake Lösungsansätze erforderlich, die als Ergänzung zu der bereits etablierten Fach- und IT-Architektur

  • das breite Nutzenpotential eines Data Lake ausschöpfen,
  • Ineffizienzen bei der Identifizierung von verfügbaren Informationen reduzieren und
  • eine Art „Überholspur“ bereitstellen, um benötigte Daten kurzfristig und flexibel den regulären Fachfunktionen zuführen zu können.
     

Überholspur mit besonderen Verkehrsregeln

Im Zielbild muss daher den Datennutzern ein analytischer Zugang zur gesamten Datenvielfalt des Data Lake ermöglicht werden. Kern einer solchen Lösung ist die Bereitstellung einer funktionsstarken Analyse- und Auswertungsumgebung für den Fachbereich um

  • umfangreiche Datenanalysen innerhalb der verfügbaren Datenbereiche sowie datenbereich-übergreifend durchzuführen,
  • Standardreports - inklusive deren Bewirtschaftung - im Sandbox-Charakter prototypisch zu entwickeln und
  • den Einsatz von Künstlicher Intelligenz (KI) und Mustererkennung zu ermöglichen

Ziel ist die produktive Verwendung dieser – teilweise prototypischen – Ergebnisse als vorläufige und zeitlich begrenzt nutzbare Zwischenlösung. Eine „saubere“ Umsetzung im Data Lake, das heißt eine Überführung solcher Vorstufen der Entwicklung in die regulären Data Lake-Standards, erfolgt danach in einem festgelegten Zeitraum.

Dieses Vorgehensmodell birgt aber auch Risiken, da hier Funktionen und Daten, die nicht über den regulären Softwareentwicklungsprozess erstellt werden, in produktive Berichtsstrecken einfließen. Das kann zu Unsicherheiten bezüglich der Definition, der Qualität und der Herkunft dieser Daten führen. Außerdem darf es nicht zu einer unüberwachten Nutzung von vertraulichen Informationen (externer und interner Datenschutz) kommen.

Diese Risiken gilt es zu mitigieren, ohne die Vorteile der Lösung wirkungslos zu machen. Dafür ist die Schaffung folgender Rahmenbedingungen zu empfehlen:

  • Für den Funktionsbereich dieses Auswertungstools ist eine besondere Governance einzurichten und die Vergabe der Zugriffsrechte restriktiv zu handhaben. Das heißt der Umfang zulässiger Use Cases ist klar und deutlich einzugrenzen. Über die Freigabe der Nutzung sollte, da es sich nicht um einen Regelprozess handelt, im Einzelfall entschieden werden. Zusätzlich empfiehlt sich ein Monitoring der Verwendung des Tools.
  • Darüber hinaus sind die prototypisch umgesetzten Funktionen beziehungsweise ad hoc-Abfragen ausreichend zu dokumentieren und der Fachbereich sollte in der Lage sein, eine Mindest-Qualitätssicherung durchzuführen.

Im Ergebnis liegen die benötigten Daten dem Fachbereich signifikant schneller in nutzbarer Form vor. Gleichzeitig existiert eine vollständige Transparenz der verwendeten Reporting-Funktionalitäten, da die Entwicklung gänzlich im Fachbereich liegt.

09.12.2021