Der Catalog ist nicht das Dashboard

Der Catalog hilft, Assets und Kontext zu finden. Ein Dashboard beantwortet eine situative Frage mit Filtern, Zeitfenster und Visualisierung. Catalog ≠ Dashboard: Der Catalog genehmigt keine Zahl allein, und ein Dashboard dokumentiert nicht automatisch deren Herkunft.

← Vorheriger Teil · Nächster Teil →

Entscheidung

Jeder produktive Dashboard-Claim erhält einen stabilen Link zu Metric-ID, Datensatz, Owner und Gültigkeitskontext im Catalog. Der Catalog verweist zurück auf aktive Verbraucher.

zeigt eine Zahl in einem bestimmten Zusammenhang, zum Beispiel mit Filtern, Zeitraum und Zielgruppe. Der Catalog hilft beim Finden und Verstehen. Wenn beides vermischt wird, sieht eine Zahl vertrauenswürdig aus, obwohl Definition, Filter oder Owner fehlen.

Lösung: Jeder wichtige Dashboard-Claim bekommt eine stabile Verbindung zur fachlichen Definition, zur Datenquelle, zum Owner und zur Version. Nutzer sehen im Dashboard genug Kontext für die Entscheidung und können bei Bedarf über den Catalog die Herkunft und Bedeutung prüfen.

Ein Claim ist mehr als eine Kachel. Er ist eine überprüfbare Aussage wie: „Die monatliche Churn-Rate für zahlende Self-Service-Kunden liegt im Juli bei 3,2 Prozent.“ Damit andere die Aussage korrekt nutzen können, brauchen sie Metric-Version, Population, Zeitraum, Filter, Währung oder Einheit, Datenstand und Gültigkeitsgrenzen. Das Dashboard präsentiert diesen Kontext selektiv; der Catalog macht ihn auffindbar und verbindet ihn mit Definition, Datenprodukt und weiteren Consumern.

Unterschiedliche Nutzeraufgaben

Catalog-Nutzer fragen: Welche Daten oder Kennzahlen existieren? Wem gehören sie? Sind sie freigegeben? Woher stammen sie? Welche Produkte und Reports verwenden sie? Dashboard-Nutzer fragen: Was hat sich verändert? Ist ein Ziel gefährdet? Wo soll ich eingreifen? Das erste ist Discovery und Verständnis, das zweite eine analytische Entscheidungssituation.

Darum sollte eine Catalog-Seite nicht zu einem zweiten Dashboard werden. Kleine Profil- oder Qualitätsvisualisierungen können beim Verständnis helfen, ersetzen aber keinen kuratierten Entscheidungskontext. Ebenso sollte ein Dashboard nicht das gesamte Glossar nachbilden. Es zeigt die für die Entscheidung notwendigen Hinweise und bietet einen stabilen Deep Link für Details.

Worked Example: Churn im Executive Dashboard

Ein Executive Dashboard enthält „Monthly Logo Churn“. Die Kachel filtert Testkunden, interne Accounts und Kunden ohne volle Abrechnungsperiode aus. Im Catalog ist die Metric-ID customer.logo_churn.monthly.v3 mit Definition, Owner, Semantic-Version, Datenprodukt, Lineage und aktiven Consumern verknüpft. Das Dashboard übergibt beim Deep Link seine Filterparameter, sodass ein Nutzer nicht auf einer allgemeinen Asset-Seite landet.

Das CRM-Team ändert den Statuscode für Kündigungen. Die Lineage-Analyse findet die betroffene Metric und drei Dashboards. Der Catalog Steward erzeugt einen Impact-Hinweis; Metric Owner und BI Owner prüfen, ob die Semantik oder nur das Mapping betroffen ist. Nach Tests wird die Änderung veröffentlicht. Ein Dashboard mit lokaler Altlogik fällt beim Abgleich auf und erhält ein Ablaufdatum.

Das Beispiel zeigt auch den Rückweg: Nutzungstelemetrie meldet, dass ein regionales Dashboard seit sechs Monaten nicht geöffnet wurde. Sein BI Owner bestätigt die Stilllegung. Der Catalog markiert es als retired, statt es weiter als aktiven Consumer und vertrauenswürdigen Einstiegspunkt anzuzeigen.

Workflow

1. Entscheidung und Zielgruppe erfassen. Dokumentiere nicht nur Dashboard-Name, sondern Handlung, Frequenz und Nutzergruppe.
2. Kritische Claims inventarisieren. Beginne mit fünf Kacheln, deren Fehlinterpretation materielle Folgen hätte.
3. Kontext explizieren. Halte Metric-ID, Version, Population, Zeitraum, Filter, Einheit, Freshness und Ausnahmen fest.
4. Beziehungen verlinken. Verbinde Claim, Dashboard, Datenprodukt, Definition, Owner und Lineage mit stabilen IDs.
5. Publish-Gate anwenden. Prüfe vor Veröffentlichung Status, Kontext, Zugriffsrechte und Reconciliation.
6. Impact simulieren. Ändere Quelle, Filter oder Metric-Version und kontrolliere Benachrichtigung sowie Migration.
7. Lebenszyklus schließen. Speise Nutzung, Incidents und Stilllegung in den Catalog zurück.

Sizing nach Reife und Größe

SME/SMB: Nutze eine Dashboard-Produktseite mit Owner, Zweck, fünf Claims und Links. Eine einfache Liste stabiler Metric-IDs genügt. Prüfe monatlich aktive Nutzung und veraltete Reports.

Mid-market: Fordere Catalog-Asset- und Metric-IDs im BI-Publish-Prozess. Domänen betreiben Consumer-Register und Deprecation-Backlogs. Ein zentrales Team stellt Templates, API-Verlinkung und Nutzungsintegration bereit.

Enterprise: Trenne Consumer-Portal, Catalog-Suche und BI-Workspace bewusst. Automatisiere Cross-Tool-Lineage und Zugriffsprüfung, klassifiziere materielle Claims und führe gestufte Deprecation durch. Executive oder regulatorische Reports brauchen strengere Evidenz als explorative Team-Analysen.

Handoffs

Der BI Developer liefert nicht nur eine URL, sondern Claim-Manifest, Filter und erwartete Ergebnisse. Der Metric Owner bestätigt fachliche Passung, nicht das visuelle Design. Der Catalog Steward stellt Auffindbarkeit und Beziehungen sicher. Der BI Owner verantwortet Zielgruppe, Veröffentlichung und Stilllegung. Consumer melden missverständliche Claims oder fehlende Kontexte zurück.

Definiere für materielle Änderungen eine Reaktionsfrist. Ein Impact-Hinweis sollte betroffene Version, erwartete Auswirkung, Testfenster, Migrationsdatum und Rückfallplan enthalten. So wird aus passiver Lineage ein operativer Handoff.

Anti-Patterns

Dashboard-Namen als fachliche Definition nutzen; jeden Chart als neue Metrik anlegen; tote Dashboards im Catalog als aktiv zeigen; Filterkontext verschweigen.

Screenshot-Katalog: Vorschaubilder dominieren, während Metric-ID und Status fehlen. Linkfriedhof: URLs werden gesammelt, aber nicht auf Erreichbarkeit oder Nutzung geprüft. Unsichtbare Defaults: BI-Filter, Zeitzone oder Währung verändern den Claim, ohne angezeigt zu werden. Zertifizierung ohne Scope: Ein ganzes Dashboard trägt ein Siegel, obwohl nur einige Metrics kontrolliert sind. Viele Wahrheiten: Regional angepasste Claims verwenden denselben Namen ohne Variantenbeziehung.

Gegenmaßnahmen sind claim-basierte Verlinkung, maschinenlesbare Manifeste, sichtbare Defaults, Zertifizierung auf passender Granularität und versionierte Varianten. Nicht jede lokale Analyse muss registriert werden; produktive, geteilte oder entscheidungskritische Consumer schon.

Publish- und Betriebscheckliste

• Hat das Dashboard eine Zielgruppe, Entscheidung, Owner und Review-Datum?
• Besitzt jeder kritische Claim eine stabile Kennzahl-ID und Version?
• Sind Grundgesamtheit, Filter, Zeitfenster, Zeitzone, Einheit und Freshness sichtbar?
• Verlinkt der Catalog auf den konkreten Nutzer und dieser zurück auf den Claim?
• Ist die Lineage bis zum verantworteten Datenprodukt testbar?
• Werden Zugriffsrechte beim Deep Link respektiert?
• Gibt es Impact-, Abgleich- und Rückfalltests?
• Fließen Nutzung, Incidents und Retirement-Status zurück?

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metadata Foundations
• Lernpfad — Metadata Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Woche 1: Wähle ein Executive- oder Betriebsdashboard und formuliere fünf Claims vollständig. Woche 2: Verknüpfe Metric-IDs, Datenprodukte, Owner und Lineage. Woche 3: Ergänze sichtbare Defaults und ein kleines Publish-Gate. Woche 4: Teste eine Quellenänderung, prüfe Benachrichtigungen und archiviere einen veralteten Consumer.

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Metadata Foundations
• Lernpfad — Metadata Foundations

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Im zweiten Monat nimmst du die wichtigsten Dashboards einer Domäne auf und führst ein Consumer-Register ein. Im dritten Monat automatisierst du Linkprüfung, Nutzungssignale und Impact-Erkennung. Etabliere Deprecation-Zeiträume und eine monatliche Triage für ungeklärte Claims.

Miss Anteil kritischer Claims mit vollständigem Kontext, Zeit bis zur Impact-Bestätigung, aktive Consumer auf aktueller Metric-Version, tote Links und stillgelegte Dashboards. Page Views allein zeigen Popularität, nicht korrekte Entscheidungen.

Review aus Sicht eines Consumers

Bitte für den monatlichen Review eine Person, die das Dashboard nutzt, aber nicht gebaut hat. Sie soll einen Claim in einem vollständigen Satz erklären, Filter und Datenstand erkennen und über den Deep Link Definition, Owner und Datenprodukt finden. Anschließend soll sie feststellen, welche weiteren Consumer dieselbe Metric verwenden. Jede notwendige mündliche Erklärung markiert fehlenden Kontext oder einen schwachen Handoff.

Prüfe danach den umgekehrten Weg. Starte bei einer Metric oder einem Datenprodukt im Catalog und ermittle alle aktiven Dashboards. Vergleiche diese Liste mit BI-Nutzung und Owner-Bestätigung. Abweichungen zeigen blinde Consumer, tote Links oder unvollständige Lineage. Für kritische Claims sollte das Team begründen können, warum ein Consumer aktiv, veraltet oder ausgenommen ist.

Ein wirkungsorientiertes Scoreboard verbindet Discovery und Betrieb: vollständige Claim-Manifeste, erfolgreiche Deep Links, bestätigte Impact-Hinweise, Zeit bis zur Migration, überfällige Deprecations und ungeklärte lokale Varianten. Ergänze qualitative Fehlinterpretationen aus Support oder Entscheidungsmeetings. Ein beliebtes Dashboard kann weiterhin semantisch riskant sein.

Lege für Ausfälle einen einfachen Rückfallweg fest. Ist eine Metric oder Quelle fragwürdig, muss der BI Owner den Claim sichtbar kennzeichnen, auf den letzten bestätigten Stand wechseln oder die Kachel kontrolliert ausblenden können. Ein still weiterlaufendes Dashboard vermittelt sonst Sicherheit, obwohl seine Bedeutungskette gebrochen ist.

Weiterführende Begriffe und Playbooks

Die Einordnung beginnt bei Die Vier-Schichten-Bedeutungslandkarte und Metadata ist nicht der Catalog. Die ausführbare Wiederverwendung behandelt Semantic Layer statt dicker Consumer. Ergänzend helfen Glossar, Business Intelligence, Data Lineage, KPI und Data Product.