Teil 1
Governance im Data Engineering — Pipelines, Contracts und Qualität gemeinsam betreiben
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.
Sizing: KMU — drei Pipelines mit Contract vor Transform. Mid-Market — DQ-Owner-Pfad und Waiver. Enterprise — Breaking-Change-Vorlauf mit Consumer-Pfad.
Die Serie Governance im Data Engineering gibt dir den Einstieg und den roten Faden für die folgenden Teile. Sie schreibt Data Contracts und DQ-on-Platform nicht neu — sie hängt Gates an die Kette.
Data Engineering setzt fachliche Erwartungen in Pipelines um: Grain, Frische, Schema und Fehlerbehandlung. Wenn der Vertrag unklar ist, liefert das Team pünktlich — nur nicht das, was Sales und Finance meinen.
KMU — ein Contract vor der ersten Transform. Mid-Market — DQ-Gate mit fachlicher Triage. Enterprise — Breaking-Change-Vorlauf im Contract, Consumer-Pfad Pflicht.
Diese Seite ist der Function-Schnitt, keine Landscape-Serie. Operating-Tiefe: Contracts, DQ auf der Plattform, Warehouse.
Pipelines extrahieren, transformieren und veröffentlichen Daten. dbt-Modelle machen SQL modular und testbar. Orchestratoren koordinieren Abhängigkeiten. Quality Checks erkennen Abweichungen. Keine dieser Fähigkeiten entscheidet jedoch allein, was ein Feld bedeutet, welches Risiko akzeptabel ist oder ob ein Produkt für eine Entscheidung freigegeben werden darf.
Genau hier entsteht Reibung.
Engineers erhalten unpräzise Anforderungen, treffen pragmatische Annahmen und werden später für fachliche Abweichungen verantwortlich gemacht. Stewards dokumentieren Regeln, ohne zu wissen, ob sie technisch ausführbar sind. Owner genehmigen Ziele, aber nicht die Übergaben. Consumer sehen eine grüne Pipeline und erwarten korrekte Daten.
Eine erfolgreiche Pipeline beweist technische Ausführung. Ein belastbares Datenprodukt beweist zusätzlich Semantik, Qualität, Verantwortlichkeit und kontrollierte Änderung.
Konzept halten — Last-Säulen: Quality und Metadata tragen diese Kette; Verantwortung ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.
Orientierungskarte — Pipeline liefert Durchsetzung, nicht Bedeutung
| Problem im Alltag | Einstieg | Verantwortung / Beratung / Umsetzung | Einbinden | Ergebnis / Nachweis | Nicht so |
|---|---|---|---|---|---|
| Transform ohne Contract-Owner | Einstiegsangebot | Verantwortung: Pipeline-Contract. Semantik beim Fach-Owner | DE-Lane + Steward | Ein Contract vor Publish | Engineers als Data Owner |
| DQ-Tickets ohne Triage | Pilotprojekt | Verantwortung: Gate+Triage. Beratung: Ticket-Tool | Steward | Ein Gate das stoppt | Mehr Checks ohne Entscheidung |
| Breaking Change ohne Consumer | Einstiegsangebot | Verantwortung: Vorlauf im Contract. Beratung: Orchestrator | Product Owner | Ein angekündigter Bruch | Hotfix ohne Notice |
Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation
Lane-Kasten — Data Engineering im Mischprojekt
| Problem | Pipeline grün, Semantik falsch; Engineers haften für Sales-Definitionen. |
| Auftrag | Contract in der Pipeline, DQ-Gates, Breaking-Change-Vorlauf. |
| Nicht | Owner der fachlichen Bedeutung sein. |
| Artefakt | Contract + Gate vor Publish. |
| Modus | Own auf Gates; Influence auf Ticket-Tool; Semantik bleibt Fach-Owner. |
Tiefe bleibt diese Serie. Der Kasten sagt nur: Durchsetzung, nicht Glossar. Übersicht: Lanes und Delegation.
Produkte und Entscheidungen
Source-Ingestion-Produkt
Dieses Produkt übernimmt Daten aus einer operativen Quelle.
Sein Contract umfasst:
- Source-System und Objekt; Extraktionsmodus; Schlüssel und fachliche Ebene; erwartete Aktualität; erlaubte Felder; Lösch- und Retention-Verhalten; Schema-Drift-Reaktion; technische Wiederanlaufstrategie.
Der Engineer entscheidet über Connector, Ladeverfahren und Recovery.
Der fachliche Owner entscheidet, welche Daten für welchen Zweck übernommen werden dürfen.
Staging-Produkt
Staging macht Quellzustände reproduzierbar.
Es klärt:
- Typisierung;
- technische Deduplizierung;
- Ladezeitpunkt;
- Source Delete;
- Null-Repräsentation;
- Quellschlüssel;
- unveränderte Rohwerte;
- Quarantäne.
Staging sollte Semantik nicht heimlich neu definieren. Eine technische Normalisierung ist keine fachliche Klassifikation.
Transformationsprodukt
Ein Transformationsprodukt verbindet Quellen zu einer wiederverwendbaren fachlichen Struktur.
Sein Contract benötigt:
- Zweck; fachliche Ebene; Business Key; Join-Regeln; Filter; Historisierungslogik; Ableitungen; Quality-Erwartungen; Owner und Steward; Versionsregeln.
dbt kann Modelle, Tests, Dokumentation, Abhängigkeiten und Reviews bündeln. Die fachliche Entscheidung bleibt technologieunabhängig.
Publiziertes Data Product
Ein publiziertes Produkt ist mehr als das letzte Modell im DAG.
Es bietet:
- definierte Nutzer; stabile Schnittstelle; SLO; fachliche Freigabe; Quality Status; Change Notice; Supportpfad; Deprecation-Regel.
Pipeline-Control-Produkt
Auch Betriebs- und Qualitätsnachweise sind ein Produkt.
Es enthält:
- Run Status; Freshness; Volumen; Testresultate; fehlerhafte Grundgesamtheit; Incident; befristete Ausnahme; Freigabe; Wiederherstellung.
Wo Governance hängt
Am unklaren Intake
„Baut eine Kundentabelle“ ist kein umsetzbarer Contract.
Der Intake muss mindestens klären:
- Nutzer; Entscheidung; Grundgesamtheit; fachliche Ebene; Aktualität; Quelle; Sensitivität; akzeptable Lücke; fachlichen verantwortliche Person.
Zwischen Quelle und Pipeline
Operative Systeme ändern Felder für ihren Prozess.
Ein technisch kompatibler Datentyp kann eine neue Bedeutung tragen. Deshalb braucht jede kritische Quelle eine benannte Änderungsbeziehung, nicht nur automatische Schema-Erkennung.
Zwischen Engineer und Steward
Der Engineer weiß, wie eine Regel zuverlässig ausgeführt wird.
Der Steward weiß, welcher fachliche Zustand erwartet wird und wie Ausnahmen eingeordnet werden.
Problematisch wird es, wenn der Engineer Schwellenwerte allein setzt oder der Steward nicht ausführbare Freitextregeln übergibt.
An fehlgeschlagenen DQ-Tests
Ein roter Test beantwortet noch nicht:
- Ist das Produkt unbrauchbar?
- Welche Nutzer sind betroffen?
- Darf mit Hinweis weitergeliefert werden?
- Wer akzeptiert die Ausnahme?
- Bis wann muss korrigiert werden?
Tests brauchen eine Policy für Severity, Routing und Waiver.
An stillen Annahmen
Ein coalesce, ein Default-Wert oder ein Inner Join kann fachlich folgenreich sein.
Code Review prüft Lesbarkeit und technische Korrektheit. Kritische fachliche Annahmen brauchen zusätzlich Steward- oder Owner-Review.
An Backfills
Ein Backfill kann historische Werte neu schreiben.
Vor Ausführung müssen Scope, Stichtag, Reconciliation, Consumer-Auswirkung, Rollback und Kommunikationsweg geklärt sein.
An Verantwortung im Repository
Ein Git-Codeowner ist ein Reviewer, nicht automatisch der Data Owner.
Repository-Rechte dürfen nicht als fachliche Accountability interpretiert werden.
Engineer versus Steward
Der Engineer verantwortet
- implementierbare Pipeline-Logik; technische Tests; Deployment; Observability; Performance; Wiederanlauf; Rückbau; technische Lineage; sichere Secret- und Rechteverwendung.
Der Steward verantwortet
- verständliche Definitionen; fachliche Quality-Erwartungen; Regelkontext; Issue-Triage; Ausnahmevorbereitung; Katalogkontext; Nutzer-Kommunikation; Eskalation an den verantwortliche Person.
Gemeinsam verantworten sie die Übersetzung
Eine fachliche Erwartung wie „jede aktive Bestellung besitzt einen gültigen Kunden“ muss operationalisiert werden.
Gemeinsam klären sie:
- Was bedeutet aktiv?
- Welcher Zeitpunkt gilt?
- Welche Kundenquelle ist autoritativ?
- Sind Gastbestellungen erlaubt?
- Welche Grundgesamtheit wird getestet?
- Welche Fehlerrate blockiert?
- Wo wird die Gap-Grundgesamtheit gespeichert?
- Wer entscheidet über Ausnahmen?
Der Steward schreibt nicht zwingend SQL. Der Engineer erfindet nicht die fachliche Policy.
Rollen-Mapping
Data Owner
Der Owner sitzt in der verantwortlichen Domain.
Er entscheidet über:
- Zweck;
- autoritative Quelle;
- akzeptable Quality;
- Zugriff;
- Freigabe;
- Ausnahmen;
- Restrisiko.
Data Steward
Der Steward hält Contracts und Issues fachlich arbeitsfähig.
Er sorgt dafür, dass Tests nicht nur technische Symptome, sondern relevante Erwartungen abbilden.
Data Product Owner
Der Product Owner priorisiert:
- Nutzer-Anforderungen;
- Reliability-Arbeit;
- Vereinbarung-Änderungen;
- technische Schulden;
- Releases;
- Deprecation.
Er balanciert Delivery und Betrieb, ohne fachliches Risiko allein zu akzeptieren.
Data Architect
Der Architect schützt:
- fachliche Ebene;
- Domain-Grenzen;
- Schlüssel;
- Vereinbarung-Formate;
- Schichtverantwortung;
- Versionierung;
- Breaking-Change-Pfade.
Data Custodian
Plattform- und Engineering-Teams teilen Custodianship.
Sie betreiben Betrieb, Speicher, Orchestrierung, Berechtigungen, Logs, Backup und Recovery.
Data Consumer
Consumer melden:
- Definitionslücken;
- unerwartete Nullwerte;
- ungeeignete Aktualität;
- fehlende Dimensionen;
- Breaking Changes;
- lokale Workarounds.
Hilfskarte — wen zuerst fragen
Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.
| Frage | Zuerst | Dann |
|---|---|---|
| Wer verantwortet Grain und Zweck? | Fach-Owner | Steward |
| Wer setzt den Contract in der Pipeline um? | Engineer | Architect |
| Wer triagiert den roten DQ-Test? | Steward | Owner |
SMB versus Enterprise
SMB
Ein kleines Team sollte wenige kritische Ketten vollständig beherrschen.
Praktische Besetzung:
- Fachbereichsleitung als verantwortliche Person;
- Analyst als Steward und Nutzer;
- Analytics Engineer als Product Owner, Architect und Engineer;
- Cloud- oder IT-Verantwortlicher als technischer Betreiber.
Das Minimum:
- fünf kritische Produkte;
- ein Vereinbarung je Produkt;
- Tests für Schlüssel, Aktualität und zentrale Regeln;
- ein Incident-Kanal;
- sichtbare befristete Ausnahme;
- versionierte Deployments;
- getesteter Wiederanlauf.
Nicht jedes Modell braucht eine eigene Governance-Seite.
Enterprise
Ein Enterprise benötigt föderierte Engineering-Standards.
Zentral sinnvoll sind:
- Vereinbarung-Schema;
- Deployment Kontrollregeln;
- Observability;
- Security-Baseline;
- Lineage-Schnittstelle;
- Incident-Klassen;
- befristete Ausnahme-Felder;
- Mindesttests;
- Golden Paths.
Domains verantworten:
- Semantik;
- Produktgrenzen;
- fachliche Tests;
- Nutzer;
- Quality-Akzeptanz;
- Änderungsfreigaben.
Data-Quality-Gates
Vor dem Merge
- SQL- und Konfigurationsvalidierung;
- Unit- oder Komponentenprüfung;
- Vereinbarung-Kompatibilität;
- kritische fachliche Assertions;
- Review der Annahmen;
- Impact Analysis.
Vor der Veröffentlichung
- Freshness;
- Vollständigkeit;
- Schlüssel;
- Abgleich;
- referenzielle Integrität;
- erlaubte Werte;
- Vergleich zur Vorversion.
Im Betrieb
- Laufstatus;
- Laufzeit;
- Volumenabweichung;
- Testtrend;
- Nutzer-Nutzung;
- wiederkehrende befristete Ausnahme;
- SLA-Verletzung.
Ein Gate darf blockieren, warnen oder nur beobachten. Die Einstufung wird nach Risiko gewählt.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Domain Owner | DE / Architect | Data Contract vor Transform |
| Steward | Pipeline Custodian | DQ-Gate mit fachlicher Triage |
| Product Owner | Consumer | Breaking-Change-Vorlauf, nicht stilles Schema-Update |
Mini-Fall
Anwendungsbeispiel (Lehrfall, keine Kundendaten).
Symptom: Die Datenpipeline läuft technisch fehlerfrei. Sales zählt aber Angebote, Finance zählt gebuchte Umsätze. Beide nennen es „Umsatz“, meinen aber unterschiedliche fachliche Einheiten. Data Engineering wird für diese Bedeutungsfrage verantwortlich gemacht, obwohl sie fachlich entschieden werden muss.
Typischer Fehlstart: Mehr Tests in dbt, ohne Vereinbarung-verantwortliche Person.
Vereinbarung: Vereinbarung vor Transform; DQ-Prüfpunkt mit fachlicher Triage; Breaking Change nur mit Nutzer-Pfad.
Anti-Patterns
Grüne Pipeline gleich gute Daten
Technischer Erfolg sagt nichts über fachliche Eignung.
Steward schreibt Tickets, Engineer entscheidet
So wandert fachliches Risiko unbemerkt ins Delivery-Team.
Jeder Test blockiert Produktion
Unterschiedliche Risiken benötigen unterschiedliche Severities.
dbt Docs als vollständiger Contract
Generierte Dokumentation ist wertvoll, ersetzt aber keine Owner-, Zweck- und Waiver-Entscheidung.
Tests ohne Gap-Population
Eine Fehlerzahl ohne betroffene Datensätze erschwert Diagnose und Korrektur.
Backfill ohne Consumer-Hinweis
Historische Veränderungen dürfen nicht still erfolgen.
Lineage nur als Graph
Lineage erzeugt Wert, wenn sie Impact Reviews und Benachrichtigungen auslöst.
DQ-Schulden dauerhaft waiven
Ein Waiver ohne Ablaufdatum wird zur neuen, inoffiziellen Regel.
Toolstandard als fachliche Policy
Ein Framework kann Kontrollen ausführen. Es entscheidet nicht, welche Wahrheit gelten soll.
Mini-Scorecard
Bewerte jede Aussage mit 0, 1 oder 2 Punkten.
Contracts
- Kritische Produkte besitzen Zweck, fachliche Ebene und verantwortliche Person.
- Source- und Product-Vereinbarungen sind getrennt.
- Breaking Changes haben einen Pfad.
Qualität
- DQ-Regeln besitzen fachlichen Kontext.
- Severities und befristete Ausnahme sind definiert.
- Gap-Populationen bleiben analysierbar.
Rollen
- Engineer und Steward sind klar getrennt.
- verantwortliche Person entscheiden über Restrisiko.
- Nutzer erhalten Change Notices.
Betrieb
- Backfills sind kontrolliert.
- Incidents verbinden Technik und Fachlichkeit.
- Recovery wird getestet.
0–7 Punkte: funktionierende Jobs ohne belastbares Governance-Modell.
8–16 Punkte: kontrollierte Engineering-Basis mit Contract-Lücken.
17–24 Punkte: produktorientierte, nachweisbare Data-Engineering-Governance.
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
Woche 1
- drei kritische Pipelines auswählen;
- Source, Transformation und Produktgrenze markieren;
- Owner, Steward und Engineer benennen.
Woche 2
- Vereinbarungen mit fachlicher Ebene, Freshness und Quality ergänzen;
- stille Defaults und Join-Annahmen prüfen;
- DQ-Severities festlegen.
Woche 3
- einen fehlgeschlagenen Test durchspielen;
- befristete Ausnahme und Kommunikation testen;
- einen Backfill mit Abgleich simulieren.
Woche 4
- Wartezeit und wiederkehrende Fehler messen;
- zwei wirkungslose Tests entfernen;
- drei kritische Gates automatisieren;
- offene Entscheidung der verantwortlichen Personen eskalieren.
Weiterlesen
- Qualität durch Transformationen
- Quality Gates und Vereinbarungen
- Plattform betreiben und governieren
Weiter in dieser Serie: Contract-Gate vor Transform. Nachbar: Datenverträge im Betrieb.
