dbt als plattformübergreifende Governance-Kontrollschicht

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