Wann welcher Data Catalog ausreicht
Eine Entscheidungsmatrix verbindet konkrete Governance-Use-Cases mit den minimal benötigten Katalogfähigkeiten.
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 reicht oft: Discovery + Owner + Glossarbegriff + Link zur Warehouse-Policy — nicht die maximale Suite. Feature-Listen erzeugen zwei Risiken: Überkauf einer Suite oder Unterkauf einer Suche ohne Workflow/Durchsetzung.
„Ausreichend“ heißt:
Der priorisierte Use Case läuft Ende zu Ende (Verantwortung, Übergabe, Nachweis) — nicht dass jedes Feature-Kästchen grün ist.
Leitentscheidung
Vom Use Case zur Mindestfähigkeit entscheiden.
Nicht jede Lücke muss durch dasselbe Produkt geschlossen werden.
Die Matrix bestimmt:
- den primären Katalogtyp;
- unverzichtbare Fähigkeiten;
- notwendige Integrationen;
- ein klares Abbruchkriterium.
Entscheidungsmatrix
| Use Case | Primärer Typ | Mindestfähigkeiten | Notwendige Ergänzung |
|---|---|---|---|
| Daten finden und verstehen | Discovery Catalog | Suche, Metadatenimporting, Kontext, Lineage, Owner | Zugriffspfad |
| Plattformzugriffe kontrollieren | Platform Catalog | Objektmodell, IAM, Audit, Klassifikation | fachliche Policy |
| Datenprodukte anbieten | Marketplace | Produktseite, SLA, Request, Approval, Subscription | Provisionierung |
| KPI-Definitionen freigeben | Glossary + Stewardship | Begriffe, Rollen, Review, Historie, Asset-Link | BI-/Semantic-Layer-Verknüpfung |
| regulatorische Kontrollen belegen | Policy Suite | Policy Mapping, Attestierung, Evidence, Ausnahme | Durchsetzung und Audit Store |
| Änderungen bewerten | Discovery oder Platform Catalog | Lineage, Nutzung, Owner, Change Signal | Change Workflow |
| Qualitätsfälle steuern | Discovery oder Governance Catalog | Tests, Kritikalität, Workflow, SLA | Observability/Ticketing |
| Assets stilllegen | Catalog mit Lifecycle | Status, Lineage, Consumer, Approval, Historie | technische Deprovisionierung |
Die Tabelle ist ein Startpunkt.
Die tatsächliche Mindestgrenze hängt von Risiko, Plattformlandschaft und Betriebsmodell ab.
Use Case 1: Daten finden
Minimum
- technische Metadaten werden automatisch aktualisiert;
- Suche liefert relevante Ergebnisse;
- Owner und Beschreibung sind sichtbar;
- Lineage oder Nutzung hilft bei der Einordnung;
- ein Zugangspfad ist verlinkt.
Nicht zwingend
Ein komplexer Policy-Workflow ist nicht erforderlich, wenn nur öffentliche interne Daten gesucht werden.
Abbruchkriterium
Consumer finden zwar ein Asset, können aber weder Vertrauensstatus noch Zugang erkennen.
Use Case 2: Plattformzugriff steuern
Minimum
- Identitäten und Gruppen sind integriert;
- Berechtigungen wirken am Datenobjekt;
- Klassifikationen können Richtlinien beeinflussen;
- Änderungen werden protokolliert;
- Ausnahmen sind zeitlich begrenzt.
Nicht zwingend
Eine unternehmensweite Discovery-Oberfläche ist für einen eng begrenzten Plattformstart optional.
Abbruchkriterium
Der Katalog dokumentiert Zugriff, setzt ihn aber nicht am Laufzeitpunkt durch.
Use Case 3: Datenprodukte anbieten
Minimum
- Produktzweck und Zielgruppe sind klar;
- verantwortliche Person, Supportweg und SLA sind sichtbar;
- Nutzungsbedingungen werden verstanden;
- Bestellung und Genehmigung sind nachvollziehbar;
- Bereitstellung wird ausgelöst;
- Nutzer erhalten Änderungsmeldungen.
Nicht zwingend
Spaltenweite Lineage kann später folgen, wenn Produktgrenzen und Provisionierung zuerst zählen.
Abbruchkriterium
Die Storefront endet bei „Owner kontaktieren“.
Use Case 4: Begriffe und KPIs freigeben
Minimum
- eindeutige Definition und Umfang;
- fachlicher Owner und Steward;
- Review mit Entscheidungshistorie;
- Beziehungen zu ähnlichen Begriffen;
- Verknüpfung zum semantischen Modell und Report;
- Ablauf bei Änderungen.
Nicht zwingend
Ein Marketplace ist nicht notwendig, wenn keine Datenprodukte bestellt werden.
Abbruchkriterium
Die freigegebene Definition ist nicht mit ihrer technischen Umsetzung verbunden.
Use Case 5: Compliance nachweisen
Minimum
- Anforderungen sind auf Richtlinien und Kontrollen abgebildet;
- Kontrollen besitzen Owner und Frequenz;
- Evidenz hat Herkunft und Zeitstempel;
- Ausnahmen haben Begründung und Ablaufdatum;
- Durchsetzung-Ergebnisse sind referenziert;
- Audit-Export ist reproduzierbar.
Nicht zwingend
Eine breite Empfehlungssuche ist für diesen Use Case nachrangig.
Abbruchkriterium
Das System zeigt den Sollzustand, kann die Ausführung aber nicht belegen.
Use Case 6: Änderungen sicher durchführen
Minimum
- technische und fachliche Lineage;
- Nutzung und Kritikalität;
- verantwortliche verantwortliche Person;
- automatisches Change Signal;
- Review- und Freigabeweg;
- Benachrichtigung betroffener Nutzer.
Nicht zwingend
Ein umfassendes Glossar ist optional, wenn der Scope rein technisch ist.
Abbruchkriterium
Auswirkungen werden erst nach dem Deployment sichtbar.
Muss, Soll, Später
Für jede Fähigkeit drei Horizonte verwenden.
Muss
Ohne diese Fähigkeit scheitert der erste produktive Ablauf oder erzeugt ein unvertretbares Risiko.
Soll
Die Fähigkeit verbessert Skalierung und Bedienbarkeit, ist aber zunächst mit einem kontrollierten manuellen Schritt ersetzbar.
Später
Die Fähigkeit gehört zu einem weiteren Use Case und darf die aktuelle Auswahl nicht dominieren.
Diese Trennung reduziert Suite-Bias und unnötige Implementierung.
Bewertungsregel
Gewichtet nur Kriterien, die sich auf einen beobachtbaren Ablauf beziehen.
Beispiel:
Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.
Kriterium: Zugriffsentscheidung
Test: Sensitives Datenprodukt mit realem Nutzer bestellen
Erwartung: Policy, Owner, Approval und Provisionierung bleiben verbunden
Nachweis: Antrag, Entscheidung, gewährter Zugriff und Ablaufdatum
Eine Demo ohne reale Übergaben zählt nicht als bestanden.
Kleinste tragfähige Umsetzung
- Einen Use Case auswählen.
- Ein konkretes Asset und einen realen Nutzer bestimmen.
- Muss-Fähigkeiten aus der Matrix ableiten.
- Führende Systeme und Integrationen markieren.
- Einen Ende-zu-Ende-Test formulieren.
- Zwei Produkte oder vorhandene Lösungen testen.
- Ergebnis anhand Evidenz bewerten.
Anti-Patterns
- Alles ist Muss: Priorisierung wird verhindert.
- Feature zählt mehr als Ablauf: ein Häkchen ersetzt keinen Test.
- Manuell ist immer schlecht: ein kontrollierter Pilot darf Übergaben manuell prüfen.
- Integration wird angenommen: PowerPoint-Pfeile sind keine funktionierende Schnittstelle.
- Später nie prüfen: temporäre Lücken werden zum Dauerzustand.
Catalog Deep Dive
Part 4 of 6
View series