Steuer- und Referenzdaten Deep Dive

Problem

Eine typische Landschaft hat einen Metadatenkatalog, ein paar veröffentlichte Policies und ein Glossar mit den wichtigen Fachbegriffen. Gleichzeitig sitzen vierzig INLINE-Tabellen in Qlik-Skripten, zwölf Excel-Dateien steuern Länder- und Produktmappings, und ein halbes Dutzend SQL-VALUES-Klauseln kodiert Statuscodes, über die Finance und Sales sich nicht mehr einig sind.

Der Katalog indexiert dann Tabellen, die die Join-Keys nicht besitzen. Zugriffsrichtlinien referenzieren Rollennamen, die weder in Section Access noch in Row-Level-Filtern vorkommen. Lineage-Graphen enden an der BI-App, weil die echte Abhängigkeit ein hardcodiertes Mapping ist, das niemand registriert hat.

Unsichtbare Abhängigkeiten sind die operative Signatur dieses Musters:

• ein Länder-Remap in einer Qlik-App ist nicht derselbe Remap wie im Warehouse-Load;
• ein Parameter, der eine Fiskalperiode schließt, existiert nur in einer Notebook-Zelle;
• eine Berechtigung-Liste wird in drei Tools kopiert und unabhängig bearbeitet;
• eine Exception-Liste für „Sonderkunden“ wird als CSV per E-Mail verschickt und wöchentlich überschrieben.

Danach folgen Reload-Brüche. Ein Entwickler benennt eine Spalte im Excel-Mapping um. Ein Steward löscht eine Zeile, die noch in einem INLINE-Load vorkommt. Ein dbt-Seed wird in Git aktualisiert, während ein operatives CSV die Datei bleibt, die der Job tatsächlich liest. Die Pipeline scheitert spät — oder schlimmer: sie läuft durch mit stillschweigend falschen Joins.

Als Nächstes entstehen Audit-Lücken. Wenn ein Auditor fragt, wer das Mapping freigegeben hat, das die Umsatzallokation im letzten Quartal verändert hat, lautet die Antwort ein Git-Blame auf einem Skript, ein Timestamp im Fileshare oder „die Person, die gegangen ist“. Es gibt keinen Steward of Record, keine Valid-from-Historie und keine Consumer-Liste.

Multi-Tool-Duplikation vervielfacht die Kosten. Qlik, Power BI, Excel, SQL und Notebooks halten jeweils eine lokale Kopie „derselben“ Control-Tabelle. Teams reconcilen endlos. Metric Governance und Katalogprogramme stocken, weil die gemeinsamen Keys, die sie brauchen, keine eigene Asset-Klasse sind.

Das ist nicht dasselbe Problem wie Kennzahlen-Drift in Formeln, behandelt in Excel-Schatten-BI und Kennzahlen-Drift. Schatten-BI versteckt wiederverwendbare Berechnungen. Steuerdaten-Chaos versteckt wiederverwendbare Lookups, Parameter und Zugriffslisten. Es ist auch keine Semantic-Layer-Lücke: Kennzahlen definieren Measures; Steuerdaten definieren die kodierte Wahrheit, an die diese Measures joinen.

Verwandter Architekturkontext steht in der Serie Building a Modern Data Warehouse, der Serie BI-Governance-Entscheidungen und dem Catalog Deep Dive.

Entscheidung

Behandeln Sie Steuerdaten als eigene Asset-Klasse.

Steuerdaten sind die kleinen, geteilten, fachlich gepflegten oder architekturseitig besessenen Tabellen, die Loads, Joins, Zugriff und Interpretation steuern. Sie sind keine transaktionalen Fakten. Sie sind kein Dashboard. Sie sind kein einmaliger persönlicher Lookup.

Nutzen Sie eine praktische Taxonomie:

Entscheidungsrechte unterscheiden sich nach Klasse, aber alle sechs teilen dieselben Betriebsanforderungen: stabile ID, Owner, Change-Prozess, Publication Contract und Auffindbarkeit im Katalog.

Vergraben Sie Steuerdaten nicht in BI-Skripten als Source of Truth. Lassen Sie sie nicht nur in E-Mail-Excel. Tun Sie nicht so, als ersetze ein Glossareintrag eine gepflegte Tabelle. Platzieren Sie Steuerdaten dort, wo Stewardship, Historie und Consumers zusammentreffen — Teil 5 dieser Serie behandelt die Platzierung. Zuerst machen Sie die Asset-Klasse sichtbar und besessen.

Unterscheiden Sie klar:

• Metrics / Kennzahlenmodell — Definitionen von Measures und Populationen (BI-Governance-Entscheidungen).
• Shadow BI — unkontrollierte Arbeitsmappe-Autorität für wiederkehrende Entscheidungen (Excel-Schatten-BI und Kennzahlen-Drift).
• Kontrollregel data — kodierte Tabellen und Parameter, die Integration, Zugriff und Interpretation steuern.

Dünne BI-Apps brauchen trotzdem Control-Tabellen. Die Regel aus Fachliche Logik außerhalb der BI-Apps halten gilt: gemeinsame Wahrheit außerhalb der App; toolspezifisches Verhalten darf innen bleiben. Steuerdaten sind gemeinsame Wahrheit.

Checkliste

Bauen Sie ein First-Pass-Inventar, ohne das Meer auszukochen:

• listen Sie INLINE- / VALUES- / Seed- / „Enter data“-Tabellen in BI- und Transform-Jobs;
• listen Sie Excel-/CSV-Dateien, die als führende Quellen für Mappings und Parameter dienen;
• taggen Sie jeden Eintrag mit der Taxonomieklasse oben;
• erfassen Sie Nutzer (Apps, Modelle, Jobs) und Reload-/Veröffentlichungspfade;
• benennen Sie einen vorläufigen Owner und Backup verantwortliche Person;
• markieren Sie Sensitivität (besonders Berechtigung und personenbezogene Daten-verknüpfte Mappings) — siehe Access & Security Governance;
• notieren Sie, ob ein Katalogeintrag oder eine Richtlinie diese Tabelle bereits voraussetzt;
• kennzeichnen Sie stille Duplikate über Tools hinweg;
• erfassen Sie den zuletzt bekannten Change-Kanal (Git, E-Mail, UI, unbekannt);
• bewerten Sie operatives Risiko: Reload-Bruch, falscher Join, Audit-Lücke, Access-Leak.

Stoppen Sie, wenn Sie antworten können: Welche Control-Tabellen würden Governance morgen lahmlegen, wenn sie verschwinden?

Artefakt

Erstellen Sie ein Control Data Risk Register mit einer Zeile pro Steuerdaten-Item oder -Familie.

Pflichtfelder:

• stabile Kontrollregel-Data-ID;
• Name und Taxonomieklasse (reference / mapping / parameter / entitlement / hierarchy / exception);
• aktueller Ort (Script Inline, Excel, CSV, DB-Tabelle, Seed, Notebook);
• Owner und Backup verantwortliche Person;
• Nutzer und abhängige Jobs;
• Sensitivität und Zugriffshinweise;
• Change-Kanal und Evidenz der letzten Änderung;
• Duplikatgruppe (gleiche logische Tabelle an mehreren Orten);
• Katalog-/Richtlinie-Abhängigkeit (ja/nein und Link);
• Risiko-Tags: reload-break, silent-wrong, audit-gap, access-leak, orphan;
• Disposition: inventory, classify, extract, govern-in-place, retire-duplicate;
• Ziel-Owner und nächstes Review-Datum.

Ergebnisse: die Karte unsichtbarer Abhängigkeiten, die Duplikat-Cluster, die Berechtigung-Hotlist und der Backlog für Teile 2–5 dieser Serie.

Tools

Nutzen Sie Report Inventory und Lineage-Exports, um Consumers zu finden. Nutzen Sie Skript- und Repo-Suche nach INLINE, VALUES, Seed-Ordnern und hardcodierten Mapping-Arrays. Nutzen Sie den Katalog, um vorläufige Assets zu markieren, noch bevor sie physisch umziehen. Nutzen Sie Access Reviews für Berechtigung-Zeilen. Halten Sie Scanregeln Least-Privilege, wenn Dateien sensible Keys enthalten können.

Ressourcen

Nützliche interne Quellen sind Qlik-Skriptbibliotheken, dbt-Seed-Verzeichnisse, Warehouse-Lookup-Schemas, Fileshare-Mapping-Ordner, Section-Access-/RLS-Konfiguration, Steward-Interviews und frühere Incident-Tickets zu „falsches Mapping“ oder „Reload nach Excel-Änderung fehlgeschlagen“.

Architektur-Nachbarn: Building a Modern Data Warehouse, BI-Governance-Entscheidungen, Catalog Deep Dive. Wenn dieselbe Bedeutung in vielen Tools neu implementiert wird — nicht nur als dateibasierte Steuertabellen — weiter mit dem Redundanz Deep Dive.

Drei Apps joinen sales_otc über denselben Statuscode — die Wahrheit steckt nur in einem Qlik-INLINE. Inline-Tabellen sind Implementierungsdetail, bis mehrere Consumer von derselben kodierten Wahrheit abhängen.

zweiter Consumer dieselbe Kodierung teilt, driftet sie.

Lösung: Geteilte Steuerdaten als Produkt führen, sobald mehr als ein Consumer dieselbe Kodierung braucht — Inline bleibt lokal, bis genau dieser Fall eintritt.

In einem Satz: Inline ist Detail, bis ein zweiter Consumer dieselbe Wahrheit braucht.

Problem

Steuerdaten verstecken sich in vielen Formen offen sichtbar:

• Qlik-LOAD INLINE-Blöcke für Statusmaps, Regionsgruppen und „Fix“-Werte;
• SQL-VALUES / UNION ALL-Literaltabellen in Views und Prozeduren;
• dbt-Seeds, die als temporäre Fixtures starteten und ohne Stewardship zu produktiven Crosswalks wurden;
• Python- oder Notebook-Dictionaries und -Listen als Join-Keys in geplanten Jobs;
• Power-Query-„Enter data“-Tabellen, die in ein semantisches Modell eingefügt wurden.

Jedes Muster ist schnell für eine einzelne App. Geteilte Steuerdaten driften dann:

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

Qlik app     INLINE status 90 = Cancelled
Warehouse    VALUES status 90 = Cancelled, 95 = Void
dbt seed     status 90 = Cancelled (old label)
Power Query  Enter data: status 90 = Canceled (US spelling, different code set)

Entwickler kopieren den Block in die nächste App. Stewards können nicht an einer Stelle ändern. Kataloge sehen die Tabelle nie. Lineage-Tools melden „kein Upstream“. Auditoren finden fachliche Bedeutung in Source-Control-Kommentaren statt in einem besessenen Dataset.

Teil 1 hat Steuerdaten als Asset-Klasse gerahmt. Teil 2 isoliert das Inline-Muster, weil es der häufigste Weg ist, wie gemeinsame Wahrheit unsichtbar wird — und dabei trotzdem „in der Plattform“ aussieht.

Inline ist nicht immer falsch. Falsch ist es als System of Truth für Steuerdaten, die geteilt, sensitiv, historisch relevant oder von mehr als einem Delivery-Pfad konsumiert werden. Das deckt sich mit Fachliche Logik außerhalb der BI-Apps halten: gemeinsame Bedeutung außerhalb des Consumer-Artefakts; tool-lokales Verhalten darf lokal bleiben.

Entscheidung

Inline = Implementierungsdetail. Nie die Source of Truth für geteilte Steuerdaten.

Erlaubte Nutzungen von Inline-/Literaltabellen:

• Wegwerf-Prototypen und Spikes mit benanntem Sunset-Datum;
• echt app-lokale Präsentationslabels, die kein anderer Nutzer wiederverwenden muss;
• synthetische Demo-Daten, klar als Non-Production markiert;
• temporäre Bridges während einer Migration mit explizitem Exportdatei-Ticket;
• Unit-Test-Fixtures, die nicht als produktive Kontrollregel-Tabellen deployt werden.

Extrahieren Sie, wenn eine der folgenden Bedingungen zutrifft:

• zwei oder mehr Apps, Modelle oder Jobs brauchen dasselbe Mapping oder denselben Reference-Satz;
• Finance, Risk oder regulatorisches Reporting hängt von den Codes ab;
• Berechtigung oder personenbezogene Daten-verknüpfte Keys sind involviert (Access & Security Governance);
• Änderungshistorie zählt (wer hat was geändert, valid_from / valid_to);
• der Katalog oder eine Richtlinie benennt das Konzept bereits;
• Reload- oder Publish-Fehler wurden bereits durch eine Inline-Änderung verursacht;
• ein Steward außerhalb des Entwicklerteams muss die Werte pflegen.

Extraktionsziel ist eine governte Control-Tabelle (oder eine freigegebene API/UI über diese Tabelle). Das Skript darf die Tabelle weiterhin laden; es darf sie nicht besitzen. dbt-Seeds dürfen nur dann Packaging-Format bleiben, wenn der Seed aus dem besessenen Store generiert oder strikt dazu synchronisiert wird — nicht, wenn die CSV in Git die einzige Editor-Oberfläche für Fach-Stewards ist.

Verwechseln Sie diese Entscheidung nicht mit einem Verbot von Excel-Analyse (Excel-Schatten-BI und Kennzahlen-Drift). Inline-Extraktion betrifft kodierte geteilte Tabellen, nicht das Entfernen jeder consumerseitigen Formel.

Checkliste

Führen Sie ein Inline-Inventar durch, bevor Sie Architektur umschreiben:

• durchsuchen Sie Repos und Skriptbibliotheken nach INLINE, LOAD * INLINE, VALUES (, Seed-Ordnern, Enter data, hardcodierten dict( / Mapping-Arrays;
• erfassen Sie Dateipfad, Objektname, Zeilenanzahl-Band und Taxonomieklasse aus Teil 1;
• zählen Sie Nutzer und Duplikatskopien;
• markieren Sie Sensitivität und ob Änderungen fachliche Freigabe brauchen;
• entscheiden Sie: keep-local, extract, deduplicate-then-extract, retire;
• benennen Sie für jedes extract den Ziel-Store und Steward;
• ersetzen Sie Inline-Loads durch einen einzigen Read von der besessenen Tabelle;
• ergänzen Sie eine CI- oder Scan-Regel, damit neue geteilte Inlines nicht unbemerkt landen;
• aktualisieren Sie Katalogeinträge und Lineage, sobald die Tabelle real ist;
• führen Sie eine kurze Exception-Liste für freigegebene lokale Inlines mit Ownern und Review-Daten.

Bevorzugen Sie langweilige Konsistenz: ein Extract-Muster pro Plattform (Qlik Resident aus der Control-DB, dbt ref auf Control-Modell, Power Query aus zertifizierter Quelle).

Artefakt

Erstellen Sie Inline Inventory Scan Rules — ein lebendes Regelwerk plus Scan-Output, keine einmalige Spreadsheet.

Minimales Regelpaket:

Scan-Output-Felder: Rule ID, Location, Hash/Fingerprint, Klasse, Consumers, Owner, Disposition, Ticket-Link.

Wiederholen Sie den Scan im Zeitplan und bei Pull Requests, die Skriptpfade berühren.

Tools

Nutzen Sie ripgrep / CI-Scanner im Secret-Stil, adaptiert für INLINE und VALUES. Nutzen Sie dbt-Projektparser für Seeds. Nutzen Sie Qlik- und Power-BI-Source-Control-Diffs. Nutzen Sie Report Inventory, um Consumers anzubinden. Nutzen Sie Katalog-Bulk-Import, sobald extrahierte Tabellen existieren. Abgleichen Sie mit dem Control Data Risk Register aus Teil 1.

Ressourcen

Skriptbibliotheken, Transformations-Repos, Semantic-Model-PBIX/PQ-Traces, Notebook-Job-Definitionen, frühere Incidents zu „falschem Code-Mapping“ und Steward-Listen.

Schwesterlektüre: Fachliche Logik außerhalb der BI-Apps halten, Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen, Building a Modern Data Warehouse, Catalog Deep Dive.

Das Länder-Mapping für sales_otc kommt als CSV per Mail — zwei Reloads später weichen Warehouse und BI ab. Excel/CSV als führende Quelle bricht, sobald mehrere Systeme dieselbe Liste brauchen.

zwei Reloads später weichen Warehouse und BI ab. File-as-Source bricht, sobald mehrere Systeme dieselbe Liste brauchen.

Lösung: Fachbereiche pflegen Steuerdaten über stabile Keys und eine Stewardship-UI oder API; Excel darf Input sein, nicht der Contract.

In einem Satz: CSV als führende Quelle ist kein Steuerdaten-Vertrag.

Problem

File-as-Source-Steuerdaten brechen Pipelines auf vorhersehbare Weise:

• Spaltenumbenennungen — „Country Name“ wird zu „Country“ oder „Land“; der Load läuft weiter, wenn das Schema locker ist, oder scheitert, wenn es streng ist;
• Sheet-Reihenfolge und -Namen — Jobs, die „erstes Sheet“ oder einen hardcodierten Sheet-Titel lesen, greifen die falsche Tabelle, nachdem ein Nutzer ein Cover-Tab einfügt;
• Locale — Dezimal-Kommas, Datumsformate und Listentrenner ändern sich je nach Maschine und Region;
• Type Inference — führende Nullen bei Cost Centers werden gestrippt; Codes werden zu Zahlen; lange IDs werden zu wissenschaftlicher Notation;
• Merge-Konflikte — zwei Stewards mailen „final_v3“ und „final_v3_TL“; niemand weiß, welche Datei der Job genutzt hat;
• E-Mail-Kopien — der Orchestrierungspfad zeigt auf einen Partnerfreigabe, während Menschen einen Postfach-Anhang bearbeiten.

Diese Fehler sind operativ, nicht ästhetisch. Eine umbenannte Mapping-Spalte kann Joins auf unknown fallen lassen und erst in einem KPI-Review auftauchen. Eine Locale-Verschiebung kann Thresholds ummappen. Eine Berechtigung-CSV, die in Excel geöffnet wird, kann Keys korrumpieren und stillschweigend Zugriff erweitern — ein direktes Thema für Access & Security Governance.

Unterscheiden Sie diese Story von Excel-Schatten-BI und Kennzahlen-Drift. Schatten-BI betrifft Formeln, Refresh-Autorität und Kennzahlendefinitionen in Workbooks. Dieser Teil betrifft Control-Tabellen — Reference, Mapping, Parameter, Berechtigung, Hierarchy, Exception — deren führende technische Quelle eine mutable Datei ohne Schema Contract ist.

Inline-Extraktion (Teil 2) ohne File Contract verschiebt dieselben Bruchmodi nur in einen CSV-Seed-Ordner. Die Entscheidung muss abdecken, wie fachliche Pflege funktioniert, ohne das Grid zur API zu machen.

Entscheidung

Fachbereiche dürfen Steuerdaten über stabile Keys und eine Stewardship-UI oder API pflegen. Excel und CSV sind als Input oder Export erlaubt — nicht als unkontrollierter führender Contract.

Erlaubte Excel-/CSV-Rollen:

1. Staging Import — Nutzer lädt ein validiertes Template in einen kontrollierten Intake; die Plattform validiert Schema, lehnt schlechte Zeilen ab und schreibt in den Control Store;
2. Analysis Consumer — Nutzer lädt einen veröffentlichten Extract herunter oder verbindet sich dazu für lokale Analyse; Änderungen in dieser Kopie fließen nicht in die Produktion;
3. Validated Template Upload — versioniertes Template mit gesperrten Headern, dokumentiertem stable_id und automatisierten Checks vor dem Publish.

Verboten als führende Quelle für geteilte Steuerdaten:

• freie Workbooks auf einem Fileshare, die Jobs direkt lesen;
• gemailte CSVs, die in den „offiziellen“ Ordner umbenannt werden;
• Power Query „lies, was in diesem Pfad liegt“ ohne Vereinbarung-Tests;
• im Lake gelandete Raw-CSV als Steward-UI.

Minimaler Schema Contract für Control-Tabellen (Datei oder Datenbank):

Ergänzen Sie klassenspezifische Felder nach Bedarf (parent_id für Hierarchien, principal_id für Berechtigungs, source_code / target_code für Mappings). Lehnen Sie Loads ab, die Uniqueness von stable_id im aktiven Fenster verletzen, unbekannte Spalten im Strict Mode oder Typchecks für Keys.

Stewardship-UI/API kann sich weiterhin wie Excel anfühlen (Grid-Editing), während sie in einen relationalen Control Store schreibt. Das ist der bevorzugte Pfad, wenn Änderungsfrequenz und Sensitivität das rechtfertigen. Bis dahin ist Template-Upload mit Validierung besser als Raw File-as-SoT.

Das unterstützt dünne Consumers und gemeinsame Wahrheit (Fachliche Logik außerhalb der BI-Apps halten), ohne zu tun, als müssten Fachanwender am ersten Tag SQL lernen.

Checkliste

Bevor Sie eine Datei als Steuerdaten-Pfad akzeptieren:

• benennen Sie Taxonomieklasse und verantwortliche Person;
• sperren Sie Header-Namen und -Reihenfolge in einem veröffentlichten Template;
• fordern Sie stable_id, label, valid_from (plus valid_to, wenn Historie zählt);
• definieren Sie Encoding, Delimiter, Datumsformat und Dezimalregeln explizit;
• verbieten Sie Sheet-Positionsadressierung; adressieren Sie nach Sheet-Name und Tabellenname;
• validieren Sie Typen für Keys (führende Nullen als Text erhalten);
• führen Sie Vereinbarung-Tests in CI oder Pre-Publish aus;
• speichern Sie akzeptierte Dateien als Evidenz, nicht als Live-Editor-Oberfläche;
• schreiben Sie akzeptierte Zeilen in die Kontrollregel-Datenbank / governte Tabelle;
• veröffentlichen Sie Nutzer nur von dieser Tabelle;
• protokollieren Sie, wer was hochgeladen hat und welche Version aktiv wurde;
• für Berechtigungs: Dual Kontrollregel oder Approval-Workflow verlangen;
• retireen Sie direkte Job-Reads gegen den editierbaren Partnerfreigabe-Pfad.

Wenn ein Team auf „einfach die CSV“ besteht, behandeln Sie das als temporären Staging Import mit Expiry-Ticket — nicht als Architektur.

Artefakt

Erstellen Sie eine File-as-Source Failure Mode Checklist, die in Design Reviews und Incident-Retros genutzt wird, zusammen mit dem Schema-Contract-Minimum.

Failure-Mode-Checkliste (abhaken und Owner zuweisen):

• Spaltenumbenennung / Header-Drift;
• zusätzliche oder fehlende Spalten;
• Sheet-Umbenennung oder Reihenfolgeänderung;
• Locale- / Delimiter- / Encoding-Mismatch;
• Type Inference auf Keys (führende Nullen, wissenschaftliche Notation);
• doppelter stable_id im aktiven Gültigkeitsfenster;
• überlappende valid_from / valid_to-Ranges;
• E-Mail- oder Chat-Kopie weicht vom Job-Pfad ab;
• parallele Editoren ohne Merge-Regeln;
• personenbezogene Daten- oder Berechtigung-Keys in ungeschützten Partnerfreigaben;
• Nutzer liest noch den Dateipfad statt der Kontrollregel-Tabelle;
• kein Rejection-Pfad (schlechte Datei wird trotzdem teilweise geladen).

Schema-Contract-Minimumfelder: stable_id, label, valid_from (+ empfohlen valid_to, updated_by, updated_at, row_hash).

Legen Sie die ausgefüllte Checkliste neben dem Control-Data-Risk-Register-Eintrag für jede file-backed Familie ab.

Tools

Nutzen Sie Template-Generatoren und Schema-Validatoren im Intake-Pfad. Nutzen Sie Contract-Tests in dbt oder Pipeline-CI. Nutzen Sie DLP und Share-Berechtigungen für sensible Berechtigung-Dateien. Nutzen Sie Katalogeinträge, die auf die Control-Tabelle zeigen, nicht auf das editierbare Workbook. Nutzen Sie Report Inventory, um Jobs zu finden, die noch Raw-Pfade lesen.

Ressourcen

Fileshare-Inventare, Orchestrierungs-Job-Definitionen, frühere Reload-Incident-Tickets, Steward-Prozessdokumentation und das Excel-Shadow-BI-Register, wenn dasselbe Workbook Formeln und Control-Listen mischt — trennen Sie diese Anliegen.

Verwandte Serien: BI-Governance-Entscheidungen, Building a Modern Data Warehouse, Catalog Deep Dive.

Ein INLINE für sales_otc-Status soll „ins Lake“ — ohne Klasse für Pflege, Historie und Consumer. Klassifikation vor dem Umzug verhindert den nächsten versiegelten Ordner.

zu verschieben.

Lösung: Klassifizieren, bevor Sie Technologie wählen.

In einem Satz: Klassifizieren, bevor Sie Technologie wählen.

Problem

Nach Teilen 1–3 haben Sie üblicherweise ein Risk Register, einen Inline-Scan-Backlog und ein paar File-as-Source-Fehler. Die Versuchung ist, alles in die heißeste Plattform des Quartals zu verschieben.

Das scheitert, weil Steuerdaten-Familien nicht gleich sind:

• ein dreizeiliges Parameter-Set, das jährlich aktualisiert wird, braucht kein Streaming-Lakehouse;
• eine wöchentliche Produkthierarchie mit fünfzig Nutzer braucht zuverlässige Publication und Historie;
• eine Berechtigung-Liste braucht Zugriffskontrolle auf den Steuerdaten selbst (Access & Security Governance);
• eine Ein-App-Präsentations-Label-Map darf nach expliziter Freigabe lokal bleiben (Teil 2).

Ohne Matrix debattieren Architekten Technologie, während Stewards weiter Excel editieren. Klassifikation ist der fehlende Entscheidungsschritt zwischen Extraktion und Platzierung. Sie füttert den Katalog außerdem mit ehrlichen Metadaten vor physischen Moves (Catalog Deep Dive).

Klassifikation ist keine Metrik-Zertifizierung (BI-Governance-Entscheidungen) und keine Shadow-BI-Disposition (Excel-Schatten-BI und Kennzahlen-Drift). Sie beantwortet: Welche Art Control-Asset ist das, und welche Betriebseigenschaften muss das zukünftige Zuhause erfüllen?

Entscheidung

Klassifizieren, bevor Sie Technologie wählen.

Bewerten Sie jedes Steuerdaten-Item entlang fünf Dimensionen und mappen Sie es auf eine Operating Class, die die Platzierung in Teil 5 einschränkt.

Matrix-Dimensionen

Operating Classes (Beispiele)

C1 — Local disposable
Klein, einzelner Consumer, niedrige Sensitivität, keine Historie. Beispiel: app-lokale Chart-Farbmap. Disposition: lokal behalten oder nur aus Hygiene extrahieren.

C2 — Shared reference (stable)
Klein/mittel, seltene Änderungen, viele Consumers, niedrige–mittlere Sensitivität. Beispiel: ISO-Ländercodes, Währungscodes. Disposition: governte Reference-Tabelle, einfaches Stewardship, Snapshot optional.

C3 — Shared mapping (active)
Mittlere Größe, regelmäßige Änderungen, mehrere Consumers. Beispiel: Quellkonto → Golden Account. Disposition: Control-DB oder Äquivalent mit stable_id und Validity; Snapshots nach Warehouse/Lake nach Bedarf publishen.

C4 — Parameter set
Winzig, Änderungsfrequenz variabel, hoher Blast Radius. Beispiel: Period-Close-Flags, Thresholds. Disposition: kontrollierter Parameter Store mit Change Log und klaren Ownern; nie nur in Job-Variablen vergraben.

C5 — Berechtigung / Security Control Data
Beliebige Größe, Sensitivität hoch. Beispiel: Cost-Center-Allow-Lists für RLS / Section Access. Disposition: gehärteter Store, Least Privilege, Approval-Workflow, Audit Trail; Distribution eng kontrolliert.

C6 — Hierarchy
Struktur zählt; Änderung und Historie oft medium–high. Beispiel: Produkt- oder Org-Tree. Disposition: relationales Parent/Child oder dedizierter Hierarchy Service; abgeflachte Versionen in Analytics Stores publishen.

C7 — Exception list
Oft klein, politisch sensibel, hoher Impact auf Kennzahlen. Beispiel: manuelle Include-Konten für Revenue. Disposition: expliziter Owner, Expiry-Daten, Link zu Kennzahlendefinitionen; nicht nur in Report-Filtern verstecken.

Technologie kommt nach der Klasse: Teil 5 legt die Pflege der meisten geteilten C2–C7 standardmäßig in eine kleine relationale Control-Datenbank, mit Lake/Warehouse für Distribution und Historie — nie CSV-in-Lake als Maintenance-UI.

Ausrichten an dünnen BI-Consumers (Fachliche Logik außerhalb der BI-Apps halten) und Warehouse-Produktdenken (Building a Modern Data Warehouse).

Checkliste

Für jede Risk-Register-Zeile:

• Größe, Änderungsfrequenz, Nutzer, Sensitivität, Historiebedarf ausfüllen;
• Taxonomieklasse zuweisen (reference / mapping / parameter / entitlement / hierarchy / exception);
• Operating Class C1–C7 zuweisen;
• non-negotiable Properties listen (Audit, Approval, SLA, personenbezogene Daten);
• Steward und technischer Betreiber benennen;
• Publish-Targets entscheiden (welche Warehouses, BI-Modelle, APIs);
• „must not“-Constraints erfassen (z. B. darf nicht INLINE bleiben, darf keine editierbare Lake-CSV sein);
• erst dann ein Placement-ADR öffnen (Teil 5);
• Katalogattribute mit Klasse und Ownern vor oder beim Move aktualisieren;
• Klassifikation neu bewerten, wenn Nutzer oder Sensitivität sich ändern.

Lehnen Sie Platzierungsdebatten ab, die die Card überspringen.

Ausgearbeitetes Beispiel (kurz):

• Ländercodes — Größe low, Änderung selten, Nutzer high, Sensitivität low, Historie optional → C2. In Kontrollregel-DB pflegen; Warehouse-Dimension publishen.
• Source-to-Golden-Customer-Map — Größe medium, Änderung wöchentlich, Nutzer high, Sensitivität medium, Historie ja → C3. Kontrollregel-DB mit Validity; Warehouse-Snapshot für Joins.
• Section-Access-Cost-Center-Liste — beliebige Größe, Sensitivität high → C5. Gehärteter Store zuerst; Klassifikation blockiert „drop it in the lake“, bevor ein Ticket geöffnet wird.
• Chart-Farbmap in einer Qlik-App — C1. Keinen Plattform-Service erfinden.

Dieselbe Matrix stoppt sowohl Under-Engineering (Berechtigungs als CSV) als auch Over-Engineering (Parameter-Flags in einem Multi-Hop-Lakehouse).

Artefakt

Erstellen Sie eine Control Data Classification Card pro Item oder Familie (eine Seite / ein Ticket-Template).

Card-Felder:

• Kontrollregel-Data-ID und Name;
• Taxonomieklasse;
• Operating Class C1–C7;
• Scores: Größe, Änderungsfrequenz, Nutzer, Sensitivität, Historiebedarf;
• aktueller Ort und Duplikatgruppe;
• Steward, technischer Betreiber, Backup;
• erforderliche Properties (Audit, Approval, Encryption, SLA);
• erlaubter Maintenance-Kanal (UI/API, validiertes Template, nur Entwickler);
• verbotene Kanäle;
• Publish-Targets;
• Link zu Risk Register und Inline-/File-Checklisten;
• vorgeschlagene Placement-Optionen (nur Shortlist);
• Review-Datum.

Drucken oder ticketen Sie die Card in Architekturforen, damit „wohin damit?“ von gemeinsamen Fakten startet.

Tools

Nutzen Sie das Risk Register als Backlog-Quelle. Nutzen Sie Katalog-Custom-Attributes für die Operating Class. Nutzen Sie Access-Review-Tooling für C5. Nutzen Sie einfaches Scoring in Sheet oder Intake-Form — Raffinesse ist optional; Vollständigkeit nicht. Halten Sie BI- und Warehouse-Inventare verknüpft, damit Consumer-Counts ehrlich bleiben.

Ressourcen

Steward-Interviews, Incident-Historie, Access Policies, Kennzahlendefinitionen, die von Exception-Listen abhängen, und Hierarchy-Owner im Fachbereich.

Serienkontext: Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen, Catalog Deep Dive, BI-Governance-Entscheidungen.

Geteilte Statuscodes für sales_otc liegen als CSV im Lake — niemand versioniert, niemand testet Joins. Platzierung folgt Maintenance und Distribution, nicht dem nächsten Speichertrend.

zdem zur Gewohnheit: CSV im Lake als Pflege-UI, obwohl niemand versioniert und Joins nicht testet.

Lösung: Default ist eine kleine relationale Control-Datenbank für fachlich gepflegte geteilte Tabellen; Lake oder Warehouse nur für Distribution und Historie — nie CSV-im-Lake als Maintenance-UI.

In einem Satz: Pflege-UI und Speichertrend sind nicht dieselbe Entscheidung.

Problem

Nach der Klassifikation (Teil 4) greifen Teams trotzdem zur Gewohnheit:

• „alles Analytische geht ins Warehouse“ — inklusive zwanzigzeiliger Codelisten, die Stewards nur in Excel editieren können;
• „der Lake ist unsere Plattform“ — also überschreiben Stewards s3://…/mappings/countries.csv und hoffen, dass Crawler es merken;
• „Postgres ist zu operational“ — also bleiben Parameter in Pipeline-Variablen und INLINE-Blöcke kehren zurück;
• „nur eine Kopie“ — also stirbt historisches As-of-Reporting, oder jeder Nutzer liest die Live-Edit-Tabelle ohne Publish-Schritt.

Anti-Patterns explizit benennen:

• CSV-in-Lake als Maintenance-UI — keine Constraints, schwaches Audit, leichte stille Korruption (Teil 3);
• Warehouse-Tabelle als einzige Editor-Oberfläche ohne Stewardship-Rechte und Validierung;
• BI-App-INLINE als SoT, nachdem Sie bereits entschieden haben zu extrahieren (Teil 2);
• Duplicate Masters in Kontrollregel-DB und unkontrolliertem Excel und Seed-Ordnern;
• Berechtigung-Listen in weltlesbaren Lake-Pfaden (Access & Security Governance).

Warehouse und Lake bleiben essenziell für Analytics-Distribution, SCD-Snapshots und große abgeleitete Hierarchien. Sie sind selten der beste Ort, an dem Menschen kleine geteilte Wahrheit pflegen. Das entspricht dem Plattform-Split in Building a Modern Data Warehouse und dünnen Consumers in Fachliche Logik außerhalb der BI-Apps halten.

Entscheidung

Standard: kleine relationale Control-Datenbank für fachlich gepflegte geteilte Control-Tabellen. Lake oder Warehouse für Snapshots, Distribution und Analytics — nie CSV-in-Lake als Maintenance-UI.

Praktische Defaults nach Operating Class:

PostgreSQL (oder das Standard-RDBMS der Organisation) ist für viele Control-DBs ausreichend: Constraints, Keys, Rollen, Migrations, langweiliges Backup. Die Marke zählt weniger als die Eigenschaften — relationale Integrität, Zugriffskontrolle, Change Audit und eine API/UI, die Stewards nutzen können.

Publish-Muster:

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

Steward UI / validated template
        → Control DB (system of record)
        → batch or CDC publish
        → Warehouse / Lake snapshots (system of distribution)
        → BI apps / dbt / semantic models (consumers)

Consumers dürfen nicht in die Distribution-Kopie zurückschreiben, als wäre sie der Master. Katalogeinträge sollten sowohl auf das Control-Asset als auch auf seine veröffentlichten Projektionen zeigen (Catalog Deep Dive).

Entscheidungs-Flowchart:

flowchart TD
  A[Control data item] --> B{Shared across consumers?}
  B -->|No| C{Sensitive or audit needed?}
  C -->|No| D[Keep local inline/file with review date]
  C -->|Yes| E[Extract to control DB]
  B -->|Yes| F{Berechtigung or PII-linked?}
  F -->|Yes| G[Hardened control DB + approval]
  F -->|No| H{Business-maintained?}
  H -->|Yes| E
  H -->|No| I[Control DB or repo-synced table with owner]
  E --> J{Need analytics history or wide distribution?}
  G --> J
  I --> J
  J -->|Yes| K[Publish snapshots to WH and/or lake]
  J -->|No| L[Consumers read control DB or thin API]
  K --> M[BI / dbt / models consume publish layer]
  L --> M
  K --> N[Never edit lake/WH CSV as SoT]
  N --> E

Dokumentieren Sie jede nicht-triviale Platzierung als leichte Architekturentscheidung, damit das nächste Team die Debatte nicht neu entdeckt.

Checkliste

• Classification Card als vollständig bestätigen;
• Maintain-Store wählen (meist Kontrollregel-DB);
• Publish-Targets und Cadence wählen;
• Schema Vereinbarung definieren (stable_id, label, valid_from, …);
• Rollen definieren: Steward, technischer Betreiber, Reader-Rollen für Publish Layer;
• direkte Nutzer-Writes auf Publish-Kopien verbieten;
• editierbare Lake-CSV als SoT verbieten;
• Katalog + Lineage für Kontrollregel- und Publish-Objekte verdrahten;
• INLINE-/Datei-Quellen migrieren und Duplikate löschen;
• Backup-, Migrations- und Access-Review-Cadence setzen;
• für C5 Access-Design vor Produktivstart abschließen;
• Placement Decision Record schreiben;
• erstes Post-Move-Review planen.

Artefakt

Erstellen Sie einen Placement Decision Record (ADR-light) pro Steuerdaten-Familie.

Template-Abschnitte:

1. Title — z. B. Product hierarchy control placement;
2. Status — proposed / accepted / superseded;
3. Context — Links zu Risk Register, Classification Card, Consumers;
4. Decision — Maintain-Store, Publish-Targets, Maintenance-Kanal;
5. Consequences — was sich verbessert, was schwerer wird, Cost/Ops-Notizen;
6. Rejected alternatives — Lake-CSV-SoT, nur-Warehouse-Edit, INLINE belassen usw.;
7. Schema contract — Keys und Validity-Felder;
8. Security — besonders für Berechtigung-Klasse;
9. Owners and review date.

Kurz halten. Ziel ist eine dauerhafte Entscheidung, kein Whitepaper.

Tools

Nutzen Sie RDBMS-Migrations für Control-DB-Schema. Nutzen Sie Steward-UI oder validierten Intake aus Teil 3. Nutzen Sie Orchestrierung zum Publishen von Snapshots. Nutzen Sie dbt oder Warehouse-Jobs für Distribution-Modelle. Nutzen Sie Katalog-Sync für beide Schichten. Nutzen Sie Access-Review-Tooling für C5. Bevorzugen Sie ein Control-DB-Muster pro Organisation, um einen Zoo von One-off-SQLite-Dateien zu vermeiden.

Ressourcen

Bestehende Lookup-Schemas, IAM-Muster, Warehouse-Dim-Konventionen, Lake Landing Zones (nur als Publish-Targets) und frühere ADRs für Master Data.

Schwester-Stories: Steuerdaten klassifizieren, bevor man sie verschiebt, Excel-Schatten-BI und Kennzahlen-Drift, Fachliche Logik außerhalb der BI-Apps halten, Serien-Hubs Building a Modern Data Warehouse, BI-Governance-Entscheidungen, Catalog Deep Dive.

OpenMetadata und Lake-Formate listen sales_otc-Tabellen — Status-Mappings und Berechtigungs pflegen sie nicht. Der Control-Data-Stack braucht eigene Pflegeorte; Catalog allein ersetzt sie nicht.

In einem Satz: Bauen Sie einen minimal lebensfähigen Steuerdaten-Stack um PostgreSQL für fachlich gepflegte, multi-Consumer-Steuertabellen.

Problem

Teams suchen oft nach einem „Steuerdaten-Produkt“ und landen bei drei Fehlstarts.

Der erste ist ein Katalog. OpenMetadata oder DataHub können Verantwortung, Lineage und Glossarbegriffe zeigen. Sie werden nicht zum Schreibpfad für Status-Mappings oder Kostenstellenhierarchien. Sichtbarkeit ohne governte Tabelle lässt Consumer weiterhin Inline-LOAD INLINE, Excel-Sheets oder Notebook-Dictionaries lesen.

Der zweite ist eine Lake-Tabelle als Pflege-UI. Iceberg oder Delta können große, historisierte Referenz-Snapshots verteilen. Sie geben Stewards keine Validierung, Freigabe, Audit darüber, wer eine Zeile geändert hat, und keinen stabilen Schlüsselvertrag. Eine CSV in Object Storage ist weiterhin der Failure Mode „Datei als führende Quelle“ aus Excel und CSV als führende Quelle zerstören Pipelines.

Der dritte ist ein generisches Low-Code-Grid auf einem undefinierten Schema. Adminer, Metabase-Formulare oder NocoDB können Zeilen schnell editieren. Ohne Migrationen, Constraints, Audit und eine veröffentlichte Consumer-View wird das Grid zu einem zweiten Excel mit schönerer URL.

Der echte Bedarf ist klein: einige Dutzend bis einige Tausend Zeilen, die Fachbereiche ändern, die mehrere BI-Apps und SQL-Jobs teilen müssen und die Spaltenumbenennungen sowie Owner-Übergaben überstehen. Dieser Bedarf wurde in Steuerdaten vor dem Umzug klassifizieren klassifiziert und in Wohin Steuerdaten gehören platziert. Die Technologieentscheidung kommt nach diesen Entscheidungen.

Entscheidung

Bauen Sie einen minimal lebensfähigen Steuerdaten-Stack um PostgreSQL für fachlich gepflegte, multi-Consumer-Steuertabellen. Fügen Sie eine Stewardship-UI nur hinzu, wenn der Prozess dazu passt. Nutzen Sie Lake-Formate für Verteilung und Analytik, nicht für Stewardship. Nutzen Sie den Katalog für Discovery und Evidenz, nicht als System of Record.

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

PostgreSQL          persistence, constraints, RLS, migrations
Stable views/API    consumer contract
Backup + access     operational baseline
Optional UI         Adminer / forms / NocoDB / DIY — only if process fits
Catalog             ownership, lineage, recertification evidence
Lake/warehouse      snapshots and analytic spread — not the write path

Die Default-Platzierung bleibt eine kleine relationale Steuerdatenbank. Das passt zu Fachlogik außerhalb der BI-Apps halten: geteilte Wahrheit lebt außerhalb von Qlik, Power BI und Excel; Consumer bleiben dünn.

PostgreSQL als Kern

PostgreSQL ist die Default-Open-Source-Persistenzschicht, weil sie zur Nutzung von Steuerdaten passt:

• stabile Primärschlüssel und Fremdschlüssel zwischen Mapping-Tabellen;
• CHECK-Constraints und Domains für geschlossene Vokabulare;
• Schemas als Produktgrenzen (control_sales, control_access);
• Views als veröffentlichter Vertrag, während Basistabellen sich weiterentwickeln;
• Row-Level Security, wenn Berechtigungs- oder personenbezogene Daten-nahe Listen steward-scoped Writes brauchen;
• Migrations-Tooling (Flyway, Liquibase, Sqitch oder SQL-Dateien in CI), damit Schemaänderungen reviewbar sind;
• Point-in-Time-Backup und Restore als First-Class-Betriebsanforderung.

Typische Objekte:

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

control_<domain>.<asset>_base     editable table
control_<domain>.v_<asset>        published consumer view
control_<domain>.<asset>_audit    append-only change log (or temporal)

Veröffentlichen Sie Consumer auf der View, nicht auf der editierbaren Basistabelle. BI-Reloads, dbt-Sources und APIs dürfen nicht von UI-Spaltennamen oder Draft-Zeilen abhängen.

DuckDB, SQLite und Lake-Formate — klare Grenzen

DuckDB ist hervorragend für lokale Analytik, Reconciliation und einmalige Validierung von Steuerdaten-Extrakten. Es ist kein Enterprise-Stewardship-Store: Multi-User-Write-Concurrency, dauerhafte gemeinsame Zugriffskontrolle und betriebliches Backup/Restore für Fach-Stewards sind nicht seine Aufgabe.

SQLite passt zu Edge-Geräten, Single-Node-Tools und eingebetteten Prototypen. Es ist eine schlechte gemeinsame Steuerdatenbank für mehrere Stewards und produktive BI-Consumer.

Iceberg / Delta (mit Table Catalog) passen zu großen historisierten Referenzverteilungen, Cross-Engine-Reads und warehouse-ähnlichen Snapshots bereits governeter Steuerprodukte. Sie ersetzen nicht:

• Steward-Schreibworkflows;
• zeilenweise Validierung beim Editieren;
• Freigabe-Queues für Berechtigungs;
• Audit „wer hat dieses Mapping gestern geändert?“ für eine fünfzigzeilige Tabelle.

Anti-Pattern: „Wir legen das Mapping in den Lake, dann ist es governed.“ Verteilung ist keine Pflege.

Stewardship-UIs als optionale Beispiele

Behandeln Sie Folgendes als Beispiele mit Grenzen, nicht als empfohlene Produkt-Shortlist:

Übernehmen Sie eine UI nur, wenn sie serverseitige Validierung, rollenbasierte Schreibrechte, Audit-Evidenz und einen stabilen Consumer-Vertrag unterstützt — oder davor sitzt. Kann die UI das nicht, behalten Sie Postgres + Migrationen und wechseln Sie zu einem bewusst kleinen DIY-Schreibpfad in Einfache Stewardship-Lösungen selbst bauen, wenn kein Tool passt.

Katalog für Sichtbarkeit, nicht zum Schreiben

Verdrahten Sie Steuer-Schemas in OpenMetadata oder DataHub, damit Stewards und Consumer sehen:

• Owner und Steward;
• Beschreibung und Klassifikation;
• Lineage in Qlik-Apps, Power-BI-Modelle und Warehouse-Jobs;
• Quality- oder Freshness-Signale, wo sinnvoll;
• Rezertifizierungsdaten.

Das ist die governance-seitige Oberfläche aus dem Catalog Deep Dive. Der Katalog wird nicht zum Editor. Teil 8 bindet dieselben Assets an einen operativen Produktvertrag — unabhängig davon, ob der Schreibpfad OSS-UI oder DIY ist.

Entscheidungsregel

OSS zuerst für Persistenz und Vertrag. UI nur, wenn der Pflegeprozess passt. Lake und Katalog erweitern Verteilung und Sichtbarkeit — sie ersetzen kein Stewardship.

Passt innerhalb weniger Wochen keine UI, warten Sie nicht auf ein MDM-Programm. Bevorzugen Sie einen kleinen Custom-Schreibpfad gegenüber Excel als führender Quelle und gegenüber einem ungesteuerten Grid.

Checkliste

• Steuerdaten-Assets sind klassifiziert und haben eine Platzierungsentscheidung, bevor Tooling gewählt wird.
• PostgreSQL (oder eine äquivalente relationale Steuer-DB) ist System of Record für geteilte, fachlich gepflegte Tabellen.
• Schemaänderungen laufen über Migrationen in Version Kontrollregel.
• Nutzer lesen veröffentlichte Views oder APIs, nicht editierbare Basistabellen oder UI-Grids.
• Constraints decken Schlüssel, geschlossene Vokabulare und erforderliche Fremdschlüssel ab.
• Backup, Restore und Zugriffsrollen sind für das Steuer-Schema definiert.
• DuckDB/SQLite sind auf analytische oder Edge-Rollen begrenzt, nicht auf gemeinsames Stewardship.
• Iceberg/Delta nur für Verteilung/Snapshots bereits vertraglich gebundener Daten.
• Jede Stewardship-UI wurde auf Validierung, Audit, AuthZ und Vertrag bewertet — und bei Schwäche abgelehnt.
• Der Katalog zeigt Verantwortung, Lineage und Review-Kadenz für die Steuerprodukte.
• Excel/CSV bleiben Import-Staging oder Analyse-Nutzer, nicht der führende Vertrag.
• Fallback auf DIY-Stewardship ist explizit, wenn keine OSS-UI passt.

Artefakt

Erstellen Sie ein Minimal Viable Control Stack-One-Pager pro Umgebung (dev/test/prod).

Pflichtfelder:

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

control_db_engine: PostgreSQL <version>
instance / database / schema boundary
migration_tool_and_repo_path
backup_policy_and_owner
write_roles / read_roles
published_contracts: list of views or API endpoints
optional_stewardship_ui: name | none | diy-planned
ui_fit_assessment: validation / audit / AuthZ / contract (pass|fail)
catalog_service_and_fqn_pattern
lake_distribution: none | iceberg/delta snapshot job
pilot_assets: 1–3 table families
go_live_gate: backup tested, one consumer dual-run, owner named

Ergebnisse: genehmigter Stack für die Pilot-Domain, abgelehnte UI-Optionen mit Gründen und ein klarer Trigger, Teil 7 DIY zu starten, wenn optional_stewardship_ui = none und Fachbereiche selbst pflegen müssen.

Tools

• PostgreSQL + Migrations-Tooling in CI — Persistenz und reviewbare Schemaänderung.
• Architecture Fit — Steuer-DB vs. Lake vs. Warehouse-Platzierung bestätigen, bevor eine UI gekauft wird.
• OpenMetadata- oder DataHub-Connectoren — Steuer-Schemas für Verantwortung und Lineage harvesten (Was Governance von einem Katalog braucht).
• Optional: Adminer / Metabase / NocoDB erst nach bestandener UI-Fit-Bewertung.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Vorher: Wohin Steuerdaten gehören
• Weiter: Einfache Stewardship-Lösungen selbst bauen, wenn kein Tool passt
• Fachlogik außerhalb der BI-Apps halten
• Excel-Schatten-BI und Kennzahlen-Drift — Schattenmetriken vs. Datei-als-Quelle für Tabellen
• Catalog Deep Dive
• Ein modernes Data Warehouse aufbauen

Niemand will „Steward für alle Mappings“ von sales_otc sein — deshalb bleiben INLINE und CSV. Einfaches Stewardship startet mit wenigen kritischen Control Products, nicht mit einem MDM-Programm.

zuerst und optionale UIs nur, wenn der Pflegeprozess passt. Viele Teams bleiben danach stecken: das Grid-Tool fällt bei Validierung oder AuthZ-Review durch; MDM kaufen ist ein Mehrjahresprogramm; Excel bleibt der inoffizielle Schreibpfad, weil „wir brauchen kurzfristig etwas.“.

Lösung: Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert.

In einem Satz: Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert.

Problem

Teil 6 empfahl PostgreSQL zuerst und optionale UIs nur, wenn der Pflegeprozess passt. Viele Teams bleiben danach stecken: das Grid-Tool fällt bei Validierung oder AuthZ-Review durch; MDM kaufen ist ein Mehrjahresprogramm; Excel bleibt der inoffizielle Schreibpfad, weil „wir brauchen kurzfristig etwas.“

Dieser Stillstand reproduziert die Failure Modes aus früheren Teilen. Inline-Tabellen verstecken geteilte Wahrheit. Datei-als-Quelle bricht Pipelines bei Umbenennung und Locale. Schatten-Workbooks driften. Zugangsmatrizen leben in E-Mails. Governance wirkt im Katalog vollständig, während der Schreibpfad noch ein persönlicher SharePoint-Link ist.

Das gegenteilige Versagen ist Scope-Explosion. „Wir bauen unser eigenes MDM“ wächst Golden-Record-Matching, Survivorship, Multi-Domain-Hubs und UI-Frameworks, bevor das erste Status-Mapping einen stabilen Schlüssel und ein Audit-Log hat. Steuertabellen brauchen diese Oberfläche nicht.

Die praktische Lücke ist schmal: Fachbereiche müssen eine kleine Menge Tabellen sicher ändern; Consumer müssen einen stabilen Vertrag lesen; Auditoren müssen sehen, wer was geändert hat. Technologie ist austauschbar. Der Vertrag ist es nicht.

Entscheidung

Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert. Ergänzen Sie Freigabe nur dort, wo das Risiko des Assets es verlangt. Bleiben Sie bei Steuertabellen — nicht bei Golden-Record-MDM.

Nutzen Sie diesen DIY-Pfad, wenn:

• Domain-Regeln (Gültigkeitsfenster, Cross-Field-Checks, geschlossene Mengen) nicht in ein generisches Grid passen;
• sensible Berechtigungs nicht in einer Low-Code-Black-Box leben dürfen;
• das Team SQL plus eine dünne App betreiben kann, aber kein MDM-Programm;
• der Zeitrahmen Wochen sind, keine Quartale;
• die UI-Fit-Bewertung aus Teil 6 gescheitert ist und Excel die einzige verbleibende Alternative ist.

Die Platzierung bleibt wie in Wohin Steuerdaten gehören entschieden: meist Postgres. Stack-Defaults bleiben wie in Open-Source-Optionen für Steuerdaten. DIY ersetzt den Schreibpfad, nicht die Persistenzentscheidung.

Minimale Oberfläche (sechs Fähigkeiten)

1. Persistenz — Postgres-Tabellen, stabile Schlüssel, valid_from / valid_to, wenn Historie zählt.
2. Write-API oder Formular — Create/Update mit serverseitiger Validierung (Constraints + Anwendungsregeln).
3. Audit — wer / wann / was (append-only Change Log oder temporale Tabelle).
4. Consumer-Vertrag — stabile View oder API; nie rohe Edit-Spalten als Vertrag.
5. AuthZ — Rollen, wer welche Tabelle pflegen darf; nicht „jeder mit dem Link.“
6. Optionale Freigabe — Draft → Approved nur für kritische Assets (Berechtigungs, regulatorische Listen).

Stufen A–D (keine Framework-Religion)

Starten Sie bei der niedrigsten Stufe, die Excel-als-Quelle entfernt. Bevorzugen Sie B gegenüber C, wenn Zeilenzahlen klein und Edits selten sind. Bevorzugen Sie C, wenn Stewards bereits große Mapping-Sheets pflegen und einen Reject-Report brauchen. Bevorzugen Sie D, wenn eine falsche Zeile Zugriff gewährt oder verweigert.

Skizze: Mapping-Tabelle und Audit

Nur illustrativ — kein Produkt-Repository.

-- Editable base (stewards write here via app / approved upload)
CREATE TABLE control_sales.status_map_base (
  status_code      text PRIMARY KEY,
  status_label     text NOT NULL,
  is_revenue       boolean NOT NULL DEFAULT false,
  valid_from       date NOT NULL DEFAULT CURRENT_DATE,
  valid_to         date,
  updated_at       timestamptz NOT NULL DEFAULT now(),
  updated_by       text NOT NULL,
  CHECK (valid_to IS NULL OR valid_to >= valid_from)
);

-- Published contract (consumers read only this)
CREATE VIEW control_sales.v_status_map AS
SELECT status_code, status_label, is_revenue, valid_from, valid_to
FROM control_sales.status_map_base
WHERE valid_to IS NULL OR valid_to >= CURRENT_DATE;

-- Append-only audit
CREATE TABLE control_sales.status_map_audit (
  audit_id     bigserial PRIMARY KEY,
  changed_at   timestamptz NOT NULL DEFAULT now(),
  changed_by   text NOT NULL,
  change_type  text NOT NULL CHECK (change_type IN ('insert','update','delete')),
  status_code  text NOT NULL,
  old_row      jsonb,
  new_row      jsonb
);

Skizze: Upload → validieren → commit (Stufe C)

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

1. Steward uploads template (stable columns: status_code, status_label, is_revenue, valid_from, valid_to)
2. Server parses rows; does not touch production yet
3. Validate:
   - required keys present
   - no duplicate status_code in file
   - boolean / date parse OK
   - FK / closed-set rules pass
   - AuthZ: steward may maintain this asset
4. If any row fails → reject report (row number, field, rule); zero commits
5. If all pass → transaction:
   - upsert base
   - write audit rows
   - optional: write draft until approver promotes (tier D)
6. Consumers keep reading v_status_map; reload after publish

Pseudocode für das Gate:

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

result = validate(rows, rules)
if result.errors:
  return RejectReport(result.errors)   # no partial commit
with transaction:
  upsert(base, rows)
  append_audit(actor, rows)
  if requires_approval:
    mark_draft(rows)
  else:
    publish_or_already_live()

Anti-Patterns

• Eine Web-UI, die unbeschränkten Text speichert — zweites Excel hinter einem Login.
• Low-Code ohne Schema-Migrationen und ohne getestetes Backup/Restore.
• „Wir bauen MDM“ — Matching, Survivorship und Multi-Hub-UI, bevor ein Mapping einen Vertrag hat.
• Nutzer lesen die Edit-Tabelle inklusive Draft- und Reject-Zeilen.
• DIY-Frameworks über jede Domain streuen, bevor der erste Pilot Dual-Run-Evidenz hat.
• AuthZ überspringen, weil „nur drei Leute die URL kennen.“

Entscheidungsregel

Bauen Sie die kleinste Oberfläche, die Validierung, Audit und Vertrag erfüllt. Das Framework können Sie später tauschen; den Vertrag nicht.

Teil 8 wendet dasselbe Produkt-Betriebsmodell auf DIY und gekaufte UIs an.

Checkliste

• UI-Fit aus Teil 6 gescheitert oder kein geeignetes Produkt vorhanden; DIY ist eine explizite Entscheidung, kein Drift.
• Umfang sind Steuertabellen, nicht Enterprise-Golden-Record-MDM.
• Alle sechs Minimalfähigkeiten sind benannt; Freigabe ist begründet oder explizit out of scope.
• Stufe A–D für das Pilot-Asset gewählt und dokumentiert.
• Stabile Schlüssel und veröffentlichte Nutzer-View existieren vor UI-Politur.
• Serverseitige Validierung lehnt schlechte Uploads/Edits mit klarem Report ab.
• Audit erfasst Actor, Zeit und Before/After für Produktionsänderungen.
• AuthZ ist rollenbasiert pro Asset-Familie.
• Excel/CSV nur als gestagter Input unter Stufe C, nie als führende Quelle.
• Do-not-build-Liste ist geschrieben und mit Sponsoren reviewed.
• Ein-Wochen-MVP-Cut ist vereinbart (Tabellen, Regeln, ein Nutzer).
• Dual-Run-Plan existiert, bevor Inline- oder Dateiquellen retired werden.

Artefakt

Erstellen Sie einen DIY Stewardship Blueprint für den Pilot.

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

# DIY Stewardship Blueprint — <asset_family>

## Why DIY
- tools evaluated / rejected:
- Excel risk if we wait:

## Capabilities
- [ ] persistence
- [ ] validated write path (API | form | upload)
- [ ] audit
- [ ] consumer contract (view/API name)
- [ ] AuthZ roles
- [ ] approval (yes/no + trigger)

## Tier
A | B | C | D — rationale:

## One-week MVP cut
- tables:
- validation rules (top 5):
- first consumer:
- success metric:

## Nicht bauen
- Matching / Survivorship / Multi-Domain-Hub
- generische Workflow-Engine für alle Daten
- Katalog ersetzen
- …

## Betrieb
- Repo- / Migrationspfad:
- Backup-verantwortliche Person:
- On-Call für Schreibpfad:
- Promote-to-Produktion-Prüfpunkt:

Tools

• PostgreSQL + Migrationen — Persistenz geteilt mit Teil 6.
• Dünner interner Stack, den Sie bereits betreiben (z. B. Laravel, FastAPI, Streamlit) — eine Seite statt einer neuen Plattform bevorzugen.
• Architecture Fit — DIY innerhalb der Platzierungsentscheidung halten.
• Reject-Report-Templates (CSV out) für Stufe-C-Stewards.

Ressourcen

• Serie: Steuer- und Referenzdaten Deep Dive
• Vorher: Open-Source-Optionen für Steuerdaten
• Platzierung: Wohin Steuerdaten gehören
• Weiter: Steuerdaten als Datenprodukte betreiben
• Excel-Schatten-BI und Kennzahlen-Drift
• Excel und CSV als führende Quelle zerstören Pipelines
• Fachlogik außerhalb der BI-Apps halten

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

Section Access in der sales_otc-App filtert Regionen — die Matrix existiert nur im Skript und weicht von der IAM-Gruppe ab. Durchsetzung ist lokal; die Berechtigungsmatrix ist das Steuerdaten-Produkt.

zertifizierung. Die Zeilen, die entscheiden, wer welche Company, Kostenstelle oder Region sieht, leben trotzdem nur im App-Skript und weichen von der IAM-Gruppe ab.

Lösung: Berechtigungsmatrizen als Steuerdaten-Produkt der Klasse entitlement in der Datenbank pflegen; die App setzt durch nur.

In einem Satz: Durchsetzung ist lokal; die Matrix ist das Produkt.

Problem

Access-Governance-Programme definieren Policies, Rollen und Rezertifizierung. Währenddessen leben die Zeilen, die tatsächlich entscheiden, wer welche Company, Kostenstelle oder Region sieht, noch als:

• LOAD INLINE Section Access in jeder Qlik-App;
• Excel-USERID-Listen per E-Mail an Entwickler;
• duplizierte RLS-Rollen-Tabellen pro Power-BI-Dataset;
• Warehouse-Richtlinien ad hoc editiert ohne Steward-UI;
• Kopien, die nach jeder Joiner-/Leaver-Welle driften.

Access Security Governance deckt den Policy-Rahmen ab. Es macht die Matrix allein noch nicht zum governeden Produkt. Wenn die Matrix Inline oder dateibasiert ist, entsteht derselbe technische Albtraum wie bei anderem Steuerdaten: kein einzelner Owner, keine Impact-Analyse, kein Dual-Run, kein Audit wer eine Reduktion gewährt hat, und keine geteilte Wahrheit über Qlik, Power BI und SQL.

Failure Modes verstärken sich:

• App A erlaubt REGION=NORTH; App B hat noch gestriges Sheet — derselbe User, unterschiedliche Wahrheit.
• Ein Entwickler hardcodet „vorübergehend“ eine ADMIN-Zeile und vergisst sie zu entfernen.
• Spaltenumbenennung in Excel bricht den nächsten Reload; Produktion öffnet zu weit oder scheitert unvorhersehbar closed.
• Rezertifizierung signiert IdP-Gruppen ab, während Orphan-Matrix-Zeilen weiterhin Reduktions gewähren.

Entscheidung

Behandeln Sie Berechtigungsmatrizen als Steuerdaten-Produkte der Klassifikation entitlement. Enforce im Consumer (Section Access, RLS, Warehouse Row Policies, API-Filter). Pflegen Sie eine zentrale Matrix (oder eine kleine Familien von Matrizen) mit dem Produktvertrag aus Teil 8.

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

Central entitlement product (Postgres + contract view)
        │
        ├─→ Qlik Section Access load (enforcement)
        ├─→ Power BI RLS / OLS mapping (enforcement)
        ├─→ Warehouse / lake RLS policies (enforcement)
        └─→ API authorization filters (enforcement)

Durchsetzung vs. Produkt

Verwechseln Sie nicht „Section Access funktioniert in der App“ mit „Berechtigungs sind governed.“ Die App muss fail-closed, wenn das Produkt stale oder fehlend ist; sie darf nicht System of Record werden.

Multi-Consumer, dieselbe Tabelle

Gestalten Sie Reduktion-Schlüssel als Business Keys (company_code, cost_center, region_id), nicht als tool-spezifische Feldnamen. Veröffentlichen Sie bei Bedarf eine Consumer-View pro Durchsetzung-Stil:

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

control_access.v_entitlement_matrix     canonical rows
control_access.v_qlik_section_access    ACCESS, USERID, REGION, ...
control_access.v_pbi_rls_bridge         user_principal, dimension_key, ...

Transformationen von kanonisch → Engine-Form gehören in versioniertes SQL oder geskriptete Loads, nicht in stille Excel-Formeln. Halten Sie Identity Mapping (IdP-User → analytische USERID) explizit und owned.

DIY-Tipp: Stufen B und D

Generische Open-Source-Grids sind ein schlechter Default für Berechtigungs: leichtes Over-Grant, schwache Freigabe, unbequemes Audit. Bevorzugen Sie Teil 7:

• Stufe B — kleines Formular für Add/Change/Disable mit serverseitiger Validierung;
• Stufe D — Freigabe vor Publish für Produktions-Grants.

Nutzen Sie nie ungesteuertes Excel als führende Quelle für USER×Reduktion-Zeilen. Template-Upload (Stufe C) ist nur akzeptabel mit Reject-Reports, ohne Partial Commit und Freigabe vor Publish.

Zentrale Berechtigungs + lokales Durchsetzung

Entscheidungsregel:

Eine governed Berechtigung-Quelle; nur app-lokales Durchsetzung. Inline Section Access und Mailbox-Excel-Listen sind technische Schuld, kein Sicherheitsdesign.

Richten Sie Change Windows an Access Operations aus. Ein Joiner-/Leaver-Feed darf Identity upserten; Reduktion-Grants brauchen weiterhin Steward oder automatisierte Regeln mit Audit. Rezertifizieren Sie Matrix-Zeilen im selben Takt wie Access Reviews.

Failure Modes, gegen die Sie designen

• Inline SA über Apps kopiert mit lokalen „Fixes.“
• Excel als führende Quelle für USERID-Listen.
• Nutzer lesen Draft-Berechtigung-Zeilen.
• Reduktion-Codes mit neuer Bedeutung wiederverwenden.
• ADMIN- / Break-Glass-Accounts undokumentiert im Produkt.
• Kein Dual-Run beim Wechsel einer App auf die zentrale Matrix.
• Katalog zeigt Richtlinie-Dokumente, aber keine Lineage zur Matrix-Tabelle.

Checkliste

• Berechtigung-Assets sind klassifiziert und als Steuerprodukte registriert.
• Die kanonische Matrix lebt in der Steuerdatenbank mit veröffentlichten Views.
• Qlik / Power BI / Warehouse / API durchsetzen lokal aus diesem Vertrag.
• Keine Produktions-App stützt sich auf INLINE oder Mailbox-Excel als führende Quelle.
• Identity Mapping (IdP → analytischer User Key) ist dokumentiert und owned.
• Schreibpfad ist Stufe B/D (oder äquivalent) mit Validierung und Audit.
• Freigabe für Produktions-Grant-Änderungen, wo Risiko es verlangt.
• Automatisierte Tests decken Uniqueness, erforderliche ACCESS-Felder, Orphan Users/Keys ab.
• Rezertifizierungs-Checkliste ist geplant und mit Evidenz belegt.
• Break-Glass- / ADMIN-Zeilen sind inventarisiert und zeitlich begrenzt.
• Dual-Run und Abgleich abgeschlossen, bevor per-App-Matrizen retired werden.
• Lineage von Matrix → Apps ist im Katalog sichtbar.

Artefakt

Berechtigung Matrix Contract (Mindestfelder)

product_id: ctrl.access.entitlement_matrix
classification: entitlement
owner: security-or-data-governance-lead
steward: access-steward
custodian: analytics-platform
contract:
  canonical_view: control_access.v_entitlement_matrix
  grain: user_key × reduction_key × access_level
  keys: [user_key, reduction_key]
  attributes: [access_level, valid_from, valid_to, grant_reason, ticket_id]
enforcement_bindings:
  - engine: qlik-section-access
    view: control_access.v_qlik_section_access
  - engine: powerbi-rls
    view: control_access.v_pbi_rls_bridge
write_path:
  type: diy
  tier: D
recertification:
  cadence: quarterly
  aligns_with: access-review-cycle
break_glass:
  rows_documented: true
  max_duration_days: 7

Rezertifizierungs-Checkliste

• verantwortliche Person bestätigt, dass die Matrix weiterhin dem Richtlinie-Intent entspricht.
• Stichprobe von Grants zu Tickets / Joiner-Workflows zurückverfolgt.
• Leavers haben valid_to gesetzt; keine aktiven Orphans vs. IdP.
• ADMIN- / Break-Glass-Zeilen reviewed oder abgelaufen.
• Jeder gebundene App-Reload gegen die veröffentlichte View im letzten Fenster erfolgreich.
• Drift-Check: Inventar app-lokaler Overrides ist leer (oder mit Ablauf waivered).
• Audit-Stichprobe aufbewahrt (wer Grants seit letztem Review geändert hat).
• Katalog-Review-Datum und Evidenz-Links aktualisiert.

Tools

• Steuer-DB + DIY-Formular/Freigabe aus Teil 7 — bevorzugter Schreibpfad für Berechtigungs.
• Qlik Section Access / Power BI RLS / Warehouse-Richtlinien — nur Durchsetzung.
• Katalog-Lineage — beweisen, welche Apps an welche Matrix-Version binden.
• Access-Review-Workflow-Tooling — planen und belegen (Access Recertification Workflow, wo genutzt).

Ressourcen

• Serie: Steuer- und Referenzdaten Deep Dive
• Produktbetrieb: Steuerdaten als Datenprodukte betreiben
• DIY: Einfache Stewardship-Lösungen selbst bauen
• Weiter: Von Inline und Excel zu governeden Steuerdaten migrieren
• Access Security Governance
• Fachlogik außerhalb der BI-Apps halten — SA als gültiges lokales Durchsetzung, nicht geteilte Wahrheit
• BI-Governance-Entscheidungen
• BI-Publish Deep Dive — RLS/OLS und Tool-Adapter durchsetzen diese Matrix, sie ersetzen sie nicht

Das INLINE für sales_otc soll „dieses Wochenende“ raus — Dual-Run und Consumer-Liste fehlen. Migration ist sequenzierte Betriebsänderung, kein Cutover-Event.

Lösung: Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets.

In einem Satz: Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets.

Problem

Bis Teil 9 ist das Ziel klar: Steuer- und Berechtigung-Daten als Produkte, Postgres (oder entschiedene Platzierung) als Persistenz, optionale UI oder DIY-Schreibpfad, Katalog-Evidenz, zentrale Matrizen mit lokalem Durchsetzung. Landschaften scheitern trotzdem an der Migration.

Typische Failure Patterns:

• Big Bang: jedes INLINE und jedes Sheet in einem Release — Rollbacks unklar, Schuld verteilt sich.
• Technology-first: „alle Mappings in den Lake“ ohne Klassifikation oder Verträge.
• UI-first: NocoDB vor Schlüsseln, Tests oder Nutzeransichten.
• Inventar für immer: Scanner laufen, nichts dual-runnt.
• Zu früh retiren: Excel gelöscht, während ein kritisches Arbeitsmappe noch Month-End speist.
• Zu spät retiren: Dual-Run wird permanente Dual-Truth.

Ohne Backlog und Scorecard bleiben Teile 1–9 guter Rat neben denselben vierzig Inlines und zwölf Spreadsheets, die Governance zum technischen Albtraum gemacht haben.

Entscheidung

Betreiben Sie eine gestufte Migrationsfabrik für Steuer-Assets. Jedes Asset durchläuft dieselben Gates; der Schreibpfad kann OSS-UI oder DIY sein; der Produktvertrag ist Pflicht, bevor Consumer umschalten.

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

Inventory → Classify → Contract → Place
    → Write path (OSS UI or DIY)
    → Dual-run + reconcile
    → Switch consumers
    → Retire inline / file leading source

Priorisieren Sie nach Kritikalität × Consumer-Anzahl × Änderungsfrequenz × Berechtigung-Sensitivität — nicht danach, wie leicht das Sheet hochzuladen ist.

Stufen-Notizen

Inventar — Erweitern Sie das Risk Register aus Teil 1 und die Inline-Scan-Regeln aus Teil 2. Erfassen Sie Ort, Typ, Consumer, Owner bekannt?, letzte Änderung, Kritikalität. Schließen Sie Section-Access-INLINE und Berechtigung-Excels aus Teil 9 ein.

Klassifizieren — Nutzen Sie die Karten aus Teil 4, bevor Technologie angefasst wird. Falsche Klasse erzeugt falsche Platzierung und falschen Schreibpfad.

Vertrag — Entwerfen Sie den Produktvertrag aus Teil 8 früh (Schlüssel, Grain, Breaking-Regeln, Owner). Leerer Owner blockiert Go-Live.

Platzieren — Entscheidungsrecord aus Teil 5: Steuer-DB Default; Lake/Warehouse nur für Verteilungs-Snapshots.

Schreibpfad — Teil-6-UI, wenn Fit-Assessment besteht; sonst Teil-7-DIY auf der niedrigsten ausreichenden Stufe. Berechtigungs default Richtung B/D.

Dual-Run — Veröffentlichen Sie die Vertrags-View; halten Sie die Legacy-Quelle für ein vereinbartes Fenster in einem Shadow-Compare. Reconcilen Sie mit Counts, Key Diffs und Hashes — nicht nur Screenshots.

Umschalten — Zeigen Sie Consumer auf die veröffentlichte View; frieren Sie Legacy-Writes ein; beobachten Sie die Break Rate.

Retiren — Entfernen Sie INLINE / retiren Sie Datei-als-Quelle / archivieren Sie Kopien; behalten Sie Evidenz von Reconciliation und Owner-Sign-off. Für Excel gilt die Dispositionssprache aus Excel-Schatten-BI und Kennzahlen-Drift, wenn Workbooks auch Schatten-BI waren — hier ist das Gate „nicht mehr führende Quelle für die Steuertabelle.“

Reconciliation-Minimum

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

legacy_extract ⟷ contract_view
- row counts (valid rows)
- key set symmetric difference
- attribute hash for matched keys
- entitlement: user×reduction grants equal within tolerance 0

Null unerklärte Key Diffs vor dem Switch. Dokumentieren Sie Waivers mit Ablaufdatum.

Operating Scorecard

Tracken Sie monatlich für das Steuerdaten-Portfolio:

Scorecard-Targets gehören zum Serien-Operating-Review, nicht zu einem einmaligen Projekt-Slide.

Checkliste

• Portfolio-Inventar existiert (Inline, Datei, Berechtigung, Parameter, Hierarchien).
• Jedes Pilot-Asset hat Klassifikation + Platzierung + Produktvertrag.
• Schreibpfad gewählt (OSS oder DIY) mit AuthZ, Validierung und Audit.
• Dual-Run-Fenster, Abgleich-Methode und Pass-Kriterien vereinbart.
• Nutzer gelistet mit Switch-Ownern und Reload-/Test-Kontakten.
• Berechtigung-Migrationen enthalten Fail-Closed-Tests und Rezertifizierungs-Hook.
• Retirement-Evidenz gespeichert (Diff-Report, Freigabe, Katalog-Update).
• Scorecard-Baseline vor dem 90-Tage-Push gemessen.
• Kein Big Bang ohne Rückbau: Switch-Gates pro Asset.
• Serien-Learnings in Warehouse- / BI- / Access- / Katalog-Betriebsrhythmen verlinkt.

Artefakt

90-Tage Control Data Migration Backlog

Nutzen Sie ein Board (oder eine Tabelle) mit Spalten: asset_id, class, source_location, criticality, consumers, owner, contract_ready, placement, write_path, dual_run_start, reconcile_status, switch_date, retire_date, scorecard_tags.

Tage 0–15 — Baseline

• Inventar für Top-Domains abschließen (Sales, Finance, Access).
• Kritikalität scoren; 3–5 Pilot-Assets wählen (ein Berechtigung einschließen, falls vorhanden).
• verantwortliche Person/Stewards benennen oder Mandate-Lücken eskalieren.
• Scorecard-Baseline veröffentlichen.

Tage 16–45 — Erste Produkte live

• Verträge + Postgres- (oder entschiedene) Platzierung für Piloten.
• Schreibpfade live (OSS oder DIY); Katalogeinträge angelegt.
• Dual-Run gestartet; tägliche/periodische Abgleich für Piloten.
• Inline-Scan-Regeln für verbleibende Apps geplant.

Tage 46–75 — Umschalten und erweitern

• Pilot-Nutzer nach null unerklärten Diffs umschalten.
• Pilot-INLINE-/Datei-führende Quellen mit Evidenz retiren.
• Nächste Tranche onboarden (Ziel: Pilot-Anzahl verdoppeln).
• Berechtigung-Rezertifizierung an Access-Zyklus ausrichten.

Schritt 4 — Stabilisieren

• Dual-Run-Aging über Schwellwert abbauen.
• Scorecard-Review mit Sponsoren; Targets für nächstes Quartal setzen.
• Neues INLINE für geteiltes Kontrollregel in CI/Review-Checkliste einfrieren, wo machbar.
• Backlog an Steady-State-Stewardship-Kapazität übergeben.

Beispiel-Backlog-Zeilen:

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

asset_id          class         source                 write_path   gate
status_map_sales  mapping       qlik/Sales_App INLINE  diy-B        dual-run
fx_override_fin   parameter     sharepoint/fx.xlsx     oss-ui       contract
sa_region_matrix  entitlement   excel/sa_users.xlsx    diy-D        approve+dual
cost_center_hier  hierarchy     dbt seed hardcoded     diy-C        place+test

Tools

• Inventar + Risk Register (Artefakt Teil 1) und Inline-Scan-Regeln (Teil 2).
• Produktvertrags-Template (Teil 8) und Berechtigung-Vertrag (Teil 9).
• Abgleich-SQL/Hashes; BI-Reload-Tests.
• Report Inventory — Nutzer und Schatten-Workbooks finden.
• Architecture Fit — Platzierungsstreitigkeiten.
• Katalog — Evidenz und Lineage nach dem Switch.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Alle Teile: Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen · Inline-Tabellen · Excel/CSV führende Quelle · Klassifizieren · Platzieren · OSS-Stack · DIY-Stewardship · Produktbetrieb · Berechtigungs · Mitarbeiter- & Org-Hierarchien
• Schwesterserien und Stories:
  • Ein modernes Data Warehouse aufbauen
  • BI-Governance-Entscheidungen
  • Catalog Deep Dive
  • Fachlogik außerhalb der BI-Apps halten
  • Excel-Schatten-BI und Kennzahlen-Drift
  • Access Security Governance

Manager-Hierarchie steuert Row-Level Access auf sales_otc — HR ändert den Baum, BI filtert falsch. Org-Hierarchien sind Control Data mit Freigabe und Historie, nicht nur Stammdaten-Export.

zeitig.

Lösung: Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers.

In einem Satz: Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers.

Problem

Die meisten Landschaften pflegen Personen- und Organisationsstrukturen an mehreren Stellen gleichzeitig:

• HR hält die Beschäftigungs-Hierarchie (Manager, Abteilung, Cost-Center-Zuordnung);
• Finance pflegt eine Reporting-/Management-Hierarchie für GuV und Cost Center;
• Sales unterhält Territory- oder Account-Team-Bäume für Quota und Pipeline;
• BI-Apps betten noch eine Version als INLINE, Excel oder hardcodierte Parent–Child-Loads ein.

Jede Kopie driftet. Monatsabschluss-Finance rollt zu einem anderen Cost-Center-Parent als der HR-Org-Chart. Eine Qlik-App zeigt nach dem Reorg noch den Manager des Vorquartals. Power-BI-RLS nutzt einen Regionsbaum, den Sales in einer Tabelle aktualisiert hat, die das Warehouse nie gesehen hat.

Zwei weitere Verwechslungen verschärfen das Chaos.

Source of Record versus Reporting-Hierarchie. Der legale bzw. HR-Baum ist nicht automatisch der Baum, den Finance für Management Reporting nutzt. Matrix- (Dotted-Line-) Beziehungen sind für People Management real und für ein einzelnes Parent–Child-Beschäftigungsmodell unsichtbar. Teams, die so tun, als sei „HR immer recht für Reporting“ oder „Finance-Excel die einzige Wahrheit“, erzeugen stille Widersprüche statt zwei Produkte zu benennen.

Zeit. Manager-Beziehungen ändern sich. Menschen wechseln, Interims decken ab, Reorgs schneiden durch Fiskalperioden. Ohne Effective Dating (SCD-artige valid_from / valid_to) schreibt jedes historische Report entweder die Vergangenheit um oder kann „wer hat dieses Team im März geleitet?“ nicht beantworten.

Als Nächstes kommen ragged Trees (ungleiche Tiefe), übersprungene Levels und Dual Parents. Eine dreistufige Sales-Region sitzt neben einer fünfstufigen Corporate Org. Apps „reparieren“ Tiefe mit leeren Knoten oder duplizierten Leaves; jedes Power-BI-Semantikmodell und jede Qlik-App hält oft noch eine Kopie. Ohne explizites Hierarchie-Datenmodell — Parent–Child plus Closure oder Bridge wo nötig — und einen Steward of Record erfindet jeder Consumer seine eigene Flatten-Logik.

Die operative Signatur entspricht dem Rest dieser Serie: duplizierte Hierarchien in BI-Skripten, kein Katalog-Owner, keine Consumer-Liste, kein Dual-Run wenn jemand „nur schnell das Excel“ aktualisiert. Vor dem Umzug klassifizieren listet Hierarchy bereits als Steuerdaten-Klasse; dieser Teil macht die Betriebsentscheidung konkret.

Entscheidung

Behandeln Sie Mitarbeiter- und Organisationshierarchien als governte Steuerdatenprodukte — eine gepflegte Hierarchie (pro Zweck), viele Consumers. Apps ergänzen nur Presentation und lokale Durchsetzung; sie besitzen den Baum nicht.

Produkte explizit benennen

Veröffentlichen Sie mindestens die Produkte, die Sie wirklich nutzen. Verdichten Sie sie nicht zu einem mehrdeutigen „Org-Chart“:

HR bleibt Source of Record für Beschäftigungs-Kanten, wo das zutrifft. Reporting- und Territory-Bäume sind eigene Produkte mit eigenen Ownern, auch wenn viele Knoten geteilt sind. Verknüpfen Sie Produkte über stabile Personen- / Org- / Cost-Center-Keys; kopieren Sie keine Excel-Sheets zwischen Domains.

Eine Hierarchie, viele Consumers

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

Governte Hierarchie-Produkt(e)
        │
        ├─→ Warehouse- / Mart-Roll-up-Dimensionen
        ├─→ Qlik-Hierarchy- / As-of-Loads
        ├─→ Power-BI-Parent–Child- / Path-Spalten
        ├─→ Berechtigung-Reduktionen (Region, Cost Center, Manager-Scope)
        └─→ Allokations- und Planungsmodelle

Folgen Sie Fachliche Logik außerhalb der BI-Apps halten: geteilte strukturelle Wahrheit außerhalb der App; toolspezifisches Auf-/Zuklappen darf innen bleiben. Lassen Sie keine App zum zweiten Steward werden.

Ragged Trees und Matrix-Linien modellieren

Standard-Strukturmuster:

1. Parent–Child-Edge-Tabelle — node_id, parent_id, hierarchy_id, Gültigkeit, Attribute.
2. Closure-Tabelle oder Bridge — Ancestor/Descendant-Paare mit Depth, aus Edges neu gebaut (oder gepflegt, wo Performance es verlangt).
3. Optionale Path- / Level-Attribute — denormalisiert für BI-Komfort, aus den governten Edges generiert, nie handeditiert als führende Quelle.

Für Matrix / Dotted-Line:

• behalten Sie einen Primary Parent für das Reporting-Produkt, das einen einzelnen Roll-up braucht;
• speichern Sie sekundäre Beziehungen als typisierte Edges (relationship_type = matrix) in derselben Familie oder einem Schwesterprodukt;
• kodieren Sie Dotted-Line nie nur als Free-Text-„Notes“-Spalte in einer App.

Ragged Depth ist normal. Erzwingen Sie keine Fake-Zwischenknoten im führenden Produkt nur, um ein BI-Visual zu erfreuen. Generieren Sie Presentation-Levels in Consumer-Views, wenn ein Tool feste Tiefe verlangt.

Effective Dating und SCD für Manager-Beziehungen

Behandeln Sie Manager- und Org-Mitgliedschaft als slowly changing Control-Beziehungen:

• jede Edge trägt valid_from und valid_to (offen endende aktuelle Zeile erlaubt);
• Point-in-Time-Queries nutzen As-of-Prädikate, keine „nur Latest“-Überschreibungen;
• Reorgs veröffentlichen eine neue Version oder ein datiertes Edge-Set mit Change-Ticket;
• historische Fakten behalten die Keys, die sie hatten; sie joinen die Hierarchie as-of Fact-Datum (oder einer erklärten Business Rule).

SCD Type 2 auf Edges ist das übliche Muster. Vermeiden Sie Type-1-Overwrite für Manager-Historie, es sei denn, ein Produktvertrag sagt explizit Current-State only — und dann nutzen Sie dieses Produkt nicht für historische Roll-ups.

Alignen Sie Change Windows mit Steuerdaten als Datenprodukte betreiben: angekündigte Reorg-Cuts, Dual-Run alter vs. neuer Baum für kritische Consumers, Tests auf Zyklen, Orphans und gebrochene Closure-Rebuilds.

Entscheidungsregel

Ein gepflegtes Hierarchie-Produkt pro erklärtem Zweck; HR-Beschäftigungswahrheit und Reporting-Bäume werden getrennt benannt; Apps konsumieren veröffentlichte Views und ergänzen nur Presentation. INLINE-Org-Tabellen und Mailbox-Excel-Bäume sind technische Schuld.

Checkliste

• Hierarchie-Assets sind als Steuerdaten (hierarchy) klassifiziert und im Katalog registriert.
• Beschäftigungs- / Legal- / Reporting- / Matrix- / Territory-Produkte haben eigene verantwortliche Person — kein mehrdeutiges Spreadsheet.
• Unterschiede Source of Record (HRIS) versus Reporting-Hierarchie sind dokumentiert, nicht übertüncht.
• Führende Struktur sind Parent–Child-Edges mit valid_from / valid_to; Closure/Bridge wird generiert oder owned.
• Keine Produktions-Qlik- oder Power-BI-App nutzt INLINE oder Mailbox-Excel als führenden Org-Baum.
• Nutzeransichten bedienen Warehouse, Qlik, Power BI und Berechtigung-Reduktionen aus demselben Vertrag.
• Cycle-, Orphan-, Duplicate-Parent- (wo verboten) und Closure-Rebuild-Tests laufen beim Publish.
• Point-in-Time- (As-of-) Verhalten ist für historische Fakten und Manager-Dashboards definiert.
• Reorg-Change-Window, Dual-Run und Rückbau-Pfad existieren für kritische Nutzer.
• personenbezogene Daten- / Personenattribute auf Hierarchieknoten folgen HR-Zugriffsregeln; Reduktionskeys bleiben Business Keys.
• Lineage vom Hierarchie-Produkt → Apps ist sichtbar; Nutzer stehen im Vertrag.
• Matrix- / Dotted-Line-Edges sind typisiert und owned, nicht in App-Skripten versteckt.

Artefakt

Org Hierarchy Control Contract (Mindestfelder)

product_id: ctrl.org.reporting_hierarchy
classification: hierarchy
hierarchy_type: reporting   # reporting | legal | matrix | employment | territory
owner: finance-fpa-lead
steward: controlling-steward
custodian: analytics-platform
grain: hierarchy_id × node_id × valid_from
contract:
  edge_view: control_org.v_hierarchy_edge
  closure_view: control_org.v_hierarchy_closure
  fields:
    - hierarchy_id
    - node_id
    - parent_id          # null = root
    - valid_from
    - valid_to
    - hierarchy_type     # reporting | legal | matrix | employment | territory
    - relationship_type  # primary | matrix | interim  (optional)
    - node_label
    - business_key       # cost_center, person_id, org_unit_id, ...
  owner: finance-fpa-lead
  consumers:
    - warehouse.dim_cost_center_hier
    - qlik.Finance_Mgmt_App
    - powerbi.Pnl_Dataset
    - control_access.v_entitlement_matrix  # abgeleitete Reduktionskeys
tests:
  - no_cycles
  - single_primary_parent_per_node_per_day
  - closure_matches_edges
  - no_orphan_non_root
change_window: announced_reorg_cuts
as_of_rule: fact_date_joins_edge_validity

Pflichtfelder im Katalog sichtbar halten: hierarchy_id, node_id, parent_id, valid_from / valid_to, hierarchy_type (reporting | legal | matrix), owner, consumers.

Outputs: benannte Hierarchie-Produkte, as-of-fähiger Edge-Store, generierte Closure für Consumers und eine Reorg-Dual-Run-Checkliste, angebunden an die Migrations-Scorecard aus Teil 10.

Tools

• Kontrollregel-Datenbank + veröffentlichte Edge-/Closure-Views — führende Struktur.
• HRIS- / Finance-MDM-Extrakte — Quellen in das Produkt, keine parallelen führenden Excel-Bäume.
• Qlik-Hierarchy-Loads / Power-BI-Parent–Child- oder Path-Spalten — nur Presentation und lokale Navigation.
• Berechtigung-Matrizen (Teil 9) — konsumieren hierarchieabgeleitete Reduktionskeys; definieren den Baum nicht neu.
• Katalog-Lineage — beweisen, welche Apps welchen hierarchy_id binden.
• Report Inventory — duplizierte Org-Excel- und INLINE-Bäume finden.
• Stewardship-Schreibpfad (Teil 6 OSS oder Teil 7 DIY) für kontrollierte Edge-Edits, wo HRIS nicht schreibt.

Ressourcen

• Serienindex: Steuer- und Referenzdaten Deep Dive
• Warum unkontrollierte Steuerdaten Governance zum technischen Alptraum machen
• Steuerdaten klassifizieren, bevor man sie verschiebt
• Steuerdaten als Datenprodukte betreiben
• Fachliche Logik außerhalb der BI-Apps halten
• Von Inline und Excel zu governeden Steuerdaten migrieren
• Berechtigungsmatrizen und Section Access gehören in die DB
• Schwesterkontext: Access Security Governance, BI-Governance-Entscheidungen