Metrikdefinition, Version, zertifizierter Publish
Metrikdefinition versionieren und zertifiziert publishen: Owner, Steward, Änderungsnotiz und Consumer-Sichtbarkeit.
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:
- Definitionsdokument (Grain, Population, Formel, Ausschlüsse);
- semantische Version (Major/Minor) und Änderungsnotiz;
- Owner-Freigabe vor Publish;
- Steward-Queue für Änderungsanträge;
- 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.
- Eine Top-Metrik mit Version 1.0 und Änderungsnotiz publishen.
- Änderungsantrag-Template für Steward einführen.
- Catalog auf Version + Owner verlinken.
- Rollback-Pfad einmal trocken üben.
Semantic layer and metrics store governance
Part 2 of 5
View series