Die Landkarte der Katalogtypen
Discovery Catalog, Plattformkatalog, Data Marketplace, Glossary mit Stewardship und Policy Suite lösen unterschiedliche Governance-Probleme.
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 denselben Bedarf sales_otc vergleicht das Team Unity Catalog, OpenMetadata und ein BI-Dataset-Inventar, als wären sie dasselbe. „Data Catalog“ meint Such-UI, Plattformkatalog, Marketplace oder Policy-Suite — falscher Typ → falsche Erwartung an Durchsetzung und Stewardship.
Hinzu kommt: Fast jedes Datentool hat bereits einen inventarartigen Katalog (Information Schema, Unity Catalog, dbt Docs, BI-Dataset-Listen, Schema Registry). Teil 1 zeigt, warum „wir brauchen einen Katalog“ oft der falsche Einstieg ist. Teil 2 ordnet die Typen.
Falsche Vergleiche:
- Discovery an Richtlinie Durchsetzung gemessen;
- Plattformkatalog soll fachliche Freigaben ersetzen;
- Marketplace ohne Bestellprozess als fertig verkauft;
- Glossar als technischer Lineage-Katalog;
- Richtlinie Suite als tägliche Datensuche.
Schwerpunkt und Systemgrenzen bleiben verschieden.
Leitentscheidung
Kataloge zuerst nach ihrem primären Nutzungsversprechen einordnen.
Für jede Kategorie werden vier Fragen beantwortet:
- Wer ist der wichtigste Nutzer?
- Welche Entscheidung soll leichter werden?
- Welche Metadaten sind unverzichtbar?
- Welches angrenzende System bleibt notwendig?
1. Discovery Catalog
Primäres Versprechen
Menschen finden und verstehen vorhandene Daten.
Typische Fähigkeiten
- Volltextsuche und Facetten;
- automatisches Metadatenimporting;
- technische Metadaten;
- Lineage und Nutzungssignale;
- Beschreibungen, Tags und einfache Kollaboration;
- Empfehlungen oder Popularität.
Gute Einsatzfälle
- Analysten suchen vertrauenswürdige Tabellen.
- Engineers analysieren Auswirkungen einer Änderung.
- Teams reduzieren doppelte Datenbestände.
- Neue Mitarbeitende erschließen eine Domäne.
Typische Grenze
Discovery zeigt Kontext, erzwingt aber selten Zugriff oder komplexe Policies.
Ein Suchtreffer ist noch kein freigegebener Nutzungspfad.
2. Platform Catalog
Primäres Versprechen
Assets innerhalb einer Datenplattform technisch verwalten und kontrollieren.
Typische Fähigkeiten
- zentrale Objekt- und Berechtigungsmodelle;
- plattformnahe Lineage;
- Klassifikation und Tags;
- Zugriffskontrolle;
- Audit Logs;
- Integration mit Compute, Storage und Sharing.
Gute Einsatzfälle
- Zugriffe im Lakehouse oder Warehouse vereinheitlichen.
- Datenobjekte über Workspaces hinweg verwalten.
- technische Richtlinien nahe an der Ausführung anwenden.
- Plattformaktivitäten revisionsfähig protokollieren.
Typische Grenze
Der Blick endet häufig an der Plattformgrenze.
Fachliche Workflows und heterogene Quellen benötigen zusätzliche Integration.
3. Data Marketplace
Primäres Versprechen
Konsumierbare Datenprodukte mit klaren Bedingungen anbieten.
Typische Fähigkeiten
- kuratierte Produktseiten;
- Zielgruppe, Zweck und Serviceversprechen;
- Request- und Approval-Flows;
- Nutzungsbedingungen;
- Subscriptions und Benachrichtigungen;
- Messung von Nachfrage und Nutzung.
Gute Einsatzfälle
- Nutzer bestellen ein freigegebenes Datenprodukt.
- Domains veröffentlichen Produkte mit SLA und Supportweg.
- Wiederverwendung wird gegenüber Schattenlösungen erleichtert.
- Zugang und Nutzungszweck werden nachvollziehbar.
Typische Grenze
Eine attraktive Storefront kompensiert keine schlechte Produktqualität.
Marketplace und technische Provisionierung müssen verbunden sein.
4. Glossary plus Stewardship
Primäres Versprechen
Fachliche Bedeutung, Verantwortung und Freigabe verbindlich organisieren.
Typische Fähigkeiten
- Begriffe, Definitionen und Beziehungen;
- Rollen und Verantwortungsbereiche;
- Review- und Approval-Workflows;
- Issue- und Task-Management;
- Verknüpfung mit Datenassets;
- Änderungshistorie.
Gute Einsatzfälle
- KPI-Definitionen harmonisieren.
- Begriffe domänenübergreifend abstimmen.
- Data Stewards durch geregelte Aufgaben führen.
- fachliche Änderungen nachvollziehbar freigeben.
Typische Grenze
Ein Glossar ohne technische Verknüpfung bleibt eine Wissensinsel.
Definitionen müssen bis zu Reports, Modellen und Feldern reichen.
5. Policy Suite
Primäres Versprechen
Regeln, Kontrollen, Ausnahmen und Evidenz verwalten.
Typische Fähigkeiten
- Richtlinie-Hierarchien und Kontrollziele;
- Zuordnung zu Risiken, Assets und Verantwortlichen;
- Ausnahme- und Attestierungsworkflows;
- Kontrolltests und Nachweis Collection;
- Audit Reporting;
- Integration mit Durchsetzung-Systemen.
Gute Einsatzfälle
- regulatorische Anforderungen operationalisieren.
- Richtlinie-Ausnahmen zeitlich begrenzen.
- Kontrollwirksamkeit nachweisen.
- Prüfungen mit konsistenter Evidenz versorgen.
Typische Grenze
Eine Policy Suite ist nicht automatisch die beste Discovery-Oberfläche.
Technische Durchsetzung bleibt oft in IAM, Datenplattform oder Security Tooling.
Kompakter Vergleich
| Typ | Primärer Job | Stärkste Nutzergruppe | Häufig fehlende Ergänzung |
|---|---|---|---|
| Discovery Catalog | Finden und verstehen | Analysten, Engineers | Access Workflow, Durchsetzung |
| Platform Catalog | Plattformobjekte kontrollieren | Platform Teams | Cross-Platform-Kontext |
| Data Marketplace | Produkte konsumierbar machen | Data Consumer, Domains | technische Provisionierung |
| Glossary + Stewardship | Bedeutung entscheiden | Fachbereiche, Stewards | technische Metadatenabdeckung |
| Policy Suite | Regeln und Evidenz steuern | Risk, Compliance, Audit | Discovery und Laufzeitkontrolle |
Hybride Produkte richtig bewerten
Viele Anbieter decken mehrere Typen ab.
Deshalb nicht nur Produktetiketten vergleichen.
Prüft anhand eines echten Ablaufs:
Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.
Suche
→ Verständnis
→ Nutzungsanfrage
→ Entscheidung
→ Provisionierung
→ Überwachung
→ Evidenz
Für jeden Schritt sollte klar sein:
- welches System führt;
- welche Daten übergeben werden;
- wer verantwortlich ist;
- was bei Fehlern geschieht.
Anti-Patterns
- Feature-Checkliste ohne Priorität: hundert Häkchen verdecken den wichtigsten Ablauf.
- Suite gleich Integration: Module desselben Anbieters sind nicht automatisch verbunden.
- Marketplace als neues Portal: Produkte bleiben ohne SLA, Owner und Provisionierung.
- Plattformgrenze ignorieren: Multi-Cloud und SaaS bleiben unsichtbar.
- Glossar zentralisieren: ein Team soll Definitionen für alle Domains allein pflegen.
Kleinste tragfähige Umsetzung
- Einen priorisierten Use Case wählen.
- Den dominanten Katalogtyp bestimmen.
- Zwei notwendige Nachbarfähigkeiten benennen.
- Einen Ablauf mit realen Assets testen.
- Übergaben und Systemgrenzen dokumentieren.
- Erst danach Produkte vergleichen.
Prüffragen
- Beginnt das Problem bei Suche, Zugang, Bedeutung, Richtlinie oder Durchsetzung?
- Muss die Lösung plattformübergreifend sein?
- Welche Nutzergruppe arbeitet täglich damit?
- Welche Workflows müssen im Produkt selbst laufen?
- Welche Kontrollen müssen außerhalb ausgeführt werden?
- Welche Evidenz ist revisionsrelevant?
Catalog Deep Dive
Part 2 of 6
View series