Was Governance wirklich von einem Data Catalog braucht

Begriffe vor dem Lesen

• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien; nicht automatisch Governance.
• Capability — Konkrete Fähigkeit wie Suche, Workflow, Nachweis, Lineage oder Richtlinie-Verknüpfung.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung, Risiko oder Freigabe im definierten Umfang verantwortet.
• Workflow — Wiederholbarer Ablauf für Vorschlag, Prüfung, Entscheidung und Nachweis.
• Nachweis — Prüfbarer Nachweis, dass eine Entscheidung oder Kontrolle stattgefunden hat.

Ausgangslage

Der Catalog zeigt Lineage für sales_otc — und trotzdem kann niemand den Owner von fct_orders zu einem Qualitätsvorfall erreichen. Suche und Klassifikation schaffen Transparenz; belastbare Governance braucht wiederholbare Entscheidungen und nachweisbare Kontrollen.

Sechs Fähigkeiten bilden den Mindestkontext für einen Pilot-Flow:

1. Verantwortung;
2. Workflow;
3. Evidence;
4. Durchsetzung;
5. Quality;
6. Lifecycle.

Nicht jede Fähigkeit muss vollständig im Katalog implementiert sein. Der Katalog muss sie jedoch sichtbar verbinden und seine Systemgrenzen offenlegen.

Leitentscheidung

Jeden kritischen Use Case gegen diese sechs Fähigkeiten prüfen.

Dabei pro Fähigkeit festlegen:

• welches Ergebnis erwartet wird;
• wer verantwortlich ist;
• welches System führt;
• welches Ereignis den Ablauf startet;
• welcher Nachweis erhalten bleibt.

Plattform-native und Enterprise Catalogs lösen unterschiedliche Wege

Die Frage „Haben wir einen Katalog?“ ist zu grob.

Viele Datenplattformen bringen bereits einen nativen Katalog mit. Er liegt nah an den technischen Assets, Berechtigungen und Laufzeitereignissen. Ein Enterprise Catalog verbindet dagegen häufig mehrere Plattformen, fachliche Begriffe, Governance-Workflows und organisationsweite Verantwortungen.

Beide können notwendig sein. Beide können auch unnötige Doppelpflege erzeugen.

Die Architekturentscheidung lautet deshalb:

Welches System führt welches Governance-Signal, wo wird es durchgesetzt und auf welcher Oberfläche sieht der Consumer die Konsequenz?

Databricks Unity Catalog

Unity Catalog ist plattformnah, wenn Daten, Tabellen, Views, Modelle und Zugriffe überwiegend in Databricks betrieben werden.

Stärken für Governance sind typischerweise:

• zentrale technische Namensräume und Berechtigungen;
• Lineage nahe an ausgeführten Workloads;
• Klassifikationen und Tags an Plattform-Assets;
• Audit- und Nutzungsinformationen;
• kontrollierte Freigabe innerhalb der Plattform.

Zu prüfen bleibt:

• Wo liegt die autoritative fachliche Definition?
• Wie werden Business Owner und Stewards gepflegt?
• Wie sieht ein BI-Nutzer Zertifizierung und Qualitätsstatus?
• Wie werden Assets außerhalb von Databricks verbunden?
• Welches System führt Ausnahme, Attestierung und Lifecycle-Entscheidung?

Unity Catalog kann der führende technische Kontrollpunkt sein, ohne automatisch der einzige Consumer-Katalog zu sein.

Snowflake

Snowflake-native Katalog- und Governance-Funktionen liegen dicht an Datenobjekten, Rollen, Policies, Tags, Klassifikation, Zugriff und Nutzung.

Das ist besonders wirksam, wenn:

• Snowflake der zentrale Datenzugriffspunkt ist;
• Tags in Maskierungs- oder Zugriffspolicies einfließen;
• Objekt- und Nutzungsmetadaten aktuell benötigt werden;
• technische verantwortliche Person nah an der Plattform arbeiten.

Die offene Governance-Frage ist erneut die Consumer-Reichweite. Ein Analyst in Power BI oder ein Fachbereich in einem Datenportal darf nicht erst eine Snowflake-Rollenansicht öffnen müssen, um Definition, Freigabestatus oder bekannte Qualitätsprobleme zu verstehen.

dbt docs und dbt-Metadaten

dbt ist nahe an transformiertem Code, Tests, Modellen, Sources, Beschreibungen und Abhängigkeiten.

Damit kann es sehr gute Evidenz liefern für:

• dokumentierte Transformationslogik;
• technische und modellbezogene Lineage;
• Teststatus;
• Code Owner und Änderungsverlauf;
• Deployment- und Build-Ereignisse.

dbt docs allein ist jedoch selten ein vollständiges Governance Operating Model. Freigabeworkflows, fachliche Attestierungen, Zugriffsdurchsetzung, organisationsweite Suche und langfristige Evidenz können in anderen Systemen liegen.

Statt dbt-Beschreibungen in einem Enterprise Catalog manuell zu kopieren, sollte die Integration Herkunft, Aktualität und Link zum führenden Modell erhalten.

Power BI und semantische Modelle

Power BI liegt am tatsächlichen Konsumpunkt vieler Kennzahlen. Semantische Modelle, Berichte, Apps, Endorsement, Sensitivity Labels, Refresh-Status und Nutzungsinformationen liefern deshalb unverzichtbaren Kontext.

Governance muss hier mindestens beantworten:

• Welches semantische Modell ist freigegeben?
• Welche KPI-Version verwendet ein Bericht?
• Wann wurden Dataset oder semantisches Modell zuletzt erfolgreich aktualisiert?
• Welcher Workspace und verantwortliche Person verantworten Betrieb und Zugriff?
• Welche Downstream-Berichte sind von einer Änderung betroffen?
• Sieht der Berichtsnutzer bekannte Qualitätsprobleme vor seiner Entscheidung?

Ein Enterprise Catalog kann Power-BI-Assets organisationsweit auffindbar machen. Die kritischen Signale müssen trotzdem in App, Bericht oder semantischer Modellansicht ankommen.

Enterprise Catalog

Ein Enterprise Catalog ist besonders wertvoll, wenn er:

• Assets mehrerer Plattformen in einem Such- und Beziehungsmodell verbindet;
• fachliche Begriffe und Datenprodukte plattformübergreifend führt;
• gemeinsame Verantwortung-, Review- und Lifecycle-Workflows ermöglicht;
• Governance-Evidenz aus verschiedenen Kontrollpunkten zusammenführt;
• Nutzer in unterschiedliche Ausführungssysteme weiterleitet.

Er ist nicht automatisch autoritativ für jede Metadatenart. Laufzeit-Lineage kann aus Databricks, Policies aus Snowflake, Testresultate aus dbt und Reportnutzung aus Power BI stammen.

Ein klares System-of-Record-Muster

Für jedes Signal wird genau festgelegt:

Das Ziel ist keine zentrale Kopie aller Metadaten. Das Ziel ist ein eindeutiger Ursprung mit verlässlicher Verteilung.

Governance-Signale müssen Consumer erreichen

Steward-Oberflächen sind notwendig, aber nicht ausreichend. Governance wirkt erst, wenn ein Consumer vor oder während der Nutzung die richtige Entscheidung treffen kann.

Beim Suchen

Suchergebnisse müssen unterscheiden:

• zertifiziert, geprüft, experimentell und abgekündigt;
• fachliches Datenprodukt und technische Rohquelle;
• aktuelles Asset und veralteten Vorgänger;
• für den Zweck geeignete und eingeschränkte Nutzung;
• gesunde und beeinträchtigte Qualität.

Popularity allein ist kein Vertrauenssignal. Häufige Nutzung kann auch einen etablierten Fehler anzeigen.

Beim Bewerten

Die Asset-Seite zeigt in unmittelbarer Nähe:

• fachliche Definition und Zweck;
• Owner und erreichbaren Supportweg;
• Datenstand und Refresh-Zusage;
• Qualitätsstatus mit betroffener Dimension;
• Zertifizierungsumfang und Review-Datum;
• Klassifikation und zulässige Nutzung;
• relevante Lineage und bekannte Downstream-Auswirkung.

Beim Anfordern und Nutzen

Der Consumer braucht:

• verständliche Begründung für erforderliche Freigaben;
• sichtbaren Status und erwartete Bearbeitungszeit;
• Nutzungsbedingungen am Zugriffspunkt;
• Hinweise auf ablaufenden Zugriff;
• Warnung bei Qualitäts- oder Freshness-Verletzung;
• einen direkten Weg für Fragen und Incidents.

In BI, Notebook und Query Tool

Ein Link zurück in den Katalog ist hilfreich, aber nicht genug.

Mindestens Zertifizierung, Definition, Datenstand, Owner und kritischer Qualitätsstatus sollten über API, Extension, semantische Schicht oder eingebettete Metadaten am Konsumpunkt erscheinen.

Wenn ein Consumer erst die Arbeitsumgebung verlassen, das richtige Asset erneut suchen und mehrere Tabs vergleichen muss, wird Governance im Alltag umgangen.

Consumer-Signal testen

Ein einfacher Abnahmetest:

1. Ein Consumer findet ein Datenprodukt ohne Hilfe.
2. Er erklärt Bedeutung, Aktualität und zulässige Nutzung.
3. Er erkennt eine simulierte Qualitätsbeeinträchtigung.
4. Er wählt den freigegebenen statt eines populären veralteten Assets.
5. Er findet Owner und Incident-Weg.
6. Er sieht dieselben Kernaussagen im BI-Bericht oder Query-Kontext.

Wenn nur ein Steward die richtigen Antworten in einer Administrationsansicht findet, ist die Capability nicht Ende zu Ende wirksam.

Warum ein Data Catalog in die Irre führen kann beschreibt die typischen Fälle, in denen reichhaltige Metadaten Sichtbarkeit vortäuschen, aber keine belastbare Consumer-Entscheidung ermöglichen.

1. Verantwortung

Verantwortung bedeutet mehr als einen Namen am Asset.

Ein belastbarer Owner:

• kennt den fachlichen oder technischen Verantwortungsbereich;
• hat ein explizites Mandat;
• kann Entscheidungen treffen oder delegieren;
• besitzt einen erreichbaren Eskalationsweg;
• wird bei Rollenwechsel ersetzt;
• bestätigt die Verantwortung regelmäßig.

Was der Katalog leisten sollte

• Rollen statt nur freie Personenfelder;
• Vererbung über Domain, Produkt und Asset;
• Gültigkeit und Bestätigungsstatus;
• Benachrichtigung bei Lücken;
• Historie von Verantwortungswechseln.

Mindestnachweis

Wer hatte zum Entscheidungszeitpunkt welches Mandat?

2. Workflow

Governance wird in Übergaben sichtbar.

Ein Workflow übersetzt Regeln in konkrete Arbeit:

• Definition prüfen;
• Datenprodukt zertifizieren;
• Zugriff genehmigen;
• Qualitätsfall triagieren;
• Ausnahme bewerten;
• Stilllegung freigeben.

Was der Katalog leisten sollte

• Ereignisse in Aufgaben übersetzen;
• Status und Fristen darstellen;
• Entscheidung und Begründung speichern;
• Eskalationen auslösen;
• externe Ticket- oder Workflow-Systeme integrieren.

Mindestnachweis

Welcher Fall wurde wann von wem mit welchem Ergebnis entschieden?

3. Evidence

Evidence ist nicht dasselbe wie Dokumentation.

Dokumentation beschreibt den Sollzustand.

Evidenz belegt, dass eine Kontrolle zu einem Zeitpunkt tatsächlich ausgeführt wurde.

Beispiele:

• bestätigte verantwortliche Person-Attestierung;
• Ergebnis eines Data-Quality-Tests;
• genehmigte Zugriffsanfrage;
• Log einer Richtlinie-Entscheidung;
• Screenshot oder Export eines Kontrollzustands;
• protokollierte Ausnahme mit Ablaufdatum.

Was der Katalog leisten sollte

• Nachweise mit Asset und Kontrolle verknüpfen;
• Herkunft und Zeitstempel erhalten;
• unveränderbare Referenzen ermöglichen;
• Gültigkeitsdauer anzeigen;
• fehlende oder veraltete Evidenz melden.

Mindestnachweis

Ist die Evidenz vollständig, aktuell, nachvollziehbar und dem richtigen Kontrollziel zugeordnet?

4. Durchsetzung

Ein Katalog kann erlaubte Nutzung beschreiben.

Die Durchsetzung erfolgt häufig woanders:

• Zugriffsverwaltung;
• Warehouse oder Lakehouse;
• BI-Plattform;
• API Gateway;
• Data-Loss-Prevention-System;
• Orchestrierung oder CI/CD.

Was der Katalog leisten sollte

• Richtlinie-Kontext maschinenlesbar bereitstellen;
• Durchsetzung Points referenzieren;
• Status und Ergebnis zurückführen;
• Abweichungen sichtbar machen;
• manuelle und automatische Kontrollen unterscheiden.

Mindestnachweis

Wurde die Entscheidung am relevanten Kontrollpunkt wirksam?

5. Quality

Data Quality ist kontextabhängig.

Ein technischer Test ohne Geschäftsauswirkung ist schwer zu priorisieren.

Ein Governance-tauglicher Qualitätskontext verbindet:

• Regel und Erwartung;
• betroffenes Asset;
• kritischen Datenzweck;
• Messwert und Schwelle;
• Owner und Bearbeitungsweg;
• Downstream-Auswirkung;
• akzeptiertes Restrisiko.

Was der Katalog leisten sollte

• Testergebnisse aufnehmen oder verlinken;
• Qualitätsstatus entlang Lineage zeigen;
• kritische Use Cases priorisieren;
• Incidents mit Owner und SLA verbinden;
• Zertifizierung bei relevanten Fehlern neu bewerten.

Mindestnachweis

Wurde ein relevantes Qualitätsproblem erkannt, entschieden und innerhalb der Zusage behandelt?

6. Lifecycle

Governance beginnt nicht erst nach Veröffentlichung.

Sie begleitet:

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

Entwurf
→ Review
→ Freigabe
→ aktive Nutzung
→ Änderung
→ Ablösung
→ Archivierung oder Löschung

Was der Katalog leisten sollte

• Lifecycle-Status eindeutig darstellen;
• Freigaben und Ablaufdaten verwalten;
• Nutzer über Änderungen informieren;
• Abhängigkeiten vor Stilllegung prüfen;
• Nachfolger und Migrationspfad verlinken;
• Aufbewahrung und Löschung nachvollziehbar machen.

Mindestnachweis

Wurde das Asset kontrolliert eingeführt, verändert und beendet?

Capability-Scorecard

Bewertet jede Fähigkeit von 0 (nicht definiert) bis 3 (messbar wirksam, integriert und nachweisbar).

Ein Use Case ist nur so belastbar wie sein schwächster notwendiger Baustein. Ein perfekter Lineage-Graph kompensiert weder fehlendes Verantwortung noch fehlendes Durchsetzung.

Kleinste tragfähige Umsetzung

Für ein kritisches Datenprodukt:

1. Owner und Entscheidungsmandat bestätigen.
2. Einen Freigabe- oder Incident-Workflow modellieren.
3. Zwei relevante Qualitätsregeln anbinden.
4. Den ausführenden Zugriffskontrollpunkt referenzieren.
5. Entscheidung und Kontrollergebnis als Evidenz sichern.
6. Review- und Ablaufdatum setzen.
7. Einen Änderungsfall testen.

Prüffragen

• Welche der sechs Fähigkeiten ist für den Use Case unverzichtbar?
• Welche davon führt der Katalog selbst?
• Wo liegen die autoritativen Daten?
• Welche Signale stammen aus Unity Catalog, Snowflake, dbt oder Power BI?
• Wo sieht der Nutzer Status und Konsequenz, ohne eine Steward-Ansicht zu öffnen?
• Welche Integrationen müssen bidirektional sein?
• Wie wird ein Fehler oder Rollenwechsel behandelt?
• Welche Kennzahl beweist Wirksamkeit?