Einen Data Catalog nach Fähigkeiten auswählen

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

Für sales_otc vergleicht das Team drei „Catalogs“ anhand Feature-Tabellen — Workflow meint einmal Notification, einmal Approval. Auswahl braucht einen testbaren Capability-Rahmen, keine Produktetiketten.

Beides kann täuschen.

Anbieter verwenden dieselben Begriffe für unterschiedliche Tiefen:

• „Workflow“ kann eine Benachrichtigung oder ein mehrstufiger Approval-Prozess sein.
• „Lineage“ kann Tabellenbeziehungen oder spaltenweite Laufzeit-Lineage bedeuten.
• „Richtlinie“ kann ein Textfeld oder eine maschinenlesbare Regel sein.
• „Marketplace“ kann eine Produktseite oder vollständige Provisionierung umfassen.
• „KI“ kann Textvorschläge oder kontrollierte Automatisierung meinen.

Eine belastbare Auswahl braucht einen kleinen, testbaren Rahmen.

Gate 0: Haben wir bereits einen Plattformkatalog?

Vor RFI, Marktsondierung oder Anbieterdemo steht eine Bestandsentscheidung.

Databricks, Snowflake, dbt, Power BI und andere Plattformen liefern bereits Katalog-, Lineage-, Qualitäts-, Endorsement-, Policy- oder Nutzungsfunktionen. Ein zusätzlicher Enterprise Catalog ist nur dann begründet, wenn priorisierte Use Cases Fähigkeiten über diese Grenzen hinaus benötigen.

Das Gate verhindert zwei typische Fehler:

• Eine Organisation kauft zentrale Suche, obwohl das eigentliche Problem fehlende Definitionen und verantwortliche Person sind.
• Ein Plattformkatalog wird vorschnell als ausreichend erklärt, obwohl Nutzer mehrere Systeme übergreifend beurteilen müssen.

Schritt 1: Vorhandene Kataloge inventarisieren

Erfasst nicht nur Produkte mit „Catalog“ im Namen.

Zum Bestand gehören:

• Plattformkataloge in Warehouse und Lakehouse;
• dbt-Dokumentation und Transformationsmetadaten;
• semantische Modelle, Endorsement und Lineage in BI;
• Glossare und Definition Repositories;
• Data-Quality- und Observability-Portale;
• Zugriffsverwaltung-, Richtlinie- und Access-Request-Systeme;
• Datenportale und interne Marketplaces;
• MDM- und Reference-Data-Verzeichnisse.

Für jedes System werden Asset-Scope, Metadatenarten, Consumer, Owner, Integrationen, Aktualität und Exportfähigkeit dokumentiert.

Schritt 2: Reale Abdeckung statt Lizenzumfang prüfen

Eine aktivierte Funktion ist noch keine betriebsfähige Capability.

Prüft für jeden priorisierten Use Case:

• Sind die relevanten Assets tatsächlich erfasst?
• Werden Änderungen innerhalb der erforderlichen Frist sichtbar?
• Sind Owner und Definitionen vollständig genug?
• Erreicht das Signal den Nutzer in seinem Arbeitskontext?
• Kann eine Entscheidung ausgelöst und umgesetzt werden?
• Bleibt die Evidenz für den benötigten Zeitraum erhalten?
• Gibt es ein Team für Connector, Inhalt und Incident?

Schritt 3: Lücke klassifizieren

Nicht jede Lücke verlangt ein neues Produkt.

Ein Toolkauf löst eine Content- oder Operating-Model-Lücke nicht automatisch.

Schritt 4: Gate-Entscheidung

Bestehenden Plattformkatalog ausbauen, wenn:

• der priorisierte Use Case überwiegend innerhalb einer Plattform liegt;
• technische Assets, Lineage und Berechtigungen dort aktuell sind;
• fachlicher Kontext verlässlich angebunden werden kann;
• Nutzer die notwendigen Signale am Nutzungspunkt sehen;
• Workflow und Evidenz mit vertretbarem Aufwand integriert werden;
• kein kritischer Cross-Platform-Abbruch besteht.

Enterprise Catalog bewerten, wenn:

• Nutzer Assets über mehrere Plattformen finden und vergleichen müssen;
• gemeinsame Business Terms, Datenprodukte und verantwortliche Person plattformübergreifend gelten;
• End-to-End-Lineage für kritische Entscheidungen erforderlich ist;
• Lifecycle, Zertifizierung oder Richtlinien zentral koordiniert werden müssen;
• Evidenz aus mehreren Kontrollpunkten zusammengeführt werden muss;
• vorhandene Kataloge die Muss-Ergebnisse trotz Pilot nachweislich nicht erreichen.

Auswahl stoppen, wenn:

• kein priorisierter Use Case und kein messbares Ergebnis existiert;
• die Lücke primär aus fehlendem Verantwortung oder ungepflegten Definitionen besteht;
• autoritative Systeme und Integrationsverantwortung ungeklärt sind;
• kein Team den späteren Content- und Plattformbetrieb übernimmt.

Evidenzpaket für das Gate

Die Entscheidung darf nicht auf Architekturfolien oder Feature-Häkchen beruhen.

Das Mindestpaket enthält:

1. Systeminventar: vorhandene Katalog- und Metadatensysteme mit Owner und Scope.
2. Asset-Stichprobe: mindestens ein kritisches Datenprodukt vom Source-System bis zum Konsum.
3. Coverage-Messung: Anteil erfasster kritischer Assets, Definitionen, Owner und Lineage.
4. Freshness-Protokoll: Zeit zwischen Plattformänderung und sichtbarer Katalogänderung.
5. Consumer-Test: reale Nutzer finden, bewerten und verwenden das richtige Asset.
6. Workflow-Test: eine Freigabe, Ausnahme oder Qualitätsstörung durchläuft den kompletten Weg.
7. Durchsetzung-Nachweis: die Entscheidung wird am technischen Kontrollpunkt wirksam.
8. Audit-Export: Entscheidung, Identität, Zeitstempel und Ausführung sind rekonstruierbar.
9. Betriebsnachweis: Monitoring, Support, Content-Verantwortung und Kosten sind benannt.
10. Gap Register: jede Lücke besitzt Risiko, Owner, Maßnahme und Zieltermin.

Beweisstandard

Als Evidenz akzeptabel sind:

• exportierte Metadaten und API-Antworten;
• Zeitstempel aus Metadatenimporting und Quellsystem;
• Screenshots mit realen, anonymisierten Assets;
• Testprotokolle mit Rolle, Aufgabe und Ergebnis;
• Workflow-, Richtlinie- und Audit-Logs;
• Incident- und Support-Verläufe;
• gemessene statt geschätzte Betriebsaufwände.

Nicht ausreichend sind:

• Anbieter-Roadmaps;
• Demo-Daten ohne eigene Integrationen;
• „wird unterstützt“ ohne ausgeführten Test;
• manuell vorbereitete Happy Paths;
• ein Lizenzmerkmal ohne verantwortlichen Betriebsprozess.

Das Gate endet mit einer dokumentierten Entscheidung: vorhandene Capability ausbauen, gezielt integrieren oder eine Produktauswahl starten.

Leitentscheidung

Jeden Katalog mit demselben Capability Frame bewerten:

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

Context
Decision
Action
Evidence
Operation

Der Frame bleibt bewusst kurz.

Er prüft nicht, ob ein Feature existiert, sondern ob der priorisierte Use Case damit betrieben werden kann.

1. Context

Kann die Lösung den nötigen Kontext korrekt und aktuell verbinden?

Prüfpunkte

• unterstützte Asset-Typen;
• nachgewiesene Abdeckung der bereits vorhandenen Plattformkataloge;
• Metadatenimporting-Frequenz und Änderungsverhalten;
• technische und fachliche Lineage;
• Glossar, Klassifikation und Beziehungen;
• Nutzung, Popularität und Kritikalität;
• offene API und Exportmöglichkeiten;
• nachvollziehbare Herkunft der Metadaten.

Testfrage

Kann ein Consumer erkennen, welches Asset für seinen Zweck geeignet ist und warum?

Warnsignal

Die Demo zeigt reichhaltige Beispieldaten, aber keine Aktualisierung aus der eigenen Landschaft.

2. Decision

Kann die Lösung eine Governance-Entscheidung mit Rollen und Regeln unterstützen?

Prüfpunkte

• Rollenmodell und Mandate;
• konfigurierbare Reviews;
• mehrstufige Freigaben;
• Fristen und Eskalationen;
• Ausnahmen und Delegation;
• Entscheidungshistorie;
• Trennung von Antragsteller und Genehmiger.

Testfrage

Kann ein realer Owner eine Definition, Nutzung oder Ausnahme nachvollziehbar entscheiden?

Warnsignal

„Workflow“ bedeutet lediglich Kommentar oder E-Mail.

3. Action

Kann die Entscheidung eine wirksame Handlung auslösen?

Prüfpunkte

• Integrationen mit Zugriffsverwaltung und Datenplattform;
• Tickets und Orchestrierung;
• Webhooks und Event-Schnittstellen;
• Richtlinie-Ausgabe;
• Provisionierung und Entzug;
• Benachrichtigung betroffener Nutzer;
• Rückmeldung des Ausführungsergebnisses.

Testfrage

Wird nach einer Genehmigung der richtige Zugriff gewährt und nach Ablauf entzogen?

Warnsignal

Der Prozess endet mit einem grünen Status im Katalog.

4. Evidence

Kann die Lösung Wirksamkeit und Historie belegen?

Prüfpunkte

• Zeitstempel und Identität;
• unveränderbare Historie;
• Herkunft von Testergebnissen;
• Kontroll- und Richtlinie-Zuordnung;
• Evidenzgültigkeit;
• Audit-Export;
• Aufbewahrung und Zugriffsschutz.

Testfrage

Kann ein unabhängiger Prüfer Entscheidung und Ausführung später rekonstruieren?

Warnsignal

Nachweise bestehen nur aus veränderbaren Links.

5. Operation

Kann die Lösung dauerhaft in der Organisation betrieben werden?

Prüfpunkte

• Zuständigkeit für Plattform und Inhalte;
• Deployment- und Upgrade-Modell;
• Monitoring und Support;
• Berechtigungsadministration;
• Metadatenqualität;
• Kosten bei wachsendem Volumen;
• Ausstieg- und Exportfähigkeit.

Testfrage

Wer behebt einen ausgefallenen Connector und wer korrigiert eine falsche Definition?

Warnsignal

Der Business Case berücksichtigt Lizenzen, aber nicht Stewardship und Plattformbetrieb.

Scorecard

Eine einfache Skala verhindert Scheingenauigkeit:

Nur Muss-Fähigkeiten gewichten.

Eine hohe Gesamtsumme darf kein Abbruchkriterium kompensieren.

Beispiel:

Ein Szenario statt zehn Demos

Alle Anbieter sollten dasselbe Szenario durchführen.

Beispiel:

Eine Analystin beantragt ein sensibles Kunden-Datenprodukt für eine befristete Analyse. Der fachliche Owner prüft Zweck und Klassifikation. Nach Freigabe wird Zugriff gewährt, Nutzung protokolliert und nach 30 Tagen entzogen.

Der Test umfasst:

1. Produkt finden.
2. Bedeutung und Qualität verstehen.
3. Nutzung beantragen.
4. Entscheidung mit Begründung treffen.
5. Zugriff technisch provisionieren.
6. Ausführung zurückmelden.
7. Evidenz exportieren.
8. Zugriff nach Ablauf entziehen.

Beobachtet Brüche, Medienwechsel und manuelle Nacharbeit.

Katalog ist Teil einer Landschaft

Die Auswahl darf nicht isoliert erfolgen.

Ein Katalog grenzt an:

• Datenplattform und Storage;
• Transformation und Orchestrierung;
• semantische Schicht und BI;
• Zugriffsverwaltung und Security;
• Data Quality und Observability;
• Privacy, Risk und Compliance;
• Ticketing und Workflow;
• MDM und Reference Data.

Die Einordnung dieser Produktfamilien vertieft Metadaten-Tools und Produktkategorien.

Die fachliche Grundlage zu Herkunft, Qualität, Lineage, Aktivierung und Operating Model liefert die Serie Metadata Deep Dive.

Kleinste tragfähige Auswahl

1. Vorhandene Plattformkataloge und Metadatensysteme inventarisieren.
2. Einen priorisierten Use Case festlegen.
3. Das Gate mit Asset-, Consumer- und Workflow-Evidenz durchführen.
4. Pro Frame-Perspektive ein Muss-Ergebnis definieren.
5. Drei Abbruchkriterien benennen.
6. Ein identisches Testszenario vorbereiten.
7. Eigene Daten und Rollen verwenden.
8. Integrationen tatsächlich ausführen.
9. Betriebsaufwand separat bewerten.
10. Entscheidung samt Evidenz dokumentieren.

Prüffragen

• Welcher Use Case finanziert und legitimiert die Auswahl?
• Welche Muss-Ergebnisse deckt ein vorhandener Plattformkatalog bereits nachweislich ab?
• Ist die verbleibende Lücke funktional, integrativ, inhaltlich oder betrieblich?
• Welche fünf bis zehn Ergebnisse sind wirklich unverzichtbar?
• Welche Systeme bleiben autoritativ?
• Welche Übergabe ist am risikoreichsten?
• Welche Evidenz muss der Test erzeugen?
• Wer trägt Plattform- und Content-Betrieb?
• Wie verlassen wir das Produkt bei Bedarf?