Glossary, Tags, Klassifikationen und Tiers

Herausforderung

Wenn ein Katalog neu eingeführt wird, sollen Glossar, Tags, Klassifikationen und Tiers oft gleichzeitig „fertig“ werden. Eine Arbeitsgruppe sammelt hunderte Begriffe, importiert vorhandene Label und legt Tier 1 bis 4 an. Danach sieht OpenMetadata reichhaltig aus, beantwortet aber die wichtigsten Fragen noch nicht zuverlässig: Bedeutet „Kunde“ überall dasselbe? Ist customer_id schützenswert oder nur ein technischer Schlüssel? Ist eine Tier-1-Tabelle geschäftskritisch, besonders vertrauenswürdig oder bloß häufig genutzt? Wer hat diese Aussage getroffen, auf welcher Quelle beruht sie und wann wird sie erneut geprüft?

Das Problem ist nicht zu wenig Taxonomie, sondern die Vermischung verschiedener Aussagen. Ein Glossarbegriff beschreibt fachliche Bedeutung. Ein Tag ergänzt flexiblen Kontext. Eine Klassifikation ordnet Tags in einen kontrollierten Zweck ein, etwa Sensitivität oder Lebenszyklus. Ein Tier drückt eine knapp definierte operative Kritikalität aus. Werden diese Konstrukte austauschbar verwendet, kann ein Asset gleichzeitig „PII“, „Customer“, „Gold“, „Tier 1“ und „zertifiziert“ tragen, ohne dass ein Nutzer weiß, welche Konsequenz daraus folgt.

Ein unternehmensweites Lexikon als Startpunkt verschärft das Problem. Es bindet viele Beteiligte, erzeugt abstrakte Definitionen und verzögert den ersten überprüfbaren Nutzen. Für einen Pilotfluss reichen dagegen 10–20 Begriffe, wenn sie entlang einer echten Entscheidung ausgewählt werden: von einer Quelltabelle über Transformationen bis zu einer Kennzahl oder einem Bericht. Das Pilotprojekt zeigt nicht nur, ob Begriffe angelegt werden können, sondern ob Bedeutung, Herkunft, Verantwortung und Verwendung im Alltag zusammenpassen.

Ansatz

Wir behandeln Glossar, Tags, Klassifikationen und Tiers als vier unterschiedliche Governance-Instrumente mit expliziten Rollen. Das Pilotprojekt beginnt mit 10–20 Begriffen eines repräsentativen End-to-End-Datenflusses, nicht mit dem Unternehmenslexikon. Jeder kontrollierte Eintrag erhält eine verantwortliche Person, eine Herkunft, einen Status und einen Review-Zeitpunkt. Erst wenn Nutzer die Einträge in einer konkreten Aufgabe verwenden und Stewardship-Änderungen zuverlässig funktionieren, wird der Umfang erweitert.

Die Konstrukte werden nach der Aussage gewählt, nicht nach Bequemlichkeit:

• Glossar: stabile fachliche Bedeutung, Synonyme und Beziehungen;
• Tag: leichter, ergänzender Kontext ohne eigene fachliche Definition;
• Klassifikation: kontrollierter Namensraum und Governance-Zweck für Tags;
• Tier: wenige Stufen operativer Kritikalität mit dokumentierten Kriterien.

Keines dieser Konstrukte ist automatisch eine Zugriffskontrolle oder ein Qualitätsnachweis. OpenMetadata dokumentiert und verbindet den Kontext; die tatsächliche Durchsetzung bleibt dort, wo sie technisch autoritativ ist.

Prinzipien für ein kleines, belastbares Vokabular

Der erste Umfang folgt einem konkreten Datenfluss und nicht dem Organigramm. Geeignet ist beispielsweise „Bestellung bis Umsatzbericht“: Quellobjekte aus CRM und ERP, zentrale Transformationsmodelle und eine genutzte Umsatz-Kennzahl. Die 10–20 Begriffe werden aus Fragen ausgewählt, die in diesem Datenfluss tatsächlich auftreten. Was ist eine Bestellung? Wann gilt Umsatz als gebucht? Welches Datum steuert die Periode? Was ist ein aktiver Kunde? Welche Kundennummer ist fachlich führend?

Jeder Begriff muss eine Entscheidung ermöglichen. Eine Definition wie „Umsatz ist der Umsatz des Unternehmens“ ist formal vorhanden, operativ aber wertlos. Eine belastbare Definition nennt Einschluss und Ausschluss, Granularität, relevante Zeitlogik und Abgrenzung zu ähnlichen Begriffen. Für „Nettoumsatz“ kann sie festlegen, ob Rabatte, Retouren, Steuern und Währungsumrechnung enthalten sind. Beispielwerte helfen, dürfen die Regel aber nicht ersetzen.

Kontrolliert bedeutet nicht zentralistisch. Ein Domain Steward darf Begriffe seines Bereichs pflegen; eine fachlich verantwortliche Person entscheidet bei Konflikten. Ein kleines Review-Forum löst nur bereichsübergreifende Fragen. Damit bleibt die Änderungszeit kurz. Ein Begriff, der drei Monate auf ein Governance Board wartet, wird außerhalb des Katalogs erklärt.

Namenskonventionen sind Teil des Produkts. Der bevorzugte Name ist verständlich, Synonyme decken etablierte Suchbegriffe ab, und Abkürzungen werden ausgeschrieben. Definitionen enthalten keine flüchtigen Implementierungsdetails. Links zu Richtlinien oder Berechnungen können ergänzen, ersetzen aber keine im Katalog lesbare Kernaussage.

Abbildung in OpenMetadata

Im OpenMetadata-Glossar bilden Glossaries einen fachlichen Kontext und Glossary Terms die kontrollierten Begriffe. Ein Term kann Beschreibung, Synonyme, verwandte Begriffe, Referenzen, verantwortliche Person und weitere Beziehungen tragen. Die Zuordnung eines Terms zu Tabellen, Spalten, Dashboards oder anderen Assets macht Bedeutung entlang des Datenflusses sichtbar. Die Zuordnung ist eine fachliche Behauptung und sollte deshalb überprüfbar sein.

Tags sind flexibler. Sie eignen sich für kompakte Marker, die gefiltert, gesucht oder automatisiert verarbeitet werden sollen. Tags erhalten ihren Sinn durch eine Classification, also einen kontrollierten Namensraum. Eine Classification Sensitivity kann etwa Public, Internal, Confidential und Restricted enthalten. Eine andere Classification Lifecycle kann Experimental, Active und Deprecated enthalten. Gleiche Wörter in verschiedenen Namensräumen sollten vermieden oder vollständig qualifiziert angezeigt werden.

Ein Tag wird nicht zum Glossarbegriff, nur weil sein Name fachlich klingt. Customer als Tag kann Assets schnell markieren, erklärt aber weder die Definition noch Beziehungen zu Account, Contact oder Legal Entity. Umgekehrt ist ein Glossarbegriff kein guter Ersatz für jede betriebliche Kennzeichnung. Deprecated braucht meist keine fachliche Ontologie, sondern einen klaren Status, verantwortliche Person und Ablauf.

Tiers sind für eine kleine, organisationsweit verständliche Kritikalitätsskala gedacht. Entscheidend ist nicht die Anzahl der Stufen, sondern eine eindeutige Frage. Ein Tier kann zum Beispiel die Auswirkung eines Ausfalls abbilden: Tier 1 betrifft regulatorische Meldungen oder zentrale Produktionsentscheidungen, Tier 2 wichtige Bereichsprozesse, Tier 3 unterstützende Analysen. Es sollte nicht gleichzeitig Qualität, Beliebtheit, Sensitivität und Service-Level ausdrücken. Falls Nutzer die Konsequenz eines Tiers nicht erklären können, wird im Pilotprojekt kein Tier vergeben.

Domains und Data Products liefern den organisatorischen und wertstrombezogenen Kontext. Sie ersetzen das Glossar nicht. Ein Begriff wie „Aktiver Kunde“ kann einem Customer-Domain-Kontext entstammen und zugleich Assets mehrerer Produkte beschreiben. Die Trennung verhindert, dass Definitionen beim Wechsel einer Plattform oder Produktgrenze dupliziert werden.

Herkunft und Entscheidungsprovenienz

Vertrauen entsteht nicht allein durch eine gute Formulierung. Für jede zentrale Aussage muss erkennbar sein, woher sie stammt und wer sie verantwortet. Als Provenienz reichen im Pilotprojekt wenige Felder oder Konventionen:

• fachlich verantwortliche Person und operativer Steward;
• Quelle der Definition, etwa Richtlinie, Datenvertrag oder freigegebene Spezifikation;
• Status wie Entwurf, freigegeben oder abgelöst;
• Datum und Anlass der letzten Entscheidung;
• nächster Review oder auslösendes Ereignis;
• betroffener Datenfluss und bekannte Ausnahmen.

Automatisch ingestierte Tags benötigen ebenfalls Provenienz. Wenn ein Scanner eine E-Mail-Adresse erkennt, ist das zunächst ein technischer Fund, keine endgültige Governance-Entscheidung. Der Wert sollte als automatisch erkannt markiert, mit Scanquelle und Zeitpunkt versehen und bei kritischen Assets bestätigt werden. Manuelle Korrekturen dürfen beim nächsten Ingestion-Lauf nicht still überschrieben werden. Dafür braucht es eine festgelegte Autorität pro Feld: Scanner schlägt Sensitivität vor, Steward bestätigt sie; die verantwortliche Person für das Glossar verantwortet fachliche Bedeutung.

Provenienz verhindert auch scheinbare Gewissheit. Ein Tier ohne Kriterien und Entscheider sieht offiziell aus, ist aber nicht auditierbar. Ein veralteter Begriff ohne Review-Historie kann gefährlicher sein als ein sichtbar als Entwurf markierter Begriff. Im Zweifel ist der Reifegrad transparent zu zeigen, nicht durch ein weiteres Label zu kaschieren.

Durchgängiges Beispiel: Bestellung bis Nettoumsatz

Das Pilotprojekt umfasst sales_order, das dbt-Modell fct_revenue und das Dashboard „Monatlicher Nettoumsatz“. Das Team wählt zwölf Begriffe: Bestellung, Bestellposition, Kunde, Rechnung, Rechnungsdatum, Buchungsdatum, Nettoumsatz, Rabatt, Retoure, Steuer, Berichtswährung und aktiver Kunde.

Für Nettoumsatz legt die verantwortliche Person aus Finance fest: fakturierter Betrag nach positionsbezogenen Rabatten und Retouren, ohne Umsatzsteuer, umgerechnet zum freigegebenen Monatskurs. Das Buchungsdatum steuert die Periode. „Revenue“ und „Net Sales“ werden als Synonyme erfasst. Der Term wird der berechneten Spalte in fct_revenue und dem KPI im Dashboard zugeordnet. Die Quelldaten-Spalte gross_amount erhält ihn bewusst nicht, weil sie eine andere Semantik hat.

Die Classification Sensitivity markiert customer_email als Confidential und customer_id nach der vereinbarten Regel als Internal, sofern die Kennung allein keinen Personenbezug offenlegt. Lifecycle.Deprecated markiert ein altes Umsatzmodell. Der Begriff „Nettoumsatz“ bleibt davon unabhängig: Bedeutung und Lebenszyklus sind verschiedene Aussagen.

Das Dashboard erhält Tier 1, weil es einen monatlichen, vorstandsrelevanten Abschlussprozess steuert. Das zugrunde liegende Modell erhält nur dann ebenfalls Tier 1, wenn die Tier-Regel Abhängigkeiten einschließt oder sein Ausfall dieselbe Auswirkung hat. Tiers werden nicht blind entlang der Lineage vererbt. Eine Arbeitskopie des Dashboards bleibt Tier 3 oder ohne Tier, obwohl sie dieselben Begriffe verwendet.

Im Review testet ein Controller drei Aufgaben: den freigegebenen Nettoumsatz finden, die verwendete Zeitlogik verstehen und die verantwortliche Person bei einer Abweichung kontaktieren. Ein Engineer prüft, welche Spalte die Definition technisch realisiert. Der Steward kontrolliert, ob Tags und Terms an der richtigen Granularität hängen. Erst wenn diese Aufgaben ohne Nebenkanal gelingen, gilt das Pilotprojekt als nutzbar.

Das einfachste tragfähige Modell

Das Minimum besteht nicht aus möglichst vielen Objekten, sondern aus einem geschlossenen Pflegekreislauf:

1. Einen Datenfluss und zwei konkrete Nutzeraufgaben wählen.
2. 10–20 entscheidungsrelevante Begriffe erfassen.
3. Pro Begriff Definition, verantwortliche Person, Status und Quelle pflegen.
4. Höchstens zwei Klassifikationen mit wenigen Tags einführen.
5. Tiers nur mit einer einzigen, messbaren Kritikalitätslogik verwenden.
6. Begriffe und Tags an repräsentative Assets und Spalten hängen.
7. Nutzeraufgaben durchführen und offene Fragen protokollieren.
8. Änderung, Freigabe und erneute Prüfung einmal real durchspielen.

Ein Spreadsheet kann als Entwurfs- und Review-Artefakt dienen, OpenMetadata ist jedoch der Ort für veröffentlichte Zuordnungen und Navigation. Importierbarkeit allein ist kein Erfolgskriterium. Entscheidend ist, ob das Modell nach der Erstbefüllung weiter gepflegt wird.

Anti-Patterns und ihre Folgen

Das Unternehmenslexikon zuerst: Tausende Begriffe ohne Asset-Bezug erzeugen Suchrauschen und langwierige Abstimmung. Besser ist die Erweiterung Datenfluss für Datenfluss, mit Wiederverwendung bereits freigegebener Begriffe.

Ein Tag für jede Aussage: Freie Tags wachsen schnell, kollidieren sprachlich und tragen keine belastbare Definition. Kontrollierte Aussagen gehören in einen benannten Namensraum oder ins Glossar.

Glossar als Kopie des physischen Schemas: Ein Term pro Spaltenname dokumentiert Implementierung statt Geschäftsbedeutung. Mehrere technische Felder dürfen denselben fachlichen Begriff realisieren; ähnlich benannte Felder können unterschiedliche Begriffe benötigen.

Tier als Gesamturteil: „Tier 1“ wird gleichzeitig als wichtig, qualitativ gut, sensibel und zertifiziert verstanden. Dadurch kann niemand eine Konsequenz ableiten. Qualität, Sensitivität, Verlässlichkeit und Kritikalität brauchen getrennte Signale.

Automatische Vererbung ohne Prüfung: Ein sensibles Quellfeld macht nicht automatisch jedes aggregierte Ergebnis gleich sensibel; umgekehrt kann eine Kombination unscheinbarer Felder ein neues Risiko erzeugen. Vererbung liefert Vorschläge, keine pauschale Wahrheit.

Verantwortliche Person ohne Mandat: Eine Person wird eingetragen, kann Definitionen aber weder freigeben noch Konflikte lösen. Verantwortung braucht ein konkretes Entscheidungsrecht und eine vereinbarte Reaktionszeit.

Dauerhafter Entwurf: Ungeprüfte Einträge sehen für Nutzer offiziell aus. Entwürfe brauchen sichtbaren Status, begrenzten Umfang und eine Frist für Freigabe oder Löschung.

Grenzen bewusst dokumentieren

OpenMetadata kann Bedeutung, Beziehungen, Zuständigkeiten und Schutzkontext sichtbar machen. Es beweist nicht automatisch, dass eine Definition fachlich korrekt, ein Tag vollständig oder ein Tier aktuell ist. Ingestion kann vorhandene Metadaten übernehmen und Scanner können Kandidaten erkennen; Governance-Entscheidungen bleiben menschlich verantwortlich.

Eine Classification ist auch keine Zugriffspolitik. Sensitivity.Restricted kann einen Workflow, eine Suche oder einen Hinweis auslösen, entzieht aber nicht von selbst Rechte im Warehouse, BI-System oder Dateispeicher. Diese Grenze gehört in das Operating Model und wird in Teil 4 vertieft.

Ebenso ersetzt ein Glossarbegriff keinen Metric Contract und keine ausführbare Qualitätsregel. Er beschreibt die fachliche Bedeutung; Berechnungslogik, Tests, Service Levels und Change Control liegen in den dafür autoritativen Systemen. OpenMetadata verlinkt diese Evidenz und macht Abweichungen auffindbar.

Hilfe beim Umsetzen

Beginnt mit einem 90-minütigen Workshop für einen bekannten Datenfluss. Bringt eine fachlich verantwortliche Person, einen Steward, einen Engineer und einen echten Nutzer zusammen. Sammelt zunächst die Fragen, nicht die Begriffe. Markiert anschließend jene 10–20 Konzepte, deren Uneindeutigkeit heute Suche, Abstimmung oder Fehlentscheidungen verursacht.

Erstellt für jeden Begriff einen kurzen Review-Datensatz: bevorzugter Name, Definition, Synonyme, was enthalten ist, was ausdrücklich nicht enthalten ist, verantwortliche Person, Quelle und zwei repräsentative Asset-Zuordnungen. Trennt in einem zweiten Schritt die benötigten Marker: Ist es Bedeutung, flexibler Betriebsstatus, kontrollierter Schutzkontext oder Kritikalität? So wird das passende OpenMetadata-Konstrukt gewählt, bevor Objekte angelegt werden.

Nutzt den OpenMetadata-Glossar-Generator für konsistente Begriffsentwürfe und den OpenMetadata-Klassifikations-Generator für kontrollierte Tag-Sets. Der OpenMetadata-Domain- und Produkt-Generator hilft, fachlichen Kontext und Verantwortungsgrenzen zu dokumentieren, ohne sie mit Definitionen zu vermischen.

Plant nach zwei Wochen einen Nutzungsreview. Fragt nicht nur, wie viele Begriffe zugeordnet wurden. Prüft, ob Nutzer schneller das richtige Asset fanden, weniger Rückfragen stellten und Konflikte über den definierten Stewardship-Weg gelöst wurden.

Checkliste

• Das Pilotprojekt deckt einen benannten End-to-End-Datenfluss und echte Nutzeraufgaben ab.
• Der Umfang umfasst zunächst 10–20 entscheidungsrelevante Begriffe.
• Jeder Begriff besitzt Definition, verantwortliche Person, Quelle, Status und Review-Auslöser.
• Synonyme verbessern die Suche, ohne widersprüchliche Definitionen zu verstecken.
• Glossarbegriffe sind an repräsentative Assets oder Spalten gebunden.
• Tags sind nach Governance-Zweck in klar benannten Klassifikationen organisiert.
• Automatisch erkannte und manuell bestätigte Werte sind unterscheidbar.
• Die Autorität pro Metadatenfeld und das Verhalten bei Re-Ingestion sind geklärt.
• Ein Tier beantwortet genau eine definierte Kritikalitätsfrage.
• Nutzer können die praktische Konsequenz jeder verwendeten Tier-Stufe erklären.
• Qualität, Zertifizierung, Sensitivität und Kritikalität werden nicht vermischt.
• Entwurf, Freigabe, Änderung und Ablösung wurden praktisch getestet.
• Die Grenze zu Zugriffsverwaltung, betrieblicher Durchsetzung und ausführbaren Tests ist dokumentiert.
• Nutzungserfolg wird an Aufgaben und Entscheidungen gemessen, nicht nur an Objektzahlen.

Artefakt

Das zentrale Artefakt ist ein „Semantic Context Decision Record“ für den Pilotfluss. Es enthält:

• Datenfluss, Nutzeraufgaben und einbezogene Assets;
• 10–20 freigegebene Begriffe mit Definition, Synonymen und Umfang;
• Glossar-Verantwortung, Steward und Entscheidungsweg;
• Klassifikationen, Tags und erlaubte Werte;
• Tier-Zweck, Kriterien und Konsequenzen;
• Herkunft und Autorität pro Metadatenfeld;
• Regeln für automatische Vorschläge, manuelle Bestätigung und Überschreiben;
• Review-Rhythmus, Nutzungsnachweise und offene Ausnahmen;
• explizite Grenzen zu Zugriffsdurchsetzung, Qualitätstests und Kennzahlenvereinbarungen.

Der Record ist kurz genug für einen Review, aber konkret genug, um die Konfiguration in OpenMetadata und die Zuordnung an Assets reproduzierbar zu machen. Änderungen am Modell werden dort begründet; OpenMetadata zeigt den veröffentlichten Zustand.

Tools

• OpenMetadata-Glossar-Generator — Glossarbegriffe, Synonyme, Verantwortliche und Asset-Mapping entwerfen.
• OpenMetadata-Klassifikations-Generator — kontrollierte Tags, Klassifikationen und Sensitivität an Spalten vorbereiten.
• OpenMetadata-Domain- und Produkt-Generator — Domain-Kontext für Begriffe und Produkte abgrenzen.

Ressourcen

• OpenMetadata: Glossary
• OpenMetadata: Classification
• OpenMetadata: Tiering
• OpenMetadata: Domains und Data Products