Framework

Data Governance Framework

Vereinfacht beschrieben ist der Zweck von Data Governance die Verwaltung und Organisation des Daten-Lebenszyklus.
Die damit verbundenen Handlungsfelder lassen sich in einem Data Governance Framework zusammenfassen:

DataGovernanceFramework_Dach_weiß

Rollen

Es werden Rollen definiert und mit Personen besetzt, um die dazugehörigen Aufgaben für die Data Governance zu erledigen.

mehr →

Prozesse

Data Governance steuert die mit den Daten verbundenen Prozesse und stellt die Basis für die Arbeit der entsprechenden Rollen dar. 

mehr →

Regeln

Daten sind einer Reihe von internen und externen Regelwerke unterworfen, zB. der DSGVO oder spezifische Security-Richtlinien.

mehr ab 19.12.

Technologien und Tools

Die Umsetzung von Rollen, Prozessen und Regelwerken werden durch den Einsatz von Technologien und Tools unterstützt.

mehr →

Data Governance Workshop gewinnen!

Für einen einfachen und erfolgreichen Start in das Thema Data Governance unterstützen wir Sie mit einem Data Governance Workshop.

Im Rahmen dieses Workshops starten wir die Erhebung Ihrer derzeitigen Situation und entwickeln einen groben Fahrplan für Ihre nächsten Schritte.

Jetzt mitspielen und gewinnen!
Nikolaus

Rollen

Im Rahmen von Data Governance werden zahlreiche Rollen definiert. Dabei sind die Data Stewards und Data Governance Manager die wesentlichsten.
Je nach Umfang der Data Governance Initiative ist es sinnvoll, noch weitere Rollen ins Team mit aufzunehmen und die Rollenlandschaft weiter zu skalieren.

Rollenpyramide von Robert Seiner

DataGovernance_Pyramide

Die Rollenpyramide von Robert Seiner zeigt eine sehr ausgeprägte Struktur der Rollen, wie sie in großen Organisationen durchaus angebracht ist. Die Rollen werden dabei dem operativen, taktischen oder strategischen Level zugeordnet. Derart umfangreiche Organisationsstrukturen bedürfen wiederum eigener interner Steuermechanismen mit einem Data Governance Programm Team zur administrativen Unterstützung.

wichtige Rollen

Es werden Rollen definiert und mit Personen besetzt.

Im Rahmen von Data Governance werden einige Rollen definiert. Die beiden wichtigsten Rollen in Data Governance Initiativen sind der Data Governance Manager und die Data Stewards.

Die weiteren Rollen werden je nach Umfang der Data Governance Initiative erforderlich.

Die Herangehensweise bei Kundenprojekten orientiert sich in vielen Fällen nur bedingt an der vorgeschlagenen Rollenpyramide von Seiner. Jegliche Erweiterung der Aufbauorganisation muss mit großem Bedacht auf die bestehenden Strukturen erfolgen. In vielen Unternehmen sind folgende Rollen besetzt, die sinnvollerweise in Data Governance Initiativen eingebunden werden sollten:

BI Verantwortliche und Analysten

BI Analysten sind vor allem auf operativer oder taktischer Ebene eingebunden. Ihre Aufgaben sind die Spezifizierung und Umsetzung von Reportanforderungen für die jeweils verantwortlichen Themenbereiche.

Sie sind Ansprechpartner für die Anwender
und Key User bei Fragen zu Berichten
(sowohl inhaltlich als auch technisch)  und fungieren sie als Schnittstelle zwischen Anwender / Key User und IT Entwickler im Reporting Umfeld .

Prozess- und Anwendungsverantwortliche

In der Data Governance Initiative müssen diese sicherstellen, dass die festgelegten Prozesse den Vorgaben entsprechend ausgeführt, gesteuert und optimiert werden.

Zu ihren Aufgaben zählt die Abstimmung von Anforderungen im IT-Anforderungsprozess.

Außerdem  steuern sie wertvolles Wissen über die Struktur der Vorsystemdaten bei und sind verantwortlich für die Weiterentwicklung  des Vorsystems (Change Prozesse).

Vertreter der Fachbereiche

Das Wissen über die Struktur der Daten liegt oftmals weniger im Fachbereich selbst, sondern eher bei den BI Analysten. Der Beitrag des Fachbereichs zum Datenqualitätsmanagement ist meist durch die Ressourcenverfügbarkeit limitiert.

Externe Dienstleister

Externe Dienstleister unterstützen bei der Anwendungsentwicklung und verfügen über Wissen zu Implementierungsdetails. Auch bei der Datenbereitstellung können diese unterstützen und liefern Support bei Änderungen der Daten.

Die hier exemplarisch genannten Rollen wirken bei unseren Kundenprojekten an Data Governance Initiativen mit. Zu beachten ist, dass die Aufgaben auf Entscheidungsebene (Data Governance Manager oder Council), auf Verwaltungsebene (Data Steward Coordinator, Programm Team) und auf operativer Ebene (vor allem Data Stewards, Datenqualitätsmanager) abgedeckt werden bzw. von der Ressourcenkapazität abgedeckt werden können.

Ein Ziel unserer Workshops ist es, die Rollenverteilung gemeinsam mit unseren Kunden herauszuarbeiten und so etwaige Engpässe (bei Kapazitäten oder nicht abgedeckten Aufgaben) aufzeigen zu können. Engpässe können oft entweder durch Schärfung der Rollen oder aber auch durch effizienten Werkzeugeinsatz kompensiert werden.

 

Skalierung von Data Governance Initiativen und Data Domains

Die Datenlandschaft in Unternehmen ist in der Regel sehr umfangreich. Unzählige Tabellen aus ERP Systemen, CRM Systemen, der Finanzbuchhaltung, Produktion etc. werden in täglichen operativen Prozessen verwendet. Nicht nur das Volumen dieser Daten erreicht hohe Ausmaße, sondern auch deren Komplexität, vor allem durch den steigenden Bedarf an Anpassungen der jeweiligen Basis Lösungen.

Selbst wenn man sich nur auf jene Daten beschränkt, die essentiell für das Berichtswesen und Analysen sind, haben wir es mit einer schwer handhabbaren Menge an Tabellen, Dateien und Services zu tun, die im Rahmen der Data Governance gesteuert werden sollen. Ab einer gewissen Unternehmensgröße und der damit einhergehenden Systemkomplexität ist es für einzelne Wissensträger nur noch bedingt zumutbar, hier den kompletten Überblick zu bewahren und die Verantwortung für die Governance über all diese Systeme und den damit produzierten Daten zu übernehmen.

Als Ordnungsbegriff haben sich an dieser Stelle sogenannte Data Domains etabliert.

Wir versammeln unter einer Data Domain jene Daten, die entweder einem gemeinsamen Zweck dienen oder einer homogenen Quelle entspringen.

Die Bildung von Data Domains erfolgt meist auf Basis der eingebundenen Vorsysteme. Beispielsweise Buchhaltungsdaten als eine Domäne und Produktionsdaten als eine weitere. Ausgehend von meist bereits etablierten Rollen im Unternehmen, wie zum Beispiel Application Owner für die jeweiligen Kernsysteme, können aus dieser Organisation auch die Rollen im Data Governance beschickt werden. Hier ist das Wissen (notwendigerweise) in den Organisationen meist ohnehin sehr ausgeprägt.

Einige Datenbereiche haben jedoch eine Reihe von Vorsystemen und auch fachliche Anwendungsbereiche, auf die sie einwirken. So sind Kundendaten zum Beispiel sowohl in Finanzbuchhaltungs-Anwendungen ebenso relevant, wie in vertriebsunterstützenden Systemen (z.B. CRM). Der Unterschied liegt jedoch in meist differierenden Anforderungen an die Daten in deren Umfang und Qualität. Auch aus dieser "Daten-Subjekt" bezogenen Sicht können Data Domains gebildet werden. Dies bringt insofern großen Nutzen, da der Fokus der Steuerungsaufgaben erstens fachlich über die Verwendung der Daten getrieben ist und großes Potential in den systemübergreifenden Perspektiven der Daten gehoben werden kann (Vermeidung von Redundanzen, Klärung von Synchronisationsmechanismen etc.).

Diese Einordnung dient der Skalierung der Data Governance Initiativen, um die dazugehörigen Rollen, wie zum Beispiel die bereits erwähnten Data Domain Stewards entsprechend mit Wissensträgern besetzen zu können.

 

(Interne) Data Governance Partner

Einige Abteilungen müssen in Data Governance Initiativen partnerschaftlich eingebunden werden. Dabei handelt es sich nicht um klassische Einbindung als Rollen im Data Governance Konstrukt, sondern diese organisatorischen Einheiten leisten aufgrund ihrer definierten Aufgabe im Unternehmen einen wesentlichen Beitrag für die Data Governance Initiative im Rahmen "ihrer täglichen Arbeit".

Beispiele für solche Partner im Datagovernance Programm sind:

  • Information Technology (IT)
  • Information Security
  • Internal Audit / Legal
  • Human Resources
  • Project Management Office (PMO)

Mitglieder aus diesen Organisationseinheiten sind in vielen Initiativen notwendig, um Data Governance erfolgreich einleiten zu können und profitieren aber auch ihrerseits in der Regel von diesen. Deren aktueller Beitrag zur Governance in ihrem jeweiligen Bereich muss nicht im Rahmen der Data Governance Initiative repliziert werden. Existierende Zuständigkeiten können jedoch im Sinne eines "minimal invasiven Data Governance Ansatzes" eingebunden werden.

Ein gute Beispiel für eine partnerschaftliche Einbindung sind IT Abteilungen. Sie müssen nicht dezidiert steuernd oder operativ im Rahmen einer klassischen Rolle zur Data Governance  beitragen, sind aber üblicherweise stark in die technische Umsetzung und den Betrieb von unterstützenden Lösungen eingebunden. Die IT-bezogenen Aufgaben sind meist durch Linien oder Projektorganisation abgedeckt.

Ebenso werden Beratungsleistung die Daten betreffend aus der Linienorganisation abgedeckt. Ein Beispiel dafür können rechtliche Belange zur Speicherung und Verwendung von z.B. Mitarbeiterdaten sein. Die für die Governance notwendigen Informationen werden auch im operativen Geschäft unabhängig der Data Governance Initiative benötigt

Diese Datagovernance Partner sind jedoch nicht als eigene Gruppe in diesem Kontext zu sehen, sondern werden je nach Bedarf in die einzelnen Prozesse (und deren Gestaltung) eingebunden.

Prozesse

Der wohl wichtigste Prozess im Data Governance ist das Data Quality Monitoring.

Meistens poppt das Thema Datenqualität bei der Anpassung oder Entwicklung von Berichten auf. Werden Daten aus einer "neuen" Perspektive betrachtet, zeigt sich oft, dass deren Qualität dieser neuen Betrachtung nicht vollständig standhalten. Natürlich muss man fairerweise erwähnen, dass eine perfekte Datenqualität meist ein frommer Wunsch  ist, jedoch eine zumindest ausreichende Datenqualität sollte permanent gewährleistet werden können.

Im Rahmen von Data Governance gilt es zu vermeiden, dass mäßige Datenqualität erst im veröffentlichten Bericht zum Vorschein kommt. Idealerweise ist die Qualität der Daten bereits vorher bekannt und wird anhand eines klar definierten Regelwerks kontinuierlich geprüft und gemessen. Die Definition des Qualitätsanspruchs an die Daten muss schon ein Teil der Anforderung sein.

Data Quality Monitoring hat mindestens zwei Ausgangspunkte:

  • Regelwerke, die bereits bei der Entwicklung bekannt sind (sowohl bei der Entwicklung neuer Berichte, wie auch bei der Entwicklung neuer Modelle oder deren Anpassung)
  • Regelwerke, die sich erst in der Verwendung der Daten zeigen (gemeldete Fehler im Berichtswesen)

Beide Ausgangspunkte müssen zur Anpassung jenes Regelwerkes führen, dem die Daten im Rahmen von ETL Prozessen unterworfen sind. Bei jeder Aktualisierung der Daten für das Berichtswesen kann festgestellt werden, ob den Anforderungen an die Daten genüge getan wird. Im Rahmen der Aktualisierung durchlaufen die Daten eine Reihe von Prüfschritten. Welche diese sind, wird zuerst im Rahmen der Anforderungsdefinition festgelegt. Ein Beispiel dafür wäre, dass kein Angebot ohne vorhandene Kundennummer im Bericht aufscheinen darf.

Werden Fehler im Bericht eingemeldet, kann dies dazu führen, dass die Liste der Prüfregeln angepasst werden muss. Zum Beispiel gibt es möglicherweise "wichtige" Angebote, die mitgezählt werden müssen, obwohl hierzu kein Kunde im Kundenstamm zu finden ist.

Für die Einhaltung dieser Regeln (und die Bearbeitung der Daten bei Regelverletzungen) ist aus Data Governance Sicht im ersten Schritt der Data Steward zuständig. Er muss eine Verbesserung der Daten einleiten oder eine Bearbeitung der Transformationsprozesse veranlassen, zum Beispiel Fallback-Stammdatensätze, die für die genannten Fälle verwendet werden können.

Technisch kann das Datenqualitätsmonitoring in unterschiedlicher Intensität betrieben werden. Es gibt eine Reihe von speziellen Werkzeugen, vor allem im Bereich des Stammdaten-Managements, die auch die kontinuierliche Anwendung von Regelwerken unterstützen. Wir empfehlen einen klaren Prozess für das Issue Tracking, um eine Überführung in die Datenqualitätsregelwerke zu gewährleisten.

Aus BI- und Datawarehouse-Sicht können aber auch schon einfache Datenqualitätsreports (Listen mit Abweichungen von Regelwerk) eine einfache Lösung darstellen. Wichtig dabei bleibt, dass die gemeldeten Regelverletzungen auch bearbeitet werden. Nur weil bekannt ist, dass Daten falsch sind, macht es das nicht zu besseren Daten! Aber man kann in Analysen darauf Rücksicht nehmen, beispielsweise durch das Ausgrenzen "zweifelhafter" Datensätze.

Technologien und Werkzeuge

Data Cataloging Tool

Ein Werkzeug, um sich der unternehmenseigenen Datenlandschaft zu nähern, diese besser zu verstehen und zu verwalten, ist ein Data Cataloging Tool.

Mit Azure Purview wurde Ende letzten Jahres von Microsoft ein Werkzeug veröffentlicht, mit welchem eine "Inventur" der Datenlandschaft, eine Klassifizierung von Dateninhalten und eine Übersicht über die im Unternehmen (zwischen den Systemen) vorhandenen Datenflüssen ermöglicht.

Was Purview ist und wie es funktioniert, zeigt Ihnen Wolfgang Straßer in diesen zwei (englischen) Videos. Viel Spaß dabei!

Azure Purview

Mit den in Purview enthaltenen Konnektoren ist es möglich, Verbindungen zu Dateninseln im Unternehmen zu definieren. Der Begriff eines Scans fasst im nächsten Schritt den Scope einer Inventur, die berücksichtigen Klassifikationsregeln und die Frequenz der Scans zusammen.

Purview erstellt im nächsten Schritt eine Datenlandkarte - die Data Map - in welcher die einzelnen Data Assets (Tabellen, Dateien) und deren Zusammenhänge katalogisiert werden.

Mit der webbasierten Oberfläche dem Purview Studio können Data Stewards mit dem erstellten Datennetzwerk arbeiten, nach klassifizierten Datenelementen suchen und deren Zusammenhänge analysieren.

Data Catalog und Data Assets

In einem Data Catalog werden die Bestandteile der Datenlandschaft katalogisiert, klassifiziert, in Relation zu einander gesetzt und über eine der Hauptanwendung des Katalogs - der Suche - den Datenverwendern im Unternehmen zur Verfügung gestellt.

Neben den bestehenden Systemen wie z.B. eine Datenbank werden auch die Strukturen darin - wie z.B. Tabellen und deren Spalten - und die Zusammenhänge der Datenflüsse katalogisiert. Es werden auch die Datenschnittstellen, die zwischen einer Datenbank und einem Data Lake existieren, definiert. 

Weiters geht es um die Klassifikation der Daten. Welche Elemente sind im Datenkatalog oder in der einzelnen Tabelle enthalten, wie zum Beispiel eine E-Mail-Adresse. Neben den technischen Strukturen sind im Daten Katalog auch die Verantwortlichkeiten definiert.

Wie kommen die Informationen in den Datenkatalog?

Der Datenkatalog ist also die zentrale Komponente zur Erfassung der Datenlandschaft. Die Inhalte gliedern sich in folgende Bereiche:

  • Technische Informationen (z.B. Tabellenschema mit Spalten, Datentypen und weiteren technischen Eigenschaften)
  • Datenklassifikation
  • Zuordnung von Verantwortlichkeiten (Experten, Dateneigner)
  • Business Glossary

 

Data Catalog in Azur Purview

Es gelangen folgende Konzepte zum Einsatz:

  • Ein Data Asset steht in Purview für eine Einheit zur Definition der Datenlandkarte. Im einfachsten Fall stellt ein Data Asset z.B. eine Tabelle in einer Azure SQL Datenbank oder eine Datei im Data Lake dar. Die Eigenschaften eines Data Asset gliedern sich einerseits in
    • die Einordnung in der Datenhierarchie (Tabelle -> Schema -> Datenbank -> Datenbankserver),
    • die technischen Details,
    • das Schema des Assets (z.B. Spalten in einer Tabelle),
    • den Verantwortlichkeiten (Owner, Experts)
  • Die Data Map - der zentrale Datenkatalog - integriert Information, welche Azure Purview durch automatisierte Scans der Quellsysteme, der Klassifikation der Datenelemente, die Elemente aus dem Business Glossary sowie der manuellen Überarbeitung der Elemente. 

 

  • Eine Besonderheit von Purview stellt die automatisierte Erstellung der Data Lineage dar. Erkennt Purview Zusammenhänge zwischen Data Assets, so werden diese miteinander verknüpft. Diese Verbindungen können z.B. SQL Aufbereitungen in einer Datenbank sein, aber auch Datenschnittstellen mit Azure Synapse Pipelines.
  • Einen einfachen Zugang zu den Daten in der Data Map bietet der Data Catalog bzw. die Suche darin. Die vielleicht mit einer einfachen Suche nach einem Stichwort (z.B. Kunden) gestartete Suche nach Data Assets kann in den nächsten Schritte mit einer Vielzahl der Eigenschaften im Datenkatalog kombiniert werden. So kann das Suchergebnis anhand der Datenklassifikation, dem Business Glossary, der Data Owners und Experts aber auch der Datenquellen verfeinert werden.

Wie kommen die Inhalte in den Datenkatalog?

Um den Datenkatalog mit Leben zu befüllen, sind in Azure Purview Datenquellen vorhanden. Diese stellen die Funktionalität zur Verfügung, die technische Inventur der Datenquelle durchzuführen. In diesem Schritt werden (im Beispiel einer Azure SQL Datenbank), die Schema, die Tabellen, die Spalten in diesen Tabellen sowie deren Eigenschaften wir Datentypen etc. eingelesen und verarbeitet.

Im nächsten Schritt können mit Purview automatisierte Datenklassifikation vorgenommen werden. Purview analysiert in diesem Schritt die Datenquellen anhand vordefinierter Klassifikationsregeln (z.B. einem regulären Ausdruck) um u.a. Telefonnummern oder Emailadressen zu erkennen und diesen Elementen eine entsprechende Klassifikation zuzuweisen. Neben den über 200 systemeigenen Klassifikationsregeln  können auch eigene Regeln und Klassifikationen erstellt werden.

Im nächsten Schritt kombiniert Purview die gesammelten Informationen in die Data Map - das zentrale Netzwerk an Dateninformationen.

Data Lineage

Unter Data Lineage versteht man das nachvollziehbare Aufzeichnen des Weges der Daten

  • von der Datenquelle (im operativen System),
  • über die Transformationen denen die Daten in der DWH-Beladung unterworfen sind,
  • bis hin zu deren Verwendung in analytischen Modellen (deren Einfluss auf Kennzahlen) und
  • darüber hinaus manchmal auch deren Archivierungsmechanismen.

Wozu braucht man das? Sicher sind Ihnen Anfragen wie folgende bekannt:

  • Die Geschäftsführung verlangt einen Bericht und Sie haben keine Ahnung, wo Sie die Daten herzaubern sollen?
  • Irgendwie passen die Daten eines Berichts nicht zusammen und die Fachanwender wollen sicherstellen, dass die richtige Quellen im Datawarehouse verwenden werden?
  • In welchen Datensenken sind personenbezogene Daten gespeichert, welche bei DSGVO-Anfragen berücksichtigt werden müssen?
  • Welche Zusammenhänge und Schnittstellen bestehen zwischen zwei oder mehreren Systemen im Unternehmen?

Diese Fragen können mit Hilfe möglichst konsequenter Data - Lineage adressiert werden. Unter Lineage (ein Begriff aus der Ethnologie) versteht man eine gemeinsame Abstammung oder auch den Familien-Stammbaum. Legt man den Begriff der Lineage auf das Datenumfeld um, so versteht man das nachvollziehbare Aufzeichnen des Weges der Daten.

In erster Linie handelt es sich dabei um eine zu pflegende Dokumentation. Diese kann jedoch (entsprechende Technologien vorausgesetzt) auch automatisiert oder wenigstens teilautomatisiert erfolgen. Mit Azure Purview ist es möglich, automatisiert diese Lineage-Information aus den Datentransformationssystemen wie z.B. Azure Data Factory in die Datenlandkarte zu übernehmen. Weiters hat dieser automatisierte Ansatz den Vorteil, dass die Dokumentation mit jeder Änderung der Pipeline in der Data Factory auch in der aktuellsten Version in Azure Purview veröffentlicht wird.

Weitere Informationen finden Sie auch unter diesem Link: https://learn.g2.com/data-lineage

Power BI Integration

Ein Datenkatalog lebt durch die gute Integration mit vielen Systemen, um die Strukturen, Datenklassifikationen und Zusammenhänge zwischen den Systemen zu vereinen.

In Azure Purview steht bereits jetzt eine Vielzahl an Schnittstellen zur Verfügung - die Liste an native unterstützten Systemen wird von Monat zu Monat länger.

Eine sehr wichtige Schnittstelle stellt die Power BI Integration in Azure Purview dar. Mit dieser Integration von Power BI in die Azure Purview Data Map besteht nun die Möglichkeit, die Datalineage (Herkunft) von der Datenquelle über die Aufbereitungen, das Power BI Datenmodell bis zu den Power BI Reports und Dashboards nachzuvollziehen.

Azure Purview

Mit der nun verfügbaren Metadatenschnitstelle ist es möglich, die Inhalte von Power BI Datasets in die Purview Data Map zu überführen und Power BI als ein Teil der gesamten Datenherkunft zu analysieren.

Falls Sie diese Integration live sehen wollen, gibt es dazu ein kurzes Video!

Business Glossary / Kennzahlen-Dokumentation

Neben den technischen Details im Datenkatalog ist eine für die Anwender in den Fachabteilungen verständliche Definition zwingend notwendig. In diesem Zusammenhang spricht man vom Business Glossary.

Die Idee hinter einem Business Glossary ist einfach definiert - in einem Unternehmen sollten wir alle vom selben sprechen! Nehmen wir nur die Definition von Kennzahlen wie dem Umsatz, dem Deckungsbeitrag 1 oder anderen Berechnungen.

Hier ist es wichtig, dass diese Informationen gleich definiert sind, aber auch definiert ist wo diese Informationen in der Datenlandschaft zur Verfügung stehen.

Azure Purview

Im Business Glossary können diese Definitionen in einem einheitlichen Schema und einer Struktur abgelegt werden und im nächsten Schritt den Data Assets im Katalog zugewiesen werden. So wird mit dieser Aktion der Schritt von der technischen Inventur (den technischen Elementnamen) in Richtung einer geschäftsorientierten Klassifikation vorgenommen.

Wie das Business Glossary in Azure Purview definiert und verwendet wird zeigen wir Ihnen in diesem kurzen Video!