Warum ungenutzte Assets zu Governance-Debt werden
Ungenutzte Pipelines, Marts und Dashboards sind nicht harmlos — sie erzeugen Hygiene-Debt: Assets ohne Purpose, Consumer oder Owner, die Kataloge, Stewardship und Vertrauen untergraben.
Hygiene-Governance beginnt nicht mit einer Löschwelle. Sie beginnt mit der Entscheidung, welche Pipeline, welcher Mart und welches Dashboard ohne Purpose, Consumer oder Owner weiterlaufen — und dass Ungenutzt Debt ist, bis Disposition dokumentiert ist.
Typische Fragen sind:
- Welche Asset-Klassen zählen — Pipelines, Marts/Views, Dashboards, Jobs, Workbooks/Exports?; Welches der drei Signale fehlt — Purpose, Nutzer-Nachweis, verantwortliche Person?; Welche Klasse liegt vor — Orphan, Zombie, Dead Job, Shadow-Kopie?; Welche Kosten und welcher Blast Radius bleiben trotz null Klicks?; Wann ist Ungenutzt nicht sofort Löschen — welche Notify braucht Disposition?; Welche Befunde sind Hygiene, welche Redundanz (doppelte Bedeutung)?
Wenn Katalog, Schedule und Nutzung auseinanderlaufen, gilt das Dashboard als live, der Owner ist gegangen, und Access-Reviews treffen den Zombie wie das Leitprodukt. Das Problem ist nicht der Orchestrator. Es ist der fehlende Vertrag zwischen Register, Triade und Disposition.
Gute Hygiene-Ops macht Ungenutztes ausführbar — Purpose, Consumer und Owner am selben Asset, nicht am neuesten Catalog-Eintrag.
Anschluss an Data Lifecycle & Retention, Data Product Lifecycle Governance und Redundanz Deep Dive.
Die Serie Datenhygiene gibt dir den Einstieg und den roten Faden. Die folgenden Teile vertiefen Inventar-Klassen, Score Keep/Archive/Retire, sicheres Retirement, Lifecycle-Gates und die Operating Scorecard so, dass Zweck, Rollen, Entscheidungen und Nachweise im Alltag nachvollziehbar bleiben.
Ausgangslage
Nachts läuft eine Pipeline, die niemand mehr abfragt. Das Dashboard hängt im Katalog, der Owner ist gegangen — Access-Review und Kostenalarm treffen es trotzdem. Ein Dead Job schreibt in eine unveränderte Tabelle. Daneben lebt ein Shadow-Excel als stille Wahrheit. Teams kaufen dann eine Hygiene-Plattform oder taggen Assets deprecated — und der nächste Clone entsteht, weil niemand sagt, was retired ist.
Was diese Serie klärt
- Orientierung: Hygiene-Debt, Triade Purpose/Nutzer/verantwortliche Person, Register (diese Seite)
- Vertiefung: Orphans, Zombies und Shadow-Kopien inventarisieren
- Vertiefung: Keep, Archive oder Retire scoren
- Vertiefung: Pipelines, Marts und Dashboards sicher retiren
- Vertiefung: Datenmüll mit Lifecycle-Gates verhindern
- Abschluss: Hygiene Operating Scorecard
Lesepfad
- Warum ungenutzte Assets zu Governance-Debt werden
- Orphans, Zombies und Shadow-Kopien inventarisieren
- Keep, Archive oder Retire scoren
- Pipelines, Marts und Dashboards sicher retiren
- Datenmüll mit Lifecycle-Gates verhindern
- Hygiene mit einer Operating Scorecard betreiben
Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Asset-, Job- und Toolnamen durch eure Catalog-, BI- und Prozessquellen.
Begriffe vor dem Lesen
- Datenhygiene — Regelmaessige Pflege von Datenassets, damit ungenutzte, veraltete oder ungeownte Artefakte nicht weiterwirken.
- Orphan — Asset ohne fachlich benannten verantwortliche Person.
- Zombie — Asset ohne aktive Nutzung, das technisch weiterlebt.
- Shadow-Kopie — Inoffizielle Kopie neben der freigegebenen Quelle oder Kennzahl.
- Disposition — Entscheidung: behalten, archivieren, stilllegen oder loeschen.
Qualität, Quellkorrektur und AI-Nutzung
Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.
Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.
Produkte und Entscheidungen
Hygiene braucht nicht „eine Aufräum-Platform“, sondern geschnittene Produkte.
Hygiene Debt Register
Dieses Produkt beschreibt:
- Asset-ID; Typ (
pipeline,mart,dashboard,job,workbook,other); Domain/Plattform; Purpose-Status; verantwortliche Person/Backup; Nutzer-Evidenz und Messfenster; Hygiene-Klasse; Kosten-/Blast-Score; Disposition-Platzhalter; Reviewdatum.
Entscheidungen:
- Welche Top zehn einer Domain sind materiell genug für v1?; Wer darf eine Zeile schließen — Domain-verantwortliche Person oder Steward?; Welche
unknown-Triade gilt als Befund, nicht als Keep?
Purpose-/Consumer-/Owner-Triade
Drei Signale, ein Asset.
Es benötigt:
- Purpose
documented|assumed|unknown; letzter View/Load/API-Call; Owner und Backup (leer = Orphan).
Entscheidungen:
- Welches Fenster zählt als „kein Nutzer“ — 90 oder 180 Tage je Klasse?; Wer ist Backup, bevor der verantwortliche Person geht?; Welche Katalogzeile suggeriert live, obwohl niemand konsumiert?
Klassen-Tag
Noch nicht lösen — nur trennen.
Entscheidungen:
- Orphan, Zombie, Dead Job, Shadow, mixed?; Welche Shadow-Excel ist Hygiene, welche Redundanz-Fork wandert in den Redundanz Deep Dive?; Welche Retention-Richtlinie existiert, ohne Retirement-Betrieb (Missing Pieces)?
Disposition-Platzhalter
inventory / keep / archive / retire / delete — Entscheidung in Teil 3.
Entscheidungen:
- Was bleibt bewusst inventory, bis Evidenz da ist?; Welche Notify brauchen Nutzer vor Retire?; Welches Blind-Delete würde neue Shadows züchten?
Wo Governance hängt
Zwischen null Klicks und weiterlaufenden Kosten
Ungenutzt ist nicht Nullrisiko. Compute, Lizenz und Access-Review bleiben.
Zwischen Katalog-„live“ und fehlendem Consumer
Der Eintrag suggeriert Autorität. Stewards finden Leitprodukte nicht.
Zwischen gegangenem Owner und Incident-Pfad
Zombie-Jobs treffen dieselben On-Call-Wege wie Live-Produkte.
Zwischen Clone und fehlender Retire-Ansage
Neue Teams kopieren, weil niemand sagt, was tot ist.
Zwischen Retention-Policy und fehlendem Inventar
Policy heilt Hygiene nicht, wenn niemand weiß, was noch lebt.
Zwischen Hygiene-Befund und Redundanz-Fork
Zwei Metrik-Logiken sind ein anderes Problem. Ein Register für beides verwischt Disposition.
Rollen-Mapping
Domain / Process Owner
Accountable für Purpose und die Entscheidung Keep versus späteres Retire. Der Owner löscht nicht allein und nicht blind.
Hygiene Steward
Führt Register, Klasse, Reviewdatum und die Grenze zur Redundanz-Serie. Stewardship braucht Kapazität, nicht die Restzeit zwischen Kostenalarm und Sprint.
Platform / Orchestrator Custodian
Liefert Schedule-, Storage- und Compute-Signale. Konfigurationsmacht ist keine Disposition.
BI / Report Owner
Consumer-Evidenz und Backup für Dashboards. Ein View-Log ersetzt nicht den fachlichen Purpose.
Architect
Blast Radius und Downstream-Lineage-Hinweis. Architektur ersetzt nicht das Register.
Audit / Cost Consumer
Empfängt Hotlist und Orphan-Queue. Sie erfinden keine parallele Löschliste.
Mini-Fall
Symptom: Nacht-Pipeline ohne Downstream seit 90 Tagen. Dashboard letzter View > 180 Tage, kein verantwortliche Person. Job schreibt in unveränderte Tabelle. Shadow-Excel neben der offiziellen Quelle.
Typischer Fehlstart: Hygiene-Plattform kaufen und deprecated taggen, ohne Register, ohne Triade und ohne Disposition-Platzhalter.
Vereinbarung: Hygiene Debt Register für eine Domain; Top zehn ohne Purpose, Nutzer oder verantwortliche Person; Klassen trennen; Hygiene von Redundanz splitten; erst inventarisieren, dann in Teil 3 scoren — nicht sofort löschen.
Kritische Übergaben
| Von | An | Artefakt |
|---|---|---|
| Domain Owner | Hygiene Steward | Purpose-Status und Keep-Intuition |
| Custodian | Steward | Schedule-, View- und Kosten-Signale |
| BI Owner | Steward | Consumer-Evidenz und Backup |
| Steward | Architect | Blast-Radius-Kandidaten |
| Steward | Redundanz-Serie | Forks mit doppelter Bedeutung |
| Steward | Teil 2 / 3 | Inventory-Matrix und Disposition-Backlog |
Anti-Patterns
- Ungenutzt als Nullrisiko führen
- Sofort löschen ohne Evidenz und Notify
- Hygiene und Redundanz in ein Register mischen
- Plattform kaufen vor dem Register
- Katalog-Tag
deprecatedohne verantwortliche Person-Queue - Platform-Admin als alleinigen Hygiene-verantwortliche Person führen
- Retention-Richtlinie als Ersatz für Inventar behandeln
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.
Schritt 1: Rahmen und Entscheidung klären
Asset-Klassen einer Domain listen. Triade grob füllen. Owner und Steward benennen. Top-zehn-Hotlist öffnen.
Schritt 2: Control und Nachweis umsetzen
Register schließen. Klassen taggen. Redundanz-Forks auslagern. Kosten- und Blast-Hinweise ergänzen.
Schritt 3: Testen und Ausnahmen sichtbar machen
Orphan-Owner-Queue starten. Negativtest: Blind-Delete eines Zombies ohne Notify gilt als Fehlschlag. Teil-2-Matrix vorbereiten.
Schritt 4: Messen und begrenzt ausrollen
Aufwand und Lücken messen. Nur bestandene Muster auf eine zweite Domain übertragen. Scorecard folgt am Serienende, nicht als erstes Tool.
Exit-Kriterien
- Die Pilot-Domain hat ein Register mit Triade und Klasse je Top-Asset.
- Ungenutzt ist als Debt geführt, nicht als Nullrisiko.
- Disposition-Platzhalter existiert — Delete ist nicht der Default.
- Hygiene-Befunde sind von Redundanz-Forks getrennt.
- technischer Betreiber liefert Nutzungs- und Kosten-Signale; Domain Owner bleibt für Purpose accountable.
Weiterlesen
- Data Lifecycle & Retention
- Missing Pieces: Lifecycle & Retirement
- Data Product Lifecycle Governance
- Measuring Dashboard Governance
- Redundanz Deep Dive
Data Hygiene
Part 1 of 6
View series