Warum ein Data Catalog Governance vortäuschen kann

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

„Wir haben einen Data Catalog“ steht im Audit-Slide — om-pilot listet Tabellen aus sales_otc. Offen bleibt: Wer ändert „aktiver Auftrag“? Wer stoppt den Mart bei Qualitätsfehler? Ein Catalog kann Verantwortung, Freigaben, Durchsetzung, Qualitätswege und Audit stützen; er erzeugt sie nicht allein.

Größenordnung: KMU/SMB — plattformnative Inventare behalten; zehn kritische Assets mit Owner + Entscheidungspfad steuern, bevor ein weiterer Katalog gekauft wird. Mid-Market — Capability-Lücke vs. bestehende Tool-Kataloge; cross-cutting Workflows nur wo nötig. Enterprise — explizit maßgeblicher Katalog je Capability, Scorecards an Outcomes statt Metadatenimport-Counts.

Katalog ≠ Metadaten ≠ Dashboard ≠ Semantic Layer

Ein Data Catalog wendet Metadaten an, damit Menschen Assets, Owner und Stewardship-Zustände finden. Metadaten sind der breitere Steuerungsinhalt — sie leben auch in Warehouse, dbt, IAM, Quality-Tools und BI. Ein Dashboard konsumiert vertrauenswürdige Kennzahlen für einen Scan; es inventarisiert nicht die Landschaft. Ein Semantic Layer / Metrics Store ist der Ort governten Kennzahlen-Sinns — nicht allein Katalog-Beschreibungsfelder und nicht Dashboard-Visual-Calcs.

Ein weiteres Katalogprodukt schafft weder Metadatenqualität noch Kennzahlen-Singularität noch Dashboard-Produktdisziplin.

Er sagt noch nicht, ob:

• kritische Daten einen entscheidungsfähigen verantwortliche Person haben;
• Begriffe verbindlich freigegeben werden;
• Zugriffs- und Nutzungsregeln durchgesetzt werden;
• Qualitätsprobleme einen geregelten Weg zur Behebung haben;
• Änderungen nachvollziehbar entschieden werden;
• Audit-Nachweise vollständig und belastbar sind.

Fast jedes Datentool hat bereits einen Katalog

Der zweite Denkfehler kommt oft vor dem ersten: Teams tun so, als gäbe es ohne ein neues Katalogprodukt keinen Katalog.

Das ist selten wahr.

Praktisch jedes Datentool führt bereits einen inventarartigen Katalog — oft unter anderem Namen:

Diese Bestände sind lokal autoritativ für Finden, Struktur und oft Zugriff innerhalb der Plattform. Sie beantworten aber nicht automatisch unternehmensweite Fragen zu Verantwortung, fachlicher Freigabe, plattformübergreifender Impact Analysis oder Audit-Evidence.

Deshalb ist „Wir brauchen einen Data Catalog“ oft ungenau. Präziser lautet die Frage:

Haben wir schon genug plattformnative Inventare — und fehlt uns ein übergreifendes Governance-Operating Model, das diese Inventare verbindet?

Ein weiteres Katalogprodukt ohne diese Klärung verdoppelt Suche und Pflege, ohne Governance zu erzeugen.

Ein Data Catalog ist fast nie „der erste Katalog“. Fast jedes Datentool hat bereits einen. Neu ist höchstens die unternehmensweite Steuerung darüber.

Leitentscheidung

Den Katalog nicht als Governance-Ergebnis und nicht als „erstmals vorhandenes Inventar“ bewerten, sondern als mögliche Infrastruktur für Governance-Fähigkeiten — oft ergänzend zu bereits vorhandenen Tool-Katalogen.

Die Leitfrage lautet nicht:

„Welche Funktionen hat unser Katalog?“

Sondern:

„Welche Governance-Entscheidung wird von wem getroffen, wie wird sie ausgeführt und womit wird ihre Wirksamkeit belegt — und welcher vorhandene Tool-Katalog liefert dafür bereits Wahrheit?“

Erst danach wird geprüft, welchen Anteil ein zusätzliches Katalogprodukt an diesem Ablauf übernehmen soll.

Drei Ebenen sauber trennen

1. Sichtbarkeit

Der Katalog zeigt Assets, Beschreibungen, Lineage, Owner-Felder, Klassifikationen oder Qualitätswerte.

Das ist wertvoll, weil unbekannte Daten nicht gesteuert werden können.

Sichtbarkeit beantwortet jedoch nur:

• Was existiert?
• Woher kommt es?
• Wie hängt es zusammen?
• Welcher Zustand ist dokumentiert?

2. Entscheidungsfähigkeit

Governance benötigt Rollen mit Mandat und einen eindeutigen Entscheidungsweg.

Diese Ebene beantwortet:

• Wer darf eine Definition freigeben?
• Wer akzeptiert ein Qualitätsrisiko?
• Wer entscheidet über erlaubte Nutzung?
• Wer priorisiert die Behebung?
• Wer genehmigt eine Ausnahme und bis wann?

Ein ausgefülltes Owner-Feld ist noch kein Mandat.

3. Wirksamkeit

Eine Entscheidung muss im Prozess oder technischen System ankommen.

Diese Ebene beantwortet:

• Wird unerlaubter Zugriff verhindert?
• Wird eine fehlerhafte Pipeline gestoppt?
• Wird ein veraltetes Datenprodukt außer Betrieb genommen?
• Wird eine Ausnahme nach Ablauf erneut geprüft?
• Kann ein Prüfer die Kette nachvollziehen?

Dokumentation ohne Ausführung bleibt Absicht.

Der häufigste Denkfehler

Viele Programme messen die Einführung des Werkzeugs:

• Anzahl geharvesteter Assets;
• Anteil ausgefüllter Beschreibungen;
• Zahl registrierter Nutzer;
• Suchanfragen pro Monat;
• Zahl verknüpfter Glossarbegriffe.

Diese Kennzahlen messen Adoption und Metadatenabdeckung.

Sie beweisen nicht, dass ein Governance-Risiko reduziert wurde — und sie ignorieren oft, dass dieselben Assets bereits in Unity Catalog, Information Schema oder dem BI-Inventar existierten.

Eine bessere Messung verbindet Katalognutzung mit einem Ergebnis:

• Zeit bis zur Identifikation des verantwortlichen Owners;
• Anteil fristgerecht geschlossener Qualitätsfälle;
• Dauer einer Impact Analysis vor einer Änderung;
• Anteil kritischer Assets mit gültigem Kontrollnachweis;
• Zahl verhinderter oder rechtzeitig korrigierter Fehlverwendungen;
• Anteil kritischer Assets, bei denen der autoritative Katalog klar ist (Plattform vs. übergreifend).

Capability statt Feature

Ein Feature ist eine Produktfunktion.

Eine Capability ist eine wiederholbar erbrachte organisatorische Fähigkeit.

Beispiel Verantwortung:

Der Katalog kann Feature, Workflow und Nachweis teilweise abdecken.

Mandat, Eskalation und Konsequenz bleiben Aufgaben des Operating Models.

Kleinste tragfähige Umsetzung

Nicht den gesamten Katalog „governed“ machen.

Stattdessen einen kritischen Anwendungsfall auswählen, zum Beispiel einen regulatorischen Report oder einen zentralen Vertriebs-KPI.

1. Fünf bis zehn relevante Assets abgrenzen.
2. Für jedes Asset einen entscheidungsfähigen Owner bestätigen.
3. Eine konkrete Entscheidung definieren, etwa Freigabe der KPI-Definition.
4. Den ausführenden Kontrollpunkt benennen.
5. Erwartete Evidenz und Aufbewahrungsdauer festlegen.
6. Einen echten Fall vollständig durchspielen.
7. Durchlaufzeit, offene Übergaben und fehlende Nachweise messen.

Der Pilot ist erfolgreich, wenn die Entscheidung reproduzierbar funktioniert.

Eine schöne Katalogseite allein genügt nicht.

Anti-Patterns

Metadatenimporting als Erfolg

Millionen erfasste Spalten erhöhen die Abdeckung, aber oft auch das Suchrauschen — besonders wenn dieselben Objekte bereits im Plattformkatalog stehen.

Zweiter Katalog ohne Auftrag

Ein Enterprise-Catalog wird eingeführt, obwohl Unity Catalog, Warehouse-Metastore oder BI-Inventar die lokalen Inventarfragen bereits lösen. Ohne klaren übergreifenden Auftrag entsteht Doppelpflege.

Owner ohne Mandat

Eine Person wird eingetragen, kennt ihre Rolle jedoch nicht oder kann nichts entscheiden.

Policy als PDF

Eine Regel ist verlinkt, aber weder in Zugriffssysteme noch in Arbeitsabläufe übersetzt.

Zertifizierung ohne Ablauf

Ein grünes Badge bleibt bestehen, obwohl Daten, Definition oder Qualitätslage geändert wurden.

Dashboard ohne Konsequenz

Rote Werte sind sichtbar, lösen aber weder Ticket, Eskalation noch Entscheidung aus.

Prüffragen

• Welche Entscheidung wird durch den Katalog schneller oder sicherer?
• Welcher bereits vorhandene Tool-Katalog liefert dieselbe Inventarwahrheit schon?
• Wer trägt dafür ein explizites Mandat?
• Wo findet die technische oder organisatorische Ausführung statt?
• Welches Ereignis startet den Workflow?
• Welche Evidenz beweist das Ergebnis?
• Wann läuft eine Freigabe oder Ausnahme ab?
• Was geschieht, wenn niemand reagiert?

Wenn diese Fragen nicht beantwortet sind, fehlt Governance-Fähigkeit — unabhängig davon, wie viele Katalogprodukte lizenziert sind.

Artefakt

Erstellt eine einseitige Capability-Kette:

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

Risiko oder Bedarf
→ verantwortliche Entscheidung
→ Workflow und Übergaben
→ ausführender Kontrollpunkt
→ Evidenz
→ Wirksamkeitskennzahl

Markiert pro Schritt das führende System.

Der Katalog darf mehrere Schritte unterstützen, sollte aber nicht pauschal für die gesamte Kette verantwortlich erklärt werden.