Governance-Plattform Vendor-Starts

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

Die Lenkungsrunde hat Fabric wegen der Feature-Liste gekauft. Sechs Wochen später gilt der Workspace-Administrator als Data Owner.

Was diese Serie klärt

• Orientierung: Microsoft Fabric als Governance-Einstieg
• Vertiefung: Databricks und Unity Catalog als Governance-Einstieg
• Abschluss mit betreibbaren Next Steps über Argonos als Governance-Einstieg

Begriffe und Kürzel vor dem Lesen

• verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
• technischer Betreiber — Betreibt Plattform und Zugriffspfad; ist nicht automatisch der fachliche verantwortliche Person.
• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
• Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
• Data Vereinbarung — Vereinbarung zwischen Anbieter und Nutzer: Felder, Bedeutung, Qualität, Aktualität, Änderungsvorlauf, Kontakte.

Lesepfad

1. Microsoft Fabric als Governance-Einstieg
2. Databricks und Unity Catalog als Governance-Einstieg
3. Snowflake als Governance-Einstieg
4. BigQuery als Governance-Einstieg
5. dbt als plattformübergreifende Governance-Kontrollschicht
6. Cloudera CDP mit Ranger als Governance-Einstieg
7. AWS Redshift und Lake Formation als Governance-Einstieg
8. Kafka und Schema Registry als Governance-Einstieg
9. Palantir als Governance-Einstieg
10. Argonos als Governance-Einstieg

Nachbarserie: Governance-Plattform Overlay

Operating-Pfad für Workspace, Promotion und Refresh (stack-neutral, kein Tenant-Tutorial): BI-Publish Deep Dive.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Herausforderung

Microsoft Fabric kann den Weg von den Quelldaten bis zu einem Power-BI-Produkt verkürzen. Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Semantic Models und Reports können innerhalb einer SaaS-Analytics-Umgebung betrieben werden, während OneLake die gemeinsame Datengrundlage bildet. Für eine Organisation mit etabliertem Microsoft Tenant, Microsoft Entra ID, Power-BI-Landschaft und Fabric Capacity kann diese Integration reale Delivery-Reibung reduzieren.

Sie erzeugt jedoch nicht automatisch Governance.

Ein Workspace Admin ist nicht automatisch der verantwortliche Data Owner. Eine Fabric Domain vergibt oder entzieht keinen Zugriff. Ein Item Owner im Katalog verantwortet nicht zwangsläufig Business-Definition, erlaubte Nutzung oder Qualitätsrisiko. Ein zertifizierter Report beweist nicht, dass jede enthaltene Kennzahl eine freigegebene Definition, einen Grain, einen Calculation Owner und eine Reconciliation-Methode besitzt. Native Lineage garantiert keine vollständige Source-to-Consumer-Evidenz über alle Workspaces, Item-Typen und externen Transformationen.

Die Entscheidungsfrage lautet deshalb nicht:

Besitzt Fabric Governance-Funktionen?

Sondern:

Kann die Organisation Fabric als erste praktikable Governance-Grundlage für ein konkretes governed Data Product nutzen?

Fabric ist ein plausibler Einstiegspunkt, wenn der bestehende Microsoft-Kontext die Umsetzung vereinfacht und verantwortliche fachliche und technische Rollen klare Grenzen definieren und betreiben können für:

• Tenant und Identity
• Capacities
• Domains
• Workspaces
• Fabric Items und OneLake-Daten
• semantisches Modells und Reports
• Katalog und Business-Metadaten
• Zugriff und Schutz sensibler Daten
• Lineage-, Quality- und Audit-Evidenz
• Deployment, Support und Kostenverantwortung

Die Plattform-Surfaces bilden eine technische Umsetzungshierarchie. Sie bilden keine Hierarchie fachlicher Verantwortung.

Plattform-Surfaces sind keine Verantwortung-Entscheidungen

Rollen auf Tenant-, Capacity-, Domain-, Workspace- und Item-Ebene bestimmen, was Benutzer konfigurieren, erstellen, administrieren oder konsumieren dürfen. Diese Rollen sind für den Plattformbetrieb erforderlich. Sie beantworten nicht:

• warum das Data Product existiert
• welche Business-Entscheidung es unterstützt
• welche Definition freigegeben ist
• welche Nutzung erlaubt ist
• welches Qualitätsrisiko akzeptiert wird
• wer eine Ausnahme genehmigt
• wann das Produkt rezertifiziert oder stillgelegt wird

Diese Entscheidungen gehören zu verantwortlichen Data Ownern, unterstützt durch Data Stewards, Security, Architektur, Platform Operations und Delivery-Teams.

Integration kann fehlende Grenzen verdecken

Eine eng integrierte Plattform kann ein schwaches Operating Model reifer erscheinen lassen, als es ist. Teams können schnell Workspaces, Lakehouses, Warehouses, Semantic Models und Reports anlegen, aber weiterhin ohne folgende Grundlagen arbeiten:

• stabiles Domain-Modell
• benannte Verantwortung
• konsistente Workspace-Zwecke
• governede Security Groups
• Workflow zur Metadatenpflege
• vollständige Qualitätsnachweise
• Lifecycle Kontrollregeln
• Capacity- und Kostenverantwortung

Die erste Fabric-Governance-Entscheidung muss deshalb die Grenze definieren, bevor die Plattform skaliert wird.

Ansatz

Nutze Microsoft Fabric als Governance-Einstieg, wenn der integrierte Analytics- und Power-BI-Kontext die Delivery-Reibung reduziert und verantwortliche Rollen klare Grenzen über Domains, Workspaces, Katalog, Zugriff, Lineage, Semantic Models, Evidenz und Capacity definieren können.

Behandle Fabric als Operating Surface für das erste governed Data Product, nicht als Beweis bereits vorhandener Governance und nicht als universellen Standard für jeden Microsoft-Kunden.

1. Mit dem bestehenden Microsoft-Kontext beginnen

Dokumentiere die aktuelle Landschaft, bevor das Zielbild entsteht.

Die Ausgangsbewertung sollte enthalten:

• Microsoft-Entra-Tenant und Identity-Modell
• bestehende Power-BI-Workspaces, semantisches Modells, Reports und Gateways
• Fabric Capacities, Angebotspakete, Regionen und Workload-Nutzung
• aktuelle Tenant Settings und delegierte Administration
• bestehende Microsoft-Purview-Funktionen und Lizenzierung
• Quellsysteme und Ingestion-Muster
• Data-Residency-, Netzwerk- und Private-Access-Anforderungen
• aktuelle CI/CD-, Git- und Deployment-Praktiken
• Skills für Plattform, BI, Security und Stewardship
• Supportmodell und Kostenverantwortung

Fabric ist eher ein sinnvoller Startpunkt, wenn das erste governed Data Product bereits von Power BI, Microsoft Identity und einem Microsoft-betriebenen Analytics-Pfad abhängt. Die Eignung sinkt, wenn der Use Case umfangreiches Cross-Cloud Engineering benötigt, ein bestehender Nicht-Microsoft-Katalog autoritativ ist oder die Organisation Fabric und Purview nicht als koordinierte, aber getrennte Control Surfaces betreiben kann.

2. Business Domains und Fabric Domains trennen

Fabric Domains gruppieren Workspaces und deren Items logisch und unterstützen Organisation, Discovery und delegierte Administration. Die Domain-Zuordnung verändert für sich allein weder Sichtbarkeit noch Zugriff auf Items.

Eine Fabric Domain sollte deshalb ein freigegebenes Business-Domain-Modell umsetzen und dieses nicht eigenständig erfinden.

Vor dem Anlegen oder Umbauen von Domains müssen folgende Punkte entschieden sein:

• dargestellte Business Capability oder Subject Area
• verantwortlicher Domain Owner
• Steward-Netzwerk
• Data Products und Entscheidungen im Umfang
• Regeln für die Zuordnung von Workspaces
• delegierte Settings und Administration
• Shared-Data- und Cross-Domain-Abhängigkeiten
• Ausnahmen und Eskalation

Eine Domain kann federierte Governance unterstützen, aber Verantwortung nicht ersetzen. Domain Admins und Contributors setzen die Domain-Organisation technisch um. Data Owner bleiben verantwortlich für Definitionen, Nutzung, Qualität und Risiko.

3. Jedem Workspace einen expliziten Betriebszweck geben

Ein Workspace ist eine Collaboration-, Administrations-, Lifecycle- und Security-Surface. Er sollte nicht zur Standardeinheit für jede Governance-Entscheidung werden.

Jeder governed Workspace sollte dokumentieren:

• Zweck und Lifecycle-Phase
• zugeordnete Fabric Domain
• verantwortlicher Data Owner für die enthaltenen Produkte
• Workspace Admin und technischer Betreiber
• Contributor-, Member- und Viewer-Gruppen
• erlaubte Item-Typen
• Umgebung: Development, Test oder Production
• Deployment-Pfad
• Capacity-Zuordnung
• Support- und Incident-Route
• Retention- und Stilllegungsregel

Vermeide Workspaces, die ausschließlich nach Teamnamen angelegt werden, wenn Produkt-, Umgebungs- oder Security-Grenzen unterschiedlich sind. Vermeide einen gemeinsamen Workspace für nicht zusammengehörende Grains, Owner oder Lifecycle-Phasen, nur weil dasselbe Delivery-Team sie entwickelt.

4. Definieren, wo Fabric endet und Purview beginnt

Fabric und Microsoft Purview überlappen, sind aber nicht austauschbar.

Fabric-native Operating Surface

Nutze Fabric-native Funktionen für den täglichen Betrieb von Fabric Assets, insbesondere:

• Domains und Workspaces
• Discovery von Fabric Items über den OneLake Catalog
• Item Details, Tags, Endorsements und Sensitivity Labels, soweit unterstützt
• Workspace Lineage und Impact Analysis
• semantisches Modell-Model- und Power-BI-Delivery
• Tenant Settings und delegierte Administration
• Capacity-Zuordnung und Monitoring
• Git Integration und Deployment Pipelines, soweit unterstützt

Der OneLake Catalog ist der Fabric-zentrierte Einstieg für Discovery und Governance. Die Explore Experience unterstützt das Auffinden von Fabric Items. Die Govern Experience stellt Governance Insights, empfohlene Maßnahmen und Verweise auf relevante Tools bereit. Diese Insights basieren auf Fabric-Metadaten und besitzen dokumentierte Einschränkungen. Sie sind kein vollständiges Enterprise-Governance-Operating-Model.

Purview Governance Surface

Nutze Microsoft Purview, wenn Governance über Fabric hinaus in die gesamte Datenlandschaft reichen muss. Abhängig von den ausgewählten Purview-Funktionen, der Lizenzierung und regionalen Verfügbarkeit kann dies umfassen:

• Enterprise Catalog und Business Glossary
• Governance Domains und Data Products
• Data-Map-Scanning und Metadaten-Ingestion
• plattformübergreifende Discovery
• automatisierte Klassifizierung
• Business-Metadaten und Terminologie
• breiteren Lineage- und Impact-Kontext
• Information Protection, Audit und DLP
• Data Quality für unterstützte Quellen und Asset-Typen

Das Scannen eines Fabric Tenants kann Fabric-Metadaten und Lineage in Microsoft Purview übernehmen. Die aktuelle Abdeckung und Granularität variiert nach Item-Typ. Für Nicht-Power-BI-Items dokumentiert Microsoft unter anderem Einschränkungen bei der Granularität, unvollständige Sub-Item-Lineage und fehlende Cross-Workspace-Lineage in bestimmten Szenarien. Diese Grenzen müssen für das ausgewählte Data Product getestet werden.

Business Governance

Weder Fabric noch Purview sollten folgende Entscheidungen treffen:

• verantwortliche Verantwortung
• freigegebene Definitionen
• erlaubte Nutzung
• Risikoakzeptanz
• Ausnahmegenehmigung
• Zertifizierungskriterien
• Review und Rezertifizierung
• Deprecation

Die Plattformen speichern, zeigen, erzwingen oder belegen Entscheidungen. Das Operating Model trifft sie.

5. Identity und Access als eine kontrollierte Kette entwerfen

Das Access-Modell sollte mit Microsoft-Entra-Gruppen und benannten Group Ownern beginnen, nicht mit individuellen Berechtigungen, die während der Entwicklung hinzugefügt werden.

Das Design muss unterscheiden zwischen:

• Tenant Administration
• Capacity Administration
• Domain Administration
• Workspace Roles
• Item Permissions
• OneLake-Tabellen- und Ordnerberechtigungen, soweit anwendbar
• SQL-Endpoint- oder Warehouse-Berechtigungen
• semantisches Modell-Model-Berechtigungen
• Report- und App-Verteilung
• Row-Level oder Object-Level Security in semantisches Modells
• externem Sharing und Guest Access
• Service Principals und Managed Identities

Workspace Membership allein ist für ein governed Data Product häufig zu breit. OneLake Security kann über Custom Roles einen granulareren Lesezugriff auf ausgewählte Lakehouse-Tabellen und Ordner ermöglichen. Der erforderliche Access-Pfad muss jedoch über alle Engines und Konsumenten des Produkts getestet werden.

Für jede Access-Entscheidung sind zu dokumentieren:

• Business Purpose
• Identity Group
• Group verantwortliche Person
• freigegebene Surface
• erlaubte Operationen
• Bedingungen für sensible Daten
• Freigabe
• Ablauf- oder Review-Datum
• Evidenzquelle

Erfolgreiche Authentifizierung ist nicht mit erlaubter Business-Nutzung gleichzusetzen.

6. Klassifizierung und Sensitivity Labels als Controls behandeln

Sensitivity Labels aus Microsoft Purview Information Protection können auf unterstützte Fabric- und Power-BI-Items angewendet werden. Sie helfen bei Klassifizierung und Schutz, ersetzen aber nicht:

• personenbezogene Daten-Klassifizierung auf Feldebene
• eine Entscheidung zur erlaubten Nutzung
• Access Design
• Masking- oder Filtering-Anforderungen
• Retention- und Löschregeln
• Incident Verantwortung

Das governed Data Product muss einen Klassifizierungspfad von den Quellattributen über transformierte Daten und Semantic Models bis zu Reports und Exporten definieren.

Für jedes sensible Attribut sind festzuhalten:

• personenbezogene Daten-Kategorie
• Sensitivity Level
• autoritative Klassifizierungsentscheidung
• erlaubter Zweck
• Access Restriction
• Masking-, Omit- oder Filtering-Anforderung
• Export- und Sharing-Beschränkung
• Retention Rule
• erwartete Downstream-Propagation
• kontrollverantwortliche Person

Da Label-Unterstützung, Vererbung und Durchsetzung je nach Fabric Item und Consumption-Pfad variieren können, muss der Proof of Value den tatsächlichen End-to-End-Fluss testen.

7. Das governed Data Product mit dem Semantic Model verbinden

Das Semantic Model ist nicht nur eine Reporting-Hilfe. In vielen Power-BI-Landschaften bildet es den governeden Consumption Contract.

Das Modell muss explizit machen:

• Business Process und fachliche Ebene
• Conformed Dimensions und Keys
• freigegebene Measures
• Time- und Filter-Verhalten
• Calculation Verantwortung
• Row-Level und Object-Level Security
• Freshness-Erwartung
• Quality State
• Source Lineage
• Change- und Compatibility-Regeln
• Data Owner, Steward und technischer Betreiber
• Publication- und Deprecation-Status

Ein Report kann ein zertifiziertes Semantic Model nutzen und trotzdem durch lokale Report Measures Definition Drift erzeugen. Certification muss deshalb an Evidenz über Semantic Model und Kennzahlen gebunden sein und nicht nur an ein sichtbares Badge.

8. Source-to-Consumer-Evidenz aufbauen

Das erste governed Data Product sollte eine Evidenzkette über folgende Stufen pflegen:

Quelle
→ Ingestion
→ Transformation
→ governed Data Product
→ Semantic Model
→ zertifizierte Kennzahl oder Report
→ Konsument

Auf jeder Stufe werden dokumentiert:

• verantwortliche Person
• fachliche Ebene
• Klassifizierung
• Access-Entscheidung
• Lineage
• Quality-Evidenz
• Change Record

Die Fabric Lineage View zeigt Beziehungen innerhalb eines Workspaces und externe Quellen eine Stufe Upstream. Downstream-Abhängigkeiten in anderen Workspaces benötigen Impact Analysis. Für eine breitere Data-Estate-Lineage können Purview-Scans oder zusätzliche Evidenz erforderlich sein. Ein verbunden aussehendes Lineage-Diagramm ist kein Beweis für einen vollständigen Graphen.

Typische Fehlerbilder:

• Workspace Verantwortung wird mit Data Verantwortung verwechselt
• Report Certification ohne Kennzahlenfreigabe
• versteckte lokale Measures
• Cross-Workspace-Lineage-Lücken
• Quality Results nur in einem Development Notebook
• Source Changes ohne Nutzer-Migrationsnachweis
• ein sensibles Source Label ohne Validierung in Exporten oder Downstream Tools

9. Qualität operationalisieren

Qualität ist nicht abgeschlossen, wenn eine Regel einmal erfolgreich ausgeführt wurde. Ein governed Fabric Product benötigt:

• freigegebene Regeln mit Bezug zu Business Expectations
• Rule Owner und Incident verantwortliche Person
• Schwellenwerte und Schweregrad
• Ausführungsplan
• gespeicherte Failure Nachweis
• Zuordnung zu betroffenen Products und Nutzer
• Remediation Workflow
• Ausnahmefreigabe und Ablaufdatum
• für Konsumenten sichtbaren Health State
• Change- und Recertification-Trigger

Microsoft Purview Data Quality kann unterstützte Fabric-Lakehouse-Tabellen nach erforderlicher Registrierung, Scan und Konfiguration prüfen. Aktuelle Unterstützung, Voraussetzungen, Formate und Lizenzierung müssen validiert werden. Plattform-native Notebooks, Pipelines, SQL Tests oder Drittanbieter-Tools können weiterhin erforderlich sein. Entscheidend ist nicht, welcher Screen einen Score zeigt, sondern wer Regel, Fehler und Wiederherstellung verantwortet.

10. Deployment, Capacity und Kosten governeden

Fabric Capacity ist eine gemeinsam genutzte Betriebsressource. Ein governed Data Product kann trotz korrekter Daten-Controls scheitern, wenn Capacity Saturation, Deployment Drift oder unklare Kostenverantwortung den Service unzuverlässig machen.

Das Operating Model sollte definieren:

• Capacity verantwortliche Person
• Capacity Admin
• Regeln für Workload- und Workspace-Zuordnung
• Monitoring und Alerting
• Scale-, Pause- und Reservation-Entscheidungen, soweit anwendbar
• Cost Allocation oder Showback
• Trennung von Development, Test und Production
• Nutzung von Git und Deployment Pipelines
• Validierung unterstützter Item-Typen
• Deployment-Freigaben und Rückbau
• Compatibility-Anforderungen für semantisches Modells
• Incident- und Service-Level-Verantwortung

Deployment Pipelines unterstützen nicht jedes Item in gleicher Weise, und die Unterstützung verändert sich. Microsoft hat beispielsweise am 12. Februar 2026 die Pipeline-Unterstützung für Semantic Models ohne Enhanced Metadata beendet. Der Release-Prozess muss deshalb aktuelle unterstützte Items und Einschränkungen validieren, statt einen vollständigen Workspace als einheitlich deploybar anzunehmen.

Checkliste

Fabric darf erst als Startpunkt freigegeben werden, wenn die folgende Evidenz verfügbar ist.

Kontext und erster Use Case

• Ist ein erster governed Use Case benannt?
• Sind Business-Entscheidung, Konsumenten und Wert klar?
• Reduziert der aktuelle Microsoft- und Power-BI-Kontext die Delivery-Reibung tatsächlich?
• Ist die Alternative ohne neue Plattform dokumentiert?

Verantwortung und Decision Rights

• Ist ein Data Owner verantwortlich für Zweck, Definition, erlaubte Nutzung und Risiko?
• Ist ein Steward verantwortlich für Metadaten, Issue Coordination und Review-Evidenz?
• Sind Platform Admins klar von fachlicher Verantwortung getrennt?
• Sind Ausnahme- und Eskalationswege definiert?

Domain- und Workspace-Modell

• Setzt jede Fabric Domain eine freigegebene Business-Domain-Entscheidung um?
• Besitzt jeder Workspace einen eindeutigen Betriebszweck?
• Sind Domain-Zuordnung, Umgebung, Produkt, Security und Lifecycle dokumentiert?
• Wird Workspace Sprawl kontrolliert?

Katalog- und Purview-Grenze

• Wird der OneLake Catalog für Fabric-zentrierte Discovery und Governance Insights genutzt?
• Wird Microsoft Purview eingesetzt, wenn Enterprise Catalog, Glossary, breitere Klassifizierung oder plattformübergreifende Metadaten erforderlich sind?
• Ist für doppelte Metadatenfelder ein autoritativer Pflegeworkflow festgelegt?
• Sind Scan-, Refresh- und Lineage-Limitierungen dokumentiert?

Identity und Access

• Werden Entra-Gruppen statt unkontrollierter Einzelberechtigungen verwendet?
• Besitzt jede Gruppe einen Owner und Review-Prozess?
• Sind Workspace-, Item-, OneLake-, SQL- und semantisches Modell-Model-Berechtigungen gemeinsam entworfen?
• Sind Service Principals, Gäste und externes Sharing berücksichtigt?
• Kann effektiver Zugriff von der Quelle bis zum Report getestet werden?

PII und Sensitivity

• Sind sensible Attribute auf Feldebene klassifiziert?
• Ist die Sensitivity-Label-Strategie für unterstützte Items definiert?
• Sind Masking, Filtering, Omit und Export Kontrollregeln explizit?
• Sind Vererbung und Downstream-Verhalten getestet?
• Sind Retention- und Incident-Verantwortung zugeordnet?

Lineage und Change Evidence

• Reicht die Source-to-Nutzer-Lineage für Impact Analysis aus?
• Sind Cross-Workspace- und nicht unterstützte Transformationen dokumentiert?
• Erzeugt jedes Deployment einen Change Record?
• Können Konsumenten vor einem Breaking Change identifiziert werden?

Qualität und Certification

• Sind Quality Rules freigegeben und versioniert?
• Werden Fehler gespeichert und an einen benannten verantwortliche Person geroutet?
• Erfordert Certification Evidenz zu Definition, fachliche Ebene, Lineage, Qualität und Verantwortung?
• Werden lokale Report Measures kontrolliert?
• Sind Recertification- und Deprecation-Trigger definiert?

Semantic- und Power-BI-Fit

• Ist das semantisches Modell der governed Consumption Vereinbarung?
• Sind Kennzahl Definitions, Time Behavior und Filter Semantics freigegeben?
• Sind Row-Level und Object-Level Security getestet?
• Sind Reports ausreichend thin, um doppelte Business-Logik zu vermeiden?

Deployment und Umgebungen

• Sind Development-, Test- und Production-Grenzen explizit?
• Werden Git und Deployment Pipelines nur für unterstützte Items verwendet?
• Sind Freigaben, Rückbau und Compatibility Tests definiert?
• Werden manuelle Production Changes kontrolliert und belegt?

Capacity, Betrieb und Kosten

• Ist ein Capacity verantwortliche Person benannt?
• Werden Workload Consumption, Throttling und Service Health überwacht?
• Sind Support- und Incident-Routen dokumentiert?
• Sind Lizenz-, Regions- und Preview-Abhängigkeiten erfasst?
• Können Kosten ausreichend Products, Workspaces oder Domains zugeordnet werden?

Fabric bleibt nur bedingt bereit, wenn verpflichtende Controls von einer ungetesteten Funktion, unklarer Verantwortung, nicht unterstützter Lineage, fehlender Betriebskapazität oder offenen Lizenz- und Regionsfragen abhängen.

Artefakt

Dokumentiere das Ergebnis in einer Fabric Governance Grenze Map und einer Fabric Governance Readiness Decision.

Dokumentiere das Ergebnis mit dem Tool Governance Starting-Point Decision.

Pflichtfelder

Erforderliche Outputs

• Bereit für Proof of Value — das erste Data Product kann die vollständige Governance-Kette testen.
• Bedingte Readiness — Fabric ist plausibel, aber benannte Kontrollregeln müssen noch validiert werden.
• Blocker — fehlende Verantwortung, nicht unterstützter Kontrollregel-Pfad, Capacity-, Lizenz-, Regions- oder Betriebsgrenzen verhindern den Start.
• Alternative ohne neue Plattform — der bestehende Stack kann dieselben Kontrollregeln mit geringerem Risiko oder geringeren Kosten erfüllen.
• Review-Datum — die Entscheidung wird nach dem Proof of Value oder einer wesentlichen Plattformänderung neu bewertet.

Struktur der Grenze Map

Die Grenze Map sollte fünf verbundene Ebenen enthalten:

1. Business Governance — Owner, Steward, Definitionen, erlaubte Nutzung, Qualitätsrisiko, Certification und Lifecycle.
2. Fabric-Organisation — Tenant, Capacities, Domains, Workspaces und Item-Typen.
3. Control Implementation — Identity, Permissions, Sensitivity, Quality, Deployment und Monitoring.
4. Metadaten und Evidenz — OneLake Catalog, Purview, Lineage, Audit, Quality Results und Change Records.
5. Consumption — Semantic Models, zertifizierte Kennzahlen, Reports, Apps, Excel und weitere Konsumenten.

Jeder Handoff muss einen Decision Owner, Implementation Owner und eine Evidenzquelle benennen.

Entscheidungsregel

Fabric darf nur als Einstiegspunkt freigegeben werden, wenn die Organisation folgende Aussage treffen kann:

Fabric hostet und betreibt das erste governed Data Product, weil der bestehende Microsoft- und Power-BI-Kontext die Delivery-Reibung reduziert. Entscheidungen zu Business Verantwortung, erlaubter Nutzung, Qualität und Certification bleiben außerhalb der Plattformadministration. Die Verantwortung von OneLake Catalog und Purview ist explizit. Identity, Schutz sensibler Daten, Lineage, Semantic-Model-Governance, Deployment, Capacity und Kosten werden über den vollständigen Source-to-Consumer-Pfad validiert.

Die Plattform darf nicht allein deshalb freigegeben werden, weil sie bereits lizenziert ist, weil Power BI bereits genutzt wird oder weil eine Governance-Oberfläche vorhanden ist.

Tools

Nutze Tools zur Sammlung und Pflege von Entscheidungsevidenz.

Governance Stack Advisor

Nutze den Governance Stack Advisor, um Fabric mit dem bestehenden Stack und einer möglichen bedingten Alternative zu vergleichen.

Erwarteter Output:

• Profil des bestehenden Kontexts
• verpflichtende Governance Kontrollregeln
• Fabric-Stärken und Abhängigkeiten
• Capability- und Operating-Model-Lücken
• Alternative ohne neue Plattform
• Validierungsfragen

Architecture Fit

Nutze Architecture Fit, um Workload-, Integrations-, Identity-, Netzwerk-, Regions-, Deployment-, Capacity- und Koexistenzanforderungen zu testen.

Erwarteter Output:

• Workload Boundaries
• Source- und Nutzer-Constraints
• Zielmodell für Workspaces und Capacity
• Integrations- und Koexistenzwirkung
• Validierungsarchitektur
• Entscheidungsrisiken

Compliance Roadmap

Nutze die Compliance Roadmap, um PII-, Sensitivity-, Retention-, Access-, Audit- und Recertification-Anforderungen mit einer umsetzbaren Control-Sequenz zu verbinden.

Fabric-spezifische Arbeitsartefakte

• Canvas für den ersten governeden Use Case
• Fabric Domain- und Workspace-Register
• Verantwortung- und Stewardship-RACI
• Entra-Gruppen- und Access-Matrix
• Kontrollregel-Matrix nach Item-Typ
• personenbezogene Daten- und Sensitivity-Propagation-Map
• Verantwortungsmatrix für Fabric- und Purview-Metadaten
• Lineage Coverage Map
• Quality-Rule- und Incident-Register
• semantisches Modell-Model-Certification-Record
• Deployment- und Umgebungsregister
• Capacity- und Kostenverantwortungsnachweis
• Fabric Governance Grenze Map
• Fabric Governance Readiness Decision

Die Verfügbarkeit eines Tools ist keine Evidenz. Jeder erforderliche Control muss für die ausgewählten Item-Typen, Lizenzen, Region und den Consumption-Pfad konfiguriert, betrieben und getestet werden.

Ressourcen

Funktionen, Bezeichnungen, APIs, Lizenzierung, Preview-Status, regionale Verfügbarkeit und Einschränkungen von Microsoft Fabric und Purview müssen zum Umsetzungszeitpunkt erneut geprüft werden. Die folgenden offiziellen Quellen wurden für diesen Artikel am 29. Juli 2026 verifiziert:

• Microsoft-Fabric-Übersicht
• OneLake-Catalog-Übersicht
• Fabric-Daten mit dem OneLake Catalog governeden
• Fabric Domains
• Microsoft Purview zur Governance von Microsoft Fabric verwenden
• Microsoft Purview Data Map
• Metadaten und Lineage von Fabric in Microsoft Purview
• Lineage in Fabric
• Microsoft-Fabric-Berechtigungsmodell
• Sensitivity Labels auf Fabric Items anwenden
• Power-BI-Inhalte mit Endorsement promoten und zertifizieren
• Data Quality für Fabric Lakehouse in Microsoft Purview Unified Catalog
• Fabric Deployment Pipelines
• Microsoft-Fabric-Lizenzen verstehen
• Microsoft-Fabric-Capacity-Planung
• Kostenaspekte für Microsoft-Fabric-Workloads
• Neuerungen in Microsoft Fabric

Begriffe vor dem Lesen

• ABAC — Attribute-Based Access Kontrollregel: Zugriff über Eigenschaften wie Land, Zweck, Sensitivität oder Vertragsstatus.

Databricks kann ein starker Governance-Einstieg sein, wenn der erste governed Use Case durch engineering-intensive Verarbeitung, Streaming, Machine Learning oder AI geprägt ist. Unity Catalog ergänzt eine gemeinsame Kontrollschicht für Daten- und AI-Assets. Zu einer Governance-Grundlage wird die Plattform jedoch erst, wenn fachliche Verantwortung, Identitäten, Kataloggrenzen, Ausführungsumgebungen, Lineage-Evidenz, Quality Verantwortung und Kostenverantwortung gemeinsam betrieben werden.

Die Entscheidungsfrage lautet deshalb nicht, ob Unity Catalog einen Katalog, Lineage oder Zugriffskontrollen bereitstellt. Entscheidend ist, ob die Organisation diese Fähigkeiten in ein überprüfbares Databricks Governance Operating Model überführen kann.

Herausforderung

Plattformauswahl beginnt häufig mit einer Feature-Liste:

• Kann die Plattform Tabellen und Modelle katalogisieren?
• Kann sie Zugriffsrechte durchsetzen?
• Kann sie sensible Daten klassifizieren?
• Kann sie Lineage darstellen?
• Kann sie Batch-, Streaming- und KI-Workloads ausführen?

Diese Fragen sind notwendig, aber nicht ausreichend. Eine Plattform kann Kontrollen implementieren, ohne die fachlichen Entscheidungen dahinter zu besitzen.

Unity Catalog modelliert governed Assets als Securable Objects. Die Hierarchie beginnt beim Metastore und führt über Catalogs und Schemas zu Objekten wie Tabellen, Views, Volumes, Funktionen und Modellen. Privileges können Benutzern, Service Principals und Gruppen zugewiesen werden. Dadurch entsteht eine technisch konsistente Kontrollschicht. Sie entscheidet jedoch nicht:

• wer für den fachlichen Zweck eines Data Products verantwortlich ist;
• wer die erlaubte Nutzung genehmigt;
• wer fachliche Ebene und semantische Bedeutung festlegt;
• wer eine Quality Exception akzeptiert;
• wer entscheidet, ob ein Modell oder Feature in einem neuen Kontext verwendet werden darf;
• wer für die Workloads bezahlt, die das Asset erzeugen und nutzen.

Drei Fehler treten besonders häufig auf.

Catalog Verantwortung wird mit Data Verantwortung verwechselt

Ein Catalog Owner oder ein Principal mit MANAGE kann Plattformobjekte und Kontrollen administrieren. Diese Rolle ist nicht automatisch der verantwortliche Data Owner. Die fachliche Verantwortung bleibt für Zweck, erlaubte Nutzung, Qualitätserwartungen, Risikoakzeptanz und Ausnahmeentscheidungen verantwortlich.

Workspace-Design wird mit Governance-Design verwechselt

Ein Workspace ist eine Ausführungs- und Kollaborationsumgebung. Er ist allein keine vollständige Daten-, Residency-, Zugriffs- oder Kostengrenze. Catalogs sind standardmäßig aus den Workspaces erreichbar, die am selben Metastore hängen, sofern Workspace Bindings sie nicht einschränken. Eine belastbare Umgebungstrennung benötigt deshalb explizite Entscheidungen zu Catalog, Workspace, Identität, Privileges, Storage und Compute.

Betrieb Lineage wird mit End-to-End-Evidenz verwechselt

Unity Catalog erfasst Lineage für unterstützte Databricks-Aktivitäten. First-Mile-Ingestion außerhalb von Databricks, unmanaged Copies, externe APIs und Last-Mile-BI-Tools können außerhalb dieses Betriebsgraphen bleiben. External Lineage Metadata oder eine andere Integration ist erforderlich, wenn diese Kanten für Impact Analysis oder Audit-Evidenz relevant sind.

Die Governance-Grenze besteht aus drei unterschiedlichen Ebenen:

Die Kontrollschicht implementiert Entscheidungen. Sie darf nicht unbemerkt zum Entscheidungsverantwortlichen werden.

Ansatz

Nutze Databricks mit Unity Catalog als Governance-Einstieg, wenn der erste governed Use Case erhebliche Engineering-, Lakehouse-, Streaming- oder AI-Fähigkeiten benötigt und die Organisation die Plattformgrenzen explizit betreiben kann.

Eine positive Startentscheidung weist typischerweise die meisten der folgenden Merkmale auf:

• Der erste Use Case benötigt skalierbare Transformationen, Streaming, Feature Engineering, Modellentwicklung oder kombinierte Data-and-KI-Workflows.
• Daten- und KI-Assets sollen über ein gemeinsames Objekt- und Privilege-Modell governed werden.
• Mehrere Workspaces benötigen einen gemeinsamen Metastore und konsistenten Datenzugriff.
• Produktionsjobs können unter kontrollierten Service Principals statt unter persönlichen Identitäten laufen.
• Catalog-, Schema- und Workspace-Grenzen lassen sich aus Domain-, Environment-, Residency- und Permitted-Use-Anforderungen ableiten.
• Betrieb Lineage kann für externe Quellen und Nutzer ergänzt werden.
• Quality-Evidenz und Incident Verantwortung können jedem governed Product zugeordnet werden.
• Compute-Verbrauch kann einem Product, Team, verantwortliche Person oder Cost Center zugerechnet werden.

Databricks sollte nicht allein deshalb ausgewählt werden, weil es den breitesten Engineering-Funktionsumfang bietet. Ein einfacheres governed Warehouse, eine BI-Plattform oder eine Verbesserung des Semantic Layers kann die bessere No-new-platform-Alternative sein, wenn das erste Problem auf stabile SQL-Transformationen, vertrauenswürdiges Reporting oder Metric Governance begrenzt ist und die Organisation die zusätzliche Engineering- und AI-Betriebsfläche nicht benötigt.

Die Hierarchie vor den Objekten entwerfen

Die technische Kontrollhierarchie muss in eine betriebliche Hierarchie übersetzt werden.

Für ein regionales Deployment ist der Metastore eine zentrale Architekturentscheidung. Databricks dokumentiert einen Metastore je Betriebsregion; die Workspaces der Region werden daran angebunden. Workspaces am selben Metastore sehen denselben Catalog Namespace. Ein Workspace erzeugt daher standardmäßig keinen unabhängigen Katalog.

Workspace-Catalog Binding kann einen Catalog auf ausgewählte Workspaces beschränken und eine Bindung als Read-only definieren. Das ist für die Trennung von Development und Production nützlich, darf aber nur als eine Kontrolle im gesamten Environment Model verstanden werden.

Cross-Workspace- und Cross-Catalog-Zugriffe müssen als Entscheidungen dokumentiert werden. Sie dürfen nicht zufällig aus Default Visibility oder breiten vererbten Grants entstehen.

Fachliche Verantwortung, Administration und Custodian-Verantwortung trennen

Ein minimales Verantwortung-Modell unterscheidet mindestens fünf Verantwortungsbereiche.

In einer kleinen Organisation kann eine Person mehrere Rollen übernehmen. Die Entscheidungen müssen trotzdem unterscheidbar bleiben. Ein Catalog Owner darf einen sensiblen Use Case nicht allein deshalb freigeben, weil die Plattform ihm das Erteilen des Zugriffs erlaubt.

Effektiven Zugriff statt nur direkte Grants prüfen

Databricks kennt Benutzer, Service Principals und Gruppen als Identitäten. Account-level Groups sollten der Standard für Zugriffszuweisungen sein. Produktionsjobs und automatisierte Deployments sollten, wo praktikabel, unter Service Principals laufen.

Ein Effective-Access-Review muss mehr als ein SELECT auf einer Tabelle berücksichtigen:

effektiver Zugriff
= Account-Identität
+ Gruppenmitgliedschaften
+ vererbte Privileges
+ direkte Privileges
+ Verantwortung- oder Admin-Rechte
+ Workspace- und Catalog-Binding
+ Row-Filter- und Column-Mask-Policies
+ ausführbare Funktionen und Compute-Pfad

Der Review sollte beantworten:

• Welche Identitäten können das Objekt entdecken?
• Welche Identitäten können es lesen, verändern, taggen oder verwalten?
• Welche Gruppen liefern vererbten Zugriff?
• Welcher Service Principal schreibt Produktionsdaten?
• Kann der Workspace den Catalog erreichen?
• Verändern Row Filters oder Column Masks das Ergebnis abhängig von der Identität?
• Kann ein verantwortliche Person oder Administrator den vorgesehenen Freigabeprozess umgehen?
• Wird Zugriff entfernt, wenn eine Person die Rolle wechselt oder das Unternehmen verlässt?

Das Ziel ist keine lange Grant-Liste. Das Ziel ist erklärbarer, testbarer und widerrufbarer Zugriff.

Klassifikation und Policy als governed Workflows behandeln

Unity Catalog unterstützt Tags auf Securable Objects, Governed Tags mit kontrollierten Werten und Berechtigungen, automatisierte Data Classification, tabellenspezifische Row Filters und Column Masks sowie tagbasierte Attribute-based Policies.

Diese Mechanismen benötigen getrennte Verantwortung-Entscheidungen:

• Der Data Owner genehmigt die Permitted-Use-Regel.
• Der Steward verwaltet Klassifikation und Review Status.
• Security oder Privacy definiert Richtlinie Standards.
• Das Plattformteam implementiert wiederverwendbare Richtlinie Functions und Guardrails.
• Engineering verifiziert das Verhalten auf dem unterstützten Compute.
• Audit- oder kontrollverantwortliche Person prüfen Evidenz und Ausnahmen.

Automatisierte Klassifikation ist Evidenz, keine finale Genehmigung. Ein erkannter PII-Tag kann einen Control Workflow auslösen, bestimmt aber weder rechtmäßigen Zweck noch Retention, Consent oder fachliche Kritikalität.

Tagbasierte Policies können bei skalierbaren Kontrollen die objektweise Administration reduzieren. Table-level Filters und Masks können für isolierte Fälle weiterhin sinnvoll sein. Die Entscheidung muss Scope, Policy Verantwortung, Betrieb Requirements, Performance, Testbarkeit und aktuelle Cloud-spezifische Verfügbarkeit berücksichtigen.

Lineage durch externe Evidenz vervollständigen

Die Evidenzkette eines governed Products sollte Folgendes abdecken:

Quelle
→ Ingestion
→ Transformation oder Streaming
→ governed Tabelle oder Feature
→ Modell oder analytisches Product
→ BI-, API- oder AI-Consumer

Für jeden Schritt werden mindestens benötigt:

• Code- und Deployment-Version;
• verantwortlicher verantwortliche Person;
• technischer Betreiber;
• Klassifikation;
• Access Richtlinie;
• Lineage;
• Quality Tests;
• Incident verantwortliche Person;
• Kostenzuordnung;
• Approval Record.

Unity Catalog kann unterstützte Betrieb Lineage innerhalb von Databricks automatisch erfassen. External Metadata und External Lineage können vorgelagerte Systeme und nachgelagerte Consumer ergänzen, die nicht automatisch beobachtet werden. Diese Beziehungen benötigen weiterhin Verantwortung und Pflege. Eine manuell angelegte Lineage-Kante, die nie überprüft wird, ist keine verlässliche Evidenz.

Audit Logs und System Tables ergänzen die operative Evidenz, beantworten aber unterschiedliche Fragen:

• Lineage zeigt Beziehungen und Flüsse.
• Audit-Evidenz zeigt Aktionen und Zugriffsereignisse.
• Quality-Evidenz zeigt, ob das Product vereinbarte Kontrollen erfüllt hat.
• Change Records zeigen, welche genehmigte Version deployed wurde.
• Incident Records zeigen, wer bei einem Evidenzfehler reagiert hat.

Unmanaged Extracts und externe Consumer müssen als explizite Gaps dargestellt werden, bis sie integriert, eingeschränkt oder über eine befristete Ausnahme akzeptiert sind.

Compute und Kosten als Teil der Governance behandeln

Engineering- und AI-Plattformen erzeugen eine zusätzliche Governance-Dimension: Auch die Ausführung besitzt Owner, Policies und Kosten.

Das Operating Model sollte definieren:

• erlaubte Compute-Typen je Environment;
• Einsatz von Standard, Dedicated oder Serverless, soweit passend;
• unterstützte Betriebs- und Library-Patterns;
• Identitäten für Produktionsjobs;
• Netzwerk- und External-Access-Kontrollen;
• Resource Tags und Cost-Center-Regeln;
• Budgetgrenzen und Eskalation;
• Verantwortung für idle, fehlgeschlagene oder ausufernde Workloads;
• Aufbewahrung von Evidenz für Jobs, Pipelines, Modelle und Endpoints.

Serverless kann die Infrastrukturadministration reduzieren, entfernt aber nicht die Verantwortung. Aktuelle Serverless Limitations, unterstützte Sprachen, Netzwerkverhalten, Policy Support und regionale Verfügbarkeit müssen für Cloud und Workload geprüft werden.

Databricks Billing System Tables, darunter system.billing.usage, können Nutzung Ressourcen, Identitäten, Produkten und Custom Tags zuordnen. Diese Evidenz wird erst nutzbar, wenn Tagging Model und Cost Owner vor dem Production Deployment verpflichtend sind.

Checkliste

Nutze die Readiness Checkliste, bevor Databricks als Einstieg freigegeben wird.

Dokumentiere die Entscheidung mit dem Tool Governance Starting-Point Decision.

Ein Readiness Result sollte eines von vier expliziten Ergebnissen verwenden:

• Bereit für den Proof of Value: Grenzen, Owner und Validierungstests sind ausreichend definiert.
• Bedingte Readiness: Databricks ist plausibel, aber benannte Gaps müssen im Proof of Value geschlossen werden.
• Blockiert: Ein wesentliches Residency-, Identity-, Kontrollregel-, Operating-Capacity- oder Kostenproblem verhindert einen verantwortbaren Start.
• No-new-platform-Alternative: Das erste governed Ergebnis kann sicherer mit der bestehenden Plattform und einer engeren Governance-Maßnahme erreicht werden.

Artefakt

Das erforderliche Artefakt ist ein Databricks Governance Operating Model, kein allgemeines Architekturdiagramm.

Dokumentiere mindestens die folgenden Felder:

decision:
  firstGovernedUseCase:
  businessOutcome:
  targetConsumers:
  criticality:
  cloud:
  region:
  accountAndMetastoreDesign:
  catalogAndSchemaBoundaries:
  workspaceAndEnvironmentModel:
  dataOwner:
  dataSteward:
  technicalOwner:
  identitySource:
  accountGroups:
  productionServicePrincipals:
  privilegeModel:
  classificationTaxonomy:
  governedTags:
  rowAndColumnPolicyModel:
  policyOwner:
  lineageCoverage:
  externalLineageGaps:
  auditEvidence:
  qualityTests:
  qualityThresholds:
  incidentOwner:
  computeModel:
  costAttribution:
  budgetOwner:
  deploymentAndChangeModel:
  unresolvedGaps:
  validationTests:
  decisionOutcome:
  noRegretNextStep:
  reviewDate:

Das Operating Model weist außerdem die wiederkehrenden Verantwortungen zu.

Verantwortung muss Personalwechsel überstehen. Nutze Gruppen, Service Principals, managed Deployment Processes und Review Dates statt das Wissen eines einzelnen Administrators.

Tools

Ein Proof of Value sollte Governance-Verhalten testen, nicht nur Workload Performance.

1. Grenze Test

Erzeuge einen Development- und einen Production Catalog. Binde den Production Catalog nur an den genehmigten Production Workspace, definiere den vorgesehenen Access Mode und verifiziere den verweigerten Zugriff aus einem nicht gebundenen Workspace.

2. Identity and Privilege Test

Provisioniere Account Groups und einen Production Service Principal. Erteile Zugriff über Gruppen, führe den Production Workload über den Service Principal aus und dokumentiere den effektiven Zugriff eines Developers, Consumers, Stewards und Administrators.

3. Policy and Classification Test

Wende einen Governed Classification Tag auf sensible Spalten an. Implementiere die ausgewählte Row- oder Column-Policy, teste positive und negative Fälle und dokumentiere, wer die Regel genehmigt, implementiert und verändern kann.

4. Evidence Chain Test

Verfolge eine Quelle durch Ingestion, Transformation, ein governed Product und einen externen Consumer. Ergänze External Lineage für fehlende Kanten, verknüpfe die deployed Code Version, füge Quality Results hinzu und prüfe Audit-Evidenz.

5. Failure and Incident Test

Erzwinge einen Quality-Threshold-Verstoß oder einen Access-Policy-Fehler. Prüfe, ob der Workload wie vorgesehen fehlschlägt oder quarantined wird, ob der richtige Owner informiert wird und ob Remediation und Ausnahmeentscheidung dokumentiert werden.

6. Cost Accountability Test

Tagge den Workload mit Product-, Environment- und Cost-Center-Metadaten. Frage Billing-Evidenz ab, gleiche sie mit dem verantwortlichen Budget Owner ab und teste die Eskalationsgrenze.

Infrastructure as Code sollte dort eingesetzt werden, wo es Wiederholbarkeit für Metastores, Workspace Assignment, Catalogs, Grants, Policies und Compute Configuration verbessert. Automatisierung implementiert genehmigte Entscheidungen; sie darf Verantwortung oder Permitted-Use-Regeln nicht erfinden.

Ressourcen

Die folgenden offiziellen Databricks-Ressourcen wurden für diesen Entscheidungsartikel geprüft. Product Behavior, Cloud Support, Preview Status, Licensing und regionale Verfügbarkeit müssen für das konkrete Deployment erneut validiert werden.

• What is Unity Catalog?
• Unity Catalog securable objects
• Unity Catalog privileges reference
• Create a Unity Catalog metastore
• Workspace-catalog binding
• Identity best practices
• Governed tags
• Data Classification
• Row filters and column masks
• Create and manage ABAC policies
• Lineage in Unity Catalog
• External lineage
• Audit log system table
• Monitor costs using system tables
• Serverless compute limitations
• Databricks pricing and platform tiers

Begriffe vor dem Lesen

• RBAC — Role-Based Access Kontrollregel: Zugriff über Rollen wie Steward, Analyst, Admin oder Auditor.

Herausforderung

Snowflake kann eine starke Operating Surface für SQL Analytics, Warehouse-zentrierte Data Products und kontrolliertes Data Sharing bilden. Access-Control-Modell, Tags, Masking Policies, Row Access Policies, Secure Views, Sharing-Mechanismen, Account-Usage-Evidenz und Warehouse Controls können ein konsistentes Governance-Design technisch umsetzen.

Sie erzeugen dieses Design nicht automatisch.

Ein Snowflake Object besitzt einen Owner, aber Object Verantwortung ist ein administratives Privileg und kein Nachweis für verantwortliche Data Verantwortung. Ein Tag kann eine Klassifizierung dokumentieren, entscheidet aber nicht über erlaubten Zweck, Permitted Use, Retention oder Ausnahmeakzeptanz. Ein Secure View oder Share kann die Provider-seitige Bereitstellung kontrollieren, definiert jedoch nicht, was der Consumer nach dem Zugriff mit abgeleiteten Daten tun darf.

Die relevante Entscheidungsfrage lautet deshalb nicht:

Besitzt Snowflake Governance- und Security-Funktionen?

Sondern:

Kann Snowflake die Entscheidungen für das erste governede SQL Data Product durchsetzen und gleichzeitig verantwortliche Verantwortung, testbaren Zugriff, kontrolliertes Sharing, Lifecycle-Evidenz und Kostenverantwortung erhalten?

Snowflake ist ein plausibler Governance-Einstieg, wenn der erste governede Use Case von SQL Transformation, Warehouse Consumption oder governed Data Exchange geprägt ist und die Organisation folgende Grenzen explizit betreiben kann:

• Business Purpose und Data Verantwortung
• Account-, Cloud-, Region- und Environment-Design
• Role Hierarchy und Privilege Administration
• Human- und Service Identities
• Klassifizierungs- und Tag Governance
• Masking-, Row-Access- und Object-Access-Richtlinien
• Secure Views, Partnerfreigaben und Nutzer-Use-Grenzen
• Lineage, Access History und Change Nachweis
• Retention, Recovery und Product Lifecycle
• Warehouse-, Budget- und Kostenverantwortung

Drei wiederkehrende Fehler führen dazu, dass eine technisch korrekte Snowflake-Implementierung schwach governed bleibt.

Object Verantwortung wird mit Data Verantwortung verwechselt

Das Privileg OWNERSHIP ermöglicht einer Rolle, ein Snowflake Object zu kontrollieren und Zugriff entsprechend dem Access-Control-Modell zu übertragen oder zu vergeben. Dadurch ist die Rolle operativ mächtig. Sie ist damit nicht automatisch verantwortlich für Business Purpose, Definition, Criticality, Quality Expectation, Permitted Use oder Risk Acceptance der Daten.

Der verantwortliche Data Owner kann eine Policy freigeben, ohne Object Verantwortung zu besitzen. Umgekehrt kann eine Plattformrolle Object Verantwortung halten, ohne eine neue Business-Nutzung genehmigen zu dürfen. Das Operating Model muss diese Verantwortungen trennen, selbst wenn eine Person vorübergehend mehrere Rollen ausübt.

Klassifizierung wird mit Durchsetzung verwechselt

Snowflake Tags können Metadaten dokumentieren und in tag-basierten Masking- oder Row-Access-Designs verwendet werden. Sensitive Data Classification kann beim Erkennen potenziell sensibler Spalten unterstützen. Diese Mechanismen reduzieren manuelle Arbeit, aber Klassifizierung benötigt weiterhin Freigabe, Policy Selection, Effective-Access-Tests und Review.

Eine als personenbezogen getaggte Spalte ist nicht allein durch den Tag geschützt. Schutz besteht erst, wenn die freigegebene Policy zugeordnet ist, die vorgesehenen Identity- oder Attributbedingungen korrekt auswertet, über die realen Query Paths das erwartete Ergebnis liefert und über Änderungen hinweg governed bleibt.

Secure Sharing wird mit Downstream Control verwechselt

Secure Data Sharing kann ausgewählte Snowflake Objects bereitstellen, ohne die gespeicherten Provider-Daten in den Consumer Account zu kopieren. Imported Databases sind read-only, und Secure Views werden empfohlen, wenn der Provider Struktur oder Zeilen der Bereitstellung begrenzen muss.

Diese Provider-seitige Kontrolle beseitigt die Downstream-Verantwortung nicht. Ein Consumer kann den erlaubten Zugriff entsprechend seinen Privilegien und Tools für lokale abgeleitete Assets, Exporte oder analytische Ergebnisse nutzen. Der Provider benötigt deshalb eine dokumentierte Permitted-Use-Grenze, einen Consumer Owner, eine Retention Rule, einen Incident Contact, einen Review-Prozess und einen getesteten Revocation-Pfad.

Die Plattform-Controls müssen mit verantwortlichen Entscheidungen verbunden sein. Snowflake setzt den Control technisch um; das Operating Model liefert die Autorität.

Ansatz

Nutze Snowflake als Governance-Einstieg, wenn SQL-zentrierte Data Products, kontrolliertes Sharing und Policy Durchsetzung zentral sind und Business Verantwortung, Role Design, Klassifizierung, Lifecycle, Evidenz und Kostenverantwortung explizit zugeordnet werden.

Behandle das Ergebnis als begrenzte Einstiegspunkt-Entscheidung für einen ersten governeden Use Case. Nutze sie nicht als Beweis, dass Snowflake zur universellen Plattform für jedes Engineering-, BI-, Streaming-, AI- oder Operational-Workload werden muss.

1. Mit dem governeden SQL- oder Sharing-Use-Case beginnen

Wähle ein konkretes Produkt statt eines abstrakten Plattformprogramms. Die erste Validierung muss identifizieren:

• unterstützte Business-Entscheidung oder Prozess
• autoritative Quelle
• fachliche Ebene des Produkts und Refresh-Anforderung
• SQL-Transformation- und Warehouse-Bedarf
• interne und externe Konsumenten
• sensible Felder und erlaubte Zwecke
• erwartetes Sharing-Muster
• Quality Expectations und Incident-Pfad
• Retention- und Recovery-Anforderung
• erwartetes Compute-Profil und Cost verantwortliche Person

Snowflake ist eher der richtige Einstieg, wenn der Use Case ein governed relationales Modell, wiederverwendbare SQL Transformationen, getrennten Compute, stabile analytische Consumption oder kontrollierte Cross-Account-Verteilung benötigt.

Der Current Stack kann die bessere Option bleiben, wenn nur eine kleine Reporting-Verbesserung erforderlich ist, Verantwortung und Prozesse die eigentlichen Lücken darstellen oder ein neuer Account und ein neues Operating Model mehr Komplexität als Governance-Nutzen erzeugen würden.

2. Account-, Region- und Environment-Grenzen zuerst entwerfen

Der Snowflake Account ist eine wesentliche Security-, Administrations-, Commercial- und Evidenzgrenze. Vor dem Anlegen von Product Schemas sind zu dokumentieren:

• Cloud Platform und unterstützte Region
• Residency- und rechtliche Anforderungen
• für die Kontrollregeln erforderliche Snowflake Edition
• Organization- und Account-Modell
• Trennung von Development, Test und Production
• Netzwerk- und Private-Connectivity-Anforderungen
• Replication-, Failover- und Cross-Region-Sharing-Erwartungen
• Identity-Provider- und Provisioning-Modell
• Plattformadministration und Emergency Access
• Account-weites Monitoring, Budgets und Nachweis Retention

Feature-Parität über Editions, Cloud Platforms und Regionen darf nicht vorausgesetzt werden. Die aktuelle Snowflake-Dokumentation ordnet Masking Policies, Row Access Policies, Sensitive Data Classification und die Account-Usage-View ACCESS_HISTORY der Enterprise Edition oder höher zu. Extended Time Travel bis zu 90 Tagen benötigt ebenfalls Enterprise Edition. Private Connectivity und bestimmte Funktionen für regulierte Workloads benötigen Business Critical oder höher. Edition, Region und Account-Typ gehören deshalb in die Readiness-Entscheidung und dürfen nicht als späteres Procurement-Detail behandelt werden.

Environment Separation kann getrennte Accounts, Databases, Schemas, Roles, Warehouses oder eine kontrollierte Kombination nutzen. Das richtige Design hängt von erforderlicher Isolation, Deployment-Pfad, Recovery-Modell und Evidenzgrenze ab. Eine Naming Convention ist keine Environment Isolation.

3. Business Accountability von Snowflake Administration trennen

Definiere die Rollen vor den Grants.

In einem kleinen Team kann eine Person mehrere Verantwortungen übernehmen, aber jede Entscheidung muss sichtbar bleiben. Eine Rolle, die SELECT vergeben kann, darf nicht stillschweigend zur Rolle werden, die den Business Purpose freigibt.

4. Die Role Hierarchy nach Duties und Products aufbauen

Snowflake unterstützt Role-Based Access Control, Role Hierarchies und Database Roles. Privileges werden auf Securable Objects vergeben und über die Role Hierarchy vererbt. Direkte User Grants sind über User-Based Access Control möglich, aber RBAC bleibt die empfohlene Production-Grundlage.

Eine praktikable Hierarchie unterscheidet üblicherweise:

• streng kontrollierte Account Administration
• Security und Grant Administration
• Platform Operations
• Database- und Schema-Administration
• Richtlinie Administration
• Engineering- und Deployment-Rollen
• produktspezifische Read-, Write- und Operate-Rollen
• Nutzer Roles
• Audit- und Nachweis-Review-Rollen

Database Roles können Privileges innerhalb einer Database bündeln und an Account Roles vergeben werden. Sie sind für Product-scoped Access nützlich, aber Vererbung, Sharing-Verhalten und Einschränkungen müssen für das geplante Design getestet werden.

Für jedes governede Product ist Effective Access zu prüfen und nicht nur die sichtbaren Direct Grants:

effective access
= User oder Service Identity
+ zugewiesene Account Roles
+ aktive Secondary Roles
+ Database-Role-Inheritance
+ Object Verantwortung und administrative Privileges
+ Future Grants
+ Auswertung von Masking und Row Access
+ Secure-View- oder Share-Grenze
+ Warehouse- und Execution-Pfad

Das Review muss zeigen, wer das Produkt entdecken, abfragen, verändern, freigeben, besitzen, klassifizieren, mit Policies versehen, teilen und administrieren kann. Es muss außerdem zeigen, wie Zugriff nach Rollenwechsel, Vertragsende oder Exception Expiry entfernt wird.

5. Kontrollierte Service Identities einsetzen

Production Ingestion, Transformation, Orchestration, BI und Data-Sharing-Prozesse dürfen nicht von persönlichen Identities abhängen.

Snowflake User Objects unterscheiden menschliche und serviceorientierte Nutzung. Aktuelle Authentifizierungsoptionen umfassen Federated Authentication für Personen und stärkere programmatische Muster wie Workload Identity Federation, Key-Pair Authentication und Programmatic Access Tokens für unterstützte Service-Szenarien. Snowflake schafft außerdem passwortbasierten Zugriff für Service Users ab; neue Designs sollten daher keine langlebigen Service-Passwörter als Standard erzeugen.

Für jede Service Identity sind zu dokumentieren:

• Workload und verantwortlicher technischer Betreiber
• User Type und Authentication Method
• zugewiesene Role und Least-Privilege-Grants
• erlaubte Netzwerk- oder Identity-Provider-Grenze
• Warehouse und Resource Limits
• Secret- oder Credential-Lifecycle, falls relevant
• Non-interactive Monitoring
• Rotation, Revocation und Break-glass Process
• Deployment- und Change verantwortliche Person

Eine Service Identity ist nicht nur ein technisches Credential. Sie ist ein operativer Actor, dessen Zugriff, Kosten und Änderungen zugeordnet werden müssen.

6. Klassifizierung mit Policies und Zugriff verbinden

Die governede Policy Chain muss explizit sein:

Business Classification
→ freigegebener Metadata Tag
→ Policy Selection
→ Role- oder Attribute Condition
→ Masking, Row Restriction oder Object Access
→ Effective-Access-Test
→ Audit Evidence
→ Recertification

Nutze Tags für governede Metadaten wie Sensitivity, PII Category, Business Domain, Owner, Retention Class, Product Status oder Cost Center. Kontrolliere, wer diese Tags erstellen, verändern und zuweisen darf. Wenn Edition und Design es erlauben, können Tag-based Masking oder Tag-based Row Access die objektweise Policy Administration reduzieren.

Das Policy Design muss weiterhin definieren:

• Richtlinie verantwortliche Person
• freigegebene Business Rule
• Umfang und unterstützte Data Types
• Role-, Attribute- oder Mapping-Table-Condition
• Verhalten für privilegierte und nicht privilegierte Identities
• Verhalten bei null, unknown und neuen Classification Values
• Richtlinie Priority und Konflikte
• Deployment- und Rückbau-Methode
• Test Identities und erwartete Ergebnisse
• Exception Route und Expiry
• Evidenz- und Recertification-Trigger

Eine direkt zugewiesene Masking Policy kann Vorrang vor einer Tag-based Policy haben. Eine Row Access Policy wird vor Masking Policies ausgewertet, wenn beide gelten. Diese Interaktionen müssen Teil der Tests sein; andernfalls kann das Metadatenmodell korrekt aussehen, während das Query Result falsch ist.

Temporäre Ausnahmen benötigen einen verantwortlichen Owner, expliziten Zweck, engeren Scope, Expiry, Evidenz und Review. Dauerhafte breite Bypass Roles dürfen nicht verwendet werden, um ungelöstes Policy Design zu umgehen.

7. Secure Views und Data Sharing als Verträge governen

Nutze ein Provider-to-Consumer-Modell und behandle einen Share nicht nur als technischen Endpoint.

Auf der Provider-Seite werden dokumentiert:

• autoritative governede Quelle
• freigegebenes Data Product und fachliche Ebene
• verwendeter Secure View, Shared Object oder Listing
• bereitgestellte Felder, Zeilen und Historie
• Permitted Purpose
• Klassifizierungs- und Richtlinie-Verhalten
• Freshness- und Quality-Erwartung
• Retention- und Revocation-Regel
• Sharing Owner und Support Contact

Auf der Consumer-Seite werden dokumentiert:

• benannter Account, Organization oder Business Domain
• freigegebener Purpose und Nutzer verantwortliche Person
• lokale Rollen und Access-Review-verantwortliche Person
• Downstream-Copy- und Export-Grenze
• Retention- und Deletion-Verpflichtung
• Incident- und Breach-Contact
• Beschränkungen für Derived Products und Onward Sharing
• Review- und Termination-Datum

Cross-Grenze Evidence umfasst Vertrag oder Freigabe, Lineage, Access Evidence, Usage Review, Change Notice und Revocation Test.

Secure Data Sharing vermeidet Provider-seitige Datenkopien, ersetzt aber keine Permitted-Use-Governance. Imported Data ist in der Imported Database read-only; dies verhindert für sich allein nicht, dass ein Consumer lokale abgeleitete Objects oder Exporte erstellt. Die fachliche und technische Grenze muss deshalb in beiden Accounts getestet werden.

Für sensible Daten empfiehlt Snowflake Secure Views oder Secure UDFs statt direktem Sharing von Base Tables. Durch Masking oder Row Access Policies geschützte Daten können mit unterstützten Database-Role-Mustern geteilt werden. Direct-Share-Restrictions können außerdem gelten, wenn Provider- und Consumer-Accounts unterschiedliche Security- oder Compliance-Level besitzen. Diese Bedingungen sind vor der Freigabe des Shares zu validieren.

Cross-Region- oder Cross-Cloud-Verteilung erzeugt zusätzliche Fragen zu Replication, Auto-Fulfilment, Residency, Latency und Kosten. Ein Same-Region-Direct-Share-Design darf nicht als identisch für andere Regionen oder Cloud Platforms angenommen werden.

8. Evidenz über eine sichtbare Policy Definition hinaus aufbauen

Eine Policy Definition ist Configuration Evidence. Governance benötigt zusätzlich den Nachweis, dass der Control freigegeben, deployed, wirksam und reviewed wurde.

Das Evidence Package kombiniert:

• Verantwortung- und Steward-Records
• Object- und Role-Grants
• Tag Assignments und Classification State
• Richtlinie Definitions und Richtlinie References
• Effective-Access-Test-Results
• Query und Access History
• Login- und Authentication Nachweis
• Object-, Schema- und Deployment-Change-Records
• Transformation und Source Lineage
• Data-Quality-Results und Incidents
• Partnerfreigabe Configuration und Nutzer Reviews
• Warehouse Usage und Cost Attribution
• Exceptions, Expiry und Recertification

Die View SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY liefert detaillierte Access Evidence für unterstützte erfolgreiche Aktivitäten und hält Records 365 Tage mit dokumentierter Latenz vor. Sie darf nicht als einzige Audit-Quelle behandelt werden. Fehlgeschlagene Zugriffsversuche, Authentication Activity, Grant Changes, Deployment Evidence und externe Consumer Actions benötigen weitere Views, Logs oder Operating Records.

Nutze POLICY_REFERENCES und zugehörige Account-Usage- oder Organization-Usage-Views, um Policy Associations zu identifizieren. Nutze begrenzte Queries und explizite Retention-Entscheidungen, wenn Evidenz länger als native History Windows aufbewahrt werden muss.

Lineage muss den vollständigen Product Path abdecken:

Quelle
→ Load oder Ingestion
→ Transformation
→ governede Table oder View
→ Shared oder Semantic Product
→ BI-, API- oder externer Consumer

Snowflake kann Object- und Access Evidence innerhalb seiner Grenze bereitstellen. Externe Ingestion, Orchestration, BI Measures, Exporte und Consumer-seitige Derivatives benötigen gegebenenfalls Metadata Integrations oder separate Records. Markiere diese Kanten als Evidenzlücken, bis sie kontrolliert oder explizit akzeptiert wurden.

9. Retention, Recovery und Lifecycle getrennt definieren

Data Retention ist nicht eine einzelne Einstellung.

Der Product Lifecycle unterscheidet:

• Business-Retention-Anforderung
• Active-Data-Retention
• Time-Travel-Periode
• Fail-safe-Verhalten
• Backup- oder Disaster-Recovery-Anforderung
• Verwendung temporärer und transienter Objects
• Beendigung geteilter Daten
• Retention von Audit Nachweis
• Legal Hold oder Deletion Obligation
• Product Deprecation und Nutzer Migration

Snowflake Standard Time Travel beträgt einen Tag. Enterprise Edition kann Time Travel für unterstützte Objects auf bis zu 90 Tage erweitern. Fail-safe ist ein Best-Effort-Recovery-Service und kein Ersatz für user-controlled Historical Access oder eine fachliche Backup Policy. Temporary und Transient Tables besitzen unterschiedliche Recovery-Eigenschaften und dürfen nicht nur zur Reduzierung von Storage Cost für autoritative langlebige Daten verwendet werden.

Für jedes governede Product sind Object Types, Retention Parameters, Recovery Test, Deletion Workflow und Owner zu dokumentieren. Ein Retention Tag ohne technische Lifecycle Action ist Metadata und kein Durchsetzung.

10. Warehouses und Kosten verantwortlich machen

Snowflake trennt Storage und Compute über Virtual Warehouses. Dadurch wird Compute Assignment zur Governance-Entscheidung.

Für jedes Warehouse sind zu definieren:

• Purpose und governede Workloads
• Environment
• Owner und Support Team
• erlaubte Roles und Service Identities
• Size, Scaling und Auto-suspend Richtlinie
• Concurrency und Workload Isolation
• Resource Monitor oder Budget
• Cost Center und Product Attribution
• Alert Thresholds und Escalation
• Change- und Review-Prozess

Resource Monitors können Warehouse Credit Consumption verfolgen und bei definierten Schwellen benachrichtigen oder zugewiesene Warehouses suspendieren. Budgets können breitere unterstützte Credit Usage überwachen, und Custom Budget Actions können Reaktionen automatisieren. Diese Funktionen bestimmen nicht, wer zahlen soll oder welches Business Result die Kosten rechtfertigt. Cost Allocation Tags, Warehouse Verantwortung und Product-level Accountability müssen durch das Operating Model definiert werden.

Vermeide ein breites Warehouse für nicht zusammengehörende Products, wenn dadurch Cost Attribution, Workload Isolation oder Incident Verantwortung unmöglich werden. Vermeide ein Warehouse pro kleinem Object, wenn der Betriebsaufwand den Control-Nutzen übersteigt. Nutze die kleinste Grenze, die erklärbare Access-, Performance- und Cost-Evidenz erzeugt.

Checkliste

Nutze diese Checkliste, bevor Snowflake als Governance-Einstieg freigegeben wird.

Ausgangskontext

• Erster governed Use Case, Business-Entscheidung, fachliche Ebene und Konsumenten sind benannt.
• SQL-, Warehouse- oder governed-Sharing-Bedarf ist für den Use Case wesentlich.
• Die Current-Stack-Alternative wurde bewertet.
• Cloud, Region, Edition und Account-Typ wurden validiert.
• Residency-, Netzwerk- und regulierte Workload-Anforderungen sind dokumentiert.

Verantwortung und Operating Model

• Data Owner und Data Steward sind benannt.
• Object Verantwortung ist von Business Accountability getrennt.
• Verantwortungen für Security, Platform, Engineering, Sharing und FinOps sind zugeordnet.
• Exception Approval und Escalation sind definiert.
• Review- und Recertification-Daten sind gesetzt.

Identity und Access

• Die Role Hierarchy ist dokumentiert und getestet.
• Database Roles, Future Grants und Verantwortung Powers sind in Effective-Access-Reviews enthalten.
• Production Workloads nutzen kontrollierte Service Identities.
• Authentication- und Network Kontrollregeln passen zu Human- und Service-Use-Cases.
• Joiner-, Mover-, Leaver- und Revocation-Pfade sind getestet.

Klassifizierung und Policy

• Classification Model und kontrolliertes Tag Vocabulary sind freigegeben.
• Tag Administration und Assignment Rights sind beschränkt.
• Masking, Row Access und Object Access sind mit verantwortlichen Entscheidungen verbunden.
• Richtlinie Precedence, Bypass Conditions und unsupported Paths sind getestet.
• Exceptions besitzen verantwortliche Person, Evidenz, Expiry und Review.

Sharing und Downstream Use

• Provider- und Nutzer verantwortliche Person sind benannt.
• Regeln für Permitted Use, Copy, Export, Retention und Onward Sharing sind explizit.
• Secure Views oder vergleichbare governede Objects stellen nur freigegebene Daten bereit.
• Cross-Account-Richtlinie-Verhalten ist getestet.
• Change Notice, Usage Review und Revocation Tests sind definiert.

Evidenz, Lifecycle und Kosten

• Access-, Authentication-, Grant-, Richtlinie-, Lineage-, Quality- und Change-Evidenz wird aufbewahrt.
• Native History Windows und Latenzen sind verstanden.
• Time Travel, Fail-safe, Backup und Deletion werden nicht vermischt.
• Warehouses besitzen verantwortliche Person, Limits, Monitoring und Cost Attribution.
• Der Proof of Value enthält Access Denial, Richtlinie Change, Incident und Revocation-Szenarien.

Artefakt

Das finale Deliverable ist eine Snowflake Policy and Control Map plus Readiness-Entscheidung.

Dokumentiere das Ergebnis mit dem Tool Governance Starting-Point Decision.

Snowflake Policy and Control Map

Erstelle eine Zeile für jede governede Entscheidung und jeden Durchsetzung-Pfad.

Verpflichtende Readiness-Felder

Der Decision Record muss enthalten:

• erster governed Use Case
• Account-, Region- und Environment-Modell
• Data Owner und Steward
• Role Hierarchy und Service Identities
• Classification- und Tag-Modell
• Masking- und Row-Access-Richtlinie-Design
• Sharing- und Permitted-Use-Grenze
• Lineage- und Audit-Evidenz
• Retention und Lifecycle
• Warehouse- und Kostenverantwortung
• Gaps und Proof-of-Value-Tests

Readiness-Ergebnisse

Wähle ein explizites Ergebnis.

Ready

Der erste Use Case kann End-to-End governed werden, erforderliche Capabilities und Edition sind verfügbar, Verantwortung ist zugeordnet, Effective Access ist testbar, Sharing-Grenzen sind freigegeben und Evidenz kann aufbewahrt werden.

Conditional

Snowflake ist der bevorzugte Einstiegspunkt, aber benannte Bedingungen müssen vor Production erfüllt werden, zum Beispiel Enterprise-Edition-Entscheidung, Role Redesign, Service-Identity-Migration, Consumer Contract, Lineage Integration oder Cost-Control-Setup.

Blocker

Ein verpflichtender Control kann aktuell nicht umgesetzt oder betrieben werden. Beispiele sind ungelöste Residency, fehlende verantwortliche Verantwortung, nicht unterstützte regionale Capability, nicht freigegebene Sensitive-Data-Nutzung, unvollständige Consumer Accountability oder kein nachhaltiger Platform Support.

Current-Stack-Alternative

Die bestehende Umgebung kann den ersten Use Case mit weniger organisatorischer Reibung erfüllen, oder die eigentlichen Lücken liegen in Verantwortung, Metadaten und Prozessen statt im Platform Durchsetzung.

Setze für jedes Ergebnis ein Review-Datum. Eine Readiness-Entscheidung ohne Review Trigger wird zu veralteter Plattformdoktrin.

Tools

Governance Stack Advisor

Nutze den Governance Stack Advisor, um Snowflake mit Fabric, Databricks, BigQuery und der Current-Stack-Option anhand derselben Governance-Evidenzkategorien zu vergleichen.

Erwarteter Output:

• erster governed Use Case
• Mandatory Kontrollregeln
• Organizational Fit
• Plattform- und Edition-Fragen
• Operating-Model-Gaps
• Validation Plan

Architecture Fit

Nutze Architecture Fit, um Account Topology, Cloud und Region, Data Movement, Integration, Network, Workload, Recovery und Cost Boundaries zu bewerten.

Erwarteter Output:

• Account- und Environment-Modell
• Source- und Nutzer-Integration-Map
• Residency- und Network Constraints
• Warehouse- und Workload-Grenzen
• Migration- oder Coexistence-Impact
• technischer No-Regret Next Step

Die Tools strukturieren Evidenz. Sie genehmigen weder Purpose noch Verantwortung, Access oder Sharing.

Ressourcen

Validiere vor der Implementierung die ausgewählte Cloud, Region, Edition und den aktuellen Release-Status. Snowflake Capabilities ändern sich kontinuierlich, und bestimmte Governance Controls sind editionsabhängig.

Access Control und Identity

• Overview of Access Kontrollregel
• Access control best practices
• Access control privileges
• Database roles and role hierarchies
• User management
• Overview of Snowflake authentication
• Authentication policies
• Workload identity federation

Klassifizierung und Policies

• Introduction to object tagging
• Sensitive data classification
• Dynamic Data Masking
• Row access policies
• Tag-based masking policies
• Tag-based row access policies
• POLICY_REFERENCES

Sharing, Evidenz und Lifecycle

• About Secure Data Sharing
• Use secure objects to control data access
• Partnerfreigabe data protected by a policy
• Direct share restrictions
• Partnerfreigabe data across regions and cloud platforms
• ACCESS_HISTORY
• Snowflake Time Travel
• Fail-safe
• Backups

Editions, Regionen und Kosten

• Snowflake editions
• Supported cloud regions
• Working with resource monitors
• Monitor credit usage with budgets
• Object tags for resource usage

Begriffe vor dem Lesen

• Transferprüfung — Transfer Impact Assessment: Prüfung, ob ein Datentransfer in ein Drittland mit Schutzmaßnahmen vertretbar ist.

Herausforderung

BigQuery kann ein starker Governance-Einstieg sein, wenn die vorhandene Landschaft GCP-nativ ist und der erste governede Use Case auf serverloser analytischer Verarbeitung, governeden Datasets, SQL Products, Data Sharing oder BI Consumption basiert. Google Cloud stellt dafür eine breite Control Surface bereit: Resource Hierarchy, BigQuery Datasets und Objects, IAM, Row- und Column-Level Controls, Data Masking, Audit Logs, Knowledge Catalog, Lineage, Data Quality, Reservations und Service Perimeters.

Diese Fähigkeiten entfernen keine Governance-Entscheidungen. Serverless Operation reduziert Infrastrukturadministration; sie entscheidet nicht über Business Purpose, Data Verantwortung, Permitted Use, Residency, Export Boundaries, Incident Verantwortung oder Kostenverantwortung.

Die relevante Frage lautet deshalb nicht:

Kann BigQuery analytische Daten speichern, abfragen und schützen?

Sondern:

Kann die Organisation ein wertvolles Dataset oder Analytics Product von der Quelle bis zum Consumer governen und dabei Verantwortung, Effective Access, Region, Export, Quality Evidence und Kostenverantwortung explizit halten?

Vier Fehlmuster treten regelmäßig auf.

Project Structure wird mit einem Governance-Modell verwechselt

Google Cloud Organizations, Folders und Projects sind wichtige administrative und Policy Boundaries. BigQuery ergänzt Datasets als weitere Gruppierungs- und Location-Grenze. Keines dieser Objects etabliert automatisch eine Business Domain, einen verantwortlichen Data Owner oder einen freigegebenen Product Scope. Ein Project kann unabhängige Workloads enthalten, und ein Business Product kann mehrere Projects überspannen.

Technischer Zugriff wird mit Permitted Use verwechselt

IAM, Dataset Permissions, Authorized Views, Row-Level Access Policies, Column-Level Access Control und Masking können einschränken, was eine Identity abfragen darf. Sie entscheiden nicht, ob der Purpose genehmigt ist, ob ein Export erlaubt ist, ob eine Downstream Copy aufbewahrt werden darf oder ob ein neuer Consumer Context eine Recertification benötigt.

Serverless wird mit ownerless verwechselt

BigQuery entfernt Capacity Planning für On-Demand Workloads und kann Reservation-basierte Capacity skalieren. Jobs verbrauchen trotzdem Geld, Quotas und operative Aufmerksamkeit. Production Datasets, Reservations, Assignments, Exports und wiederkehrende Transformationen benötigen benannte Owner und Eskalationspfade.

Native Lineage wird mit vollständiger Evidenz verwechselt

Knowledge Catalog und BigQuery können Lineage für unterstützte Services und Processing Paths erfassen und anzeigen. Externe Quellen, lokale Dateien, unmanaged Exports, nicht integrierte Transformation Tools, Semantic Models und Downstream Consumers können außerhalb des Graphen bleiben. Fehlende Kanten müssen integriert, dokumentiert oder als explizite Gaps akzeptiert werden.

Das Governance Design muss drei Ebenen verbinden:

BigQuery implementiert und belegt Controls. Verantwortliche Rollen bleiben für die zugrunde liegenden Entscheidungen zuständig.

Ansatz

Nutze BigQuery als Governance-Einstieg, wenn der erste governede Use Case von GCP-nativer serverloser Analytics profitiert und die Organisation Cloud-, Dataset-, Identity-, Protection-, Evidence-, Region-, Export- und Cost Boundaries als ein zusammenhängendes Modell betreiben kann.

Eine positive Entscheidung hat normalerweise die meisten der folgenden Merkmale:

• Google Cloud ist bereits eine akzeptierte strategische oder operative Umgebung.
• Das erste Product ist SQL-, BI-, Sharing- oder Analytics-zentriert.
• Google Cloud Zugriffsverwaltung Groups und Service Accounts können über einen zuverlässigen Lifecycle governed werden.
• Organization-, Folder-, Project-, Dataset- und Environment-Grenzen können bewusst entworfen werden.
• Dataset Locations und verbundene Services erfüllen Residency- und Processing-Anforderungen.
• Fine-Grained Access und Masking können mit echten Identities und Consumption Paths getestet werden.
• Knowledge Catalog kann die erforderlichen Business- und technischen Metadaten halten oder synchronisieren.
• Lineage und Quality Nachweis decken die relevante Source-to-Nutzer-Kette ab.
• Exports, Copies und Sharing werden governed statt als unsichtbares Downstream-Verhalten behandelt.
• On-Demand Spend oder Reservation Capacity kann Products, Teams oder Cost Centern zugeordnet werden.

BigQuery sollte nicht nur gewählt werden, weil es serverless ist oder bereits in einem Google Cloud Account verfügbar ist. Ein vorhandenes Warehouse, eine Semantic Layer oder eine BI Platform kann die bessere No-New-Platform-Alternative sein, wenn die eigentlichen Lücken bei Verantwortung, Metric Governance, Dokumentation oder Operating Discipline liegen.

1. Resource- und Dataset-Hierarchie vor dem Laden entwerfen

BigQuery übernimmt die Google Cloud Resource Hierarchy und ergänzt Datasets unterhalb von Projects. Die Hierarchie soll Operating Decisions übersetzen und nicht mechanisch ein Organigramm spiegeln.

Eine Dataset Location wird bei der Erstellung gewählt und kann nicht einfach in place geändert werden. Location gehört deshalb in die Readiness-Entscheidung – zusammen mit Source Location, Transformation Services, Reservations, Policy Resources, Sharing Patterns und Downstream Tools.

Environment Separation kann Projects, Datasets oder eine kontrollierte Kombination nutzen. Die Auswahl muss auf Isolation, Deployment, IAM, Evidence, Billing und Recovery beruhen und nicht nur auf Naming Conventions.

2. Business Verantwortung von Cloud Administration trennen

Ein minimales Operating Model unterscheidet diese Verantwortungen:

Eine Person kann mehrere Rollen halten, aber die Entscheidungen müssen unterscheidbar bleiben. Der Principal, der eine Role vergeben kann, darf nicht stillschweigend zum Genehmiger des Business Purpose werden.

3. Effective Access über alle Control Levels prüfen

Die Access Chain ist breiter als eine Table Permission:

Identity und Groups
→ Organization-, Folder- und Project-Roles
→ Dataset Access
→ Table- oder Authorized-View-Access
→ Row-Level Access Policy
→ Column Policy oder Masking
→ Query- und Export-Pfad
→ Audit Evidence

Für jedes governede Product werden dokumentiert:

• genehmigter Business Purpose;
• Human Groups und Service Accounts;
• verantwortliche Person jeder Group;
• Project- und Dataset-Inheritance;
• Direct Grants und Authorized Resources;
• Row-Richtlinie-Conditions;
• Richtlinie Tags, Data Richtlinien oder Masking Rules;
• privilegierte administrative Pfade;
• Export-, Exportdatei-, Copy- und Sharing-Permissions;
• Exception Approver und Expiry;
• Recertification Trigger.

Effective-Access-Tests müssen benannte Test Identities und erwartete Ergebnisse nutzen. Ein Role Inventory ohne Query-Path-Validierung ist keine ausreichende Evidenz.

4. Klassifizierung, Protection und Export als einen Workflow behandeln

Eine governede Protection Chain muss explizit sein:

Business Classification
→ freigegebener Metadata Term oder Tag
→ Policy Selection
→ IAM- und Data-Policy-Implementation
→ Row Restriction, Column Access oder Masking
→ Effective-Query-Test
→ Export- und Sharing-Test
→ Audit Evidence
→ Recertification

Column-Level Access Control kann Zugriff über Policy Tags beschränken, und Dynamic Data Masking kann ausgewählte Werte für definierte Principals verschleiern. Row-Level Access Policies können Zeilen anhand von Identity Conditions filtern. Diese Controls ergänzen sich, governen aber Exports oder Downstream Copies nicht automatisch.

VPC Service Controls können einen von IAM unabhängigen Service Perimeter ergänzen und Ingress- sowie Egress-Pfade einschließlich ausgewählter Export-Szenarien beschränken. Perimeter, unterstützte Services, Dry-Run-Validierung, Exceptions und Operational Verantwortung müssen Teil des Designs sein. Der Perimeter ersetzt weder Least-Privilege IAM noch Permitted-Use-Freigaben.

5. End-to-End-Evidenz statt isolierter Plattform-Screenshots aufbauen

Die Evidence Chain sollte abdecken:

Source
→ Ingestion oder Federation
→ Transformation
→ governed Dataset
→ Analytical Product oder Semantic Model
→ BI-, API-, Sharing- oder AI-Consumer

An jeder Stufe werden aufbewahrt:

• stabiler Asset Identifier;
• Owner und Steward;
• Source Authority und fachliche Ebene;
• Classification und Permitted Use;
• Access-Richtlinie-Referenz;
• Lineage Link;
• Quality Rules und aktueller Status;
• Deployment- oder Job-Version;
• Location und Retention Rule;
• Incident Route;
• Cost Attribution;
• Change Approval.

Knowledge Catalog kann zentrale Discovery, Business Glossary, Metadata, Lineage und Data Quality bereitstellen. Diese Funktionen müssen mit einem Operating Workflow verbunden werden: Wer schlägt Metadata vor, wer validiert sie, wer genehmigt sie, wie werden Konflikte aufgelöst und wann erfolgt das Review?

Audit Logs beantworten, wer was wann und wo getan hat. INFORMATION_SCHEMA Views beantworten operative und Usage-Fragen. Quality Results zeigen, ob vereinbarte Rules bestanden wurden. Diese Evidenztypen ergänzen sich und dürfen nicht in einer generischen Aussage wie „Monitoring vorhanden“ zusammenfallen.

6. Kosten- und Capacity-Verantwortung in die Readiness aufnehmen

BigQuery kann On-Demand Pricing oder Reservation-basierte Capacity nutzen. Reservations können Production-, Test-, Business-Unit- oder andere Workloads isolieren, und Assignments verbinden Projects, Folders oder eine Organization mit Capacity Pools.

Das Governance-Modell definiert:

• Billing Project und Cost verantwortliche Person;
• On-Demand- oder Reservation-Entscheidung;
• Edition- und regionale Anforderungen;
• Reservation Administration Project;
• Project-, Folder- oder Organization-Assignments;
• Baseline- und Autoscaling-Limits, wenn genutzt;
• Isolation von Production und Development;
• Labels oder einen anderen Attribution-Mechanismus;
• Budget Thresholds und Eskalation;
• verantwortliche Person für fehlgeschlagene, ineffiziente oder runaway Workloads.

Eine serverlose Query ohne Cost Owner bleibt eine unmanaged Production Activity.

Checkliste

Kontext und Scope

• Ist der erste governede Use Case benannt und begrenzt?
• Sind Dataset, Analytical Product und Nutzer explizit?
• Ist der aktuelle Organization-, Folder-, Project- und Region-Kontext dokumentiert?
• Wurde die No-New-Platform-Alternative bewertet?

Verantwortung und Metadata

• Sind Data Owner, Steward, technischer Betreiber und FinOps verantwortliche Person benannt?
• Ist eine Authority für Business Terms und Classifications definiert?
• Kann Knowledge Catalog oder ein anderer Catalog autoritative Metadata synchronisieren statt duplizieren?
• Sind fachliche Ebene des Produkts, Freshness, Quality und Permitted Use für Nutzer sichtbar?

Identity und Protection

• Werden Access Grants nach Möglichkeit über Groups vergeben?
• Sind Service Accounts owned, monitored und revocable?
• Sind Row-, Column- und Masking Kontrollregeln mit freigegebenen Classifications verbunden?
• Sind Administrator-, Break-Glass-, Export- und Sharing-Pfade in den Tests enthalten?

Evidence und Operations

• Deckt Lineage jeden materiellen Handoff ab?
• Werden Quality Failures gespeichert und an einen Incident verantwortliche Person geroutet?
• Werden Audit Logs für den erforderlichen Zeitraum und Umfang aufbewahrt?
• Sind nicht unterstützte oder externe Kanten als Gaps dokumentiert?

Region, Lifecycle und Kosten

• Sind Dataset-, Reservation- und Connected-Service-Locations kompatibel?
• Sind Retention-, Deletion-, Export- und Downstream-Copy-Rules explizit?
• Ist Workload Spend einem Product, Team oder Cost Center zugeordnet?
• Sind Reservation-, Edition- und regionale Annahmen vor Approval validiert?

Artefakt

Dokumentiere das Ergebnis mit dem Tool Governance Starting-Point Decision.

Fülle die Readiness Card in einem Workshop aus. Das Ergebnis wird nicht vorab eingetragen.

Die Karte dokumentiert vier Bereiche:

1. Decision Context – erster governeder Use Case, Success Criteria, Dataset- und Consumer Scope, Organization-/Project-/Region-Kontext und Decision Owner.
2. Governance and Platform Design – Dataset- und Environment Model, Data Owner und Steward, Metadata Authority, IAM und Fine-Grained Access, PII Controls, Lineage, Audit, Quality, Analytical Verantwortung, Retention, Exports, Reservations und Cost Accountability.
3. Validation, Gaps and Exceptions – Evidence Location, Proof-of-Value-Tests, bekannte Gaps, Assumptions und zeitlich begrenzte Exceptions.
4. Decision Record – Ready, Conditional oder Not Ready; bevorzugtes Starting Pattern; Alternative; Blocker; Current-Stack-Option; No-Regret Next Step; Implementation Owner; Review Date.

Das Artefakt ist Decision Evidence und kein Product Scorecard. Approval benötigt eine getestete Control Chain für einen realen Use Case.

Tools

• BigQuery Governance Readiness Decision Card
• Governed Dataset Vereinbarung
• Effective Access Test Matrix
• Classification-to-Richtlinie Map
• Source-to-Nutzer Nachweis Register
• Export and Downstream-Copy Register
• Data Quality and Incident Register
• Reservation and Cost Accountability Map

Ressourcen

BigQuery Governance und Hierarchie

• Introduction to data governance in BigQuery
• Organizing BigQuery resources
• BigQuery locations
• BigQuery Zugriffsverwaltung roles and permissions

Fine-Grained Protection und Exports

• Introduction to BigQuery row-level security
• Introduction to column-level access control
• Introduction to data masking
• VPC Service Kontrollregeln for BigQuery
• Export query results to a file

Catalog, Lineage, Quality und Evidence

• Knowledge Catalog overview
• Manage a business glossary
• About data lineage
• Automatic data quality overview
• Introduction to audit logs in BigQuery

Capacity und Kosten

• Understand reservations
• Manage workload reservations

Herausforderung

dbt kann einen konsistenten Transformation Workflow über Warehouses und Lakehouse SQL Engines hinweg bereitstellen. Sources, Models, Contracts, Tests, Documentation, Lineage, Pull Requests, Deployments und Artifacts lassen sich in einer versionierten Project Structure ausdrücken. Dadurch ist dbt eine plausible plattformübergreifende Control Layer für Transformation Governance.

Damit wird dbt nicht zur Authority für jede Governance-Entscheidung.

Das Transformation Repository kann deklarieren, dass ein Model einen Owner, eine PII Classification, einen Allowed-Usage-Wert oder ein Quality Tier besitzt. Es beweist nicht, dass die verantwortliche Business Role diese Werte genehmigt hat, solange kein externer Workflow, keine Identity und kein Decision Record mit der Deklaration verbunden sind.

Die relevante Frage lautet deshalb nicht:

Können wir Governance Metadata in YAML schreiben?

Sondern:

Kann dbt freigegebene Transformation Controls implementieren und belegen, während klare Authority Boundaries für Business Purpose, Verantwortung, Access, Privacy, Retention und Metric Certification erhalten bleiben?

Vier Fehlmuster sind häufig.

YAML wird zum ungeprüften Shadow Catalog

Developers ergänzen Descriptions, Owners und Classifications, weil die Felder verfügbar sind. Das Repository wirkt vollständig, aber Werte widersprechen dem Business Glossary, Privacy Inventory oder Platform Catalog. Metadata ohne Authority, Provenance und Review State erzeugt einen weiteren Catalog statt einer Governance Control Layer.

Test Success wird zur Definition von Quality

dbt Data Tests können Bedingungen für Models und Sources prüfen, und fehlerhafte Datensätze können gespeichert werden. Bestehende Tests beweisen nicht, dass die gewählten Rules die fachliche Quality Expectation repräsentieren, dass Thresholds freigegeben wurden oder dass ein Incident Owner reagieren wird.

Pull-Request Approval wird mit Business Approval verwechselt

Ein Code Reviewer kann SQL, Naming, Performance und Deployment Risk prüfen. Dieses Review genehmigt nicht automatisch einen neuen Business Purpose, Sensitive-Data-Use, eine Retention-Änderung oder eine zertifiziert Metric Definition.

Transformation Lineage wird mit End-to-End Lineage verwechselt

dbt Artifacts repräsentieren den Project Graph und zugehörige Resources. Ingestion außerhalb von dbt, Platform Policies, Extracts, Semantic Models, Reports, APIs und AI Consumers können außerhalb bleiben. Der Handoff zu externen Catalogs und Evidence Systems muss explizit entworfen werden.

Die Grenze muss sichtbar bleiben:

Ansatz

Nutze dbt als plattformübergreifende Governance Control Layer, wenn SQL Transformation über eine oder mehrere Analytics Platforms wesentlich ist und die Organisation ein wiederholbares Contract-, Metadata-, Test-, Review- und Evidence Pattern benötigt, ohne Business Authority im Transformation Tool zu zentralisieren.

Eine positive Entscheidung setzt normalerweise voraus:

• ein relevantes Volumen gemeinsamer SQL Transformation Logic;
• unterstützte Adapter und Deployment Environments für die Zielplattformen;
• einen versionierten Development- und Release-Prozess;
• ein autoritatives Metadata Schema, das außerhalb einzelner Projects vereinbart ist;
• benannte Data Owner und Stewards für die Freigabe promoteter Metadata;
• einen klaren Catalog- und Lineage-Publication-Pfad;
• gespeicherte Quality Failures und einen Incident Workflow;
• Trennung von Code Review und Business Approval;
• explizite Handoffs für Access, Permitted Use, Retention und semantisches Modell Certification;
• einen Migration Plan für duplizierte Transformationen in BI Tools, Stored Procedures oder lokalen Scripts.

Führe dbt nicht als verpflichtende Schicht für jeden Workload ein. Native SQL, Stored Procedures, Notebooks, Streaming Engines, Low-Code Tools und plattformspezifische Pipelines bleiben valide, wenn sie besser zum Workload passen und über äquivalente Contracts und Evidence governed werden.

1. Den Transformation Governance Contract definieren

Die Control Layer benötigt einen expliziten Contract, den alle beteiligten Projects implementieren.

Mindestens werden definiert:

• unterstützte Platforms und Adapter;
• governeder Source- und Model Umfang;
• Naming und stabile Identifiers;
• Source Declaration Requirements;
• Model Vereinbarung Requirements;
• verpflichtende Model- und Column-Metadata;
• Verantwortung- und Stewardship-References;
• Classification- und Permitted-Use-References;
• Data-Test-Kategorien und Thresholds;
• Stored-Failure-Rules;
• Review- und Approval States;
• Deployment Environments und Version Nachweis;
• Catalog-, Lineage- und semantisches Modell-Handoffs;
• Incident- und Exception-Workflow;
• Deprecation- und Recertification-Trigger.

Der Contract unterscheidet autoritative Werte von lokalen Implementation Values. Eine Model Description kann für abgeleitete Transformation Logic autoritativ sein. Sie darf nicht stillschweigend den Enterprise Business Term oder eine Privacy Decision überschreiben.

2. Contracts für die Form nutzen, nicht für jedes Governance-Versprechen

Ein dbt Model Contract definiert die Form des zurückgegebenen Datasets und kann unterstützte Column Names und Data Types durchsetzen. Das ist ein wertvoller Implementation Control, aber enger als ein vollständiger Data Product Contract.

Der breitere Contract benötigt weiterhin:

• Business Purpose und Nutzer Umfang;
• freigegebenen fachliche Ebene und Semantics;
• Source Authority;
• Permitted Use;
• Classification und Richtlinie Linkage;
• Freshness und Service Expectation;
• Quality Thresholds;
• Retention und Deletion Rule;
• Incident verantwortliche Person;
• Publication- und Deprecation-Status.

Model Contracts sind deshalb eine ausführbare Komponente des breiteren Transformation Governance Contract.

3. Den vollständigen Evidence Lifecycle verbinden

Der Lifecycle muss explizit sein:

Approved Requirement
→ Source Declaration
→ Model Contract
→ Transformation
→ Data Tests
→ Stored Failure Evidence
→ Technical Review
→ Accountable Approval
→ Deployment
→ Catalog- und Consumer-Publication
→ Change und Recertification

Verpflichtende Metadata enthält mindestens:

• verantwortliche Person- und Steward-Reference;
• Domain oder Product;
• fachliche Ebene;
• personenbezogene Daten- oder Sensitivity Classification;
• Criticality;
• Quality Tier;
• Allowed-Usage-Reference;
• Richtlinie References;
• Lifecycle State;
• Review Date.

Das Repository muss außerdem Build Evidence bewahren. dbt Artifacts wie manifest.json, run_results.json, catalog.json, sources.json und das Semantic Manifest liefern unterschiedliche Evidenztypen. Speichere Artifact Version, dbt Version, Environment, Commit, Invocation und Deployment Identifier, die für die Reproduktion eines Production State erforderlich sind.

4. Failures als operative Evidenz speichern

Ein Dashboard mit einem roten Test reicht nicht aus. Für materielle Controls müssen fehlerhafte Datensätze oder ein freigegebenes aggregiertes Evidence Set mit Kontext aufbewahrt werden.

Das Operating Pattern definiert:

• welche Tests Publication blockieren;
• welche Tests warnen, aber Publication erlauben;
• Failure Thresholds;
• Failure-Storage-Location und Retention;
• Sensitive-Data-Handling in Failure Tables;
• Incident Routing;
• Product-Health-Status;
• Nutzer Communication;
• Exception Owner und Expiry;
• Re-Test- und Closure-Nachweis.

store_failures kann fehlerhafte Datensätze persistieren, ersetzt aber standardmäßig vorherige Failures desselben Tests. Langfristige Incident Evidence kann deshalb einen zusätzlichen Append- oder Snapshot-Prozess benötigen. Failure Storage ist ein Implementation Mechanism und nicht der vollständige Incident Record.

5. Metadata durch Declared, Validated und Approved States promoten

Metadata sollte drei sichtbare States durchlaufen.

Declared

Der Developer liefert Model Descriptions, Column Descriptions, Tests und Implementation Metadata. Die Werte sind nützlich, aber noch nicht automatisch autoritativ.

Validated

Automatisierte Checks prüfen Required Fields, Controlled Vocabularies, References, Contract Completeness und Consistency. Catalog Synchronization und Steward Review vergleichen die Deklaration mit autoritativen Quellen.

Approved

Die verantwortliche Rolle genehmigt Business-relevante Werte, Policy Linkage, Effective Date, Version und Recertification Trigger. Der Approved State wird an Subscribers publiziert oder über einen stabilen Identifier verknüpft.

Ein praktischer Metadata Record kann so aussehen:

models:
  - name: fct_sales_order_line
    description: Governed sales-order-line transformation model.
    config:
      contract:
        durchgesetzt: true
      meta:
        product_id: sales-order-lines
        data_owner_ref: owner:sales-operations
        steward_ref: steward:sales-data
        grain: one-row-per-order-line
        pii_classification_ref: classification:customer-indirect
        allowed_usage_ref: policy:commercial-analytics
        quality_tier: tier-1
        review_status: approved
        policy_version: "2026-07"
        review_date: "2026-10-29"

Die References zeigen auf autoritative Records. Langer Policy Text sollte nicht in jedes Project kopiert werden.

6. Technical Review von Accountable Approval trennen

Der Pull-Request Workflow braucht unterscheidbare Approval Gates.

Nicht jede Änderung benötigt jedes Gate. Der Contract definiert Schwellen. Eine Korrektur einer Description benötigt möglicherweise nur Technical Review; ein Grain Change oder neuer PII Use erfordert Accountable Recertification.

7. Catalog-, Access- und Semantic-Handoffs entwerfen

Das dbt Project publiziert oder verlinkt die Evidenz, für die es am besten geeignet ist:

• Model- und Column-Identifiers;
• Transformation Logic und Dependencies;
• Tests und Results;
• Source Freshness;
• Deployment Version;
• Descriptions der Derived Logic;
• Exposures, Groups und semantisches Modell Definitions, wenn genutzt.

Es übergibt Entscheidungen, die es nicht durchsetzt:

• Identity und Platform Privileges;
• Row- und Column-Richtlinien;
• Retention- und Deletion-Kontrollregeln;
• Legal- oder Privacy Approval;
• Enterprise-Glossary-Authority;
• zertifiziert Metric Approval;
• Downstream Export- und Consumption Kontrollregeln.

Das Ziel ist synchronisierte Authority und nicht ein Tool, das vorgibt, jedes Feld zu übernehmen.

Checkliste

Scope und Architektur

• Sind unterstützte Platforms, Adapter und Environments explizit?
• Löst dbt gemeinsame Transformation-Governance-Probleme statt nur Default-Tooling zu werden?
• Ist duplizierte Transformation Logic inventarisiert und priorisiert?
• Sind Non-dbt Workloads durch äquivalente Kontrollregeln abgedeckt?

Metadata und Authority

• Ist das autoritative Metadata Schema definiert?
• Hat jedes Feld Source Authority, Approver und Review State?
• Werden YAML Values mit Business Glossary und Platform Catalogs synchronisiert?
• Werden stabile Identifiers statt Name-only Matching genutzt?

Contracts, Tests und Evidence

• Werden Model Vereinbarungen dort eingesetzt, wo sie durchsetzbaren Wert liefern?
• Sind Data Tests mit freigegebenen Quality Expectations verbunden?
• Werden Failure Records sicher gespeichert und an einen verantwortliche Person geroutet?
• Werden Artifacts mit Commit-, Environment- und Deployment-Kontext aufbewahrt?

Review und Approval

• Sind Code Review und Business Approval getrennt?
• Sind Change Thresholds und Recertification Trigger definiert?
• Sind Exceptions zeitlich begrenzt und mit Nachweis verknüpft?
• Kann ein Release blockiert werden, wenn verpflichtende Governance Nachweis fehlt?

Handoffs und Lifecycle

• Ist Catalog- und Lineage-Publication automatisiert oder operativ owned?
• Werden Access-, Richtlinie-, Retention- und semantisches Modell-Entscheidungen an die richtige Authority übergeben?
• Können Nutzer Model Status, Quality und Deprecation State sehen?
• Wird die Kontrollregel Layer bei Änderungen an Platforms, Adapters oder Responsibilities überprüft?

Artefakt

Dokumentiere die Entscheidung mit dem Tool Governance Starting-Point Decision.

Fülle die dbt Decision Card in einem Workshop aus. Approved, Conditional oder Not Approved wird nicht vorab eingetragen.

Die Karte dokumentiert:

1. Decision Context – Transformation-Governance-Problem, Business Outcome, unterstützte Platforms, Source-/Model-Scope und Decision Owner.
2. Control-Layer Design – Metadata Schema, Contracts, Test Strategy, Failure Evidence, Pull-Request Approvals, Deployment Evidence, Catalog-/Lineage-Handoff, Access-/Policy-Handoff, Semantic-Handoff und Migration duplizierter Logic.
3. Validation, Gaps and Exceptions – Evidence Location, Proof-of-Value-Tests, ungelöste Gaps, Dependencies, Assumptions und zeitlich begrenzte Exceptions.
4. Decision Record – Status, Approved Pattern, Location des Transformation Governance Contract, Alternative, Blocker, No-Regret Next Step, Implementation Owner und Review Date.

Das Artefakt zeigt, dass dbt Controls implementiert und belegt, ohne zur Authority für Verantwortung, Permitted Use, Access Approval oder Retention zu werden.

Tools

• dbt Kontrollregel-Layer Decision Card
• Transformation Governance Vereinbarung
• Metadata Authority Matrix
• Required Metadata Validator
• Data-Test and Threshold Register
• Stored-Failure and Incident Pattern
• Pull-Request Approval Matrix
• Artifact Retention Register
• Catalog and Lineage Handoff Map
• Transformation Duplication Retirement Backlog

Ressourcen

Contracts, Tests und Failures

• Model contracts
• Add data tests to your DAG
• store_failures
• Sources and source freshness

Metadata und Artifacts

• meta configuration
• About dbt artifacts
• Manifest JSON file
• Run results JSON file
• Catalog JSON file
• Sources JSON file

Semantic Handoff

• dbt Kennzahlenmodell
• semantisches Modell manifest