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 Consumer weiß, welche Konsequenz daraus folgt.

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

Ansatz

Wir behandeln Glossar, Tags, Klassifikationen und Tiers als vier unterschiedliche Governance-Instrumente mit expliziten Rollen. Der Pilotprojekt beginnt mit 10–20 Begriffen eines repräsentativen End-to-End-Flows, nicht mit dem Unternehmenslexikon. Jeder kontrollierte Eintrag erhält einen Owner, eine Herkunft, einen Status und einen Review-Zeitpunkt. Erst wenn Consumer die Einträge in einer konkreten Aufgabe verwenden und Stewardship-Änderungen zuverlässig funktionieren, wird der Scope 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 Scope folgt einem Flow und nicht dem Organigramm. Geeignet ist beispielsweise „Bestellung bis Umsatzbericht“: Quellobjekte aus CRM und ERP, zentrale Transformationsmodelle und ein konsumierter Umsatz-KPI. Die 10–20 Begriffe werden aus Fragen ausgewählt, die in diesem Flow 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; ein fachlich verantwortlicher Owner 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, Owner und weitere Beziehungen tragen. Die Zuordnung eines Terms zu Tabellen, Spalten, Dashboards oder anderen Assets macht Bedeutung entlang des Flows sichtbar. Die Zuordnung ist eine fachliche Behauptung und sollte deshalb reviewbar 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, Owner 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 den betrieblichen Impact 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, Popularität, Sensitivität und Service-Level ausdrücken. Falls Consumer 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:

• fachlicher Owner und operativer Steward;
• Quelle der Definition, etwa Richtlinie, Datenvertrag oder freigegebene Spezifikation;
• Status wie Draft, Approved oder Deprecated;
• Datum und Anlass der letzten Entscheidung;
• nächster Review oder auslösendes Ereignis;
• betroffener Flow 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; Quellsystem liefert technische Schemas, Glossar-Owner 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

Der 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 der Finance Owner 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 denselben Impact erzeugt. 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 den Owner 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 Flow und zwei konkrete Consumer-Aufgaben wählen.
2. 10–20 entscheidungsrelevante Begriffe erfassen.
3. Pro Begriff Definition, Owner, 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. Consumer-Aufgaben 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 Enterprise-Lexikon zuerst: Tausende Begriffe ohne Asset-Bezug erzeugen Suchrauschen und langwierige Abstimmung. Besser ist die Erweiterung Flow für Flow, 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.

Owner ohne Entscheidungsrecht: Eine Person wird eingetragen, kann Definitionen aber weder freigeben noch Konflikte lösen. Verantwortung muss eine konkrete Verantwortung und Reaktionszeit haben.

Dauerhafter Draft: Ungeprüfte Einträge sehen für Consumer offiziell aus. Drafts brauchen sichtbaren Status, begrenzten Scope 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 Flow. Bringt einen fachlichen Owner, einen Steward, einen Engineer und einen echten Consumer 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, In/Out of Scope, Owner, 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 Consumer schneller das richtige Asset fanden, weniger Rückfragen stellten und Konflikte über den definierten Stewardship-Weg gelöst wurden.

Checkliste

• Der Pilotprojekt deckt einen benannten End-to-End-Flow und echte Nutzer-Aufgaben 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.
• Draft, Freigabe, Änderung und Deprecation wurden praktisch getestet.
• Die Grenze zu Zugriffsverwaltung, Betrieb 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 das Pilotprojekt-Flow. Es enthält:

• Flow, Nutzer-Aufgaben und einbezogene Assets;
• 10–20 freigegebene Begriffe mit Definition, Synonymen und Umfang;
• Glossar-Owner, 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-Cadence, Nutzungsnachweise und offene Ausnahmen;
• explizite Grenzen zu Access Durchsetzung, Qualitätstests und Metric Vereinbarungen.

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, Owner 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