Was OpenMetadata ist — und was nicht

Begriffe vor dem Lesen

• Metadata / Metadaten — Beschreibende Informationen über Daten, Systeme, Nutzung, Qualität, Herkunft und Verantwortung.
• 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

OpenMetadata richtig einordnen: eine erweiterbare Metadatenplattform, die technischen, fachlichen und operativen Kontext verbindet, aber weder Datenbank noch Policy Engine noch automatische Governance-Lösung ist.

Was diese Serie klärt

• Orientierung: Was OpenMetadata ist — und was nicht
• Vertiefung: Die OpenMetadata-Architektur und das Entitätenmodell
• Abschluss mit betreibbaren Next Steps über Wann OpenMetadata passt — und wann nicht

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. Was OpenMetadata ist — und was nicht
2. Die OpenMetadata-Architektur und das Entitätenmodell
3. OpenMetadata vs. Collibra und Alation
4. OpenMetadata vs. Microsoft Purview und Unity Catalog
5. OpenMetadata vs. DataHub
6. Wann OpenMetadata passt — und wann nicht

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

Herausforderung

Für das Pilotprojekt Order-to-Cash (sales_otc im Warehouse, OpenMetadata-Tenant om-pilot) erwarten Sales und Governance, dass „der Catalog“ Owner, Zugriff, Qualität und Audit zugleich löst. Nach dem Metadatenimport stehen Tabellen — Freigaben und Durchsetzung liegen weiter in IAM und Warehouse. OpenMetadata ist Metadaten-Kontext für diesen Flow, kein Ersatz für alle Kontrollsysteme.

Die Plattform bietet Katalog, Governance, Lineage, Qualität und Kollaboration und kann deshalb wie Ersatz für jedes angrenzende Produkt wirken. Das ist sie nicht.

Ansatz

KMU — ein Ingestion-Pfad und Verantwortung für priorisierte Assets. Mid-Market — Domain-Stewards, Glossar vs. Inventar getrennt, Review-Cadence. Enterprise — Multi-Source Identity, Connector-Ops und Catalog≠Semantic-Layer-Grenzen.

OpenMetadata als aktive Metadatenplattform behandeln: als gemeinsame Kontextebene, die Verantwortung, Verträge, Lineage und Betriebssignale für Daten-, Analyse-, Pipeline- und AI-Assets sichtbar macht. Die Plattform übernimmt technische Metadaten, verbindet sie mit fachlichem Kontext und Betriebssignalen und macht diesen Kontext durchsuchbar, governable und per API nutzbar.

Sie ersetzt weder Verträge noch Verantwortung-Entscheidungen noch Durchsetzung im laufenden System. Sie soll autoritative Systeme verbinden, nicht für alles selbst autoritativ wirken.

Quellsysteme erzeugen Daten und Laufzeitereignisse
OpenMetadata verbindet Kontext und Beziehungen
Governance-Teams geben Bedeutung und Verantwortung frei
Kontrollsysteme erzwingen Zugriff, Aufbewahrung und Ausführung
Consumer finden den freigegebenen Nutzungspfad

Was in die Plattform gehört

OpenMetadata kann technische Metadaten aus Datenbanken, Warehouses, BI-Tools, Pipelines, Dashboards, Topics und ML-Modellen mit fachlichem und operativem Kontext verbinden:

• verantwortliche Person, Teams und Domains;
• Beschreibungen, Glossarbegriffe, Tags und Klassifikationen;
• Schema, Nutzung, Lineage und Änderungshistorie;
• Profiling, Testergebnisse, Freshness und Vertrauenssignale;
• Tasks, Diskussionen, Anfragen und Freigabekontext.

Der Wert liegt im Beziehungsmodell. Eine Tabelle ohne Owner, Zweck, Lineage, Qualitätsstatus und Downstream-Consumer ist nur ein Inventareintrag. Im verbundenen Metadatengraphen unterstützt dieselbe Tabelle Discovery, Impact Analysis und governte Entscheidungen.

Was sie nicht ersetzt

OpenMetadata wird nicht selbst zur Ausführungsgrenze jeder Kontrolle.

Metadaten können eine Sensitivitätsklassifikation oder erlaubte Nutzung dokumentieren. Eine separate Laufzeitkontrolle muss sie dennoch durchsetzen. Ebenso zeigt ein Lineage-Graph, dass ein KPI betroffen ist; er repariert weder das dbt-Modell noch gibt er einen Release frei.

Kleinste tragfähige Umsetzung

Mit einer Business-Frage beginnen, nicht mit allen Konnektoren:

1. Eine wertvolle Analytics-Domain auswählen.
2. Eine Datenplattform, eine Transformationsschicht und eine BI-Oberfläche anbinden.
3. Für kritische Assets Owner, kurze Beschreibung, Domain und Klassifikation verlangen.
4. Einen Fachbegriff mit dem freigegebenen KPI oder Datenprodukt verknüpfen.
5. Mit Lineage eine konkrete Change- oder Incident-Frage beantworten.
6. Messen, ob Menschen das freigegebene Asset schneller finden und richtig verwenden.

So entsteht zuerst ein funktionierendes Metadatenprodukt, bevor die Plattform auf den gesamten Bestand skaliert wird.

Häufige Anti-Patterns

• Erst harvesten, später govern: Tausende Assets ohne verantwortliche Person erzeugen Suchrauschen statt Discovery.
• Katalog gleich Kontrolle: Das Dokumentieren einer Richtlinie wird mit ihrer Durchsetzung verwechselt.
• Ein generischer Score: Dashboard, Quelltabelle und kritischer KPI benötigen unterschiedliche Vertrauensnachweise.
• Platform Team besitzt jede Definition: Der technische Betrieb ist zentral, die fachliche Verantwortung nicht.

Hilfe beim Umsetzen

Schreibt in einem Satz: „OpenMetadata ist für uns ___, nicht ___.“ Beispiel: Katalog + Lineage + Stewardship-Workflows, nicht Policy-Durchsetzung und nicht das Warehouse. Danach Governance Starting-Point Decision: passt der Fit zum Problem, das ihr lösen wollt? Wenn Durchsetzung die Hauptlücke ist, zuerst Unity/Purview/IAM klären — nicht OM als Ersatz verkaufen.

Checkliste

• Geht es im ersten Use Case um Discovery, Impact Analysis, Qualitätstransparenz oder Stewardship?
• Welches System bleibt für jedes Metadatenfeld und jede Laufzeitkontrolle autoritativ?
• Für welche Assets sind verantwortliche Person, Zweck, Klassifikation und Lineage verpflichtend?
• Welche Nutzer prüfen, ob die Plattform eine echte Entscheidung verbessert?

Artefakt

Eine einseitige Metadaten-Grenzkarte erstellen: Sources of Truth, OpenMetadata-Entitäten, menschliche Decision Rights, Durchsetzung Points und die Nachweise jedes Systems.

Tools

• OpenMetadata Docs — Produkt- und Konzeptübersicht.
• Governance Starting-Point Decision — ob/wann OpenMetadata der Einstieg ist.
• OpenMetadata-Ingestions-Generator — späterer Einstieg in Ingestion, sobald die Einordnung klar ist.

Ressourcen

• OpenMetadata-Dokumentation
• OpenMetadata Metadata Standard
• OpenMetadata Data Governance Guide