Steuerdaten klassifizieren, bevor man sie verschiebt

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.