Zum Inhalt springen
Search the hub
Metrikdefinition, Version, zertifizierter Publish

Metrikdefinition, Version, zertifizierter Publish

Metrikdefinition versionieren und zertifiziert publishen: Owner, Steward, Änderungsnotiz und Consumer-Sichtbarkeit.

Category
Data Governance
Reading time
4 min
Published
Tags
metrics versioning certification publish semantic-layer
Download PDF

Begriffe vor dem Lesen

  • Metric Drift — Auseinanderlaufen derselben Kennzahl ueber Tools, Reports oder lokale Formeln hinweg.
  • Kanonische Definition — Verbindliche Beschreibung von Grundgesamtheit, fachliche Ebene, Formel, Zeitlogik und Ausschluessen.
  • Metrics Store — Wiederverwendbarer Ablage- oder Publish-Ort für freigegebene Kennzahlenlogik.
  • Abgleich — Nachweisbarer Vergleich mehrerer Implementierungen gegen dieselbe genehmigte Definition.
  • Change Prüfpunkt — Pruefpunkt vor Aenderungen an Formel, Umfang, Quelle oder Publish-Ort.

Ohne Version ist jede Dashboard-Korrektur eine stille Geschichtsänderung. Consumer müssen wissen, welche Definition sie sehen — und wann sie gewechselt hat.

Dieser Teil definiert den Mindestvertrag für Definition, semantische Version und zertifizierten Publish — bevor Verantwortung-RACI und Change-Gates darauf aufsetzen.

Vorher: Metrik-Drift Überblick. Weiter: Semantic-Layer-Verantwortung RACI. Vertiefung: KPI & Metric Governance.

Entscheidung

Jede zertifizierte Metrik trägt:

  1. Definitionsdokument (Grain, Population, Formel, Ausschlüsse);
  2. semantische Version (Major/Minor) und Änderungsnotiz;
  3. Owner-Freigabe vor Publish;
  4. Steward-Queue für Änderungsanträge;
  5. Custodian-Deploy in den Metrics Store / Semantic Layer mit Rollback-Pfad.

„zertifiziert“ im Catalog ohne Version und Publish-Gate ist Labeling, keine Governance.

Workflow

1. Definition schärfen

Der Data Owner unterschreibt einen Satz, den ein Consumer wiederholen kann, plus Beispiele und Gegenbeispiele. Artefakt ist das Definitionsdokument mit Grain, Population, Formel und Ausschlüssen — nicht eine Pseudocode-Wand im Wiki. Der Steward sammelt Anträge und markiert Mehrdeutigkeiten, bevor sie in den Store wandern. Wird dieser Schritt übersprungen, erfindet jeder Dashboard-Autor ein lokales Measure, und „zertifiziert“ bleibt ein Badge.

2. Breaking vs. nicht-breaking

Der Owner entscheidet, ob eine Änderung die Vergleichbarkeit bricht. Major gilt, wenn Population oder Formel YoY oder Cross-Tool-Vergleiche ungültig macht; Minor gilt für Klarstellung und zusätzliche Filterdokumentation. Der Steward schreibt die Änderungsnotiz so, dass ein Consumer den Unterschied in einem Satz versteht. Wird der Schnitt nicht gezogen, landet ein Breaking Change als „kleine Korrektur“ in Produktion, und Reconciliation hat keine Version zum Pinnen.

3. Publish-Gate

Nur Owner-freigegebene Versionen erscheinen als certified. Entwürfe bleiben gekennzeichnet und sind für Entscheidungsdashboards gesperrt. Der Custodian deployed erst nach Gate — nicht aus einem Chat-Auftrag. Wird das Gate übersprungen, behandeln Consumer Entwürfe als Wahrheit und der Catalog lügt über den Betriebsstand.

4. Historie und Parallelbetrieb

Bei Major-Wechsel laufen alte und neue Version bis zum Cutover-Datum parallel. Der Steward informiert registrierte Consumer und hält beide Versionen adressierbar; der Custodian stellt Rollback und Versionspin sicher. Wird Parallelbetrieb übersprungen, überschreibt der Store die Geschichte, und Change-Gates im nächsten Teil haben nichts, worauf sie hinweisen können.

5. Evidenz

Wer hat wann welche Version freigegeben — das steht an der Version, nicht im Chat. Der Steward legt Freigabe, Änderungsnotiz und Consumer-Hinweis ab; der Owner zeichnet Semantik; der Custodian speichert Deploy- und Rollback-IDs. Fehlt diese Evidenz, können Audit und Reconciliation nicht beweisen, welche Definition eine Zahl erzeugt hat.

Handoffs

Von An Artefakt
Data Owner Steward Freigegebene Definition + Version
Steward Custodian Deploy-/Rollback-Auftrag
Steward Data Product Owner Release Notes für Consumer
Requestor Steward Änderungsantrag
Steward Audit Publish-Historie

Anti-Patterns

  • Überschreiben der Live-Definition ohne Version
  • Zertifizierungslabel ohne Freigabe durch die verantwortliche Person
  • Breaking Change als „kleine Korrektur“ tarnt
  • Nur Wiki pflegen, Store nicht aktualisieren
  • Tool-UI-Rename als Versionsersatz

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.

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.

  1. Eine Top-Metrik mit Version 1.0 und Änderungsnotiz publishen.
  2. Änderungsantrag-Template für Steward einführen.
  3. Catalog auf Version + Owner verlinken.
  4. Rollback-Pfad einmal trocken üben.

Semantic layer and metrics store governance

Part 2 of 5

View series

Knowledge check

Tour