Die fehlenden Bausteine

Größenordnung: KMU — ein Produkt, fünf Expectations, ein Steward-Response-Pfad. Mid-Market — shared Rule-IDs über Domänen. Enterprise — Severity-Foren und plattformübergreifende Result-Historie.

Die Serie Die fehlenden Bausteine gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Ausgangslage

Fehlende Governance-Schleifen schließen — Fixes brauchen Ursache und Feedback.

Was diese Serie klärt

• Orientierung: Die fehlenden Bausteine – Teil 1: Datenqualität
• Vertiefung: Die fehlenden Bausteine – Teil 2: Vertrauenswürdige Kennzahlen
• Abschluss mit betreibbaren Next Steps über The Missing Pieces – Teil 6: Datenlebenszyklus & Stilllegung

Begriffe und Kürzel vor dem Lesen

• verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
• Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
• Data Vereinbarung — Vereinbarung zwischen Anbieter und Nutzer: Felder, Bedeutung, Qualität, Aktualität, Änderungsvorlauf, Kontakte.
• Lineage — Woher Daten kommen und wohin sie fließen — für Impact-Analyse bei Änderungen.

Lesepfad

1. Die fehlenden Bausteine – Teil 1: Datenqualität
2. Die fehlenden Bausteine – Teil 2: Vertrauenswürdige Kennzahlen
3. Die fehlenden Bausteine – Teil 3: Data Verantwortung & Stewardship
4. Die fehlenden Bausteine – Teil 4: Metadaten, Katalog & Lineage
5. The Missing Pieces – Teil 5: Richtlinien- & Zugriffs-Governance
6. The Missing Pieces – Teil 6: Datenlebenszyklus & Stilllegung

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Daten können besser werden, während die Ursache unverändert bleibt

Im Vertriebs-Dashboard wird die Lieferquote grün — weil die Pipeline fehlende Termine nachträglich füllt. Im ERP bleiben die leeren Liefertermine. Die Zahl sieht besser aus; die Ursache ist unverändert.

Bronze-, Silver- und Gold-Schichten sowie Tests sind sinnvoll. Sie schaffen Nachvollziehbarkeit in der Plattform. Sie beantworten aber nicht die Governance-Frage:

Verbessern wir den Prozess, der fehlerhafte Daten erzeugt – oder werden wir nur immer besser darin, seine Fehler downstream zu kompensieren?

Eine Transformation kann einen falschen Wert korrigieren. Sie kann fehlende Daten ergänzen, ungültige Statuswerte ummappen oder Ausnahmen abfangen. Dadurch steigt die Qualität des nachgelagerten Datensatzes.

Der Geschäftsprozess, die Eingabemaske, die Schnittstelle oder das Quellsystem, das den Fehler erzeugt hat, kann dabei jedoch unverändert bleiben.

Genau diese Unterscheidung ist der Ausgangspunkt dieses Playbooks.

Transformation ist nicht das Problem

Transformationen sind ein unverzichtbarer Bestandteil moderner Datenarchitekturen. Viele Regeln gehören dauerhaft in die Datenplattform, weil sie keinen Fehler reparieren, sondern Daten für einen neuen Zweck nutzbar machen.

Die relevante Frage ist daher nicht:

Sollten wir weniger transformieren?

Sondern:

Erzeugt diese Transformation neuen fachlichen Wert – oder kompensiert sie dauerhaft ein Problem, das an seiner Entstehungsstelle behoben werden sollte?

Wenn aus einem temporären Fix eine dauerhafte Abhängigkeit wird

Ein Downstream-Fix kann vollkommen richtig sein. Ein Bericht, eine Abrechnung oder ein regulatorischer Prozess kann nicht immer warten, bis ein operatives System angepasst wurde. Eine Transformationsregel kann die Auswirkungen eines Fehlers schnell begrenzen und den Geschäftsbetrieb schützen.

Das Problem entsteht, wenn der temporäre Charakter verloren geht.

Ein typisches Muster sieht so aus:

Der ursprüngliche Fehler ist für die Nutzer möglicherweise nicht mehr sichtbar. Gleichzeitig bleibt die Quelle unverändert und produziert weiterhin dieselbe Abweichung.

Mit jeder zusätzlichen Schicht entstehen neue Abhängigkeiten:

• dieselbe fachliche Annahme wird an mehreren Stellen implementiert,
• Änderungen müssen mehrfach nachvollzogen werden,
• unterschiedliche Teams können unterschiedliche Korrekturen entwickeln,
• die ursprüngliche Ursache wird im Datenfluss immer schwerer erkennbar,
• neue Data Products übernehmen möglicherweise nur einen Teil der vorhandenen Reparaturlogik.

So kann eine erfolgreiche kurzfristige Maßnahme langfristig zu technischer und fachlicher Schuld werden.

Erkennen ist nicht dasselbe wie Beheben

Data-Quality-Werkzeuge und Tests sind wichtig, weil sie Probleme sichtbar und messbar machen.

Microsoft Purview beschreibt Data Quality als die Bewertung und Überwachung von Datenbeständen, um gezielte Verbesserungsmaßnahmen zu ermöglichen. dbt Data Tests prüfen definierte Annahmen über Quellen und Modelle und liefern die Datensätze zurück, die eine Erwartung verletzen. Source Freshness überwacht zusätzlich, ob Quelldaten innerhalb eines erwarteten Zeitfensters aktualisiert wurden.

Diese Funktionen beantworten wichtige Fragen:

• Sind Pflichtfelder vollständig?
• Sind Schlüssel eindeutig?
• Liegen Werte innerhalb eines gültigen Bereichs?
• Stimmen Beziehungen zwischen Datensätzen?
• Sind Daten aktuell genug?
• Wo und seit wann tritt eine Abweichung auf?

Sie beantworten jedoch nicht automatisch:

• Warum erzeugt der Prozess den Fehler?
• Wer besitzt den verursachenden Geschäftsprozess?
• Muss die Eingabevalidierung, Schnittstelle oder Anwendung angepasst werden?
• Bis wann soll die Ursache behoben sein?
• Wann kann die temporäre Transformationsregel wieder entfernt werden?

Das ist keine Schwäche einzelner Produkte. Es ist die Grenze zwischen technischer Erkennung und organisatorischer Ursachenbehebung.

Der fehlende Feedback Loop

Nachhaltige Datenqualität benötigt einen geschlossenen Kreislauf zwischen Datenplattform und Entstehungsprozess.

Ein mögliches Zielmodell besteht aus sieben Schritten:

1. Erkennen
   Das Problem wird über Profiling, Regeln, Tests, Monitoring oder Nutzerfeedback sichtbar.

2. Auswirkung eindämmen
   Eine temporäre Transformation, Quarantäne-Regel oder fachliche Ausnahme schützt nachgelagerte Prozesse.

3. Verantwortung zuweisen
   Quellsystem, Geschäftsprozess und verantwortlicher Owner werden identifiziert.

4. Ursache analysieren
   Es wird geprüft, warum der Fehler entsteht: fehlende Validierung, unklare Prozessregel, Schnittstellenproblem, Bedienfehler oder falsche Systemlogik.

5. An der Quelle beheben
   Prozess, Anwendung, Schnittstelle oder Validierung werden so angepasst, dass der Fehler nicht weiter erzeugt wird.

6. Validieren und überwachen
   Die Verbesserung wird nachgewiesen und über einen definierten Zeitraum beobachtet.

7. Temporären Fix entfernen
   Nicht mehr benötigte Reparaturlogik wird kontrolliert aus der Pipeline entfernt.

Der letzte Schritt ist besonders wichtig. Bleibt eine alte Korrektur nach dem Source Fix bestehen, kann sie selbst neue Fehler erzeugen oder zukünftige Daten falsch interpretieren.

Welche Rolle spielt der Data Steward?

Der Data Steward sollte nicht automatisch jede technische oder fachliche Ursache selbst beheben. Er ist auch nicht zwingend der Owner des Quellsystems.

Seine zentrale Aufgabe kann darin bestehen, den Qualitätsprozess über Systemgrenzen hinweg steuerbar zu machen:

• Qualitätsproblem und Business Impact dokumentieren,
• betroffene Datenprodukte und Verbraucher identifizieren,
• Source Owner und Process Owner einbinden,
• temporäre Korrektur transparent machen,
• Status, Priorität und Zieltermin nachverfolgen,
• Validierung der Source-Korrektur koordinieren,
• Entscheidung über den Rückbau des Workarounds nachvollziehbar machen.

Damit wird Stewardship mehr als die Pflege eines Katalogeintrags. Es wird zur Verbindung zwischen technischer Beobachtung und fachlicher Verantwortung.

Die eigentliche Änderung bleibt dort, wo sie hingehört:

• Der Process Owner verantwortet den Geschäftsprozess.
• Der System verantwortliche Person verantwortet die Anwendung oder Schnittstelle.
• Das Data Team schützt die Datenprodukte und setzt notwendige temporäre Kontrollen um.
• Der Data Steward koordiniert Definition, Transparenz, Eskalation und Nachverfolgung.

Temporäre Korrekturen brauchen einen Lebenszyklus

Ein Fix sollte nicht nur aus SQL, einer Mapping-Tabelle oder einer zusätzlichen Business Rule bestehen. Er benötigt Governance-Metadaten.

Mindestens folgende Informationen sollten nachvollziehbar sein:

Ein Ablaufdatum muss nicht bedeuten, dass eine Regel automatisch gelöscht wird. Es kann zunächst ein verpflichtendes Review auslösen.

Der wesentliche Punkt ist: Ein temporärer Fix darf nicht unsichtbar zu einem dauerhaften Bestandteil der Architektur werden.

Nicht jeder Fehler kann sofort an der Quelle gelöst werden

Auch ein geschlossenes Governance-Modell braucht Pragmatismus.

Eine Source-Korrektur kann aus guten Gründen Zeit benötigen:

• ein externes SaaS-System lässt sich nur eingeschränkt anpassen,
• eine Lieferantenschnittstelle liegt außerhalb der eigenen Kontrolle,
• eine Legacy-Anwendung wird erst später ersetzt,
• historische Daten bleiben trotz Prozessverbesserung fehlerhaft,
• regulatorische oder operative Fristen erfordern eine sofortige Absicherung.

In solchen Fällen kann eine dauerhafte oder langfristige Transformation die wirtschaftlich sinnvollste Lösung sein.

Entscheidend ist, dass diese Entscheidung bewusst getroffen wird:

Nicht jeder Downstream-Fix ist schlechte Architektur. Problematisch wird er, wenn niemand mehr weiß, warum er existiert, wer ihn verantwortet und ob er noch benötigt wird.

Praktische Leitfragen für Teams

Bei jeder neuen Data-Quality-Regel oder Reparaturtransformation können fünf Fragen helfen:

1. Ist das eine fachliche Transformation oder die Reparatur eines vermeidbaren Fehlers?
2. Kann die Ursache im Quellsystem oder Geschäftsprozess beeinflusst werden?
3. Wer besitzt die Ursachenbehebung – nicht nur den Downstream-Fix?
4. Hat die temporäre Korrektur ein Review-Datum und ein definiertes Zielbild?
5. Wie wird nachgewiesen, dass der Fix später entfernt oder vereinfacht werden kann?

Diese Fragen ersetzen keine Data-Quality-Plattform. Sie ergänzen sie um Verantwortung und Lebenszyklus.

Fazit

Moderne Datenplattformen können Datenqualität innerhalb einer Pipeline deutlich verbessern. Tests, Profiling, Monitoring und Transformationen sind dafür unverzichtbar.

Doch eine hochwertige Gold-Tabelle beweist nicht automatisch, dass der erzeugende Geschäftsprozess hochwertige Daten liefert.

Die fehlende Komponente ist häufig nicht noch ein weiterer Test oder eine weitere Transformationsschicht. Es ist der geschlossene Feedback Loop:

Detect the issue. Contain the impact. Assign ownership. Fix the source. Validate the result. Remove the workaround.

Die entscheidende Frage lautet deshalb:

Verbessern wir die Systeme, die Daten erzeugen – oder kompensieren wir nur immer effizienter ihre wiederkehrenden Probleme?

Weiterführende Ressourcen

• Databricks: What is the medallion lakehouse architecture?
• dbt Developer Hub: Add data tests to your DAG
• dbt Developer Hub: Source freshness
• Microsoft Learn: Overview of data quality in Microsoft Purview Unified Catalog
• Microsoft Learn: Data quality actions in Unified Catalog
• IBM: What is data quality?
• IBM: What is root cause analysis?

Zentrale Daten bedeuten nicht automatisch eine zentrale Wahrheit

Im Forecast-Meeting stehen drei Umsatzzahlen nebeneinander: CRM, Finance-Ledger und BI-Dashboard. Alle heißen „Revenue“. Eine zentrale Plattform löst das nicht, solange Definition, Stichtag und Owner nicht dieselbe Entscheidung teilen.

Fachliche Bedeutung entsteht heute an vielen Stellen:

Jede dieser Ebenen kann einen legitimen Zweck erfüllen. Eine Kennzahl im Data Mart kann Wiederverwendung ermöglichen. Ein semantisches Modell kann Geschäftsbegriffe und Berechnungen für verschiedene Reports bereitstellen. Eine Report-Kennzahl kann einen lokalen Analysebedarf abdecken. Excel kann für Fachanwender der schnellste und vertrauteste Weg sein, Daten weiterzuverarbeiten.

Die Governance-Frage lautet daher nicht:

Welche dieser Ebenen ist falsch?

Sondern:

Wie verhindern wir, dass dieselbe fachliche Kennzahl unabhängig an mehreren Stellen neu definiert wird?

Denn zentralisierte Daten lösen nicht automatisch das Problem verteilter Geschäftslogik.

Warum Kennzahlen an mehreren Stellen entstehen

Nicht jede Kennzahl lässt sich einmal definieren und für immer unverändert verwenden. Geschäftsmodelle, Produkte, Verträge, Marktbedingungen und regulatorische Anforderungen verändern sich. Unterschiedliche Nutzergruppen benötigen außerdem unterschiedliche Detailstufen und Analysekontexte.

Deshalb existieren mehrere sinnvolle Orte für Berechnungen:

Das Ziel kann deshalb nicht sein, jede Berechnung technisch an genau einen Ort zu zwingen. Eine zu starre Zentralisierung kann Self-Service blockieren und neue Anforderungen unnötig verlangsamen.

Die bessere Leitlinie ist:

Define shared meaning centrally. Allow local analysis without silently redefining the shared meaning.

Wenn aus einer Kennzahl viele technisch plausible Versionen werden

Ein Beispiel: Das Unternehmen verwendet die Kennzahl Revenue.

Auf den ersten Blick klingt die Definition einfach. In der Praxis können jedoch viele Fragen entstehen:

• Brutto- oder Nettoumsatz?
• Rechnungsdatum, Buchungsdatum oder Leistungszeitraum?
• Stornierungen sofort oder rückwirkend berücksichtigen?
• Einmalige Umsätze und wiederkehrende Umsätze gemeinsam oder getrennt?
• Nur aktive Kunden?
• Welche Währung und welcher Wechselkurs?
• Welche organisatorische Zuordnung gilt bei rückwirkenden Änderungen?
• Sind interne Umsätze enthalten?

Wenn diese Entscheidungen an mehreren Stellen unabhängig getroffen werden, können mehrere Ergebnisse entstehen, obwohl jede einzelne Berechnung technisch korrekt ausgeführt wird.

Das bekannte Meeting-Szenario mit mehreren Personen und mehreren Zahlen ist deshalb kein Beweis dafür, dass eine Plattform versagt hat. Es ist vielmehr ein mögliches Symptom dafür, dass die Berechnungen unterschiedliche Definitionen, Filter, Zeiträume oder Kontexte verwenden.

Die Zahlen können jeweils korrekt sein – aber möglicherweise beantworten sie nicht dieselbe Frage.

Technisch gültig ist nicht automatisch fachlich vergleichbar

Ein häufiger Reflex lautet: Es muss eine einzige Zahl geben.

Das ist nicht immer richtig.

Finance kann Umsatz nach Rechnungslegung betrachten. Sales kann gebuchten Vertragswert betrachten. Customer Success kann wiederkehrenden Umsatz aktiver Kunden analysieren. Alle drei Kennzahlen können legitim sein.

Das Governance-Problem entsteht erst, wenn unterschiedliche Kennzahlen denselben Namen tragen oder ihr Kontext nicht sichtbar ist.

Vertrauen benötigt deshalb mehr als technische Konsistenz. Nutzer müssen erkennen können:

• Was wird gemessen?
• Warum wird es gemessen?
• Welche Regeln gelten?
• Welcher Zeitraum und welcher Filterkontext werden verwendet?
• Welche Datenquellen fließen ein?
• Wer verantwortet die fachliche Definition?
• Für welchen Zweck ist die Kennzahl freigegeben?
• Welche Varianten existieren bewusst?

Eine gute Governance-Lösung muss nicht jede Variante verhindern. Sie muss Varianten verständlich und vergleichbar machen.

Semantic Layers adressieren genau diese Lücke

Die zunehmende Bedeutung semantischer Ebenen zeigt, dass zentrale Speicherung allein nicht ausreicht. Fachliche Definitionen müssen ebenfalls wiederverwendbar werden.

Die dbt Semantic Layer ist beispielsweise darauf ausgelegt, kritische Geschäftskennzahlen zentral zu definieren und über verschiedene nachgelagerte Werkzeuge verfügbar zu machen. Microsoft beschreibt Managed Self-Service BI als ein Modell, bei dem viele Report-Ersteller zentrale, gemeinsam genutzte Semantic Models wiederverwenden. Qlik Master Measures kombinieren eine Expression mit Name, Beschreibung und Tags, damit Kennzahlen innerhalb einer Anwendung wiederverwendet werden können.

Diese Ansätze lösen nicht jedes Governance-Problem. Sie zeigen aber eine gemeinsame Richtung:

Business logic should be reusable as a governed product – not repeatedly rebuilt as local code.

Wichtig ist dabei die Balance. Ein zentrales semantisches Modell darf nicht zu einem monolithischen Objekt werden, das jede denkbare Fragestellung abbilden muss. Auch Microsoft weist bei Managed Self-Service BI darauf hin, dass weder ein einziges Modell für alle Unternehmensdaten noch ein neues Modell für jeden einzelnen Report sinnvoll ist.

Das Ziel ist nicht maximale Zentralisierung, sondern kontrollierte Wiederverwendung.

Excel ist nicht das Problem

Excel wird in Governance-Diskussionen häufig als Gegenpol zur zentralen Datenplattform dargestellt. Diese Sicht ist zu einfach.

Excel erfüllt reale Anforderungen:

• Fachanwender kennen das Werkzeug.
• Analysen lassen sich schnell anpassen.
• Daten können ergänzt, kommentiert und geplant werden.
• Ad-hoc-Fragen benötigen nicht immer einen neuen produktiven Report.
• Viele operative Prozesse basieren weiterhin auf Tabellenmodellen.

Das Governance-Risiko entsteht nicht durch die Datei selbst. Es entsteht, wenn geschäftskritische Logik außerhalb sichtbarer Verantwortung, Dokumentation und Validierung wächst.

Ein möglicher Weg ist, Excel weiterhin als Analyseoberfläche zu nutzen, aber die Daten und Kernkennzahlen aus einem gemeinsamen semantischen Modell zu beziehen. Microsoft unterstützt beispielsweise Live-Verbindungen von Excel zu Power-BI-Semantikmodellen. Dadurch können Anwender in ihrer vertrauten Oberfläche arbeiten und dennoch eine gemeinsame Datenbasis nutzen.

Trotzdem bleibt eine Grenze:

Ab welchem Schritt wird aus persönlicher Analyse eine neue fachliche Definition?

Die entscheidende Frage lautet daher nicht:

Wie verhindern wir Excel?

Sondern:

Wie erkennen wir, wann lokale Logik wiederverwendet, dokumentiert oder in ein gemeinsames Modell überführt werden sollte?

„Trusted“ ist mehr als ein Badge

Zertifizierungen und Endorsements sind sinnvoll. Sie helfen Nutzern, hochwertige und offiziell freigegebene Inhalte zu finden. Power BI unterstützt beispielsweise die Kennzeichnungen Promoted und zertifiziert, um vertrauenswürdige Inhalte sichtbarer zu machen.

Ein Badge allein beantwortet jedoch nicht alle Fragen:

• Ist die Kennzahl fachlich eindeutig definiert?
• Ist der verantwortliche Person sichtbar und erreichbar?
• Sind Filter, Ausschlüsse und Zeitlogik verständlich?
• Gilt die Zertifizierung nur für das semantisches Modell oder auch für lokale Report-Änderungen?
• Wird die Kennzahl in einer Anwendung oder Excel-Datei weiter angepasst?
• Wann wurde die Definition zuletzt geprüft?

Deshalb sollte „Trusted“ nicht nur ein Status sein, sondern ein nachvollziehbares Versprechen:

A trusted metric is understandable, owned, validated, reusable and transparent about its context.

Vertrauen entsteht nicht dadurch, dass jede Person dieselbe Zahl sehen muss. Es entsteht dadurch, dass jede Person verstehen kann, warum eine Zahl gilt – und ob sie mit einer anderen Zahl vergleichbar ist.

Governance muss für die Menschen funktionieren, die sie pflegen

KPI Governance wird häufig als technisches Metadatenproblem behandelt. Dann stehen Tabellen, Spalten, Lineage, SQL-Ausdrücke und Plattformobjekte im Mittelpunkt.

Business User und Data Stewards denken jedoch oft anders:

• Was bedeutet die Kennzahl?
• Wann darf ich sie verwenden?
• Welche Variante gilt für meinen Prozess?
• Wer entscheidet über eine Änderung?
• Warum unterscheidet sich mein Ergebnis vom Finance-Report?

Wenn die Beantwortung dieser Fragen tiefes Wissen über technische Lineage, Datenbankschemas oder Tool-spezifische Begriffe voraussetzt, bleibt Governance auf Spezialisten beschränkt.

Forschung zu Data Catalogs beschreibt genau diese Herausforderung: Kataloge können Metadaten leicht erfassbar, aber schwer auffindbar machen – oder umgekehrt. Unterschiedliche Nutzergruppen besitzen unterschiedliche Kenntnisse und benötigen verständliche mentale Modelle.

Daraus folgt eine praktische Designregel:

Governance participation should be easier than bypassing governance.

Ein Data Steward sollte nicht erst SQL lesen müssen, um eine KPI zu verstehen. Eine fachliche Definition sollte in Business-Sprache sichtbar sein. Technische Details bleiben wichtig, sollten aber als vertiefende Ebene verfügbar sein – nicht als Einstiegshürde.

Rollen rund um eine vertrauenswürdige Kennzahl

Eine einzelne Rolle kann nicht alle Aufgaben übernehmen. Je nach Organisation können die Bezeichnungen variieren, aber die Verantwortungen sollten sichtbar sein.

Der Data Steward muss nicht jede DAX-, SQL-, Qlik- oder Excel-Formel selbst entwickeln. Seine Rolle kann darin bestehen, die fachliche Definition und den Änderungsprozess über technische Grenzen hinweg sichtbar zu halten.

Ein mögliches Zielbild für Trusted Metrics

Ein nachhaltiges Modell kann aus sieben Schritten bestehen:

1. Fachlich definieren
   Die Kennzahl wird in verständlicher Geschäftssprache beschrieben – inklusive Zweck, Scope, Zeitbezug und Varianten.

2. Verantwortung zuweisen
   Ein verantwortlicher Business Owner und ein Data Steward sind sichtbar.

3. Zentral implementieren
   Berechnungslogik, Filter und Geschäftsregeln werden an einer geeigneten gemeinsamen Stelle gepflegt.

4. Validieren und zertifizieren
   Datenqualität, Berechnung, Vergleichswerte und fachliche Abnahme werden geprüft.

5. Über eine semantische Ebene bereitstellen
   Reports, Anwendungen und Analysewerkzeuge erhalten konsistenten Zugriff.

6. Über mehrere Kanäle wiederverwenden
   BI, Anwendungen und Excel dürfen unterschiedliche Darstellungen erzeugen, ohne die Kernbedeutung neu zu erfinden.

7. Nutzung und Feedback überwachen
   Fragen, Abweichungen und neue Anforderungen fließen in einen kontrollierten Verbesserungsprozess zurück.

Wiederverwendung darf Flexibilität nicht verhindern

Ein gemeinsames Modell ist nur dann erfolgreich, wenn es tatsächlich genutzt wird.

Zu wenig Governance kann zu vielen unabhängigen KPI-Versionen führen. Zu viel Zentralisierung kann dazu führen, dass Fachbereiche die Plattform umgehen, weil jede Änderung zu langsam oder zu kompliziert wird.

Dazwischen liegt ein kontrolliertes Self-Service-Modell:

Governance sollte also nicht nur kontrollieren. Sie sollte einen einfachen Weg anbieten, aus einer guten lokalen Idee eine gemeinsam nutzbare Definition zu machen.

Ein einfacher Lifecycle für Kennzahlen

Eine Kennzahl kann ähnlich wie ein Datenprodukt einen Lebenszyklus besitzen:

Dabei sollten Änderungen nicht unsichtbar erfolgen.

Eine neue Definition kann Auswirkungen auf Reports, Anwendungen, Forecasts oder Verträge haben. Deshalb sind folgende Informationen hilfreich:

Praktische Leitfragen für Teams

Bei jeder neuen KPI, Measure oder Report-Berechnung können folgende Fragen helfen:

1. Existiert bereits eine fachlich vergleichbare Kennzahl?
2. Wird eine neue Definition benötigt – oder nur eine neue Darstellung?
3. Wo lebt die verbindliche Geschäftslogik?
4. Welche lokalen Erweiterungen sind erlaubt und wie werden sie sichtbar?
5. Ist die Definition für Business User verständlich, ohne technischen Code lesen zu müssen?
6. Sind Owner, Steward, Status und Änderungsverlauf sichtbar?
7. Können BI, Anwendungen und Excel dieselbe Kernkennzahl wiederverwenden?
8. Wie wird eine häufig genutzte lokale Formel in das gemeinsame Modell zurückgeführt?

Diese Fragen ersetzen keine Semantic Layer und keinen Data Catalog. Sie verbinden technische Wiederverwendung mit fachlicher Verantwortung.

Fazit

Moderne Datenplattformen können Daten zentral speichern, transformieren und bereitstellen. Das allein garantiert jedoch noch keine konsistenten Geschäftsantworten.

Fachliche Bedeutung kann in Pipelines, Views, semantischen Modellen, BI-Measures, Anwendungen und Excel weiterentwickelt werden. Diese Flexibilität ist wertvoll. Sie wird erst dann zum Risiko, wenn dieselbe Kennzahl unabhängig neu definiert wird und Kontext, Verantwortung oder Vergleichbarkeit verloren gehen.

Die fehlende Komponente ist deshalb nicht zwingend ein weiteres Tool. Häufig fehlt die Verbindung zwischen:

Die entscheidende Frage lautet:

Wenn mehrere technisch gültige Werkzeuge dieselbe KPI unterschiedlich berechnen können – wo lebt dann die vertrauenswürdige Kennzahl?

Vielleicht lautet die bessere Antwort nicht in einem einzelnen Tool, sondern:

Sie lebt in einer gemeinsam verstandenen, verantworteten und wiederverwendbaren Definition.

Weiterführende Ressourcen

• dbt Developer Hub: dbt Kennzahlenmodell
• dbt Developer Hub: Metric properties
• Microsoft Learn: Managed self-service BI
• Microsoft Learn: Promote and certify Power BI content with endorsement
• Microsoft Learn: Power BI semantic model experience in Excel
• Microsoft Learn: semantisches Modell models across workspaces
• Qlik Help: Reusing measures with master measures
• Qlik Help: Using master measures in expressions
• Microsoft Learn: Glossary terms in Microsoft Purview Unified Catalog
• Research: Comprehensive and Comprehensible Data Catalogs

Eine zugewiesene Rolle ist ein wichtiger Anfang – aber noch kein Betriebsmodell

Im Katalog steht ein Name neben der Kundentabelle. Wenn die Region falsch ist, weiß trotzdem niemand, wer die Definition ändern darf und wer nur den Export stoppen kann. Ein zugewiesener Name ist noch kein Betriebsmodell.

Sichtbare Zuständigkeit hilft. Ohne sie bleibt oft schon die erste Frage unbeantwortet:

Wer ist die richtige Ansprechperson für dieses Datenobjekt?

Doch eine weitere Frage ist mindestens ebenso relevant:

Kann die zugewiesene Person im Alltag tatsächlich entscheiden, priorisieren, eskalieren und Veränderungen anstoßen?

Zwischen einem Namen im Katalog und einer wirksamen Governance-Praxis liegt ein Operating Model.

Dieses Playbook stellt deshalb nicht infrage, ob Verantwortung und Stewardship benötigt werden. Es untersucht, welche Bedingungen aus einer dokumentierten Rolle eine handlungsfähige Verantwortung machen.

Verantwortung, Stewardship und Accountability sind nicht dasselbe

Die Begriffe werden in Organisationen unterschiedlich verwendet. Es gibt kein universelles Rollenmodell, das für jedes Unternehmen gleich aussehen muss.

Trotzdem hilft eine klare Trennung der Verantwortungsarten:

Die konkreten Namen können abweichen. Entscheidend ist, dass Zweck, Entscheidungsrechte und Übergaben verständlich sind.

Ein Data Steward muss nicht jede Pipeline reparieren. Ein Data Owner muss nicht jede Metadatenbeschreibung selbst pflegen. Ein Platform Team sollte nicht allein entscheiden müssen, welche fachliche Definition richtig ist.

Governance wird wirksam, wenn Rollen zusammenarbeiten – nicht wenn eine einzelne Rolle alle offenen Aufgaben übernehmen soll.

Warum zugewiesene Verantwortung passiv bleiben kann

Eine formale Zuweisung kann vollständig und korrekt sein, während der operative Weg trotzdem unklar bleibt.

Ein mögliches Muster sieht so aus:

Das bedeutet nicht automatisch, dass die zugewiesenen Personen ihre Rolle nicht ernst nehmen. Häufig fehlen Rahmenbedingungen.

Typische Hindernisse können sein:

1. Kein klarer Scope

Der Name eines Owners ist hinterlegt, aber nicht der Umfang der Verantwortung.

Gehört dazu:

• die fachliche Definition?
• die Datenqualität an der Quelle?
• der Zugriff?
• die Priorisierung technischer Änderungen?
• die Verwendung in Reports?
• die Freigabe einer Kennzahl?
• die Kommunikation bei Abweichungen?

Ohne Scope kann dieselbe Rolle gleichzeitig zu weit und zu eng interpretiert werden.

2. Verantwortung ohne Zeit und Kapazität

Stewardship wird häufig zusätzlich zu einer bestehenden Fach- oder IT-Rolle übernommen. Das kann sinnvoll sein, weil die fachliche Nähe erhalten bleibt.

Problematisch wird es, wenn Aufgaben zwar zugewiesen werden, aber kein realistischer Zeitrahmen, keine Priorisierung und keine Vertretung existieren.

Dann konkurriert Governance mit operativen Tagesaufgaben – und verliert häufig dort, wo keine unmittelbare Eskalation entsteht.

3. Verantwortung ohne Entscheidungsrechte

Eine Person kann für die Qualität einer Definition verantwortlich gemacht werden, ohne eine Änderung genehmigen, ablehnen oder priorisieren zu dürfen.

Dann wird aus Verantwortung möglicherweise nur Koordination.

Nicht jede Rolle benötigt vollständige Entscheidungsfreiheit. Aber es sollte klar sein:

• Welche Entscheidungen darf die Rolle selbst treffen?
• Welche Entscheidungen benötigen Zustimmung?
• Wer entscheidet bei Konflikten?
• Welche Leitplanken gelten?

4. Kein sichtbarer Eskalationspfad

Ein Steward erkennt ein wiederkehrendes Problem, kann es aber nicht dauerhaft lösen.

Vielleicht liegt die Ursache in einem Quellsystem, einem Geschäftsprozess, einer externen Schnittstelle oder einer anderen Domäne.

Ohne Eskalationsweg entstehen leicht lokale Workarounds. Das Problem wird technisch abgefangen, während die fachliche Entscheidung offen bleibt.

5. Zu technischer Kontext

Ein technischer Asset-Name, komplexe Lineage und Dutzende Metadatenfelder helfen einem Business Steward nicht automatisch bei der fachlichen Entscheidung.

Technische Details sind notwendig. Sie sollten jedoch nicht die einzige Einstiegsebene sein.

Business User und Stewards benötigen zuerst verständlichen Kontext:

• Was bedeutet das Datenobjekt?
• Für welchen Prozess wird es verwendet?
• Welche Auswirkung hat das Problem?
• Welche Kennzahlen und Entscheidungen sind betroffen?
• Wer muss eingebunden werden?

6. Zu aufwendige oder getrennte Workflows

Wenn ein Problem nur über lange Formulare, mehrere Systeme oder schwer auffindbare Governance-Seiten erfasst werden kann, sinkt die Beteiligung.

Das ist kein Argument gegen Kontrolle. Es ist ein Designproblem:

Governance sollte den richtigen Weg einfacher machen als den Umweg.

Ein Katalog kann Verantwortung abbilden – aber Organisation nicht ersetzen

Governance-Produkte unterstützen Rollen, Berechtigungen, Glossare, Aufgaben und Workflows. Viele Plattformen unterscheiden bereits zwischen Data Ownern, Data Stewards, Domain-Verantwortlichen und technischen Rollen.

Diese Funktionen sind wertvoll. Sie schaffen Struktur, Auffindbarkeit und Nachvollziehbarkeit.

Sie können jedoch nicht allein festlegen:

• wie viel Zeit eine Person für Stewardship erhält,
• welche fachlichen Entscheidungen sie treffen darf,
• welches Team eine Änderung finanziert,
• wie Konflikte zwischen zwei Fachbereichen gelöst werden,
• welche Priorität ein Governance-Problem gegenüber anderen Anforderungen besitzt,
• wer bei Abwesenheit oder Rollenwechsel übernimmt.

Das Tool bildet das Operating Model ab. Es ersetzt nicht dessen organisatorische Vereinbarung.

Die entscheidende Frage ist deshalb nicht:

Unterstützt unser Katalog Verantwortung?

Sondern:

Ist die im Katalog sichtbare Verantwortung mit einem realen Entscheidungs- und Arbeitsprozess verbunden?

Accountability braucht einen Handlungsweg

Der englische Begriff Accountability wird häufig mit Verantwortung übersetzt. Im Governance-Kontext ist die Unterscheidung hilfreich:

• Responsibility beschreibt, wer eine Aufgabe ausführt oder betreut.
• Accountability beschreibt, wer für eine Entscheidung oder ein Ergebnis einsteht.

Eine Person kann beispielsweise für die Pflege eines Glossarbegriffs verantwortlich sein, während der Business Owner für dessen fachliche Freigabe accountable bleibt.

Das verhindert zwei Extreme:

1. Der Steward wird zum alleinigen Verantwortlichen für alle Datenprobleme.
2. Der Owner bleibt nur ein Name für formale Freigaben und nimmt nicht am Entscheidungsprozess teil.

Eine klare Aufteilung kann so aussehen:

Diese Tabelle ist kein universelles RACI-Modell. Sie zeigt nur, dass Governance-Aufgaben meist mehrere Rollen verbinden.

Ein einfacher Lifecycle macht Verantwortung sichtbar

Verantwortung wird leichter greifbar, wenn Probleme, Entscheidungen und Änderungen einen nachvollziehbaren Status besitzen.

Ein möglicher Lifecycle:

Dabei sollten nicht nur technische Tickets sichtbar sein. Auch der fachliche Kontext gehört dazu.

Der Lifecycle sollte nicht für jedes kleine Anliegen gleich schwergewichtig sein. Ein einfacher Glossarhinweis benötigt keinen Governance-Ausschuss.

Die Tiefe des Prozesses sollte sich an Risiko, Reichweite und Business Impact orientieren.

Wie Verantwortung und Stewardship handlungsfähig werden

Ein wirksames Zielmodell verbindet Assets, Rollen, Feedback, Entscheidungen und kontinuierliche Verbesserung.

Ein mögliches Vorgehen besteht aus acht Schritten:

1. Datenobjekt und Geschäftskontext sichtbar machen
   Zweck, Verbraucher, Kritikalität und relevante Richtlinien werden verständlich beschrieben.

2. Business Owner zuweisen
   Eine Person oder ein klar definiertes Gremium übernimmt Verantwortung für Wert, Zweck, Priorisierung und wesentliche fachliche Entscheidungen.

3. Data Steward zuweisen
   Der Steward koordiniert Definitionen, Qualität, Metadaten, Feedback und den täglichen Governance-Prozess.

4. Probleme und Feedback einfach erfassen
   Nutzer können Fragen und Abweichungen mit ausreichendem Business-Kontext melden, ohne zuerst die technische Architektur verstehen zu müssen.

5. Priorisieren und eskalieren
   Auswirkung, Risiko, Reichweite und Richtlinien bestimmen den Bearbeitungsweg.

6. Entscheiden und beheben
   Owner und Steward treffen die fachliche Entscheidung oder arbeiten mit Data-, Analytics- und IT-Teams an der Umsetzung.

7. Status verfolgen und kommunizieren
   Betroffene Nutzer erkennen, wer handelt, welcher Status gilt und welche Auswirkungen zu erwarten sind.

8. Prüfen und verbessern
   Ergebnisse werden validiert. Regeln, Prozesse, Rollen oder Schulungsinhalte werden bei Bedarf angepasst.

Stewardship braucht Enabler – nicht nur Aufgaben

Eine Rolle wird nicht durch eine lange Aufgabenliste wirksam. Sie benötigt passende Rahmenbedingungen.

Klarer Verantwortungsbereich

Für jedes relevante Datenobjekt sollte erkennbar sein:

• was owned wird,
• was stewarded wird,
• welche Entscheidungen erwartet werden,
• welche Verantwortungen ausdrücklich nicht dazugehören.

Zeit und realistische Kapazität

Stewardship benötigt einen vereinbarten Arbeitsanteil oder zumindest eine realistische Priorisierung.

Dabei muss nicht jede Organisation Vollzeit-Stewards einsetzen. Häufig ist fachlich verankertes Stewardship sinnvoller. Die Kapazität sollte jedoch zur erwarteten Aufgabenmenge passen.

Definierte Entscheidungsrechte

Entscheidungsrechte können nach Risiko gestaffelt werden:

• kleine redaktionelle Änderungen durch den Steward,
• fachliche Definitionen mit Freigabe des Owners,
• bereichsübergreifende Konflikte durch ein Governance Council,
• technische Umsetzung durch zuständige Produkt- oder Plattformteams.

Sichtbarer Eskalationsweg

Eine Eskalation ist kein Scheitern. Sie ist ein geplanter Weg für Themen, die eine einzelne Rolle nicht lösen kann.

Nutzbare Werkzeuge

Werkzeuge sollten die tägliche Arbeit unterstützen:

• persönliche Aufgabenansicht,
• klare Prioritäten,
• verständliche Formulare,
• einfache Suche,
• Business-Kontext vor technischen Details,
• Benachrichtigungen ohne Informationsüberlastung,
• nachvollziehbarer Status,
• direkte Feedback-Möglichkeit.

Kontext und Anleitung

Definitionen, Richtlinien, Beispiele und Entscheidungshilfen sollten dort sichtbar sein, wo eine Aufgabe bearbeitet wird.

Zusammenarbeit

Data Governance verbindet Fachbereich, Data Teams, IT, Security, Privacy und weitere Funktionen. Übergaben sollten explizit sein.

Regelmäßige Reviews

Owner und Steward ändern sich. Datenprodukte werden ersetzt. Definitionen verlieren ihre Relevanz.

Regelmäßige Reviews halten Rollen, Regeln und Metadaten aktuell.

Business-Nähe ist kein Komfortmerkmal

Governance wird häufig über technische Objekte aufgebaut, weil Tabellen, Spalten, Pipelines und Reports automatisiert erfasst werden können.

Für viele fachliche Aufgaben reicht dieser Blick nicht aus.

Ein Business Steward benötigt möglicherweise nicht zuerst:

prod_dwh.conformed_customer_v4.customer_status_cd

Sondern:

Customer Status
Zeigt den aktuell gültigen fachlichen Status eines Kunden im aktiven Vertragsprozess.

Danach können technische Details, Lineage, Qualitätsregeln und betroffene Reports folgen.

Die Reihenfolge beeinflusst die Nutzung.

Ein Governance-System kann technisch vollständig sein und trotzdem wenig Beteiligung erzeugen, wenn seine Nutzer keinen verständlichen Einstieg finden.

Deshalb gilt:

Business context should be the entry point; technical metadata should provide the evidence behind it.

Nicht jede Governance-Aufgabe gehört in ein zentrales Tool

Ein weiterer möglicher Fehler wäre, jede fachliche Interaktion in ein separates Governance-Portal zu verschieben.

Stewards und Owner arbeiten bereits in Fachanwendungen, Ticket-Systemen, Collaboration-Tools, BI-Plattformen und Produkt-Backlogs.

Ein praktikables Modell kann Governance in bestehende Arbeitsabläufe integrieren:

• Feedback direkt aus einem Report erfassen,
• Data-Quality-Issues mit einem bestehenden Ticket verknüpfen,
• Freigaben über bekannte Benachrichtigungskanäle bereitstellen,
• den Governance-Status im Datenprodukt oder BI-Katalog anzeigen,
• technische Details im Governance-System halten, aber die relevante Aktion dort anbieten, wo Nutzer arbeiten.

Das zentrale Governance-System bleibt der nachvollziehbare Bezugspunkt. Die Interaktion muss jedoch nicht vollständig dort stattfinden.

Wie lässt sich aktive Verantwortung messen?

Eine hohe Anzahl zugewiesener Owner beweist noch keine wirksame Governance.

Neben Coverage können operative Kennzahlen betrachtet werden:

Auch diese Kennzahlen müssen im Kontext betrachtet werden. Eine niedrige Anzahl von Issues kann gute Qualität bedeuten – oder eine zu hohe Hürde für Feedback.

Das Ziel ist nicht maximale Aktivität. Das Ziel ist nachvollziehbare und wirksame Verantwortung.

Häufige Anti-Patterns

Der Owner als reine Freigabeinstanz

Der Owner wird nur kontaktiert, wenn ein Formular genehmigt werden muss. Fachliche Priorisierung und Zielbild bleiben außerhalb des Prozesses.

Der Steward als universeller Problemlöser

Jede offene Frage landet beim Steward – unabhängig davon, ob sie fachlich, technisch, regulatorisch oder organisatorisch ist.

Das Governance-Team als Flaschenhals

Ein zentrales Team muss jede Definition und jede Änderung selbst bearbeiten. Die Organisation skaliert nicht mit dem Datenumfang.

Verantwortlichkeit ohne Bestätigung

Personen werden automatisch zugewiesen, wissen aber nicht, dass sie verantwortlich sind oder welche Erwartungen gelten.

Technische Vollständigkeit ohne fachliche Nutzbarkeit

Alle Tabellen sind gescannt und Lineage ist vorhanden, aber Nutzer verstehen weder Zweck noch Bedeutung der Daten.

Ein Prozess für jedes Risiko

Eine kleine Beschreibungsänderung durchläuft denselben Prozess wie eine kritische regulatorische Entscheidung.

Balance: Governance darf nicht selbst zum Hindernis werden

Mehr Verantwortung bedeutet nicht automatisch mehr Freigaben.

Ein zu schweres Modell kann neue Engpässe erzeugen:

• jede Änderung benötigt mehrere Genehmigungen,
• lokale Teams warten auf zentrale Entscheidungen,
• Stewards verwalten Aufgaben statt Datenverständnis,
• Business User umgehen Prozesse, weil sie zu langsam sind.

Ein gutes Operating Model nutzt abgestufte Leitplanken:

Governance sollte proportional sein.

Praktische Leitfragen für Teams

Für jedes kritische Datenprodukt, jede Kennzahl oder Governance-Domain können folgende Fragen helfen:

1. Ist klar, was der Owner tatsächlich besitzt und entscheidet?
2. Ist klar, welche täglichen Aufgaben beim Data Steward liegen?
3. Haben beide Rollen ihre Verantwortung bestätigt?
4. Sind Zeit, Vertretung und realistische Kapazität berücksichtigt?
5. Welche Entscheidungen dürfen direkt getroffen werden?
6. Wie sieht der Eskalationsweg bei Konflikten oder Source-Problemen aus?
7. Können Business User Probleme und Fragen einfach melden?
8. Ist der fachliche Kontext verständlich, bevor technische Details angezeigt werden?
9. Sind Status, Priorität und nächste Aktion sichtbar?
10. Wer prüft regelmäßig, ob Rollen und Verantwortungen noch aktuell sind?

Diese Fragen ersetzen kein Governance-Tool. Sie machen sichtbar, welche organisatorischen Verbindungen das Tool abbilden sollte.

Fazit

Data Verantwortung und Data Stewardship sind keine fehlenden Konzepte. Sie sind in Governance-Frameworks und Plattformen längst etabliert.

Die mögliche Lücke liegt zwischen Zuweisung und Handlung.

Ein Name im Katalog schafft Sichtbarkeit. Wirksame Verantwortung benötigt zusätzlich:

Die zentrale Frage lautet deshalb:

Ist Verantwortung ein aktives Operating Model – oder nur ein Feld im Datenkatalog?

Vielleicht ist die wichtigste Aufgabe von Governance nicht, immer mehr Verantwortlichkeiten zuzuweisen.

Vielleicht ist sie, Menschen so auszustatten, dass sie Verantwortung tatsächlich übernehmen und gemeinsam in Ergebnisse übersetzen können.

Weiterführende Ressourcen

• Microsoft Learn: Data Governance Roles and Permissions in Microsoft Purview
• Microsoft Learn: Data governance with Microsoft Purview
• Microsoft Learn: Glossary terms in Microsoft Purview Unified Catalog
• Microsoft Learn: Get started with data governance in Microsoft Purview
• AWS Prescriptive Guidance: Roles and responsibilities for a data mesh
• AWS Cloud Adoption Framework: Data governance
• Collibra Product Resource Center: About Stewardship
• Collibra Product Resource Center: Data Catalog workflows
• Collibra Product Resource Center: Issue roles
• IBM: What is Data Stewardship?
• IBM: What is Data Governance?

Technische Sichtbarkeit ist wertvoll – aber nicht dasselbe wie Verständnis

In der Steuerungsrunde fragt niemand nach dem Schema-Namen — sondern: Woher kommt die Umsatzzahl im Dashboard, und wer darf die Definition ändern? Ein Katalog voller Tabellen beantwortet das allein nicht — Metadata (Bedeutung, Owner, Lineage) muss kuratiert werden; der Catalog ist die Discovery-Anwendung, nicht das Dashboard und nicht der Semantic Layer.

Moderne Datenplattformen können sehr viele Informationen über Daten erfassen und sichtbar machen:

• Datenbanken, Schemas, Tabellen und Spalten,
• Dateien, APIs und Streaming-Quellen,
• Pipelines, Jobs und Transformationen,
• Abhängigkeiten zwischen Upstream- und Downstream-Assets,
• Klassifizierungen und Sensitivity Labels,
• Qualitätsergebnisse, Nutzungssignale und zugewiesene Verantwortlichkeiten,
• Reports, Dashboards, Modelle und Datenprodukte.

Diese Sichtbarkeit ist ein großer Fortschritt gegenüber undokumentierten Datenlandschaften und isoliertem Wissen in einzelnen Teams.

Sie hilft bei Fragen wie:

Woher kommt dieses Feld?

Welche Reports hängen von dieser Tabelle ab?

Was könnte durch eine Änderung an diesem Modell betroffen sein?

Wohin fließen sensible Informationen?

Business User beginnen jedoch häufig mit anderen Fragen:

Was bedeutet diese Zahl?

Welche Definition ist für meinen Anwendungsfall freigegeben?

Warum existieren diese Daten?

Kann ich sie für diese Entscheidung verwenden?

Wer kann sie erklären oder eine Änderung freigeben?

Der Unterschied ist wichtig:

Metadaten können Daten sichtbar machen. Kontext macht sie verständlich.

Dieses Playbook stellt den Nutzen von Katalogen, automatischem Metadata Deep Diveing oder Lineage nicht infrage. Es betrachtet die Lücke zwischen technischer Transparenz und gemeinsamem fachlichem Verständnis.

Metadaten, Katalog und Lineage lösen unterschiedliche Aufgaben

Die Begriffe hängen zusammen, sind aber nicht austauschbar.

Eine reife Governance Experience verbindet diese Fähigkeiten.

Ein Katalog ohne fachliche Bedeutung kann zu einem durchsuchbaren Inventar technischer Objekte werden.

Ein Glossar ohne Verbindungen zu realen Assets kann zu einem Wörterbuch werden, das vom Arbeitsalltag getrennt ist.

Lineage ohne Kontext kann zu einem detaillierten Graphen werden, der jeden Pfad zeigt, aber wenig über den Zweck erklärt.

Der Nutzen entsteht durch die Beziehungen zwischen diesen Elementen.

Die Lücke zwischen technischer Sichtbarkeit und fachlichem Verständnis

Technische Metadaten lassen sich häufig leichter automatisieren, weil Systeme Schemas, Objektnamen, Datentypen, Jobs und Ausführungsbeziehungen bereitstellen können.

Fachliche Bedeutung funktioniert anders. Sie hängt von Unternehmenssprache, Prozesswissen, beabsichtigter Nutzung, Richtlinien, Interpretation und teilweise auch von Abstimmungen zwischen Domains ab.

Ein Scanner kann in der Regel erkennen, dass eine Spalte existiert.

Er kann nicht immer zuverlässig bestimmen:

• was das Feld fachlich bedeutet,
• ob sein Name irreführend ist,
• welche Definition freigegeben wurde,
• warum eine Transformationsregel existiert,
• welche Ausnahmen akzeptiert sind,
• ob eine KPI für eine bestimmte Entscheidung geeignet ist,
• welcher Geschäftsprozess die Daten erzeugt oder verwendet,
• wer Unklarheiten zwischen Fachbereichen auflösen soll.

Das macht automatisches Metadatenimporting nicht weniger wichtig. Automatisierung ist für Skalierung notwendig.

Es bedeutet, dass Automatisierung und Stewardship unterschiedliche Stärken besitzen:

Maschinen können Struktur und technische Evidenz skalierbar erfassen. Menschen müssen weiterhin Bedeutung, Zweck und Verantwortung vereinbaren.

Mehr Metadaten bedeuten nicht automatisch leichtere Auffindbarkeit

Ein Katalog kann Millionen Assets enthalten und Nutzer trotzdem im Unklaren lassen, wo sie beginnen sollen.

Suchergebnisse können enthalten:

• mehrere physische Tabellen mit ähnlichen Namen,
• historische Versionen,
• Staging- und Intermediate-Modelle,
• verschiedene Domain Views,
• zertifizierte und nicht zertifizierte Datensätze,
• reportspezifische Extrakte,
• technische Objekte, die für den Betrieb wichtig, aber nicht für die direkte fachliche Nutzung gedacht sind.

Alle diese Assets können korrekt katalogisiert sein.

Die verbleibende Herausforderung ist die Navigation.

Ein Nutzer, der nach Umsatz aktiver Kunden sucht, weiß möglicherweise nicht, ob er hier beginnen soll:

raw.crm_account

stg_salesforce_account

conformed_customer

mart_revenue_customer_month

semantic_sales_model

oder bei einem freigegebenen Report.

Ein nützlicher Katalog benötigt deshalb mehr als vollständige Indizierung. Er benötigt sinnvolle Einstiegspunkte.

Mögliche fachliche Einstiegspunkte sind:

• Business Domains,
• Datenprodukte,
• Critical Data Elements,
• Fachbegriffe,
• Trusted Metrics,
• zertifizierte semantische Modelle,
• freigegebene Reports,
• häufige Geschäftsfragen,
• Prozess- oder Capability Maps.

Die technischen Assets bleiben als Evidenz und Implementierungsdetail verfügbar. Sie müssen nicht das Erste sein, was jeder Nutzer sieht.

Der Katalog sollte bei der Auswahl helfen – nicht nur beim Finden

Discovery besitzt mindestens drei Ebenen:

1. Auffindbarkeit – Kann der Nutzer relevante Assets finden?
2. Verständlichkeit – Kann er Zweck, Bedeutung und Einschränkungen verstehen?
3. Entscheidungsunterstützung – Kann er beurteilen, welches Asset für die beabsichtigte Nutzung geeignet ist?

Ein Suchergebnis ist noch keine vertrauenswürdige Auswahl.

Für eine Auswahl benötigen Nutzer möglicherweise folgenden Kontext:

Das Ziel ist nicht, das längstmögliche Metadatenformular zu erzeugen.

Das Ziel ist, den minimal notwendigen Kontext für eine sichere Entscheidung bereitzustellen.

Technische Lineage ist Evidenz – fachlicher Kontext ist Interpretation

Technische Lineage ist sehr wertvoll für Impact Analysis, Ursachenanalyse, Change Planning und die Nachverfolgung sensibler Daten.

Sie kann einen Pfad wie diesen zeigen:

Dieser Pfad beantwortet wichtige Fragen:

• Welche Upstream-Assets tragen zum Ergebnis bei?
• Welche Downstream-Objekte könnten von einer Änderung betroffen sein?
• Wo wird ein Feld transformiert?
• Welche Reports nutzen das Ergebnis?

Der Pfad allein erklärt jedoch möglicherweise nicht:

• warum eine Quelle als maßgeblich gilt,
• welche Geschäftsregel angewendet wird,
• warum ein Datensatz ausgeschlossen wird,
• welche Definition die Kennzahl repräsentiert,
• ob ein Dashboard für eine bestimmte Entscheidung freigegeben ist,
• welches Team die fachliche Bedeutung verantwortet,
• welche bekannten Einschränkungen die Interpretation beeinflussen.

Das ist keine Schwäche von Lineage. Es ist die Grenze zwischen technischer Nachvollziehbarkeit und fachlicher Erklärung.

Technische und fachliche Lineage sollten sich ergänzen

Technische Lineage ist häufig detailliert und systemorientiert.

Fachliche Lineage ist meist selektiver und ergebnisorientierter.

Keine der beiden Sichten sollte die andere ersetzen.

Eine vereinfachte fachliche Lineage ohne technische Evidenz kann zu abstrakt werden.

Ein vollständiger technischer Graph ohne Business View kann für viele Nutzer zu komplex werden.

Ein nützliches Modell ermöglicht den Wechsel zwischen den Ebenen:

Der Nutzer kann bei der Bedeutung beginnen und bei Bedarf in technische Evidenz hineinzoomen.

Fachliche Bedeutung sollte verknüpft – nicht in jedes Asset kopiert werden

Ein häufiges Wartungsproblem entsteht, wenn dieselbe Definition in Dutzende Tabellen, Spalten, Reports und Dokumente kopiert wird.

Die kopierten Texte entwickeln sich mit der Zeit auseinander.

Ein stärkeres Muster ist, wiederverwendbare Konzepte zentral zu steuern und mit relevanten Assets zu verknüpfen.

Beispiel:

Business Term: Aktiver Kunde

Definition: Ein Kunde mit mindestens einem aktiven, abrechenbaren Vertrag am Reporting-Stichtag.

Verknüpft mit:

• Customer-Status-Feld,
• Conformed Customer Model,
• Active-Customer-KPI,
• Customer semantisches Modell,
• Commercial Dashboard,
• Retention Richtlinie oder Qualitätsregel, sofern relevant.

Das zentrale Konzept kann besitzen:

• einen verantwortliche Person,
• einen Steward,
• einen Freigabestatus,
• eine Änderungshistorie,
• Beispiele,
• Synonyme,
• verwandte Begriffe,
• Richtlinienverweise.

Die technischen Assets können lokale Implementierungsdetails ergänzen, ohne das Konzept unabhängig neu zu definieren.

Das reduziert Duplikate und hält Kontext gleichzeitig nah an der Nutzung.

Nicht jedes Metadatenfeld benötigt denselben Governance-Aufwand

Eine häufige Reaktion auf fehlenden Kontext ist, weitere Pflichtfelder einzuführen.

Das kann die Vollständigkeit erhöhen, aber auch die Beteiligung senken, wenn jedes Asset denselben Umfang manueller Dokumentation erfordert.

Governance sollte proportional zu Wert, Risiko und Reichweite sein.

Ein mögliches gestuftes Modell:

Damit werden zwei Extreme vermieden:

• jedes temporäre technische Objekt manuell zu dokumentieren,
• kritische Business Assets nur mit technischen Metadaten auszustatten.

Automatisierte Metadaten und menschliche Pflege sollten gemeinsam gedacht werden

Automatisierung kann beitragen:

• Schema- und Spaltenerkennung,
• Datentypen und technische Eigenschaften,
• Klassifizierungen,
• Lineage aus unterstützten Systemen,
• Job- und Pipeline-Beziehungen,
• Nutzungsstatistiken,
• Freshness- und Ausführungsmetadaten,
• Ergebnisse von Qualitätstests,
• Erkennung von Änderungen.

Menschliche Pflege ist besonders wichtig für:

• fachliche Definitionen,
• Zweck und beabsichtigte Nutzung,
• Beispiele und Ausnahmen,
• Kritikalität,
• Freigabe und Zertifizierung,
• Verantwortung-Entscheidungen,
• fachliche Auswirkungen,
• bekannte Einschränkungen,
• domänenübergreifende Interpretation.

Das Ziel sollte weder sein, Menschen durch Scanning zu ersetzen, noch alles manuell zu dokumentieren.

Ein praktikables Modell lautet:

Automatisiert, was Systeme wissen. Pflegt gemeinsam, was der Fachbereich vereinbaren muss.

Metadatenqualität ist ein eigenes Governance-Thema

Auch Metadaten können unvollständig, veraltet, inkonsistent oder schwer vertrauenswürdig sein.

Typische Fragen zur Metadatenqualität sind:

• Ist der verantwortliche Person noch in dieser Rolle?
• Ist die Beschreibung aktuell?
• Deckt die Lineage den vollständigen Pfad oder nur eine Plattform ab?
• Ist die Zertifizierung noch gültig?
• Sind Glossarbegriffe mit den richtigen Assets verbunden?
• Wird eine abgelöste Tabelle noch als empfohlene Quelle angezeigt?
• Sind bekannte Einschränkungen sichtbar?
• Entspricht die dokumentierte Granularität den tatsächlichen Daten?

Ein Katalog sollte Metadaten deshalb nicht nur speichern. Er sollte die Gesundheit der Metadaten sichtbar machen.

Mögliche Kennzahlen sind:

Coverage-Werte benötigen Kontext.

Ein Katalog kann eine hohe Metadatenvollständigkeit erreichen, während Nutzer trotzdem Schwierigkeiten haben, das richtige Asset auszuwählen.

Das Ergebnis ist wichtiger als die Anzahl ausgefüllter Felder.

Die letzte Meile der Lineage ist relevant

Viele Datenpfade enden nicht an einer Warehouse-Tabelle.

Sie laufen weiter:

Nicht jeder Downstream-Schritt lässt sich über jedes Tool automatisch erfassen.

Daraus entstehen praktische Fragen:

• Umfasst Lineage die semantische Ebene?
• Sind Report-Level-Measures sichtbar?
• Können Nutzer erkennen, welches zertifizierte Datenprodukt ein Dashboard verwendet?
• Werden Exporte und lokale Berechnungen als gesteuerte Ergebnisse oder persönliche Analyse behandelt?
• Kann ein wichtiges Spreadsheet als Business Asset registriert werden, sobald es operativ relevant wird?
• Ist der Entscheidungskontext mit den verwendeten Daten verbunden?

Das Ziel ist nicht, jede private Berechnung mit einem Enterprise-Prozess zu steuern.

Das Ziel ist zu erkennen, wann lokale Nutzung gemeinsam, wiederkehrend oder geschäftskritisch wird.

Ab diesem Punkt sollten Kontext und Verantwortlichkeit der Bedeutung des Ergebnisses folgen.

Ein Katalog sollte unterschiedliche Nutzer mit unterschiedlichen Sichten unterstützen

Derselbe Metadaten-Graph dient verschiedenen Anforderungen.

Eine Oberfläche muss nicht alles gleichzeitig zeigen.

Progressive Disclosure kann helfen:

1. Mit Business-Name, Zweck, Status und Owner beginnen.
2. Qualität, Freshness, Nutzungshinweise und verwandte Assets zeigen.
3. Lineage und technische Implementierungsdetails bei Bedarf öffnen.
4. Richtlinien-, Audit- und Betriebsevidenz für Spezialrollen bereitstellen.

So bleibt technische Tiefe erhalten, ohne der einzige Einstiegspunkt zu sein.

Stewardship hält Bedeutung mit der Realität verbunden

Kataloge und Lineage sind keine einmaligen Einführungsprojekte.

Fachdefinitionen ändern sich. Systeme werden ersetzt. Kennzahlen werden überarbeitet. Reports werden abgelöst. Neue regulatorische Anforderungen erzeugen neue Klassifizierungen und Kontrollen.

Ohne Stewardship kann der Katalog langsam zu einem historischen Abbild dessen werden, was früher einmal richtig war.

Stewardship kann Kontinuität unterstützen durch:

• Review kritischer Definitionen,
• Validierung von Verantwortung und Ansprechpartnern,
• Verknüpfung neuer Assets mit bestehenden Konzepten,
• Auflösung doppelter oder widersprüchlicher Begriffe,
• Prüfung von Zertifizierung und Nutzungshinweisen,
• Dokumentation bekannter Einschränkungen,
• Koordination von Nutzerfeedback,
• eindeutige Kennzeichnung abgelöster Assets,
• Prüfung, ob Lineage und Kontext nach Änderungen noch vollständig sind.

Der Steward sollte nicht jedes technische Detail manuell pflegen müssen.

Die Rolle schützt Bedeutung, Qualität und Nutzbarkeit, während Automatisierung einen großen Teil der technischen Evidenz aktuell hält.

Häufige Anti-Patterns

Der Katalog als technisches Inventar

Millionen Assets werden gescannt, aber Business User können keine freigegebenen Einstiegspunkte erkennen.

Das Glossar als separates Wörterbuch

Definitionen existieren, sind aber nicht mit Datensätzen, Kennzahlen, Reports oder Prozessen verbunden.

Lineage als Wand aus Knoten

Der Graph ist technisch vollständig, aber zu detailliert, um Auswirkungen für Nicht-Spezialisten zu erklären.

Pflichtmetadaten ohne klaren Nutzen

Nutzer füllen Felder aus, weil der Workflow es verlangt, aber die Informationen helfen weder bei Discovery noch bei Entscheidungen oder Kontrollen.

Definitionen überall kopieren

Dieselbe fachliche Bedeutung wird unabhängig in Modellen, Reports, Katalogfeldern und Dokumenten gepflegt.

Zertifizierung ohne Review

Ein Asset bleibt als vertrauenswürdig markiert, obwohl sich Verantwortung, Logik oder Nutzung verändert haben.

Automatisierte Vollständigkeit ohne fachliche Validierung

Beschreibungen und Klassifizierungen werden skalierbar erzeugt, aber bei hohem Business Impact nicht überprüft.

Business-Kontext ohne technische Evidenz

Eine ansprechende Datenproduktseite existiert, aber Nutzer können Quelle, Transformation oder betroffene Downstream-Assets nicht nachvollziehen.

Ein praktikables Modell für Metadaten, die Verständnis erzeugen

Ein möglicher Ansatz:

1. Fachliche Einstiegspunkte identifizieren
   Mit Domains, Datenprodukten, kritischen Kennzahlen, Reports und Fachbegriffen beginnen, nach denen Nutzer tatsächlich suchen.

2. Technische Metadaten automatisiert erfassen
   Unterstützte Plattformen, Schemas, Pipelines, Modelle, Klassifizierungen und Lineage scannen.

3. Fachkonzepte mit technischen Assets verbinden
   Glossarbegriffe, Prozesse, Capabilities, KPIs und Richtlinien mit den Assets verknüpfen, die sie umsetzen.

4. Den minimal nützlichen Business-Kontext ergänzen
   Zweck, Scope, Granularität, beabsichtigte Nutzung, Owner, Steward, Qualitätsstatus und bekannte Einschränkungen beschreiben.

5. Verständliche Lineage-Sichten bereitstellen
   Sowohl detaillierte technische Lineage als auch vereinfachte fachliche Pfade anbieten.

6. Vertrauenswürdige Auswahl sichtbar machen
   Zertifizierung, Lifecycle-Status und Nutzungshinweise verwenden, um empfohlene Assets von Drafts, Legacy-Objekten und technischen Zwischenstufen zu unterscheiden.

7. Feedback und Stewardship integrieren
   Nutzern ermöglichen, Fragen zu stellen, Unklarheiten zu melden und Verbesserungen dort vorzuschlagen, wo sie Daten verwenden.

8. Metadaten als Teil von Changes aktualisieren
   Kontext, Verknüpfungen, Verantwortung und Zertifizierung anpassen, wenn Datenprodukte, Pipelines oder Reports verändert werden.

9. Ergebnisse statt nur Vollständigkeit messen
   Prüfen, ob Nutzer Daten mit weniger Supportaufwand finden, verstehen und korrekt verwenden.

Praktische Fragen für Teams

Für ein kritisches Datenprodukt, eine Kennzahl oder einen Report:

1. Kann ein Business User das Asset finden, ohne technische Objektnamen zu kennen?
2. Ist der Zweck in Fachsprache verständlich?
3. Ist die Definition mit gesteuerten Fachbegriffen verknüpft?
4. Sind Owner und Steward sichtbar und aktuell?
5. Können Nutzer beabsichtigte Nutzung, Granularität, Scope und bekannte Einschränkungen erkennen?
6. Sind Qualitäts- und Freshness-Status verständlich?
7. Reicht die Lineage von relevanten Quellen bis zum Nutzungspunkt?
8. Können Nutzer zwischen fachlicher und technischer Lineage wechseln?
9. Sind freigegebene, experimentelle, Legacy- und abgelöste Assets klar unterscheidbar?
10. Wird wiederverwendete fachliche Bedeutung zentral verknüpft, statt immer wieder kopiert?
11. Können Nutzer Feedback geben, ohne ihren normalen Arbeitsablauf zu verlassen?
12. Werden Metadaten überprüft, wenn sich das zugrunde liegende Datenprodukt verändert?

Diese Fragen verlangen nicht, dass jede Organisation dasselbe Katalogmodell einführt.

Sie helfen zu prüfen, ob Metadaten tatsächlich Verständnis und Nutzung unterstützen.

Fazit

Metadaten, Kataloge und Lineage sind keine fehlenden Fähigkeiten. Moderne Plattformen bieten bereits leistungsfähige Möglichkeiten, Assets zu finden, technische Beziehungen zu erfassen, Kontext anzureichern und Datenflüsse nachzuvollziehen.

Die mögliche Lücke entsteht, wenn technische Sichtbarkeit als Endergebnis betrachtet wird.

Eine vollständige Karte erzeugt nicht automatisch eine gemeinsame Sprache.

Ein detaillierter Lineage-Graph erklärt nicht automatisch die fachliche Bedeutung.

Ein durchsuchbarer Katalog sagt Nutzern nicht automatisch, welches Asset für ihre Entscheidung geeignet ist.

Die Brücke benötigt:

Die zentrale Frage lautet deshalb:

Haben wir mehr Metadaten – oder mehr Verständnis?

Vielleicht besteht das Ziel von Metadata Governance nicht darin, alles gleich tief zu dokumentieren.

Vielleicht besteht es darin, die wichtigsten Daten so verständlich zu machen, dass Menschen sie finden, bewerten, korrekt nutzen und wissen, wer helfen kann, wenn die Bedeutung unklar ist.

Weiterführende Ressourcen

• Microsoft Learn: Microsoft Purview Data Governance Glossar
• Microsoft Learn: Microsoft Purview Data Map
• Microsoft Learn: Datenobjekte im Microsoft Purview Unified Catalog suchen und verwalten
• Microsoft Learn: Data Lineage in Microsoft Purview
• Databricks Documentation: Lineage in Unity Catalog
• Databricks Documentation: External Lineage in Unity Catalog
• Databricks Documentation: What is Unity Catalog?
• Collibra Product Resource Center: Business Glossary
• Collibra Product Resource Center: About Data Catalog
• Collibra Product Resource Center: About Collibra Data Lineage
• AWS Documentation: Amazon DataZone Concepts
• AWS Documentation: Business Glossary in Amazon DataZone erstellen und pflegen

Begriffe vor dem Lesen

• RBAC — Role-Based Access Kontrollregel: Zugriff über Rollen wie Steward, Analyst, Admin oder Auditor.
• ABAC — Attribute-Based Access Kontrollregel: Zugriff über Eigenschaften wie Land, Zweck, Sensitivität oder Vertragsstatus.

Eine Richtlinie kann auf dem Papier vollständig und in der Praxis unvollständig sein

Die Richtlinie steht im Intranet: Kundendaten nur zweckgebunden. Trotzdem exportiert ein Analyst die volle Kundentabelle — der Warehouse-Zugriff ist seit dem Projektstart offen. Es fehlen selten die Texte; es fehlt die durchgesetzte Zugriffskette.

Die meisten Organisationen haben Sicherheitsstandards, Klassifizierungen, Datenschutzregeln, Aufbewahrung, Freigaben und Rollen.

Häufig existieren außerdem ausgereifte technische Fähigkeiten:

• Identity Provider und Single Sign-on,
• rollenbasierte Zugriffskontrolle,
• attributbasierte Richtlinien,
• Zeilen- und Spaltenberechtigungen,
• Maskierung und Verschlüsselung,
• Berechtigung Management,
• Workflows für Zugriffsanforderungen,
• Access Reviews und Rezertifizierungen,
• Audit Logs und Monitoring.

Diese Fähigkeiten sind wichtig. Sie bilden die technischen und organisatorischen Bausteine für kontrollierten Zugriff.

Die offene Frage lautet, ob die ursprüngliche Absicht einer Richtlinie dauerhaft mit den Kontrollen verbunden bleibt, die in Systemen, Plattformen und Geschäftsprozessen tatsächlich ausgeführt werden.

Eine Richtlinie kann beispielsweise festlegen:

Kontaktinformationen von Kunden dürfen nur von autorisierten Teams für freigegebene Geschäftszwecke verwendet werden.

Für die operative Umsetzung müssen trotzdem viele Entscheidungen getroffen werden:

• Welche Datenobjekte enthalten Kundenkontaktdaten?
• Welche Identitäten repräsentieren autorisierte Nutzer, Anwendungen und Service-Konten?
• Welche Business-Rollen benötigen Zugriff?
• Auf welcher Ebene soll Zugriff gewährt werden: Domain, Katalog, Schema, Tabelle, Zeile oder Spalte?
• Sollen Daten sichtbar, maskiert oder aggregiert werden?
• Wer genehmigt eine Anforderung?
• Wie lange soll der Zugriff gültig bleiben?
• Welche Ausnahmen sind zulässig?
• Wie wird der fortbestehende Bedarf überprüft?
• Welcher Nachweise zeigen, dass die Richtlinie tatsächlich wirkt?

Die Richtlinie beschreibt die Absicht.

Die Kontrollumgebung setzt sie um.

Governance wird operativ, wenn sich Richtlinienabsicht bis zu Zugriffsentscheidung, technischer Durchsetzung, Review und Nachweis nachvollziehen lässt.

Dieses Playbook stellt weder Richtlinien noch IAM-Systeme oder Plattformkontrollen infrage. Es betrachtet die mögliche Lücke zwischen dem Dokumentieren einer Regel und ihrer konsistenten Ausführung in einer sich laufend verändernden Datenlandschaft.

Policy Governance und Access Governance hängen zusammen – sind aber nicht dasselbe

Die Begriffe überschneiden sich, lösen jedoch unterschiedliche Teile des Problems.

Ein Policy Repository kann die Absicht dokumentieren, ohne Zugriff technisch durchzusetzen.

Eine IAM-Plattform kann Identitäten verwalten, ohne die vollständige fachliche Bedeutung jedes Datenobjekts zu kennen.

Eine Datenplattform kann Berechtigungen durchsetzen, ohne zu wissen, ob der gewährte Zugriff noch dem aktuellen Geschäftsbedarf entspricht.

Ein Datenkatalog kann Klassifizierungen und Owner sichtbar machen, ohne selbst das System zu sein, das Berechtigungen provisioniert.

Der Nutzen entsteht, wenn diese Fähigkeiten durch ein klares Operating Model miteinander verbunden werden.

Die Kette von der Richtlinie zur Kontrolle

Ein praktikabler Policy-Lifecycle lässt sich als fünf verbundene Stufen betrachten:

1. Richtlinie definieren
   Absicht, Geltungsbereich, Verpflichtungen, verbotene Nutzung und erwartete Kontrollen werden freigegeben.

2. Verantwortung zuweisen
   Owner, Stewards, Genehmiger, Reviewer und technische Kontrollverantwortliche werden benannt.

3. Zugriff umsetzen
   Rollen, Privilegien, Filter, Maskierungen, Berechtigungs und Plattformkontrollen werden konfiguriert.

4. Zugriff überprüfen
   Nutzung, fortbestehender Geschäftsbedarf, Rollenwechsel, Konflikte und Ausnahmen werden bewertet.

5. Zugriff durchsetzen und verbessern
   Nicht mehr benötigte Berechtigungen werden entfernt, Verstöße behoben, Ausnahmen gesteuert und Richtlinien oder Kontrolldesign bei Bedarf angepasst.

Jede Stufe kann für sich ausgereift sein, während die End-to-End-Verbindung trotzdem unvollständig bleibt.

Beispiele:

• Eine Richtlinie existiert, aber niemand ist für die technische Umsetzung verantwortlich.
• Eine Rolle ist zugewiesen, aber die dahinterliegenden Berechtigungen unterscheiden sich je Plattform.
• Zugriff wird bereitgestellt, aber Ablauf- oder Review-Datum fehlen.
• Reviews werden abgeschlossen, aber das Ergebnis wird nicht im Zielsystem umgesetzt.
• Ausnahmen werden genehmigt, bleiben aber aktiv, nachdem der ursprüngliche Grund entfallen ist.
• Technische Kontrollen funktionieren, aber Nutzer verstehen nicht, warum Zugriff gewährt oder verweigert wurde.
• Nachweise liegen in mehreren Systemen, aber der vollständige Entscheidungsweg lässt sich nicht rekonstruieren.

Häufig fehlt nicht die Kontrolle – sondern die Verbindung

Moderne Plattformen stellen viele Mechanismen für Zugriffskontrolle bereit.

Snowflake unterstützt rollenbasierte und objektbezogene Berechtigungsmodelle. Databricks Unity Catalog kombiniert Privilegien, Verantwortung, attributbasierte Richtlinien, Zeilenfilter, Spaltenmaskierung und Workspace-Einschränkungen. AWS Lake Formation unterstützt fein granulare und tagbasierte Kontrollen. Cloud-IAM-Plattformen bieten Rollen, Bedingungen, temporäre Berechtigungen und Access Analysis.

Die Herausforderung besteht deshalb selten darin, dass überhaupt keine technische Möglichkeit existiert.

Die Herausforderung besteht vielmehr in den Entscheidungen:

• Welche Kontrolle setzt welche Richtlinie um?
• An welcher Stelle soll die Kontrolle durchgesetzt werden?
• Wie bleibt dieselbe Absicht über mehrere Plattformen hinweg konsistent?
• Wer verantwortet die Abbildung von Richtlinie auf technische Umsetzung?
• Wie werden Ausnahmen dargestellt?
• Wie werden Änderungen getestet?
• Wie entstehen Nachweise?
• Wie werden veraltete Berechtigungen entfernt?

Eine Klassifizierung wie Vertraulich – Kunden-PII kann beispielsweise Einfluss haben auf:

• Sichtbarkeit im Katalog,
• Zugriffsanforderungen für Datenprodukte,
• Warehouse-Berechtigungen,
• Zeilenfilter,
• Spaltenmaskierung,
• Report-Level Security,
• Exportberechtigungen,
• API-Zugriff,
• Machine-Learning-Workspaces,
• Berechtigungen von Service-Konten,
• Aufbewahrungs- und Löschkontrollen.

Die Klassifizierung selbst ist noch keine Kontrolle.

Sie ist Kontext, der eine oder mehrere Kontrollen steuern sollte.

Ein gesteuertes Label wird dann wertvoll, wenn seine Bedeutung konsistent in operatives Verhalten übersetzt wird.

Von der Identität zur Zugriffskontrolle

Access Governance beginnt, bevor eine Berechtigung vergeben wird.

Sie beginnt mit der Identität.

Eine Organisation muss möglicherweise folgende Identitäten steuern:

• Mitarbeitende,
• Führungskräfte,
• externe Partner,
• Dienstleister,
• temporäre Kräfte,
• Gäste,
• Service-Konten,
• Anwendungen,
• Automatisierungsidentitäten,
• Empfänger von Data Partnerfreigaben,
• KI-Agenten und andere Machine Identities.

Die Zugriffsentscheidung hängt anschließend von Kontext ab, zum Beispiel:

• Business-Rolle,
• Organisationseinheit,
• Projekt oder Domain,
• geografischer Standort,
• Beschäftigungsstatus,
• Geräte- oder Netzwerkkontext,
• Datenklassifizierung,
• Nutzungszweck,
• beantragte Dauer,
• Risikostufe,
• Anforderungen zur Funktionstrennung,
• vertragliche oder regulatorische Verpflichtungen.

Daraus entsteht ein Lifecycle:

Phase A — gewähren

Phase B — nachweisen und entziehen

Der Prozess sollte nicht davon ausgehen, dass jede Zugriffsanforderung eine lange manuelle Genehmigungskette benötigt.

Zugriffe mit geringem Risiko und klaren Regeln können häufig innerhalb freigegebener Leitplanken automatisiert werden.

Kritische oder außergewöhnliche Zugriffe benötigen möglicherweise zusätzliche Prüfung, begrenzte Laufzeit und stärkere Nachweise.

Das Ziel ist proportionale Governance:

Der Kontrollaufwand sollte Sensitivität, Umfang, Dauer und potenzielle Auswirkung des Zugriffs widerspiegeln.

Least Privilege ist eine Richtung – keine einmalige Konfiguration

Least Privilege ist ein breit anerkannter Sicherheitsgrundsatz: Es werden nur die Berechtigungen vergeben, die für die vorgesehene Aufgabe benötigt werden.

In der Praxis lässt sich Least Privilege kaum allein durch ein initiales Design dauerhaft erreichen.

Zugriffsanforderungen verändern sich, weil:

• Mitarbeitende Teams wechseln,
• Projekte enden,
• Verantwortlichkeiten wachsen oder kleiner werden,
• Anwendungen ersetzt werden,
• Datenprodukte weiterentwickelt werden,
• Notfallzugriffe vergeben werden,
• temporäre Arbeit dauerhaft wird,
• Service-Konten zusätzliche Aufgaben erhalten,
• Rollendefinitionen mit der Zeit breiter werden.

Eine anfangs angemessene Berechtigung kann später zu weitreichend sein.

Deshalb benötigt Least Privilege einen Lifecycle:

Nutzungsevidenz kann Reviewern helfen, aktiv benötigte Zugriffe von Berechtigungen zu unterscheiden, die möglicherweise nicht mehr verwendet werden.

Nutzung allein reicht jedoch nicht aus.

Eine Berechtigung kann verwendet und trotzdem unangemessen sein.

Eine Berechtigung kann über einen ruhigen Zeitraum ungenutzt bleiben und dennoch für einen gültigen saisonalen oder Notfallprozess erforderlich sein.

Fachlicher Kontext bleibt notwendig.

Rollen helfen bei der Skalierung – können Komplexität aber auch verbergen

Rollenbasierte Zugriffskontrolle ist hilfreich, weil Berechtigungen Rollen zugewiesen werden können, statt sie für jeden Nutzer einzeln zu verwalten.

Das Rollendesign erzeugt jedoch eigene Governance-Fragen:

• Welche fachliche Verantwortung bildet die Rolle ab?
• Welche technischen Berechtigungen enthält sie?
• Sind die Berechtigungen über Umgebungen hinweg konsistent?
• Ist die Rolle zu breit?
• Kombiniert sie widersprüchliche Aufgaben?
• Wer verantwortet die Rollendefinition?
• Wer darf die Rolle beantragen oder genehmigen?
• Wie oft wird die Rolle überprüft?
• Sind geerbte Berechtigungen sichtbar?
• Können Nutzer verstehen, was sie durch die Rolle erhalten?

Mit der Zeit können entstehen:

• Rollenexplosion – zu viele sehr eng definierte Rollen,
• Rollenakkumulation – Nutzer behalten Rollen aus früheren Verantwortungsbereichen,
• Rolleninflation – bestehende Rollen erhalten immer mehr Berechtigungen, weil ein neues Modell aufwendig erscheint,
• verschachtelte Komplexität – Gruppen und Vererbung erschweren die Erklärung effektiver Berechtigungen.

Die Antwort muss nicht sein, Rollen grundsätzlich aufzugeben.

Möglicherweise sollten Rollen mit Attributen, Bedingungen, Zeitbegrenzungen, Tags und klarer Verantwortung kombiniert werden.

RBAC, ABAC und datenbezogene Kontrollen lösen unterschiedliche Aufgaben

Unterschiedliche Zugriffskontrollmodelle können sich ergänzen.

Kein einzelnes Modell löst jedes Szenario.

Die wichtige Governance-Frage ist, ob die Organisation erklären kann, warum ein bestimmtes Kontrollmodell gewählt wurde und wie es die beabsichtigte Richtlinie umsetzt.

Zugriff auf Daten ist mehr als Zugriff auf Tabellen

Aus Sicht der Data Governance muss der vollständige Nutzungspfad betrachtet werden.

Daten können genutzt werden über:

• Warehouse-Abfragen,
• Lakehouse-Notebooks,
• semantische Modelle,
• BI-Dashboards,
• Report-Abonnements,
• Exporte,
• Spreadsheets,
• APIs,
• Anwendungen,
• Reverse ETL,
• Data Partnerfreigaben,
• Machine-Learning-Features,
• KI-Assistenten und Agenten.

Ein Dashboard kann eingeschränkt sein, während das zugrunde liegende semantische Modell breit zugänglich ist.

Ein Nutzer besitzt möglicherweise keinen direkten Tabellenzugriff, kann aber detaillierte Datensätze aus einem Report exportieren.

Eine im Warehouse maskierte Spalte kann in einem replizierten Downstream-System unmaskiert erscheinen.

Eine Anwendung kann ein Service-Konto verwenden, dessen Berechtigungen über den Bedarf einzelner Nutzer hinausgehen.

Ein Data Share kann fortbestehen, nachdem die ursprüngliche Zusammenarbeit beendet wurde.

Die relevante Frage lautet deshalb nicht nur:

Wer kann diese Tabelle abfragen?

Sondern auch:

Über welche Kanäle können diese Informationen angesehen, heruntergeladen, kombiniert, weitergegeben oder von automatisierten Systemen genutzt werden?

Access Reviews sind Entscheidungen – keine Checkbox-Übungen

Regelmäßige Access Reviews können dabei helfen zu bestätigen, ob Nutzer, Gruppen, Gäste, Anwendungen und privilegierte Rollen weiterhin Zugriff benötigen.

Ein Review wird dann wertvoll, wenn der Reviewer ausreichend Kontext für eine Entscheidung besitzt.

Ein schwacher Review zeigt möglicherweise nur:

Nutzer: Maria Beispiel
Gruppe: FIN_DATA_READ
Entscheidung: Genehmigen / Ablehnen

Ein stärkerer Review kann zusätzlich zeigen:

• fachlichen Zweck,
• Rolle und Abteilung,
• Datensensitivität,
• beantragten Umfang,
• ursprünglichen Genehmiger,
• Alter der Berechtigung,
• letzte Nutzung oder Nutzungsmuster,
• zugehöriges Projekt oder Vertragsverhältnis,
• bekannte Konflikte bei der Funktionstrennung,
• Ablaufdatum,
• Empfehlung des Owners,
• Auswirkung eines Entzugs.

Das Ziel ist nicht, jedes Review-Formular möglichst groß und komplex zu machen.

Es geht um den minimal notwendigen Kontext für eine verantwortungsvolle Entscheidung.

Review Fatigue ist ein operatives Risiko.

Erhalten Reviewer Hunderte schlecht erklärte Berechtigungen, kann die Freigabe zu einer routinemäßigen Bestätigung statt zu einer wirksamen Kontrolle werden.

Priorisierung kann helfen:

• kritische Zugriffe zuerst,
• privilegierte Zugriffe häufiger,
• risikoreiche Ausnahmen separat,
• Standardzugriffe mit geringem Risiko über Automatisierung und Stichproben,
• ungenutzte oder auffällige Berechtigungen hervorheben,
• Reviews an Personen weiterleiten, die den fachlichen Bedarf verstehen.

Ausnahmen sollten als eigenständige Governance-Objekte behandelt werden

Kein Policy-Modell deckt jede legitime Geschäftssituation vollständig ab.

Ausnahmen können notwendig sein wegen:

• dringender Incident Response,
• Migrationsprojekten,
• regulatorischen Untersuchungen,
• temporärer bereichsübergreifender Zusammenarbeit,
• Dienstleister Support,
• Einschränkungen von Legacy-Systemen,
• Business Continuity,
• noch nicht gelösten technischen Begrenzungen.

Die Existenz einer Ausnahme ist nicht automatisch ein Governance-Fehler.

Das Risiko entsteht durch eine ungesteuerte Ausnahme.

Eine gesteuerte Ausnahme sollte üblicherweise enthalten:

Eine Ausnahme ohne Enddatum kann unbemerkt zu einer dauerhaften alternativen Richtlinie werden.

Temporärer Zugriff benötigt einen expliziten Lifecycle – keine implizite Erinnerung.

Policy Owner, Data Owner und Custodian haben nicht dieselbe Aufgabe

Policy- und Access-Governance umfassen meist mehrere Verantwortlichkeiten.

In kleineren Organisationen kann eine Person mehrere Rollen übernehmen.

Entscheidend ist Klarheit:

• Wer definiert die Regel?
• Wer entscheidet über Zugriff?
• Wer setzt die Kontrolle technisch um?
• Wer prüft den fortbestehenden Bedarf?
• Wer löst Konflikte?
• Wer bestätigt die Wirksamkeit?

Fehlt diese Abgrenzung, kann ein Zugriffsproblem zwischen Teams weitergereicht werden, ohne einen klaren Verantwortlichen zu finden.

Business-freundliche Access Governance ist wichtig

Access Governance muss Daten schützen, ohne angemessenen Zugriff unnötig zu erschweren.

Ist der freigegebene Weg langsam, unklar oder zu technisch, suchen Nutzer möglicherweise alternative Wege:

• sie beantragen breitere Rollen als benötigt,
• bitten Kollegen um Datenexporte,
• erstellen lokale Kopien,
• teilen Zugangsdaten oder Dateien außerhalb des vorgesehenen Prozesses,
• nutzen alte Berechtigungen weiter, weil neue Zugriffe schwer zu erhalten sind.

Das rechtfertigt keine schwachen Kontrollen.

Es unterstützt ein Usability-Prinzip:

Der gesteuerte Weg sollte leichter verständlich sein als der Workaround.

Eine nützliche Zugriffsanforderung kann erklären:

• was das Datenprodukt enthält,
• welche Klassifizierung gilt,
• welche Nutzungen vorgesehen oder untersagt sind,
• welche Zugriffsstufen verfügbar sind,
• welcher Genehmigungsweg erwartet wird,
• wie lange die Bearbeitung voraussichtlich dauert,
• wer Owner und Ansprechpartner ist,
• ob Zugriff zeitlich begrenzt ist,
• was protokolliert oder überprüft wird.

Wo möglich, sollte Fachsprache vor technischen Rollennamen stehen.

Statt Nutzer zwischen kryptischen Gruppen wählen zu lassen, kann die Erfahrung mit dem Zweck beginnen:

Ich benötige aggregierten Kundenumsatz für die monatliche regionale Planung.

Das System kann diesen Zweck anschließend dem passenden Datenprodukt, der geeigneten Rolle und den erforderlichen Kontrollen zuordnen.

Policy-as-Code kann Konsistenz verbessern – ersetzt aber keine Governance

Policy-as-Code und Infrastructure-as-Code können Zugriffsregeln versionierbar, testbar, reviewbar und wiederholbar machen.

Das kann verbessern:

• Konsistenz zwischen Umgebungen,
• Peer Review,
• automatisierte Validierung,
• Deployment-Nachvollziehbarkeit,
• Rückbau,
• Drift-Erkennung,
• Nachweiserzeugung.

Policy-as-Code benötigt trotzdem Entscheidungen zu:

• Richtlinienabsicht,
• fachlicher Terminologie,
• Verantwortung,
• Ausnahmen,
• Risikoakzeptanz,
• Testszenarien,
• Review-Zyklen.

Eine technisch gültige Regel kann trotzdem die falsche fachliche Interpretation umsetzen.

Code verbessert die Disziplin der Ausführung.

Er ersetzt keine Verantwortung.

Effektiver Zugriff ist wichtiger als konfigurierte Berechtigung

In komplexen Umgebungen können Zugriffe vererbt werden über:

• verschachtelte Gruppen,
• Rollenhierarchien,
• direkte Grants,
• Objekt-Verantwortung,
• sekundäre Rollen,
• Workspace-Berechtigungen,
• Application Berechtigungs,
• gemeinsam genutzte Credentials,
• Service Principals,
• delegierte Administration,
• Data Partnerfreigaben.

Die konfigurierte Berechtigung ist nur ein Teil des Gesamtbilds.

Organisationen müssen auch den effektiven Zugriff verstehen:

Worauf kann diese Identität tatsächlich zugreifen, nachdem alle Grants, Vererbungen, Bedingungen, Filter und Ausnahmen ausgewertet wurden?

Das ist wichtig für:

• Access Reviews,
• Incident-Untersuchungen,
• Richtlinie-Validierung,
• Analyse von Funktionstrennung,
• Bewertung von Datenexposition,
• Audit-Nachweise.

Die Analyse effektiver Zugriffe sollte technische Identitäten ebenso einbeziehen wie Menschen.

Nachweise sollten im Prozess entstehen

Audit-Evidenz lässt sich leichter bereitstellen, wenn Nachvollziehbarkeit bereits im normalen Betrieb erfasst wird.

Nützliche Nachweise können umfassen:

• freigegebene Richtlinie-Version,
• Zuordnung zu Kontrollen,
• Zustand von Identität und Rolle,
• Zugriffsanforderung und fachliche Begründung,
• Genehmigungsentscheidung,
• Provisionierungsergebnis,
• Ergebnis der Richtlinie-Auswertung,
• Ausnahmegenehmigung,
• Review- und Rezertifizierungsentscheidung,
• Nutzung oder Monitoring-Evidenz,
• Bestätigung von Entzug oder Ablauf,
• Änderungshistorie.

Das Ziel ist nicht, jedes Ereignis unbegrenzt aufzubewahren.

Nachweise sollten Risiko, Richtlinie und regulatorischem Bedarf entsprechen.

Der stärkere Grundsatz lautet:

Eine Kontrolle ist leichter vertrauenswürdig, wenn sich ihr Entscheidungsweg rekonstruieren lässt.

Wirkung von Policy- und Access-Governance messen

Die Anzahl von Richtlinien oder Rollen zeigt noch nicht, ob Governance wirksam ist.

Mögliche Kennzahlen sind:

Kennzahlen benötigen Interpretation.

Eine hohe Ablehnungsquote ist nicht automatisch gute Governance.

Eine sehr niedrige Ablehnungsquote ist nicht automatisch schwache Governance.

Das Ergebnis ist entscheidend:

Erhalten die richtigen Identitäten den richtigen Zugriff für einen begründeten Zweck, für einen angemessenen Zeitraum, mit verständlichen Kontrollen und verlässlichen Nachweisen?

Häufige Anti-Patterns

Policy nur als Dokumentation

Die Richtlinie ist freigegeben und veröffentlicht, aber keine Zuordnung zeigt, welche technischen Kontrollen sie umsetzen.

Historisch angesammelte Berechtigungen

Nutzer behalten Rollen und Berechtigungen aus früheren Teams, Projekten und Verantwortungsbereichen.

Breite Rollen als Standardlösung

Eine große Rolle wird vergeben, weil dies schneller erscheint, als den minimal notwendigen Zugriff zu identifizieren.

Manuelle Genehmigung ohne nützlichen Kontext

Genehmiger sehen technische Gruppennamen, aber nicht Geschäftsgrund, Sensitivität, Dauer oder Risiko.

Review als Massenbestätigung

Hunderte Berechtigungen werden genehmigt, weil Reviewern Kontext oder Zeit fehlen.

Dauerhafter temporärer Zugriff

Notfall- oder Projektzugriff besitzt kein Ablaufdatum, keinen Owner und keine Abschlussprüfung.

Menschen werden gesteuert, Maschinen nicht

Service-Konten, Anwendungen und Automatisierungen behalten breite Zugriffe ohne vergleichbare Reviews.

Kontrolle nur auf einer Ebene

Das Warehouse ist geschützt, aber Exporte, semantische Modelle, Reports, APIs oder Downstream-Kopien eröffnen alternative Zugriffspfade.

Klassifizierung ohne Durchsetzung

Sensible Daten sind korrekt markiert, aber das Label beeinflusst weder Zugriff noch Maskierung, Monitoring oder Review.

Sicherheit ohne Nutzbarkeit

Der gesteuerte Zugriffsweg ist so langsam oder schwierig, dass Nutzer informelle Alternativen schaffen.

Tool Verantwortung ohne Policy Verantwortung

Das IAM- oder Plattformteam betreibt die Technologie, kann aber nicht die fachliche Bedeutung akzeptablen Zugriffs entscheiden.

Ein praktikables Operating Model

Ein möglicher Ansatz:

1. Policy-Absicht in Fachsprache definieren
   Zweck, Geltungsbereich, verbotene Nutzung, erwartete Kontrollen, Ausnahmeregeln und Review-Anforderungen festlegen.

2. Kritische Daten und Zugriffspfade identifizieren
   Klassifizierungen, Datenprodukte, semantische Modelle, Reports, Exporte, APIs und technische Konsumenten verbinden.

3. Verantwortliche Rollen zuweisen
   Policy Owner, Data Owner, Stewards, Genehmiger, IAM Owner, Custodian und Reviewer benennen.

4. Policy in Kontrollmuster übersetzen
   Definieren, wann RBAC, ABAC, Maskierung, Zeilenfilter, zeitlich begrenzter Zugriff, Genehmigung oder automatisierte Entscheidungen eingesetzt werden.

5. Verständliche Zugriffswege schaffen
   Nutzer über Geschäftszweck und Datenprodukt-Kontext anfordern lassen, nicht nur über technische Gruppen.

6. Standardzugriffe innerhalb von Leitplanken automatisieren
   Manuelle Arbeit für wiederkehrende, risikoarme Szenarien reduzieren und Nachvollziehbarkeit erhalten.

7. Ausnahmen explizit behandeln
   Begründung, Scope, Owner, kompensierende Kontrollen, Ablauf und Review verlangen.

8. Effektiven Zugriff und Nutzung überwachen
   Übermäßige, inaktive, verwaiste, auffällige und policy-inkonsistente Zugriffe erkennen.

9. Proportional überprüfen
   Menschliche Aufmerksamkeit auf sensible, privilegierte, ungewöhnliche oder wirkungsstarke Zugriffe konzentrieren.

10. Review-Ergebnisse umsetzen
    Sicherstellen, dass Ablehnung, Entzug, Reduzierung oder Ablauf im Zielsystem ankommen.

11. Nachweise von Anfang an mitdenken
    Entscheidungsweg und Kontrollergebnis bewahren, ohne später alles manuell rekonstruieren zu müssen.

12. Policy und Kontrollen gemeinsam verbessern
    Incidents, Feedback, Zugriffsmuster und Ausnahmen nutzen, um sowohl Absicht als auch Umsetzung weiterzuentwickeln.

Praktische Fragen für Teams

Für ein kritisches Datenprodukt, eine Richtlinie oder einen Zugriffspfad:

1. Welche freigegebene Richtlinie steuert diesen Zugriff?
2. Können wir die Policy-Anforderung bis zu der technischen Kontrolle verfolgen, die sie durchsetzt?
3. Sind Owner, Steward, Genehmiger und technischer Kontrollverantwortlicher klar benannt?
4. Verstehen Nutzer in Fachsprache, welchen Zugriff sie beantragen?
5. Ist der beantragte Umfang auf das Notwendige begrenzt?
6. Ist die Dauer angemessen und kann temporärer Zugriff automatisch auslaufen?
7. Sind Zeilen-, Spalten-, Maskierungs-, Export- und Downstream-Kontrollen aufeinander abgestimmt?
8. Erhalten technische Identitäten dieselbe Governance-Aufmerksamkeit wie menschliche Identitäten?
9. Sehen Reviewer Geschäftsgrund, Sensitivität, Nutzung und Risiko?
10. Sind Ausnahmen sichtbar, zeitlich begrenzt und überprüft?
11. Können wir effektiven Zugriff nach Vererbung und allen Policy-Bedingungen bestimmen?
12. Werden Review-Entscheidungen tatsächlich auf der Zielplattform umgesetzt?
13. Lässt sich der vollständige Entscheidungs- und Durchsetzungsweg für Audits rekonstruieren?
14. Wissen Nutzer, warum Zugriff gewährt, verweigert, maskiert oder entzogen wurde?
15. Ermöglicht der gesteuerte Prozess legitime Arbeit, ohne Workarounds zu fördern?

Diese Fragen verlangen nicht, dass jede Organisation dasselbe IAM-Produkt, dieselbe Policy Engine oder dasselbe Genehmigungsmodell verwendet.

Sie prüfen, ob dokumentierte Absicht mit operativer Realität verbunden bleibt.

Fazit

Policy- und Access-Governance sind keine fehlenden Technologien.

Moderne Identity-Plattformen, Datenplattformen und Security-Tools bieten bereits leistungsfähige Funktionen für Rollen, Attribute, Privilegien, Maskierung, Genehmigungen, Reviews, Monitoring und Nachweise.

Das mögliche fehlende Teil ist die Verbindung zwischen ihnen.

Eine Richtlinie setzt sich nicht selbst durch.

Eine Klassifizierung schützt nicht automatisch jede Downstream-Kopie.

Eine Rollenzuweisung beweist keinen fortbestehenden Geschäftsbedarf.

Ein Access Review erzeugt keinen Nutzen, wenn der Reviewer keinen Kontext besitzt oder das Ergebnis nie umgesetzt wird.

Eine technische Kontrolle belegt keine Policy-Wirksamkeit, solange Zweck, Verantwortung und Nachweise nicht verständlich sind.

Die operative Kette lautet:

Die zentrale Frage ist deshalb:

Ist die Richtlinie nur dokumentiert – oder wird sie konsistent umgesetzt?

Vielleicht bedeutet vertrauenswürdiger Zugriff nicht, dass alle dieselben Berechtigungen besitzen.

Vielleicht bedeutet er, dass sich Zugriff erklären lässt:

• wer oder was Zugriff besitzt,
• auf welche Daten,
• für welchen Zweck,
• unter welcher Richtlinie,
• mit welchen Einschränkungen,
• für welchen Zeitraum,
• von wem genehmigt,
• wann überprüft,
• und wann wieder entzogen.

Weiterführende Ressourcen

• NIST SP 800-207: Zero Trust Architecture
• Microsoft Learn: Was sind Microsoft Entra Access Reviews?
• Microsoft Learn: Bereitstellung von Microsoft Entra Access Reviews planen
• Microsoft Learn: Data Governance mit Microsoft Purview
• Microsoft Learn: Data-Governance-Rollen und -Berechtigungen in Microsoft Purview
• AWS Documentation: Security Best Practices in Zugriffsverwaltung
• AWS Documentation: Richtlinien and Permissions in Zugriffsverwaltung
• AWS Documentation: Lake Formation Tag-Based Access Kontrollregel
• Google Cloud Documentation: Zugriffsverwaltung sicher verwenden
• Google Cloud Documentation: Privileged Access Manager Overview
• Snowflake Documentation: Overview of Access Kontrollregel
• Snowflake Documentation: Access Kontrollregel Best Practices
• Databricks Documentation: Access Kontrollregel in Unity Catalog
• Databricks Documentation: Unity Catalog Permissions Model Concepts

Daten zu erstellen ist einfach. Sie stillzulegen ist eine Entscheidung.

Ein Kundenstammsatz liegt im CRM, im Mart, in drei Excel-Exports und in einem Test-Refresh. Niemand darf löschen, weil niemand den Scope kennt. Speichern ist leicht; Stilllegen ist eine Entscheidung mit Abhängigkeiten.

Ein einzelner operativer Datensatz kann später vorkommen in:

• einer Quellanwendung,
• einer Landing- oder RAW-Schicht,
• einer standardisierten oder konformierten Schicht,
• einem oder mehreren Data Marts,
• einem semantischen Modell,
• Reports und Dashboards,
• Extrakten und Anwendungscaches,
• Excel-Dateien,
• Entwicklungs- und Testumgebungen,
• Backups, Snapshots und Replikaten.

Viele dieser Repräsentationen sind sinnvoll.

Sie können Historisierung, Reproduzierbarkeit, Performance, Isolation, Wiederherstellung, regulatorische Anforderungen und unterschiedliche fachliche Zwecke unterstützen.

Die offene Governance-Frage lautet deshalb nicht:

Warum haben wir Kopien?

Sondern:

Bleiben Zweck, Verantwortung, Klassifizierung und Lifecycle-Absicht mit jeder relevanten Repräsentation der Daten verbunden?

Günstiger Speicher beseitigt nicht die Notwendigkeit zu verstehen, warum Daten aufbewahrt werden.

Automatisierung entscheidet nicht, ob ein Datensatz weiterhin Wert erzeugt.

Eine Aufbewahrungsfrist beweist nicht, dass alle Downstream-Kopien abgedeckt sind.

Ein Löschbefehl bedeutet nicht zwangsläufig, dass jede wiederherstellbare oder abgeleitete Repräsentation verschwunden ist.

Lifecycle Governance beginnt, wenn die Erzeugung von Daten als Beginn einer Verantwortung betrachtet wird – nicht als Ende einer Bereitstellungsaufgabe.

Lifecycle Governance ist mehr als Aufbewahrung

Aufbewahrung ist nur ein Teil des Lebenszyklus.

Ein vollständiges Lifecycle-Modell berücksichtigt auch, warum Daten entstehen, wie sie geschützt werden, wer sie nutzt, wie sich ihr Wert verändert und was geschehen soll, wenn der ursprüngliche Zweck endet.

Der Lebenszyklus ist nicht nur ein Speicherthema.

Er verbindet:

• fachlichen Zweck,
• Data Verantwortung,
• Datenschutz und rechtliche Verpflichtungen,
• Architektur und Lineage,
• Sicherheitskontrollen,
• Datenqualität,
• Records Management,
• Kosten und Nachhaltigkeit,
• operative Resilienz,
• Nachweise und Auditierbarkeit.

Eine technisch korrekte Speicherregel kann trotzdem unvollständig sein, wenn sie den fachlichen Zweck oder Downstream-Abhängigkeiten nicht berücksichtigt.

Ein gut dokumentierter Aufbewahrungsplan kann trotzdem unwirksam sein, wenn er nicht in Plattformverhalten übersetzt wird.

Lifecycle Governance verbindet den Grund, warum Daten existieren, mit der Frage, wie lange ihre Aufbewahrung nützlich, erforderlich und begründbar bleibt.

Der Lebenszyklus ist selten eine einfache gerade Linie

Daten bewegen sich nicht nur einmal von der Erzeugung bis zur Löschung.

Sie werden kopiert, transformiert, aggregiert, angereichert und wiederverwendet.

Ein Kundendatensatz kann sich entwickeln zu:

Der Lebenszyklus jeder Repräsentation kann unterschiedlich sein.

Das RAW-Event kann für Audit und Replay benötigt werden.

Die konformierte Tabelle kann aktiv von mehreren Data Products genutzt werden.

Das Dashboard kann durch eine neue Version ersetzt worden sein.

Der Excel-Export kann zu einer unkontrollierten lokalen Kopie geworden sein.

Die aggregierte Kennzahl enthält möglicherweise keine personenbezogenen Daten mehr.

Das Modell-Feature kann eine eigene Aufbewahrungsdauer für Reproduzierbarkeit benötigen.

Ein einzelner Retention-Wert an der Quelle beantwortet deshalb nicht automatisch jede Downstream-Frage.

Das stärkere Modell verbindet Lifecycle-Entscheidungen mit:

• Datentyp,
• Zweck,
• Sensitivität,
• rechtlicher oder vertraglicher Verpflichtung,
• geschäftlichem Wert,
• Nutzung,
• Lineage,
• Abhängigkeit,
• Umgebung,
• Speichertechnologie,
• Wiederherstellungsanforderungen,
• Verantwortung.

Aufbewahrung, Archivierung, Stilllegung und Löschung sind unterschiedliche Entscheidungen

Diese Begriffe werden häufig gemeinsam verwendet, beschreiben aber unterschiedliche Maßnahmen.

Ein Report kann stillgelegt werden, ohne seine zugrunde liegenden Daten zu löschen.

Eine Tabelle kann gelöscht werden, während Backup-Kopien einem anderen Lifecycle unterliegen.

Ein Datensatz kann archiviert sein und trotzdem Zugriffskontrollen und Verantwortung benötigen.

Ein Quellsystem kann abgeschaltet werden, während historische Unterlagen weiter aufbewahrt werden.

Die Unterscheidung ist wichtig, weil unterschiedliche Personen für die Entscheidungen verantwortlich sein können.

Die Entscheidung folgt Zweck, Verpflichtung, Wert und Risiko

Es gibt keine universelle Aufbewahrungsfrist für alle Daten.

Angemessene Fristen hängen unter anderem ab von:

• anwendbarem Recht und Regulierung,
• vertraglichen Verpflichtungen,
• gesetzlichen oder finanziellen Aufbewahrungspflichten,
• Rechtsstreitigkeiten und Legal Holds,
• Anforderungen an operative Wiederherstellung,
• Produkt- und Kundenverpflichtungen,
• Forschungs- oder historischem Wert,
• Sicherheits- und Datenschutzrisiko,
• fachlichem Zweck,
• Datensensitivität,
• erwarteter Wiederverwendung,
• technischen Abhängigkeiten,
• Kosten und Umweltwirkung.

Für personenbezogene Daten sind Zweckbindung, Datenminimierung und Speicherbegrenzung besonders relevant.

Daten sollten nicht unbegrenzt aufbewahrt werden, nur weil sie irgendwann nützlich sein könnten.

Gleichzeitig kann eine zu frühe Löschung rechtliche, operative oder beweisbezogene Risiken erzeugen.

Das Ziel ist nicht maximale Löschung.

Das Ziel ist begründete Aufbewahrung.

Die richtigen Daten – für die richtige Zeit – aus einem klaren Grund aufbewahren und die Entscheidung erklären können.

Eine Richtlinie erreicht selten automatisch jede Kopie

Nehmen wir Kundenkontaktdaten.

Die ursprüngliche Richtlinie kann definieren:

• freigegebene Zwecke,
• Sensitivität,
• Zugriffsbeschränkungen,
• Aufbewahrungsdauer,
• Löschanforderungen.

Dieselben Informationen können später jedoch vorkommen in:

• CRM-Datensätzen,
• Change-Data-Capture-Streams,
• RAW-Dateien im Data Lake,
• Warehouse-Tabellen,
• dbt-Modellen,
• semantischen Modellen,
• BI-Extrakten,
• Report-Caches,
• Excel-Exporten,
• Anwendungsdatenbanken,
• Support-Tickets,
• Testumgebungen,
• Backups und Snapshots.

Eine Lifecycle-Richtlinie ist nur so vollständig wie ihr Scope.

Wichtige Fragen sind:

• Welche Repräsentationen sind maßgeblich?
• Welche sind temporär?
• Welche sind abgeleitet?
• Welche enthalten dieselben personenbezogenen oder vertraulichen Informationen?
• Welche besitzen einen eigenen geschäftlichen oder rechtlichen Wert?
• Welche werden durch automatische Lifecycle-Regeln abgedeckt?
• Welche benötigen einen anwendungsspezifischen Löschprozess?
• Welche sind durch einen Legal Hold geschützt?
• Welche Kopien bleiben nach einer Löschung wiederherstellbar?
• Welche Downstream-Produkte müssen aktualisiert oder neu aufgebaut werden?

Hier werden Metadaten und Lineage zu Lifecycle-Kontrollen.

Technische Lineage kann Abhängigkeiten identifizieren.

Fachlicher Kontext erklärt, ob die Abhängigkeit noch relevant ist.

Verantwortung zeigt, wer eine Änderung freigeben kann.

Policy definiert, was geschehen muss.

Monitoring prüft, ob es tatsächlich geschehen ist.

Stilllegung ist ein Impact-Management-Prozess

Ein ungenutztes Objekt zu löschen kann einfach sein.

Ein etabliertes Datenasset stillzulegen kann ein Change-Management-Prozess sein.

Eine Tabelle, ein Modell, eine API, ein Report oder ein Data Product kann Konsumenten besitzen, die aus reiner Speichernutzung nicht sichtbar werden.

Ein praktikabler Stilllegungs-Lifecycle kann folgende Schritte enthalten:

1. Kandidaten identifizieren
   Geringe Nutzung, Duplikation, Ersatz, veralteter Zweck, nicht mehr unterstützte Technologie, abgelaufene Aufbewahrung oder übermäßiges Risiko können eine Prüfung auslösen.

2. Verantwortung bestätigen
   Business Owner, Steward und Custodian für die Entscheidung identifizieren.

3. Wert und Verpflichtung bewerten
   Prüfen, ob das Asset weiterhin einen fachlichen Zweck, eine rechtliche Anforderung, einen Recovery-Bedarf oder einen historischen Nachweis unterstützt.

4. Lineage und Abhängigkeiten analysieren
   Pipelines, Reports, Anwendungen, Modelle, Exporte und Nutzer identifizieren, die vom Asset abhängen.

5. Nutzung prüfen
   Query-Aktivität, Report-Nutzung, API-Aufrufe und Stakeholder-Feedback verbinden. Nicht beobachtete Nutzung ist ein Hinweis – aber kein automatischer Beweis für Wertlosigkeit.

6. Holds und Ausnahmen prüfen
   Sicherstellen, dass Legal Holds, Untersuchungen, Verträge oder genehmigte Ausnahmen die Stilllegung nicht verhindern.

7. Maßnahme auswählen
   Behalten, optimieren, archivieren, anonymisieren, konsolidieren, deprecaten, stilllegen oder löschen.

8. Kommunizieren und migrieren
   Konsumenten informieren, bei Bedarf Ersatz bereitstellen und einen Übergangszeitraum definieren.

9. Vor dem Entfernen deprecaten
   Das Asset kennzeichnen, neue Nutzung stoppen und die geplante Stilllegung sichtbar machen.

10. Technische Änderung umsetzen
    Pipelines deaktivieren, Zugriffe entziehen, Schedules entfernen, Daten archivieren, Objekte löschen und Dokumentation aktualisieren.

11. Ergebnis verifizieren
    Bestätigen, dass Abhängigkeiten gelöst, erwartete Löschungen erfolgt und notwendige Nachweise vorhanden sind.

12. Lernen und verbessern
    Das Ergebnis nutzen, um Lifecycle-Regeln, Metadaten, Verantwortung und Stilllegungsmuster zu verbessern.

Der Prozess sollte verhältnismäßig sein.

Eine temporäre Staging-Tabelle benötigt nicht dieselbe Sorgfalt wie ein reguliertes Data Product für das Management-Reporting.

Löschung kann in modernen Plattformen mehrere technische Zustände besitzen

„Gelöscht“ ist nicht immer ein einzelner Zustand.

Abhängig von Plattform und Konfiguration können Daten zeitweise wiederherstellbar bleiben durch:

• Soft Delete,
• Versionshistorie,
• Time Travel,
• Snapshots,
• Transaktionslogs,
• Replikation,
• Disaster-Recovery-Kopien,
• Objektversionierung,
• Backup-Aufbewahrung,
• Fail-safe- oder Recovery-Zeiträume.

Das bedeutet nicht, dass die Plattform falsch arbeitet.

Recovery-Funktionen sind wertvoll.

Sie schützen vor versehentlicher Löschung, Korruption und operativen Ausfällen.

Die Governance-Anforderung besteht darin, die Zustände zu verstehen.

Für jede Plattform sollte bekannt sein:

• wann Daten aus normalen Abfragen verschwinden,
• ob sie wiederherstellbar bleiben,
• wer sie wiederherstellen kann,
• wie lange Recovery möglich ist,
• ob Lifecycle-Regeln auch auf Versionen wirken,
• wann physische Dateien entfernt werden,
• wie Backups behandelt werden,
• ob Löschung an Replikate propagiert wird,
• welcher Nachweis den Abschluss bestätigt.

Beispielsweise können Tabellenlöschung, Entfernung nicht mehr referenzierter Dateien und Ablauf historischer Versionen getrennte Vorgänge sein.

Ebenso kann die Löschung eines aktiven Cloud-Objekts mit Soft-Delete-Zeiträumen, Objektversionen oder Retention Locks interagieren.

Die relevante Definition von Löschung muss deshalb explizit sein.

Eine Lifecycle-Kontrolle sollte nicht nur die beabsichtigte Aktion beschreiben, sondern auch den technischen Endzustand, der den Abschluss belegt.

Auch abgeleitete Daten benötigen Lifecycle Governance

Lifecycle-Programme konzentrieren sich häufig auf Quelldatensätze und Storage Buckets.

Geschäftlicher Wert entsteht jedoch oft in abgeleiteten Assets:

• transformierten Tabellen,
• konformierten Dimensionen,
• aggregierten Fakten,
• Features,
• Kennzahlen,
• semantischen Modellen,
• Reports,
• Exporten,
• Notebooks,
• Trainingsdatensätzen,
• Modellergebnissen.

Abgeleitete Daten können ein anderes Risikoprofil als ihre Quelle besitzen.

Aggregation kann Sensitivität reduzieren.

Das Verknüpfen von Datensätzen kann Sensitivität erhöhen.

Ein Report kann Daten sichtbar machen, die im Warehouse maskiert sind.

Ein Trainingsdatensatz kann Werte bewahren, die sich in der Quelle inzwischen verändert haben.

Ein lokaler Export kann bestehen bleiben, nachdem der zentrale Datensatz stillgelegt wurde.

Wichtige Fragen sind:

• Enthält das abgeleitete Asset weiterhin regulierte oder vertrauliche Informationen?
• Können Personen oder Geschäftsvorgänge rekonstruiert werden?
• Erfordert Löschung an der Quelle eine Downstream-Aktualisierung oder Neuverarbeitung?
• Besitzt das abgeleitete Asset eine eigenständige Aufbewahrungspflicht?
• Wer verantwortet den Lifecycle der Kennzahl, des Modells oder Reports?
• Ist das Asset weiterhin zertifiziert oder unterstützt?
• Kann das Asset stillgelegt werden, ohne seine Quelldaten zu löschen?

Lifecycle Governance sollte Bedeutung und Risiko folgen – nicht nur physischem Speicher.

Aufbewahrungsregeln sollten ausführbar und erklärbar sein

Ein Aufbewahrungsplan beginnt häufig als Policy-Tabelle.

Zum Beispiel:

Die Richtlinie wird operativ, wenn die benötigten Metadaten verfügbar und mit technischer Ausführung verbunden sind.

Nützliche Metadaten können sein:

• Retention-Klasse,
• Retention-Trigger,
• Aufbewahren-bis-Datum,
• Review-Datum,
• Legal-Hold-Status,
• Löschmaßnahme,
• Archivspeicherklasse,
• verantwortliche Person,
• Steward,
• System of Record,
• geografischer oder vertraglicher Umfang,
• Sensitivität,
• Downstream-Abhängigkeiten,
• Löschbestätigung,
• Ausnahmestatus.

Automatisierung kann dann unterstützen bei:

• Wechseln von Speicherklassen,
• Ablaufbenachrichtigungen,
• Review-Workflows,
• Löschjobs,
• Deprecation-Warnungen,
• Entzug von Zugriffen,
• Nachweiserfassung,
• Eskalation von Ausnahmen.

Automatisierung sollte notwendige Beurteilung nicht entfernen.

Sie sollte manuelle Wiederholung reduzieren, nachdem das Entscheidungsmodell klar definiert wurde.

Relevante Lifecycle-Kennzahlen

Gespeicherte Terabytes allein zeigen nicht, ob Lifecycle Governance funktioniert.

Mögliche Kennzahlen sind:

Kennzahlen benötigen Interpretation.

Geringe Nutzung bedeutet nicht automatisch geringen Wert.

Alte Daten sind nicht automatisch wertlos.

Ein hohes Löschvolumen ist nicht automatisch gute Governance.

Das Ziel ist ein begründeter, kontrollierter und erklärbarer Lebenszyklus.

Hinweis: Die im Schaubild verwendeten Aufbewahrungsfristen sind ausschließlich Beispiele. Sie sind keine allgemeingültigen rechtlichen Empfehlungen. Tatsächliche Fristen müssen aus anwendbarem Recht, Regulierung, Verträgen, Zweck, Risiko und freigegebener Unternehmensrichtlinie abgeleitet werden.

Häufige Anti-Patterns

Alles „für alle Fälle“ aufbewahren

Daten bleiben ohne aktuellen Zweck, Owner, Review-Datum oder objektive Begründung erhalten.

Retention existiert nur in einer Tabelle

Ein Aufbewahrungsplan ist freigegeben, aber nicht mit Assets, Plattformen, Triggern oder Lösch-Workflows verbunden.

Eine Frist für alle Daten

Unterschiedliche Zwecke, Sensitivitäten und Verpflichtungen werden in eine einzige Standardfrist gezwungen.

Nur die Primärtabelle löschen

Backups, Versionen, Replikate, Exporte, Reports und Downstream-Ableitungen liegen außerhalb des Lösch-Scopes.

Archivieren ohne Verantwortung

Daten wandern in eine günstigere Speicherklasse, aber niemand bleibt für Zugriff, Qualität, Legal Holds oder spätere Löschung verantwortlich.

Dauerhafter Legal Hold

Ein Hold wird korrekt gesetzt, aber nach Ende des Grundes nie überprüft oder aufgehoben.

Stilllegung ohne Abhängigkeitsanalyse

Eine Tabelle oder API wird entfernt, bevor Konsumenten, Reports oder Anwendungen migriert wurden.

„Keine Queries“ bedeutet „kein Wert“

Technische Telemetrie wird als einziger Nachweis genutzt und rechtliche, saisonale, Recovery- oder seltene fachliche Bedürfnisse werden ignoriert.

Deprecation ohne Termin

Ein altes Asset wird als veraltet gekennzeichnet, bleibt aber unbegrenzt verfügbar und kann neue Abhängigkeiten erzeugen.

Lifecycle nur für personenbezogene Daten

Vertrauliche, finanzielle, operative, vertragliche und technisch sensible Daten erhalten keine vergleichbare Lifecycle-Aufmerksamkeit.

Lifecycle nur für Storage

Tabellen werden gesteuert, Kennzahlen, Reports, Notebooks, Exporte, Features und Modelle bleiben jedoch unberücksichtigt.

Kosten als einziges Ziel

Speicherkosten werden optimiert, ohne Nachweise, Wiederherstellbarkeit, Geschäftswert, Risiko oder Compliance zu berücksichtigen.

Löschung ohne Nachweis

Jobs laufen, aber kein Nachweis bestätigt Scope, Ergebnis, Ausnahmen oder wiederherstellbare Zustände.

Ein praktikables Lifecycle Operating Model

Ein möglicher Ansatz:

1. Lifecycle-Klassen in Fachsprache definieren
   Zweck, Sensitivität, Trigger, Aufbewahrungslogik, Archivverhalten, Löschmaßnahme und Ausnahmen beschreiben.

2. Klassen mit Datenassets verbinden
   Lifecycle-Kontext auf Quellen, Tabellen, Data Products, Reports, Dateien, Modelle und wichtige Ableitungen anwenden.

3. Verantwortliche Rollen zuweisen
   Business Owner, Steward, Custodian, Records- oder Legal-Kontakt und Kontrollverantwortliche benennen.

4. Lifecycle-Trigger erfassen
   Beispiele sind Erstellungsdatum, Vertragsende, Fallabschluss, Austritt eines Mitarbeitenden, Projektende oder Zertifizierung eines Ersatzes.

5. Abhängigkeiten und Kopien abbilden
   Lineage, Katalogmetadaten, Plattforminventar und Wissen der Stakeholder verbinden.

6. Vorhersehbare Maßnahmen automatisieren
   Speicherklassen wechseln, Review-Aufgaben erzeugen, temporäre Daten auslaufen lassen, Assets deprecaten und freigegebene Löschmuster ausführen.

7. Holds und Ausnahmen schützen
   Normale Löschung verhindern und gleichzeitig Owner, Grund, Scope und Review-Datum bewahren.

8. Nutzung, Alter und Policy-Status überwachen
   Inaktive, alte, unbesitzte, doppelte, abgelaufene und richtlinienwidrige Assets erkennen.

9. Verhältnismäßig prüfen
   Menschliche Bewertung auf hochwertige, sensible, regulierte, breit genutzte oder unklare Assets konzentrieren.

10. Stilllegung als kontrollierten Change-Prozess durchführen
    Ankündigen, deprecaten, migrieren, deaktivieren und entfernen – mit angemessener Validierung.

11. Technischen Abschluss verifizieren
    Soft Delete, Versionshistorie, Backups, Replikation und physische Entfernung verstehen.

12. Angemessene Nachweise erhalten
    Policy, Entscheidung, Owner, Maßnahme, Ergebnis und Ausnahmen dokumentieren, ohne unnötige neue Aufbewahrung zu erzeugen.

13. Die Richtlinie selbst überprüfen
    Regulierung, Produkte, Architekturen und Geschäftsmodelle verändern sich. Lifecycle-Regeln müssen sich mit ihnen verändern.

Praktische Fragen für Teams

Für einen wichtigen Datensatz, ein Data Product, einen Report oder eine Plattform:

1. Warum wurden diese Daten erfasst oder erstellt?
2. Ist dieser Zweck noch aktiv und dokumentiert?
3. Wer verantwortet die Lifecycle-Entscheidung?
4. Welche Klassifizierung und Retention-Regel gelten?
5. Welches Ereignis startet die Aufbewahrungsfrist?
6. Besteht eine rechtliche, regulatorische, vertragliche oder geschäftliche Pflicht zur Aufbewahrung?
7. Welche Quell-, Ableitungs-, Export-, Replikat- und Backup-Kopien existieren?
8. Welche Downstream-Assets und Nutzer hängen davon ab?
9. Wie häufig werden die Daten genutzt und ist die Nutzungstelemetrie vollständig?
10. Kann Archivierung den Bedarf mit weniger Zugriff, Kosten oder Risiko erfüllen?
11. Können Daten aggregiert oder anonymisiert werden, statt sie identifizierbar aufzubewahren?
12. Sind Legal Holds und Ausnahmen sichtbar, verantwortet und überprüft?
13. Was bedeutet „gelöscht“ auf jeder Plattform?
14. Wie lange können gelöschte Daten noch wiederhergestellt werden?
15. Propagiert Löschung an Replikate, Versionen, Backups und Downstream-Produkte?
16. Wie werden Konsumenten vor einer Stilllegung informiert?
17. Ist bei Bedarf ein Ersatz verfügbar und zertifiziert?
18. Welcher Nachweis bestätigt den erfolgreichen Abschluss der Stilllegung oder Löschung?
19. Wann wird die Lifecycle-Regel selbst überprüft?
20. Bewahren wir die richtigen Daten – für die richtige Zeit – aus den richtigen Gründen auf?

Diese Fragen verlangen kein universelles Lifecycle-Tool.

Sie prüfen, ob Zweck, Policy und operative Realität verbunden bleiben.

Fazit

Data Lifecycle Governance ist nicht primär eine Übung zur Optimierung von Speicherkosten.

Sie ist die Disziplin, Daten während ihrer gesamten Existenz nützlich, geschützt, verständlich und begründbar zu halten.

Moderne Plattformen bieten bereits leistungsfähige Funktionen für:

• Lifecycle-Regeln,
• Wechsel von Speicherklassen,
• Retention Labels,
• Archivierung,
• Versionshistorie,
• Wiederherstellung,
• Löschung,
• Audit und Monitoring.

Das möglicherweise fehlende Teil ist das End-to-End Operating Model.

Daten lassen sich leicht erzeugen.

Kopien lassen sich leicht erstellen.

Neue Modelle und Reports lassen sich leicht veröffentlichen.

Stilllegung benötigt eine Entscheidung.

Löschung benötigt Sicherheit.

Diese Sicherheit benötigt Kontext:

• Zweck,
• Verantwortung,
• Richtlinie,
• Lineage,
• Abhängigkeiten,
• rechtliche Verpflichtungen,
• technische Zustände,
• Nachweise.

Die Lifecycle-Kette lautet:

Phase A — unter Zweck nutzen

Phase B — aufbewahren, stilllegen, nachweisen

Die zentrale Frage lautet deshalb:

Bewahren wir die richtigen Daten – für die richtige Zeit – aus den richtigen Gründen auf?

The Missing Pieces – was die Serie verbindet

Dieser letzte Teil schließt eine Kette über das vollständige Data-Governance-Operating-Model:

1. Data Quality
   Probleme erkennen, Auswirkungen begrenzen und den Kreislauf zurück zur Ursache schließen.

2. Trusted Metrics
   Fachliche Definitionen über technische und analytische Ebenen verständlich und konsistent halten.

3. Verantwortung & Stewardship
   Zugewiesene Rollen in handlungsfähige Verantwortung, Entscheidungswege und messbare Ergebnisse verwandeln.

4. Metadata, Catalog & Lineage
   Technische Sichtbarkeit mit fachlicher Bedeutung und nutzbarem Kontext verbinden.

5. Policy & Access Governance
   Dokumentierte Absicht in gesteuerte Identitäten, operative Kontrollen, Reviews und Nachweise übersetzen.

6. Data Lifecycle & Retirement
   Nicht nur steuern, wie Daten entstehen und genutzt werden, sondern auch, warum sie aufbewahrt, wann sie stillgelegt und wie Endzustände verifiziert werden.

Das gemeinsame Thema ist nicht, dass moderne Governance-Plattformen keine Fähigkeiten besitzen.

Wert entsteht, wenn diese Fähigkeiten in einem verständlichen Operating Model verbunden werden.

Governance ist am stärksten, wenn Menschen Daten verstehen, Verantwortung wahrnehmen, Regeln vertrauen und den vollständigen Lebenszyklus von der Quelle bis zur Entscheidung – und schließlich bis zur Stilllegung – nachvollziehen können.

Weiterführende Ressourcen

• NIST Research Data Framework (RDaF)
• NIST SP 1500-18r2: NIST Research Data Framework
• EUR-Lex: Verordnung (EU) 2016/679 – Datenschutz-Grundverordnung
• Microsoft Learn: Informationen zur Datenlebenszyklusverwaltung in Microsoft Purview
• Microsoft Learn: Aufbewahrungsrichtlinien und Aufbewahrungsbezeichnungen
• AWS Well-Architected Analytics Lens: Implement data retention processes
• AWS Dokumentation: Managing the lifecycle of Amazon S3 objects
• AWS Well-Architected Security Pillar: Define scalable data lifecycle management
• Google Cloud Dokumentation: Options for controlling data lifecycles
• Google Cloud Dokumentation: Object Lifecycle Management
• Databricks Dokumentation: Remove unused data files with VACUUM
• Databricks Dokumentation: Work with table history