Teil 1
End-to-End-Governance-Architektur
Die Serie End-to-End Data Governance gibt dir den Einstieg und den roten Faden für die folgenden Teile.
Begriffe vor dem Lesen
- Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
- verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
- technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
- Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.
Ausgangslage
End-to-End Governance — Richtlinien, Metadaten, dbt, Schutz und governte BI.
Was diese Serie klärt
- Orientierung: End-to-End-Governance-Architektur
- Vertiefung: Metadatengetriebene Governance mit dbt meta
- Abschluss mit betreibbaren Next Steps über Snowflake Masking Richtlinien + Qlik Section Access
Begriffe und Kürzel vor dem Lesen
- personenbezogene Daten — Personenbeziehbare Daten: Informationen, die allein oder kombiniert eine Person identifizieren können.
- dbt — data build tool: SQL-nahe Transformationsschicht; Modelle brauchen verantwortliche Person, Tests und Verträge wie jedes Datenprodukt.
- BI — Business Intelligence: Reporting- und Analyseflächen, die governte Kennzahlen und Datenprodukte nutzen.
- verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
- Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
- Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
Lesepfad
- End-to-End-Governance-Architektur
- Metadatengetriebene Governance mit dbt meta
- Automatische RAW-Generierung mit dbt-Macros
- PII-Metadaten durch Data Warehouses propagieren
- Snowflake Masking Policies + Qlik Section Access
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.
Governance ist eine Architektur — kein Katalog neben der Plattform
KMU/SMB — ein Produktpfad von Owner-Metadata über Transform, Protection und BI-Evidenz. Mid-Market — explizites führendes System je Metadata-Typ über zwei Plattformen. Enterprise — verbundene Data-/Metadata-/Control-Planes mit Incident-Feedback-Loop.
Ein Katalog und eine Richtlinien-PDF erzeugen noch keine End-to-End-Governance. Merke die Trennung: Metadata beschreibt und steuert; ein Katalog macht Metadata auffindbar und bearbeitbar; ein Dashboard konsumiert trusted Ergebnisse — es ist nicht der Katalog. Operativ wird es erst, wenn eine fachliche Regel in Metadaten, Transformation, Schutz und BI nachvollziehbar ankommt.
Katalog, Klassifikation und Richtlinie sind nützlich. Keines davon erzeugt allein die durchgängige Kette.
Governance wird erst operativ, wenn eine fachliche Entscheidung durch die technische Plattform verfolgt werden kann:
Fachliche Richtlinie
→ freigegebene Metadaten
→ implementierte Transformation
→ Laufzeitkontrolle
→ operativer Nachweis
→ Governance-Review
Endet die Kette nach der Dokumentation, kann die Plattform wissen, dass eine Spalte personenbezogene Daten enthält, ohne diese tatsächlich zu schützen.
Beginnt die Kette erst bei der Laufzeitsicherheit, kann eine Spalte maskiert sein, ohne den fachlichen Grund, die Verantwortung oder den Freigabestatus hinter dieser Kontrolle zu erhalten.
End-to-End-Governance verbindet Entscheidungen, Metadaten, Code, Schutz, Zugriff und Nachweise zu einem kontrollierten System.
Dieser Artikel definiert dieses System. Die folgenden Parts vertiefen einzelne Mechanismen.
Mit einer klaren Verantwortungsgrenze beginnen
Die erste Architekturentscheidung ist einfach, aber wichtig:
Die Ingestion lädt Daten in die Plattform. dbt transformiert Daten, die bereits dort vorhanden sind.
Ein typischer Ablauf lautet:
Quellsysteme
→ Ingestion oder Replikation
→ Landing-Tabellen
→ dbt-Transformation
→ governte Warehouse-Layer
→ governte Nutzung
Der Ingestion-Mechanismus kann ein Managed Connector, ein CDC-Service, eine Orchestrierungspipeline, ein File Loader oder ein eigener Prozess sein.
Zu seinen Verantwortlichkeiten gehören:
- Verbindung zu Quellsystemen;
- Extraktion und Laden von Datensätzen;
- Erhalt technischer Liefermetadaten;
- Wiederholungen und Checkpoints;
- Erkennung fehlgeschlagener oder verspäteter Loads;
- Erstellung oder Aktualisierung physischer Landing-Objekte.
dbt beginnt, nachdem diese physischen Landing-Objekte existieren.
Zu den dbt-Verantwortlichkeiten gehören:
- Deklaration von Sources;
- Transformation quellsystemnaher Daten;
- Tests und Vereinbarungen;
- Lineage;
- Dokumentation und Artefakte;
- Materialisierung governter Modelle;
- Bereitstellung von Metadaten für nachgelagerte Automatisierung.
Werden beide Themen in einer gemeinsamen Prozessbox zusammengefasst, werden Verantwortung und Fehleranalyse unnötig unklar.
Die Architektur besteht aus drei verbundenen Ebenen
Eine governte Plattform wird verständlicher, wenn sie in drei Ebenen aufgeteilt wird.
1. Data Plane
Die Data Plane enthält die physischen und logischen Datenprodukte:
Landing
→ RAW
→ Conform
→ Analytics
→ Anwendungen
Jeder Layer besitzt eine andere Verantwortung.
| Layer | Primäre Verantwortung |
|---|---|
| Landing | Gelieferte Quellstruktur und Ingestion-Metadaten erhalten |
| RAW | Quellsystemnahe Daten als kontrollierte Transformationsressourcen bereitstellen |
| Conform | Gemeinsame Entitäten standardisieren, harmonisieren und integrieren |
| Analytics | Kuratierte Fakten, Dimensionen, Kennzahlen und Use-Case-Modelle bereitstellen |
| Anwendungen | Governte Daten für Nutzer und operative Prozesse verfügbar machen |
Die Bezeichnungen können je Plattform abweichen. Entscheidend ist die Trennung der Verantwortlichkeiten.
2. Metadata Plane
Die Metadata Plane beschreibt die Data Plane.
Sie enthält unter anderem:
- physische Schemas und Datentypen;
- Source- und Modellbeschreibungen;
- Verantwortung und Domäne;
- Spaltenklassifikation;
- Sensitivität und Aufbewahrung;
- Lineage und Abhängigkeiten;
- Data-Quality-Ergebnisse;
- Freshness und Betriebsstatus;
- generierte Dokumentation;
- Warehouse-Tags und Richtlinie-Referenzen.
Metadaten können über dbt-YAML, dbt-Artefakte, Warehouse-Tags, Kataloge, Berechtigungstabellen und operative Systeme verteilt sein.
Die Architektur benötigt deshalb einen expliziten Vertrag, der festlegt, welches System für welche Metadatenart führend ist.
3. Control Plane
Die Control Plane überführt Entscheidungen in erzwungenes Verhalten.
Sie umfasst:
- Richtlinien und Standards;
- Freigabeprozesse;
- CI-Validierung;
- Datentests und Vereinbarungen;
- Deployment-Kontrollen;
- Masking Richtlinien;
- Row Access Richtlinien;
- Rollen und Berechtigungs;
- Qlik Section Access;
- Audit- und Incident-Prozesse.
Ein Katalog kann eine Kontrolle beschreiben. Die Control Plane setzt sie um und überprüft sie.
Governance-Entscheidungen benötigen einen technischen Vertrag
Eine Richtlinie wie „Die E-Mail-Adresse des Kunden ist vertrauliche personenbezogene Information“ ist für Automatisierung zu abstrakt.
Die Plattform benötigt eine maschinenlesbare Darstellung:
columns:
- name: email
config:
meta:
pii: true
pii_category: email
sensitivity: confidential
classification_status: approved
masking_policy: email_mask
data_owner: customer_operations
steward: data_governance
Diese Metadaten schützen die Spalte nicht selbstständig.
Sie bilden einen technischen Vertrag, der:
- in Git geprüft;
- in CI validiert;
- in dbt-Artefakte kompiliert;
- in der Dokumentation angezeigt;
- durch Generierungs- und Propagierungslogik verwendet;
- auf Warehouse-Tags und Richtlinien abgebildet;
- mit der Laufzeitimplementierung verglichen;
- als Review-Nachweis genutzt werden kann.
Part 2 definiert diesen Vertrag im Detail.
Klassifikation und Durchsetzung sind unterschiedliche Verantwortlichkeiten
Eine Klassifikation beantwortet:
Welche Art von Daten ist das?
Wie sensibel sind sie?
Wer verantwortet die Entscheidung?
Welche Behandlung wurde freigegeben?
Die Durchsetzung beantwortet:
Was darf die aktuelle Identität sehen?
Welche Zeilen sind erlaubt?
Welche Werte müssen maskiert werden?
Welche Anwendung darf die Daten nutzen?
Beides muss verbunden werden, darf aber nicht verwechselt werden.
Eine belastbare Architektur trennt mindestens zwei Schutzdimensionen.
Spaltenschutz
Der Spaltenschutz steuert die Darstellung sensibler Werte.
Beispiele:
- vollständige Maskierung;
- Teilmaskierung;
- Hashing;
- Tokenisierung;
- Ersetzung durch
null; - rollenabhängiger Klartext.
Snowflake Dynamic Data Masking wendet Masking Policies zur Abfragezeit auf Spalten an. Tag-basiertes Masking kann Object Tags und Masking Policies verbinden, sodass markierte Spalten entsprechend der gültigen Policy und des Datentyps geschützt werden.
Zeilenbasierter Zugriff
Zeilenbasierter Zugriff entscheidet, welche Datensätze sichtbar sind.
Beispiele:
- Region;
- Gesellschaft;
- Abteilung;
- Kundenportfolio;
- Mandant;
- Vertragsbereich.
Snowflake Row Access Policies können diese Filterung zentral im Warehouse erzwingen.
Qlik Section Access kann innerhalb einer Anwendung eine dynamische Datenreduktion anwenden, indem Benutzerberechtigungen mit Reduktionsfeldern im Datenmodell verbunden werden.
Beide Kontrollen können sich ergänzen:
Warehouse Policy
→ schützt das governte Datenprodukt zentral
Qlik Section Access
→ begrenzt die Anwendungszeilen für Nutzer und Use Case
Qlik darf nicht der einzige Ort sein, an dem sensible Daten geschützt werden. Ein Nutzer oder Service mit direktem Warehouse-Zugriff würde eine rein anwendungsseitige Kontrolle umgehen.
Governance-Verantwortlichkeiten nach Rolle
Governance scheitert, wenn jedes Team davon ausgeht, dass ein anderes Team die endgültige Entscheidung trifft.
Ein praktikables Verantwortung-Modell unterscheidet folgende Rollen.
Data Owner
Der Data Owner genehmigt die fachliche Nutzung der Daten.
Typische Entscheidungen:
- erlaubte Zwecke;
- Domänenverantwortung;
- Sensitivität;
- Aufbewahrung;
- externe Weitergabe;
- akzeptables fachliches Risiko.
Data Steward
Der Steward pflegt die Klassifikation und stellt die konsistente Verwendung des Governance-Vokabulars sicher.
Typische Verantwortlichkeiten:
- Beschreibungen und Glossar-Abgleich;
- personenbezogene Daten-Kategorie;
- Klassifikationsstatus;
- Review-Datum;
- Koordination von Issues;
- Freigabenachweise.
Data Engineering oder Platform Engineering
Engineering implementiert das governte Datenprodukt.
Typische Verantwortlichkeiten:
- Source-Deklarationen;
- Transformationen;
- Tests und Vereinbarungen;
- Metadatenintegration;
- Deployment;
- Lineage;
- technische Richtlinie-Anbindung;
- Drift-Erkennung.
Engineering kann eine wahrscheinliche PII-Spalte erkennen, darf die Klassifikation aber nicht stillschweigend freigeben.
Security und Privacy
Security und Privacy definieren Schutzstandards und genehmigen risikoreiche Kontrollen.
Typische Verantwortlichkeiten:
- Maskierungsmuster;
- Richtlinie-Administration;
- Rollendesign;
- Funktionstrennung;
- Datenschutzanforderungen;
- Access Reviews;
- Incident Handling.
BI- oder Application Owner
Der Application Owner implementiert nutzungsspezifische Zugriffskontrollen.
Typische Verantwortlichkeiten:
- App-Zugriff;
- Section Access;
- Reduktionsfelder;
- freigegebene Exporte;
- Visualisierungsverhalten;
- Nutzerkommunikation;
- Anwendungsmonitoring.
Die Übergaben zwischen diesen Rollen müssen sichtbar sein. Ein Feld kann gleichzeitig einen Business Owner, einen Custodian und einen Application Owner besitzen.
Qualität ist Teil der Governance
Governance beschränkt sich nicht auf PII und Berechtigungen.
Ein Datenprodukt ist nicht vertrauenswürdig, wenn seine Verantwortung dokumentiert ist, seine Werte aber verspätet, unvollständig oder strukturell ungültig sind.
Die Architektur sollte Governance-Metadaten deshalb verbinden mit:
- Source Freshness;
- Not-null- und Unique-Erwartungen;
- referenzieller Integrität;
- erlaubten Werten;
- Volumenanomalien;
- Vereinbarung-Prüfungen;
- Abstimmungen;
- fachlicher Regelvalidierung;
- Incident-Schweregrad;
- Quality Verantwortung.
Nicht jeder Test ist gleich wichtig.
Ein praktikables Modell weist Quality Tier oder Kritikalität zu:
config:
meta:
quality_tier: critical
criticality: tier_1
custodian: data_platform
CI und Orchestrierung können für kritische Modelle strengere Gates anwenden als für explorative Modelle.
Lineage liefert Impact — aber keine automatische Verantwortlichkeit
Lineage beantwortet Fragen wie:
- Welche Quelle speist diese Kennzahl?
- Welche Modelle hängen von dieser Spalte ab?
- Welche Anwendungen könnten von einer Änderung betroffen sein?
- Wohin muss eine Klassifikation propagiert werden?
- Welche Kontrollen sollten downstream vorhanden sein?
Lineage entscheidet nicht, ob eine nachgelagerte Transformation die Klassifikation erhält oder verändert.
Beispiel:
email
→ lower(email)
bleibt üblicherweise personenbezogen.
Dagegen kann:
email
→ count(distinct email)
ein nicht personenbezogenes Aggregat erzeugen — abhängig von Granularität, Filtern und Offenlegungsrisiko.
Part 4 behandelt genau dieses Propagierungs- und Auflösungsproblem.
Nachweise schließen den Governance-Regelkreis
Eine Policy-Implementierung muss Nachweise erzeugen.
Nützliche Nachweise sind:
- freigegebene Pull Requests;
- Ergebnisse der Metadatenvalidierung;
- dbt-Testergebnisse;
- Manifest- und Katalog-Artefakte;
- Lineage-Snapshots;
- Richtlinie-Referenzen;
- Access Reviews;
- Query- und Zugriffslogs;
- Schema-Drift-Ereignisse;
- Incidents und Ausnahmen;
- Review-Daten.
Die Nachweise sollten drei Fragen beantworten:
Was wurde freigegeben?
Was wurde implementiert?
Was ist zur Laufzeit geschehen?
Können diese Antworten nicht verbunden werden, existiert Dokumentation, aber keine auditierbare Governance.
Eine minimal tragfähige Governance-Architektur
Eine erste Umsetzung benötigt nicht jede Enterprise-Funktion.
Sie benötigt einen vollständigen Kontrollpfad.
Eine minimal tragfähige Architektur kann enthalten:
-
Definiertes Governance-Vokabular
- Owner;
- Domäne;
- PII;
- Sensitivität;
- Klassifikationsstatus;
- Aufbewahrungsklasse;
- Schutz-Policy.
-
Versionierte Metadaten
- dbt-YAML;
- Code Review;
- explizite Freigabeverantwortliche.
-
Automatisierte Validierung
- Pflichtfelder;
- erlaubte Werte;
- PII-Policy-Prüfungen;
- Prüfung ungeprüfter Spalten.
-
Governte Transformationen
- Source-Deklarationen;
- Tests;
- Lineage;
- klare Layer-Verantwortlichkeiten.
-
Laufzeitkontrollen
- Warehouse-Rollen;
- Masking;
- zeilenbasierter Zugriff;
- Anwendungsberechtigungen.
-
Operative Nachweise
- Build-Ergebnisse;
- Policy-Referenzen;
- Access Review;
- Incident-Prozess.
Das ist stärker als ein großer Katalog ohne Verbindung zu Delivery und Durchsetzung.
Häufige Architekturfehler
Governance-Metadaten existieren nur im Katalog
Code und Laufzeitplattform können sie nicht zuverlässig konsumieren.
Metadaten existieren nur in dbt
Fachbereiche und Stewards können sie nicht wirksam prüfen und steuern.
PII wird automatisch erkannt und als freigegeben behandelt
Erkennung ist ein Hinweis für das Review, keine Governance-Entscheidung.
Zugriff wird ausschließlich in Qlik umgesetzt
Warehouse-Zugriffe außerhalb der Anwendung bleiben unzureichend geschützt.
Jede Regel ist direkt in SQL eingebettet
Policy-Pflege wird dupliziert und schwer auditierbar.
Metadaten werden ohne Transformationsverständnis kopiert
Abgeleitete Spalten übernehmen falsche Klassifikationen oder verlieren sensible Lineage.
Ingestion, Transformation und Governance werden als eine Tool-Verantwortung betrachtet
Fehler, Verantwortung und Kontrollgrenzen werden unklar.
Die zentrale Erkenntnis
Eine governte Datenplattform ist keine Abfolge von Tools. Sie ist ein verbundenes System aus Entscheidungen, Metadatenverträgen, Transformationen, Laufzeitkontrollen und Nachweisen.
Part 2, Metadatengetriebene Governance mit dbt meta, überführt den Architekturvertrag in ein konkretes, versioniertes Metadatenmodell in dbt.
Quellen und weiterführende Dokumentation
- dbt — meta configuration
- dbt — manifest JSON
- dbt — about dbt artifacts
- Snowflake — Dynamic Data Masking
- Snowflake — Tag-based masking policies
- Snowflake — Row access policies
- Qlik Sense — Managing data security with Section Access
