Steuerdaten als Datenprodukte betreiben

Sobald drei Pipelines das sales_otc-Statusmapping joinen, ist es ein Datenprodukt — ohne Owner und Change Window bricht der nächste Reload. Steuerdaten als Product: Verantwortung, Version, Tests, Consumer.

zitem Vertrag**.

In einem Satz: Betreiben Sie jedes geteilte Steuer-Asset als Datenprodukt mit explizitem Vertrag.

Problem

Teams hören oft auf, nachdem Zeilen in Postgres liegen. Das Inline ist weg; ein Excel ist retired; ein Formular existiert. Dann benennt ein Steward am Dienstag einen Code um, ein Qlik-Reload scheitert am Mittwoch, Power-BI-RLS driftet am Donnerstag, und niemand kann sagen, ob die Änderung breaking, freigegeben oder getestet war.

Schreibpfad-Erfolg (Teil 6 oder Teil 7) ist notwendig und unzureichend. Ohne Produktbetrieb:

• Verantwortung ist ein Katalogfeld, das niemand beantwortet;
• Stewards editieren außerhalb von Change Windows;
• Nutzer binden an Basistabellen und absorbieren jeden Draft;
• Tests prüfen Warehouse-Facts, ignorieren aber Steuerdaten-Orphans;
• Lineage endet bei „irgendein Excel hat das früher gespeist“;
• Rezertifizierung läuft nie für entitlement-nahe Listen.

Steuerdaten sind klein im Volumen und groß im Blast Radius. Eine fünfzigzeilige Status-Map kann Revenue neu definieren. Einige hundert Berechtigung-Zeilen können ganze Apps öffnen oder schließen. Das als wegwerfbare Konfiguration zu behandeln, reproduziert die ungovernable Landschaft aus Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen.

Entscheidung

Betreiben Sie jedes geteilte Steuer-Asset als Datenprodukt mit explizitem Vertrag. DIY-Formulare und gekaufte UIs sind austauschbare Schreibpfade; sie ändern Verantwortung, SLOs, Tests oder Katalog-Evidenz nicht.

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Owner + steward
Change window + communication
Version / compatibility rules
Published contract (view/API)
Automated tests
Catalog + lineage + recertification

Das ist die Betriebsschicht über Platzierung (Teil 5), OSS-Stack (Teil 6) und DIY-Stewardship (Teil 7).

Verantwortung und Stewardship

Trennen Sie Rollen, auch wenn eine Person zwei Hüte trägt:

Erfassen Sie Vertretung und Eskalation. „Owner unknown“ ist ein offenes Risiko, kein kosmetisches Metadatenproblem. Richten Sie die Sprache an Verantwortung-Praktiken anderswo aus; Steuerdaten sind weiterhin ein Produkt, nur ein kleines.

Change Windows und Kommunikation

Definieren Sie, wann produktive Steuerprodukte geändert werden dürfen:

• Standardfenster — z. B. Di/Do 10:00–12:00 lokal, Steward-Edits mit automatisierten Tests;
• Notfall — Security oder gebrochener Produktions-Reload; verkürzte Freigabe; retrospektive Notiz;
• Freeze — Monatsende, regulatorische Einreichung, Major Release — Schreibpfad read-only außer Notfall.

Ankündigen Sie breaking Changes mit Consumer-Liste, Wirksamkeitsdatum und Dual-Run-Erwartung. Stille Umbenennungen mittags sind ein Betriebsdefekt.

Breaking vs. non-breaking

Wiederverwenden Sie nie einen retired Code für eine neue Bedeutung. Bevorzugen Sie valid_to und einen Nachfolgecode.

Tests, die für Steuerprodukte zählen

Minimale automatisierte Suite (CI oder geplanter Job gegen den veröffentlichten Vertrag):

• Eindeutigkeit fachlicher Schlüssel;
• referentielle Integrität zu Parent-Steuertabellen;
• keine Orphan-Schlüssel relativ zu deklarierten Domains;
• Sanity von valid_from / valid_to;
• Freshness / „letzter erfolgreicher Publish“ für Upload-Pfade;
• Nutzer-Vertrags-Tests: erwartete Spalten, Typen, Row-Count-Grenzen;
• für Berechtigungs: keine doppelten USER×Reduktion-Schlüssel; erforderliche ACCESS-Felder vorhanden.

Warehouse-Fact-Tests ersetzen das nicht. Steuerdaten-Orphans bestehen oft Fact-Uniqueness und brechen trotzdem Joins und Section Access.

Katalog, Lineage und Rezertifizierung

Registrieren Sie jedes Steuerprodukt im Katalog mit:

• Owner, Steward, technischer Betreiber;
• Klassifikation (reference, mapping, parameter, entitlement, hierarchy, exception);
• Vertragsort (View/API FQN);
• Write-Path-Typ (oss-ui | diy | it-sql);
• Lineage zu BI-Apps, semantisches Modells und Jobs;
• Review- / Rezertifizierungs-Kadenz;
• Link zum Produktvertragsdokument.

Nutzen Sie Katalogfähigkeiten wie im Catalog Deep Dive — besonders Verantwortung, Workflow, Evidenz und Lifecycle. Rezertifizieren Sie Berechtigungsprodukte im selben Rhythmus wie Access Reviews, wo sie Durchsetzung treiben (Access Security Governance).

Derselbe Vertrag für DIY und gekaufte UI

Senken Sie die Latte nicht, weil das Formular custom ist, und nehmen Sie nicht an, dass ein Vendor-Grid gleich Governance ist. Beide müssen den Produktvertrag unten erfüllen. Teil 9 wendet das auf Berechtigungsmatrizen an; Teil 10 nutzt den Vertrag als Migrations-Gate.

Checkliste

• Business Owner, Steward und technischer Betreiber sind mit Vertretung benannt.
• Change Windows und Freeze-Regeln sind an Stewards und Nutzer veröffentlicht.
• Breaking- vs. Non-Breaking-Regeln sind geschrieben und in Freigaben genutzt.
• Nutzer binden nur an den veröffentlichten Vertrag (View/API).
• Automatisierte Tests decken Schlüssel, referentielle Integrität, Gültigkeit und Vertragsform ab.
• Katalogeintrag enthält Klassifikation, Lineage und Rezertifizierungsdatum.
• Changelog oder Audit ist abfragbar für „wer hat diesen Schlüssel geändert.“
• Write-Path-Typ ist erfasst (oss-ui / diy / it-sql), ohne den Vertrag zu ändern.
• Berechtigung-Klasse-Assets haben Freigabe- und Rezertifizierungs-Hooks.
• Dual-Run-Evidenz existiert für die letzte breaking Change (oder noch keine — dokumentiert).

Artefakt

Erstellen Sie einen Control Data Product Contract pro Asset-Familie. Speichern Sie ihn neben Migrationen oder im Governance-Repo; verlinken Sie ihn aus dem Katalog.

# control-data-product-contract.yaml
product_id: ctrl.sales.status_map
title: Sales status mapping
classification: mapping   # reference|mapping|parameter|entitlement|hierarchy|exception
domain: sales
owner: commercial-finance-director
steward: sales-data-steward
custodian: analytics-platform
write_path:
  type: diy               # oss-ui|diy|it-sql
  tier: B                 # A|B|C|D when diy
  system: internal-stewardship-app
persistence:
  engine: postgresql
  schema: control_sales
  base_table: status_map_base
contract:
  kind: view
  name: control_sales.v_status_map
  grain: one row per status_code currently valid
  keys: [status_code]
  attributes: [status_label, is_revenue, valid_from, valid_to]
compatibility:
  non_breaking: [add_optional_attribute, add_unused_code, label_text]
  breaking: [rename_key, retire_key_in_use, change_key_semantics]
change_window: "Tue/Thu 10:00-12:00 Europe/Berlin"
freeze_calendar_ref: finance-close-calendar
tests:
  - unique_status_code
  - valid_date_order
  - contract_columns_present
  - rowcount_between_5_and_200
consumers:
  - qlik:Sales_Ops_App
  - powerbi:Sales_Semantic_Model
  - dbt:mart_sales
catalog:
  fqn: "control.sales.status_map"
  lineage_expected: true
recertification:
  cadence: quarterly
  next_review: 2026-12-01
  evidence: [audit_sample, consumer_signoff]
sla:
  max_steward_latency: 2 business days
  restore_rpo_hours: 24

Markdown-Äquivalent ist in Ordnung, wenn YAML nicht genutzt wird; die Felder müssen vollständig bleiben.

Tools

• Katalog (OpenMetadata / DataHub / plattform-nativ) — Verantwortung, Lineage, Review-Daten (Was Governance von einem Katalog braucht).
• CI-Job oder geplante SQL-Tests — Vertrags- und Integritätsprüfungen.
• KPI Definition — nur wenn ein Steuerattribut eine zertifizierte Kennzahl speist; Steuerprodukte nicht mit Metrikprodukten verwechseln.
• Issue Tracker — Breaking-Change-Tickets mit Nutzer-Checkliste.

Ressourcen

• Serie: Steuer- und Referenzdaten Deep Dive
• Schreibpfade: Open-Source-Optionen · DIY-Stewardship
• Weiter: Berechtigungsmatrizen und Section Access gehören in die DB
• Catalog Deep Dive
• BI-Governance-Entscheidungen
• Fachlogik außerhalb der BI-Apps halten
• Access Security Governance