Strategie für den Data Catalog
Stand 2026-09-03
Ein Data Catalog verhindert, dass die Plattform zum Sumpf wird. Drei Aufgaben: Inventur (durchsuchbares Register), Business-Glossar (vereinbarte Begriffsdefinitionen, verknüpft mit physischen Objekten, sodass „Umsatz" eine einzige Bedeutung hat), Klassifizierung & Stewardship (Sensitivitäts-Tags + benannter Owner pro Data Product). Nur Inventur ist ein Telefonbuch; Glossar + Stewardship sind der Ort, an dem Governance lebt. Der Catalog von SAP Datasphere ist metadatengetrieben und verknüpft Lineage (M077); die strategischen Entscheidungen sind Taxonomie, Glossar-Ownership und Zertifizierungsprozess — nicht „einschalten". Aktive Metadaten (kontinuierlich erfasst) schlagen passive. Der Catalog macht „Data Products mit Verträgen" real (das Muster von BDC, M068). Auffindbarkeit ist die Voraussetzung für Self-Service, der nicht in Silos zerfällt.
Was Sie lernen
- Ein Governance-Modell für den Data Catalog entwerfen, das die drei Catalog-Aufgaben abdeckt — Inventur, Business-Glossar sowie Klassifizierung & Stewardship — mit einem benannten Owner je Glossarbegriff und je Data Product
- Einen Zertifizierungsprozess definieren, der ein Data Product von raw über catalogued zu certified für Self-Service-Konsum bewegt, und den Catalog-Umfang nach Governance-Wert statt nach Katalogisierung jedes Legacy-Objekts bestimmen
- Den Catalog von SAP Datasphere so konfigurieren, dass er aktive Metadaten erfasst (kontinuierlich angereichert: Nutzungssignale, Aktualität, Qualitätsscores) und mit Lineage verknüpft (Begleitmodul M077), sodass ein Catalog-Eintrag nachweisbare Provenienz zeigt
- Das Schattendatensatz-Fehlermuster diagnostizieren — Business-User, die ihre eigenen Datensätze neu bauen, weil sie einen zentralen nicht finden oder ihm nicht vertrauen können — und die Auffindbarkeits- und Stewardship-Korrekturen entwerfen, die es Self-Service-Analytics erlauben, ohne Fragmentierung zu skalieren
Ein Data Catalog verhindert, dass eine Datenplattform zum Datensumpf wird, und der Moment, in dem dieses Risiko real wird, ist vollkommen vorhersehbar: Sobald eine Organisation Dutzende Data Products angesammelt hat, verteilt über mehrere Datasphere-Spaces, mehrere über BDC angebundene Nicht-SAP-Quellen und Jahre an noch genutztem, angehäuftem BW-Content, hört die begrenzende Größe für den Wert der Plattform auf, "können wir diese Daten technisch speichern und modellieren" zu sein, und wird zu "kann überhaupt jemand die richtige, vertrauenswürdige Version dieser Daten finden — und wissen, ohne herumzufragen, dass man ihr trauen kann". Ein Catalog ist die Antwort auf diese zweite Frage, und Catalog-Strategie ist im Kern eine Governance-Disziplin, die zufällig in Software umgesetzt wird, kein Tooling-Installationsprojekt, das zufällig Governance berührt.
Drei Aufgaben eines Catalogs
Ein Catalog, der nur die erste dieser drei Aufgaben erfüllt, löst das Problem, für das er beschafft wurde, tatsächlich nicht — weshalb Catalog-Strategiegespräche, die bei "welches Tool" statt bei "welches Governance-Modell" stehenbleiben, tendenziell enttäuschen.
Voraussetzungen
- Mittlere praktische Erfahrung in SAP-Analytics-Projekten
- Zunächst Kernkonzepte durchgehen: C041, C038, C037
Lernergebnisse
- Die drei Aufgaben eines Data Catalogs erklären und warum Inventur allein keine ausreichende Governance ist.
- Ein Glossar-Governance- und Zertifizierungsmodell mit benannter Ownership je Begriff und je Data Product entwerfen.
- Die Erfassung aktiver Metadaten, verknüpft mit Lineage, so konfigurieren, dass Catalog-Einträge vertrauenswürdig bleiben, während sich der Bestand weiterentwickelt.
- Das Fehlermuster Schattendatensatz / Self-Service-Fragmentierung diagnostizieren und mit einer Auffindbarkeits- und Stewardship-Korrektur beheben.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.