Metadaten ist nicht der Katalog

Metadaten umfassen Definitionen, technische Struktur, Datenherkunft, Qualität, Richtlinienstatus und den Ursprung einer Information. Der Datenkatalog indexiert und verbindet diese Inhalte für die Suche. Katalog und Metadaten sind nicht dasselbe: Eine ansprechend gestaltete Katalogseite kann inhaltlich leer sein; gute Metadaten können umgekehrt vorhanden, aber schlecht auffindbar sein.

Entscheidung

Behandle wichtige Metadaten als versionierte Einträge mit Quelle, verantwortlicher Rolle, Zeitstempel und Status. Der Katalog zeigt diese Einträge, ist aber nicht automatisch ihre maßgebliche Quelle.

Ein gepflegter Katalogeintrag wirkt schnell verbindlich. Seine Informationen können jedoch aus einem technischen Scanner, einem alten Freitextfeld, einem Glossar oder einer formalen Freigabe stammen. Deshalb muss jeder wichtige Metadateneintrag mit Quelle, verantwortlicher Rolle, Status und Prüfdatum nachvollziehbar sein. Der Katalog darf diese Informationen gut auffindbar machen, ersetzt aber nicht die fachliche oder regulatorische Entscheidung dahinter.

Diese Trennung verhindert zwei gegensätzliche Fehler. Beim ersten wird jede Information im Katalog manuell zur „Wahrheit“ erklärt, obwohl ihr Ursprung unbekannt ist. Beim zweiten gilt automatisch ingestierte Information als verlässlich, obwohl sie fachlich leer oder veraltet ist. Ein Katalog kann Inhalte ausgezeichnet präsentieren; die Kontrollqualität entsteht jedoch durch Herkunft, Verantwortlichkeit und einen geregelten Lebenszyklus.

Metadatenklassen und ihre Autorität

Technische Metadaten wie Spaltenname, Datentyp oder Job-Laufzeit stammt meist aus Quellsystemen und Orchestrierung. Operative Metadaten wie Nutzung, Aktualität oder Incident-Status entsteht in Plattformdiensten. Fachliche Metadaten wie Definition, Kritikalität und Owner braucht eine autorisierte Rolle. Governance-Metadaten wie Klassifikation, Rechtsgrundlage, Retention oder Freigabestatus folgt kontrollierten Prozessen.

Die Klassen dürfen im Katalog gemeinsam erscheinen, brauchen aber nicht dasselbe führendes System. Ein Schema-Scanner ist für den aktuellen Datentyp stärker als ein manuelles Textfeld. Ein genehmigter Glossar-Record ist für die fachliche Definition stärker als eine automatisch erzeugte Beschreibung. Die Matrix der führenden Systeme macht diese Priorität explizit und legt fest, was bei Konflikten geschieht.

Jeder kritische Record sollte mindestens Datenobjekt-ID, Metadatenklasse, Wert, Quellsystem, Quell-ID, Owner, Erfassungszeit, Gültigkeitsstatus und letzte Prüfung enthalten. Für fachliche Aussagen kommen Freigabe, Version und Gültigkeitszeitraum hinzu. Der Katalog darf diese Felder anders darstellen, sollte ihre Provenienz aber nicht abschneiden.

Praxisbeispiel: Kunden-E-Mail und Retention

Im Warehouse existiert customer.email. Der Scanner erkennt Typ und technische Lineage. Ein Klassifikator schlägt „personenbezogen“ vor. Privacy bestätigt die Klassifikation und verknüpft Rechtsgrundlage sowie Aufbewahrungsregel. Das Quality-System liefert einen Nullraten-Test. Der Katalog zeigt alles in einer Seite des Datenobjekts.

Nach einer Migration heißt die Spalte gleich, enthält aber gehashte Werte. Der Scanner aktualisiert Typ und Lineage; die bestätigte Klassifikation bleibt zunächst bestehen. Ein Aktualität-Signal meldet den Widerspruch an den Privacy Steward. Dieser prüft, ob das Feld weiterhin personenbezogen ist, versioniert die Entscheidung und aktualisiert die Retention-Regel. Der Katalog zeigt anschließend den neuen Status. Würde man die Katalog-Seite selbst als Wahrheit behandeln, wären Änderung, Prüfer und zeitliche Gültigkeit kaum rekonstruierbar.

Dasselbe Prinzip gilt für Business-Begriffe. „Aktiver Kunde“ kann im Glossar freigegeben sein, während eine Kennzahl-Definition die ausführbare Berechnung hält. Der Katalog verbindet beide Records, ersetzt aber weder Freigabe noch Berechnung.

Vorgehen

1. Umfang nach Risiko wählen. Nimm zehn bis zwanzig kritische Datenobjekte und die Metadatenklassen, die Entscheidungen oder Kontrollen beeinflussen.
2. führendes System festlegen. Dokumentiere je Klasse führende Quelle, Owner, Aktualisierungsmodus und Konfliktregel.
3. Übernahmewege kartieren. Trenne automatischen Metadatenimport, technische Ableitung, manuelle Pflege und formale Freigabe. Ein KI-Vorschlag ist noch kein genehmigter Eintrag.
4. Identitäten normalisieren. Nutze stabile Datenobjekt- und Record-IDs; Namen allein überstehen Umbenennungen und Migrationen nicht.
5. Aktualität definieren. Setze je Klasse erwartete Aktualität, Toleranzfrist und Eskalation. Schema kann stündlich, Verantwortung vierteljährlich geprüft werden.
6. Projektion testen. Vergleiche Katalog-Ansicht mit Quellrecord, inklusive Status, Zeitstempel und Links.
7. Konflikte proben. Ändere testweise Quelle, Owner oder Klassifikation und beobachte Erkennung, Triage und Korrektur.

Angemessener Umfang

Kleine Unternehmen: Eine Übersicht der führenden Systeme für drei Klassen, zehn kritische Datenobjekte und eine regelmäßige Prüfung der Verantwortung reichen als Start. Ein Katalog kann ein leichtes Portal oder eine Suchseite sein. Entscheidend sind stabile Links und sichtbare Zeitstempel.

Mid-market: Lege eine Matrix pro Domäne an, betreibe automatisierten Metadatenimport und ein Steward-Backlog. Gemeinsame Mindestfelder und ein zweiwöchentliches Konfliktforum verhindern lokale Sondermodelle. Priorisiere kritische Datenprodukte statt Vollständigkeit über alle Tabellen.

Enterprise: Nutze maschinenlesbare Record-Verträge, domänenübergreifende Identitäten und abgestufte Vorgaben zur Aktualität. Kritische fachliche und Compliance-Metadaten brauchen Genehmigungsworkflow, Historie und unabhängige Stichproben. Plattformteams betreiben Transport und Normalisierung; Domänen verantworten Bedeutung.

Übergaben

Der Source Owner garantiert nicht die Oberfläche, sondern Inhalt und Änderungsereignis. Die Plattform bewahrt Provenienz, transformiert Formate und meldet Fehler. Der Katalog Steward prüft Auffindbarkeit und Konflikte. Fachliche Stewards entscheiden konkurrierende Definitionen; Privacy oder Security genehmigen kontrollrelevante Klassifikationen. Ein Ticket braucht Record-ID, beobachteten und erwarteten Wert, Materialität, Zeitstempel und Fälligkeit.

Anti-Patterns

Katalog-Felder ohne Provenienz manuell füllen; Suchtreffer mit kontrollierter Wahrheit gleichsetzen; erfolgreichen Metadatenimport statt inhaltlicher Qualität messen.

Last writer wins: Ein später Import überschreibt eine genehmigte Definition. Verhindere das mit Prioritäten je Metadatenklasse und getrennten Statusfeldern.

Owner als Freitext: Teamnamen altern, sind nicht eindeutig und erlauben keinen Workflow. Verwende referenzierte Rollen oder Gruppen mit Prüfdatum.

Aktualität für alles gleich: Ein stündliches SLA für Glossartexte erzeugt Lärm; ein quartalsweises SLA für Job-Status ist nutzlos. Leite Takt und Eskalation aus Nutzung und Risiko ab.

KI-Text ohne Status: Automatisch erzeugte Beschreibungen wirken autoritativ. Kennzeichne Quelle, Konfidenz und Prüfung-Status sichtbar.

Löschen statt historisieren: Überschriebene Records zerstören Auditierbarkeit. Bewahre bei materiellen Aussagen Version, Gültigkeit und Entscheidung.

Kontrollcheckliste

• Ist für jede kritische Metadatenklasse ein führendes System benannt?
• Bleiben Quell-ID, Zeitstempel, Owner und Status bis in die Katalog-Ansicht erhalten?
• Können Nutzer vorgeschlagene, bestätigte, abgelaufene und zurückgezogene Inhalte unterscheiden?
• Gibt es unterschiedliche Aktualität-Ziele nach Materialität?
• Werden Konflikte erkannt, bevor ein später Import genehmigte Inhalte überschreibt?
• Sind manuelle Änderungen und Freigaben historisiert?
• Zeigt der Katalog aktive Datenprodukte und Nutzer-Beziehungen?
• Werden Fehler beim Metadatenimport getrennt von inhaltlichen Qualitätsproblemen gemessen?

Vom Beispiel zum verlässlichen Betrieb

Wählt einige geschäftlich oder regulatorisch wichtige Datenobjekte und ordnet deren Metadaten nach Herkunft: automatisch aus einem System gelesen, technisch abgeleitet, fachlich gepflegt oder ausdrücklich freigegeben. Für jede Klasse wird festgelegt, welches System führt, wer Konflikte entscheidet und wann eine erneute Prüfung nötig ist.

Vergleicht anschließend die Katalogansicht mit den ursprünglichen Datensätzen. Quelle, Zeitstempel, Status und Owner müssen erhalten bleiben. Simuliert auch einen Widerspruch, etwa wenn ein Scanner eine alte Beschreibung liefert, damit Erkennung und Eskalation nicht erst im Ernstfall erprobt werden.

Im Betrieb zählen nachvollziehbare Herkunft, aktuelle kritische Einträge, offene Konflikte nach Alter und die Zeit bis zur bestätigten Korrektur. Ein hoher Anteil technisch importierter Objekte ist lediglich eine Betriebskennzahl und kein Beleg für vertrauenswürdige Metadaten.

Prüfung-Routine für Records

Ziehe monatlich eine risikobasierte Stichprobe. Wähle einen automatisch eingelesenen, einen abgeleiteten, einen manuell kuratierten und einen genehmigten Record. Öffne zuerst die Katalog-Projektion und folge dann der Quell-ID zurück. Stimmen Wert, Status, Zeitstempel und Owner? Ist erkennbar, welche Transformation stattgefunden hat? Kann eine frühere Version rekonstruiert werden?

Bewerte Abweichungen nicht pauschal als „Katalog-Fehler“. Ein veralteter Quellrecord gehört zum Source Owner, eine verlorene Provenienz zur Plattform, ein falscher Suchindex zum Katalog-Betrieb und eine ungeklärte Definition zum fachlichen Steward. Diese Zuordnung verkürzt Eskalationen und verhindert, dass das Oberflächenteam inhaltliche Entscheidungen übernimmt.

Für kritische Klassen sollte ein kleines Scoreboard genügen: Anteil mit bekannter Quelle, Anteil innerhalb des Vorgaben zur Aktualität, offene Konflikte nach Alter, Records ohne erreichbaren Owner und Zeit bis zur bestätigten Korrektur. Segmentiere nach Klasse und Materialität. Ein globaler Durchschnitt kann verschleiern, dass gerade Retention- oder Finanzdefinitionen veraltet sind.

Halte außerdem fest, wer einen Record zurückziehen darf und wie Consumer davon erfahren. Ein sichtbar zurückgezogener Eintrag ist sicherer als stilles Löschen: Er bewahrt Historie, verhindert weitere Nutzung und gibt Stewards einen klaren Migrationshinweis.

Weiterführende Begriffe und Playbooks

Die Gesamtordnung liefert Die Vier-Schichten-Bedeutungslandkarte. Danach zeigt Der Katalog ist nicht das Dashboard, wie Discovery mit Consumern verbunden wird. Ergänzend helfen Glossar, Data Lineage, Metadaten Management, Data Verantwortung und Data Quality.