Data Product Lifecycle Governance

zyklus lässt Quellen, Definitionen und Consumer auseinanderlaufen: veraltete Tabellen bleiben in BI-Modellen, parallele Versionen widersprechen sich, und niemand besitzt ein Mandat für Deprecation oder Retirement.

Lösung: Der Lebenszyklus umfasst Intake, Build und Go-live, Betrieb, Change, Deprecation und Retirement.

In einem Satz: Der Lebenszyklus umfasst Intake, Build und Go-live, Betrieb, Change, Deprecation und Retirement.

Problem

Das Data Product ist live — und ein Jahr später liest BI noch die alte Tabelle, während die Pipeline längst umgestellt ist. Go-live ohne Lebenszyklus lässt Quellen, Definitionen und Consumer auseinanderlaufen: veraltete Tabellen bleiben in BI-Modellen, parallele Versionen widersprechen sich, und niemand besitzt ein Mandat für Deprecation oder Retirement.

Das Problem ist mehr als technische Unordnung. Consumer planen gegen implizite Verträge, sensible Daten werden länger als nötig gespeichert und Teams bezahlen für ungenutzte Pipelines. Wenn ein Owner wechselt, fehlt häufig eine belastbare Übergabe von offenen Risiken, Serviceversprechen und Ausnahmen.

Lifecycle Governance verbindet deshalb Produktentscheidung und technische Realität. Jede Phase hat ein Decision Object, klare Eintritts- und Austrittskriterien sowie Evidenz. Governance endet nicht bei der Freigabe; sie steuert Änderung, Ablösung und nachweisbares Ende.

Entscheidung

Der Lebenszyklus umfasst Intake, Build und Go-live, Betrieb, Change, Deprecation und Retirement. Der Product Owner verantwortet Zweck, Consumer-Versprechen und Priorität; Data Owner und Control Owner entscheiden in ihrem Mandat über Bedeutung, Risiko und Kontrollen; Custodians setzen den Zustand nachweisbar um.

Das Operating Model trennt fachliche Risikoentscheidung, operative Ausführung und unabhängige Kontrolle. Für jedes Decision Object gibt es genau eine accountable Rolle, eine Frist, einen definierten Scope und eine Eskalation. Consulted-Rollen liefern notwendige Perspektiven; sie dürfen die Entscheidung nicht durch endlose Abstimmung blockieren. Responsible-Rollen führen die beschlossene Maßnahme aus und verlinken ihren Nachweis.

Der Workflow wird in bestehende Produkt-, Ticket-, IAM- und Betriebsprozesse eingebaut. Ein separates Governance-Portal ist nur dann sinnvoll, wenn es als verlässliches System of Record dient. Entscheidend ist nicht die Oberfläche, sondern dass Antrag, Entscheidung, Umsetzung und Wirksamkeitsprüfung über stabile Kennungen miteinander verbunden bleiben.

Operating Model und Kontrolllogik

Intake und Charter

Vor dem Build werden Problem, Zielgruppe, Nutzen, Datenumfang, Schutzbedarf, Owner und Finanzierung geklärt. Ein Charter verhindert Produkte ohne Consumer oder Mandat. Noch offene Annahmen werden als überprüfbare Hypothesen geführt, nicht als verdeckte Verpflichtung.

Für die operative Umsetzung wird dieser Punkt mit Scope, Owner, Frist und Evidenz im data-product-lifecycle-record.csv verbunden. Änderungen benötigen denselben nachvollziehbaren Entscheidungsweg wie die Erstfreigabe.

Go-live und Betrieb

Das Gate prüft Product Contract, Datenqualität, Zugriff, Lineage, Support, Retention und Kostenrahmen. Nicht jede Lücke blockiert zwingend; akzeptierte Abweichungen benötigen eine Exception. Nach Go-live überwachen SLOs, Incidents und Consumer Feedback die reale Leistung.

Für die operative Umsetzung wird dieser Punkt mit Scope, Owner, Frist und Evidenz im data-product-lifecycle-record.csv verbunden. Änderungen benötigen denselben nachvollziehbaren Entscheidungsweg wie die Erstfreigabe.

Change und Versionierung

Änderungen werden nach semantischer, technischer und operativer Wirkung klassifiziert. Ein Breaking Schema Change, eine KPI-Neudefinition und ein geänderter Permitted Use benötigen unterschiedliche Authorities. Versionen, Migrationsfenster und Consumer-Kommunikation sind Teil derselben Entscheidung.

Für die operative Umsetzung wird dieser Punkt mit Scope, Owner, Frist und Evidenz im data-product-lifecycle-record.csv verbunden. Änderungen benötigen denselben nachvollziehbaren Entscheidungsweg wie die Erstfreigabe.

Deprecation und Retirement

Deprecation ist ein angekündigter Übergang, kein Kommentar im Katalog. Consumer-Liste, Ersatz, Sunset-Datum und Migration Owner werden veröffentlicht. Retirement erfolgt erst nach Nutzungsprüfung, Archiv- oder Löschentscheidung, Entzug von Zugriffen und Aktualisierung von Katalog sowie Lineage.

Für die operative Umsetzung wird dieser Punkt mit Scope, Owner, Frist und Evidenz im data-product-lifecycle-record.csv verbunden. Änderungen benötigen denselben nachvollziehbaren Entscheidungsweg wie die Erstfreigabe.

Kadenz, Trigger und Eskalation

Die Kadenz folgt dem Risiko. Kritische oder stark veränderliche Objekte werden häufiger geprüft als stabile Objekte mit geringer Wirkung. Ein Kalender allein reicht nicht: Incidents, Eigentümerwechsel, Vertragsänderungen, ungewöhnliche Nutzung oder ein wesentliches Kontrollversagen lösen zusätzlich ein ereignisbasiertes Review aus.

Die monatliche Betriebsrunde behandelt nur Ausnahmen, überfällige Entscheidungen und Trends. Ein quartalsweises Review prüft dagegen, ob Scope, Schwellenwerte und Rollen noch angemessen sind. Dadurch wird Governance zu einer steuerbaren Routine und nicht zu einer Sammlung großer Workshops.

Praktischer Workflow

Der Workflow ist bewusst als geschlossener Kontrollzyklus formuliert. Jeder Schritt erzeugt ein Ergebnis, das der nächste Schritt verwenden kann; offene Punkte bleiben sichtbar.

1. Product Charter mit Zweck, Scope, Consumer, Owner, Schutzbedarf und Cost Envelope anlegen.

Der Intake erhält eine stabile Fall-ID und verweist auf Quellsystem, Antragsteller und betroffene Objekte. Unvollständige Angaben werden als offene Punkte markiert, statt durch Annahmen ersetzt zu werden.

2. Build gegen Contract, Qualitätsregeln, Zugriffskonzept, Lineage und Retention steuern.

Die Scope-Prüfung wird mit einem fachlichen und einem technischen Ansprechpartner durchgeführt. Damit bleiben indirekte Abhängigkeiten, nachgelagerte Consumer und ausgeschlossene Umgebungen sichtbar.

3. Go-live anhand risikobasierter Kriterien entscheiden und offene Exceptions verlinken.

Die Einstufung verwendet veröffentlichte Kriterien und dokumentiert den maßgeblichen Schwellenwert. Grenzfälle werden an die zuständige Authority eskaliert, nicht informell heruntergestuft.

4. Betrieb über SLOs, Incidents, Nutzung, Kosten und regelmäßige Owner Reviews überwachen.

Jede geplante Maßnahme besitzt Responsible, Fälligkeitsdatum und erwarteten Nachweis. Abhängigkeiten zu anderen Teams werden als eigene Tasks geführt und bleiben im Hauptrecord verlinkt.

5. Changes nach Consumer- und Kontrollwirkung klassifizieren und passend freigeben.

Die accountable Rolle erhält eine entscheidungsreife Zusammenfassung mit Optionen, Auswirkungen und Empfehlung. Zustimmung ohne prüfbare Begründung reicht bei materiellem Risiko nicht aus.

6. Deprecation mit Ersatz, Sunset-Datum und bestätigter Consumer-Kommunikation starten.

Nach der Entscheidung bestätigt ein technischer oder operativer Owner den realen Zustand. Dabei wird nicht nur die Ausführung, sondern auch das Ergebnis der Maßnahme geprüft.

7. Vor Retirement Nutzung, Abhängigkeiten, Legal Hold, Archiv und Löschung prüfen.

Überfällige Punkte werden nach Risiko und Alter priorisiert. Die Betriebsrunde entscheidet über Eskalation, zusätzliche Kontrolle oder Neuplanung und protokolliert die Begründung.

8. Technische Abschaltung nachweisen und Registry, Katalog, Lineage sowie Support aktualisieren.

Der Abschluss verlangt einen verlinkten Wirksamkeitsnachweis und einen aktualisierten Status in allen relevanten Systemen. Erkenntnisse fließen in Schwellenwerte, Vorlagen und nächste Reviews ein.

Evidenz

Evidenz muss eine Entscheidung rekonstruierbar machen. Ein Prüfer oder eine neue Ownerin sollte erkennen können, welcher Zustand vorlag, welche Regel galt, wer mit welchem Mandat entschied, welche Maßnahme ausgeführt wurde und ob sie wirksam war. Ein Screenshot ohne Zeitstempel, Scope und Quellbezug erfüllt diesen Zweck nicht.

Nachweise werden möglichst an der Quelle erzeugt: versionierte Exporte aus der Plattform, Tickets mit unveränderbarer Historie, genehmigte Decision Records und maschinenlesbare Register. Das Register verweist auf die Evidenz, kopiert aber nicht unkontrolliert vertrauliche Daten. Aufbewahrung und Zugriff richten sich nach Schutzbedarf und Audit-Anforderung.

Geeignete Kennzahlen messen Durchlauf und Wirkung: Anteil fristgerechter Reviews, Alter offener Fälle, Zeit bis zur Umsetzung, wiederkehrende Ausnahmen und Fehlerquote bei Stichproben. Reine Aktivitätszahlen wie versendete Erinnerungen oder durchgeführte Meetings zeigen keine Kontrollwirksamkeit.

Lifecycle-Evidenz muss Zustandswechsel und nicht nur den aktuellen Katalogwert zeigen. Für jede Transition werden vorheriger Status, Entscheidungsgrund, genehmigende Rolle, Datum, offene Bedingungen und technische Umsetzung festgehalten. Bei Deprecation gehören Consumer-Bestätigung und Migrationsfortschritt dazu; bei Retirement zusätzlich Nutzungsnachweis, Dependency Check, Archiv- oder Löschprotokoll und entzogene Berechtigungen. Ein Produkt gilt nicht als retired, solange ein produktiver Consumer unbemerkt auf die alte Version zugreift. Ebenso bleibt eine neue Version im kontrollierten Build-Status, solange zugesagte Go-live-Bedingungen nicht umgesetzt sind. Diese Historie macht sichtbar, ob der Lebenszyklus tatsächlich gesteuert wurde oder Statusfelder nur nachträglich an die technische Realität angepasst wurden.

Zentrales Arbeitsartefakt

Der data-product-lifecycle-record.csv dokumentiert Product ID, Version, Lifecycle State, Decision Date, Owner, Purpose, Consumer, Contract Link, Classification, Retention Class, Change Type, Sunset Date, Migration Owner, Approval, Exception und Evidence Link.

Das Artefakt wird pro Zyklus versioniert. Pflichtfelder dürfen nicht durch Freitext ersetzt werden; vertrauliche Belege bleiben in kontrollierter Ablage und werden nur referenziert. Ein geschlossener Fall besitzt Entscheidung, Umsetzung und Wirksamkeitsnachweis.

Häufige Anti-Patterns

Dokumentation ohne Entscheidungsrecht

Ein Name steht im Register, besitzt aber weder Mandat noch Budget- oder Priorisierungsrecht. Der Fall bleibt offen, obwohl die Metadaten vollständig wirken.

Gegenmaßnahme: Accountability an eine konkrete Entscheidung und Eskalationsinstanz binden; Mandat im Rollenprofil bestätigen und an einem realen Fall testen.

Tool ersetzt Operating Model

Ein Workflow wird konfiguriert, bevor Schwellenwerte, Rollen und zulässige Entscheidungen geklärt sind. Die Software automatisiert anschließend Unklarheit.

Gegenmaßnahme: Decision Objects, RACI, Fristen und Evidenz zuerst definieren; das Tool danach als ausführende Infrastruktur konfigurieren.

Vollständigkeit vor Risiko

Das Team versucht sofort alle Assets und Fälle zu erfassen. Kritische Entscheidungen gehen in einer großen Backlog-Liste unter.

Gegenmaßnahme: Mit einem klaren Scope und den risikoreichsten Objekten starten; Erweiterung erst nach einem nachweislich funktionierenden Zyklus.

Review ohne Umsetzung

Eine Entscheidung wird protokolliert, die technische oder organisatorische Maßnahme aber nicht verfolgt. Das Register zeigt grün, während der reale Zustand unverändert bleibt.

Gegenmaßnahme: Jede Entscheidung mit Umsetzungsauftrag, SLA, Responsible und Wirksamkeitsnachweis verbinden; erst danach schließen.

Unbefristete Ausnahme

Temporäre Zustände werden zur Normalität, weil Ablaufdatum oder Review Trigger fehlen. Das akzeptierte Risiko wächst unbemerkt mit dem Scope.

Gegenmaßnahme: Ablauf erzwingen, Verlängerungen wie neue Entscheidungen behandeln und wiederholte Verlängerungen an Sponsor oder Kontrollinstanz eskalieren.

Entscheidungshilfe

Die folgende Entscheidungshilfe dient als Gate vor Start oder Freigabe. Ein Nein bedeutet nicht automatisch Ablehnung; es zeigt, welche Information, Rolle oder Kontrolle vor einer belastbaren Entscheidung fehlt.

• Ist das Decision Object eindeutig benannt und technisch auffindbar?
• Sind Umfang-In, Umfang-Out und betroffene Nutzer dokumentiert?
• Gibt es genau eine accountable Rolle mit bestätigtem Mandat?
• Sind geltende Richtlinie, Kontrollziel und Risikoschwelle bekannt?
• Ist die erforderliche Evidenz aktuell, quellenbezogen und zugänglich?
• Sind Frist, Eskalation und Vertretung für Abwesenheiten festgelegt?
• Erzeugt die Entscheidung einen ausführbaren Auftrag mit Responsible und SLA?
• Sind Ablaufdatum oder nächster Review Trigger bereits geplant?
• Kann eine unabhängige Person den Fall in kurzer Zeit rekonstruieren?

Zentrale Empfehlungen

1. Mit einem produktionsnahen Scope beginnen und einen vollständigen Zyklus vom Trigger bis zum Wirksamkeitsnachweis durchführen.

2. Owner nicht nur benennen, sondern Mandat, Vertretung, Reaktionszeit und Eskalation operationalisieren.

3. Evidenz an der Quelle erzeugen und über stabile IDs verknüpfen; manuelle Screenshots nur als ergänzenden Kontext verwenden.

4. Ausnahmen und überfällige Fälle sichtbar machen, statt sie durch pauschale Statuswerte zu verdecken.

5. Kennzahlen für Risikoabbau und Durchlaufzeit verwenden; Aktivität und Dokumentmenge sind keine Erfolgsmaße.

6. Den Workflow nach jedem Quartal anhand realer Fälle vereinfachen, ohne Kontrollziel oder Nachvollziehbarkeit zu verlieren.

Ein belastbarer Betrieb entsteht, wenn Teams diese Empfehlungen nicht als zusätzliche Bürokratie, sondern als Definition eines guten Abschlusses verwenden. Der kleinste sinnvolle Prozess ist der, der eine risikorelevante Entscheidung rechtzeitig herbeiführt und ihre Wirkung belegt.

Tools und Verweise

• Data Product Owner vs Data Owner — Rollen entlang des Produkts schneiden.
• Missing Pieces — Lifecycle — Deprecation und Retirement vertiefen.
• RACI für Data Governance — Change-Entscheidungen strukturieren.
• Governance Advisor — Reifegrad und nächste Schritte bestimmen.

Nächste Story: audit-evidence-pack.