Big Data Governance

Wie in meinem vorherigen Post angekündigt, hier ein paar mehr Details und Anregungen zum Thema Data Governance mit Big Data.

Zuerst einmal muss man festhalten, dass der Begriff Data Governance ja fast genauso neu ist wie Big Data. Die englische Wikipedia spricht hier von einer “aufstrebenden Disziplin mit einer sich entwickelnden Definition” (emerging discipline with an evolving definition). Das bedeutet letztendlich das unter diesem Begriff praktisch jeder etwas anderes versteht.
Unabhängig von Big Data sind die wesentlichen Aufgaben einer Data Governance so wie sie der Autor definieren würde:

• Klassisches Datenmanagement (Daten von A nach B schaufeln, sinnvoll verbinden und verfügbar machen)
• Datenqualität (Sicherstellen und überwachen)
• Sicherheit (wer hat wann und wie Zugriff auf Daten)
• Nachvollziehbarkeit (wer hat wann Daten geändert / abgerufen)

Natürlich geht es bei diesen Themen nicht nur um Technologie und Tools, sondern auch um Strategie und die Prozesse. Das ist eigentlich nichts Neues und auch praktisch in jeder Organisation in irgend einer Art schon vorhanden. Allerdings ändert sich der Stellenwert dieser Aktivitäten dramatisch mit steigendem Analytischen Reifegrad und wachsenden Datenmengen bzw. deren Volatilität.

In Sachen Nachvollziehbarkeit kommen Themen wie “Solvency II” und “Basel III” ins Spiel. Hier muss zu jeder Zeit nachgewiesen werden das die einer Berechnung zu Grunde liegenden Daten auch valide sind. Das ist nicht ganz einfach wenn diese Datensätze auf den Desktops der Aktuare oder Quants liegen und deren Herkunft und Modifikationen gänzlich undokumentiert bleiben. Der Druck in diesem Bereich steigt also und wir werden in Zukunft sicher öfter Job-Bezeichnungen wie Data Scientist oder Data Steward (Dateneigner) zu Gesicht bekommen.

Beim Datenmanagement kommen ebenfalls neue Herausforderungen auf uns zu. Nicht nur die Masse der Daten, auch deren Volatilität steigt permanent und erfordert neue Technologien um deren Herr zu werden. Hadoop ist ja nun schon eine Weile der Renner in den IT-Abteilungen vieler grosser Unternehmen. Aber Hadoop alleine ist noch nicht der Weisheit letzter Schluss!

Denn das blosse Speichern der Datenberge bringt keinen expliziten Mehrwert. Und obendrein reden wir dann oftmals noch über unstrukturierte oder semi-strukturierte Daten… das macht die Governance dieser Informations-Flut nicht gerade einfacher.

Diese Tatsache hängt auch eng mit dem Thema Datenqualität zusammen. Die Qualität der Analysen und damit auch der Entscheidungen kann nur so gut sein wie die Qualität der verwendeten Daten. Speziell unstrukturierte Daten bedürfen intensiver Vorbereitung (Stichwort Text-Analytics) und auch die Maschinendaten (Internet der Dinge usw.…) müssen permanent auf Datenqualität und Sinnhaftigkeit geprüft werden.

Hier ist es empfehlenswert Fachanwender und IT auf einen Nenner zu bringen, was die Definition von Daten und deren Qualität angeht. Oftmals gehen die Auffassungen hier weit auseinander, was zu Frustration auf beiden Seiten führt.

Erst eine klare Definition (Glossar) schafft die Grundlage für die Datenqualitätsprozesse, die letztendlich für richtige Entscheidung auf Basis korrekter Analysen sorgen. Auch kann man mit Hilfe dieser Grundlage proaktiv für Datenqualität sorgen. Zum Beispiel kann ich einen Kunden oder ein Produkt schon bei der Eingabe auf dessen Konformität zu der jeweiligen Definition prüfen und gegebenenfalls sofort einschreiten statt später aufwendig zu korrigieren.

Beim Thema Datensicherheit werden die verteilten Daten zum Problem. Die Zeiten sind vorbei, da alle für das Geschäft relevanten Daten in einer grossen Datenbank abgelegt waren und die Sicherheitsmechanismen eines ausgereiften RDBMS für ausreichende Zugangskontrolle sorgten.

Heute haben speziell die grösseren Unternehmen einen ganzen Stack an Datentöpfen auf Basis unterschiedlichster Technologien im Einsatz. Da werden operationelle Daten in Teradata, Greenplum oder SAP HANA abgelegt, Datamarts in Aster, Exadata, PostgreSQL oder MySQL und als Data Lake kommt dann meist noch Hadoop in einer der zahlreichen Ausprägungen hinzu.

Die Folge davon sind komplexe und voneinander getrennte Sicherheitsdomänen die nur mit sehr viel Aufwand unter einen Hut gebracht werden können. In der Praxis häufen sich dann Fälle in denen Daten aus Performancegründen in eine unsichere aber zugänglich und schnelle Umgebung kopiert werden – eine Einladung zum Datenklau!

Die Lösung dieser Problematik ist allerdings selten die Konsolidierung der Datenbanken, da diese meist völlig unterschiedliche Anwendungsfälle abdecken und entsprechend dieser optimiert sind. Vielmehr müssen sich die Prozesse und Sicherheitsmechanismen der neuen Umgebung anpassen. Virtuelle Schichten (Data Federation bzw. Data Virtualization ) mit durchdachtem Security Konzept könnten z.B. eine Lösung sein.

Generell sollte das Data-Movement (verschieben von grossen Datenmengen zwischen den Systemen) so weit wie möglich reduziert werden. Technologien wie In-Database sorgen dafür das die Datenbank einen großen Teil der Arbeit erledigen kann – das schont das Netzwerk, die lokale Disk und spart oftmals erheblich Zeit.

Als Abschluss sollte nicht unerwähnt bleiben, das all diese Aktivitäten nicht einmalig sondern kontinuierlich erfolgen müssen. Data Governance ist ein Prozess, kein Projekt.

Bei Fragen oder Anregungen freue ich mich auf Kommentare zu diesem spannenden und im Zusammenhang mit Big Data so überaus wichtigen Thema.