Governance-Betriebsmodell in OpenMetadata

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

Decision Rights, Betriebsrollen und Evidenz um die Assets definieren, die Menschen tatsächlich nutzen.

Was diese Serie klärt

• Orientierung: Governance-Betriebsmodell in OpenMetadata
• Vertiefung: Domains, Data Products und Verantwortung
• Abschluss mit betreibbaren Next Steps über Adoption, Scorecards und Continuous Improvement

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. Governance-Betriebsmodell in OpenMetadata
2. Domains, Data Products und Verantwortung
3. Glossary, Tags, Klassifikationen und Tiers
4. Policies, Sensitive Data und Access Context
5. Data Quality und Trust Signals
6. Lineage als Impact-Analysis-Produkt
7. Collaboration, Issues und Stewardship Workflows
8. Adoption, Scorecards und Continuous Improvement

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

Herausforderung

In om-pilot sind Tausende Tabellen suchbar; Analysten fragen weiter im Chat nach der richtigen Order-Tabelle aus sales_otc. Fachbereiche streiten über Kennzahlen. Plattformteams bekommen Tickets zu Definitionen, die sie nicht verantworten können. Sicherheitsregeln liegen in Warehouse, BI und IAM, während der Katalog nur einen Ausschnitt zeigt.

Größenordnung: KMU — eine Domäne, zehn kritische Assets, wöchentliche Steward-Stunde. Mid-Market — Glossary/Tiers mit Domain Stewards. Enterprise — Scorecards, Policy Workflows, Multi-Domain-SLAs.

Das Problem ist selten ein fehlendes Metadatenfeld. Es fehlt ein Betriebsmodell: wer entscheidet Bedeutung, wer kuratiert, welche Evidenz zählt, wie Eskalation läuft. Ohne dieses Betriebsmodell bleibt OpenMetadata Inventar — kein Steuerungsmittel für das Pilotprojekt-Flow.

Typische Symptome sind:

• Fast jedes Asset hat einen „verantwortliche Person“, aber niemand reagiert auf Rückfragen oder Qualitätsvorfälle.
• Plattformadministratoren werden faktisch zu Datenverantwortlichen, weil nur sie Schreibrechte im Katalog besitzen.
• Glossarbegriffe, Tags und Beschreibungen entstehen in Workshops, werden aber nicht entlang realer Datenflüsse gepflegt.
• Ingestion gilt als einmalige Einrichtung; fehlgeschlagene Läufe oder veraltete Metadaten bleiben unbemerkt.
• Zertifizierungen signalisieren Vertrauen, ohne dass Aktualität, Datenqualität oder fachliche Freigabe nachweisbar sind.
• Richtlinien im Katalog werden mit Zugriffskontrolle verwechselt, obwohl die tatsächliche Durchsetzung in anderen Systemen stattfindet.
• Governance-Boards entscheiden über abstrakte Standards, aber nicht über konkrete Konflikte an kritischen Assets.

Das scheitert, weil Rollenbezeichnungen allein keine Decision Rights schaffen. „Owner“, „Steward“ und „Admin“ sind erst dann belastbar, wenn für eine konkrete Entscheidung klar ist: Wer ist rechenschaftspflichtig? Wer liefert die Arbeit? Wer muss konsultiert werden? Wer braucht nur Information? Welche Frist gilt? Und welche technische oder fachliche Evidenz wird im Katalog sichtbar gemacht?

Ansatz

OpenMetadata wird als Entscheidungs- und Evidenzschicht betrieben, nicht als universelle Durchsetzungsinstanz. Das Betriebsmodell verteilt Verantwortung auf drei Ebenen:

1. Die Plattform verantwortet Verfügbarkeit, Ingestion, technische Standards und den sicheren Betrieb.
2. Die Domain verantwortet Bedeutung, Priorität, fachliche Qualität und Freigabe ihrer Daten.
3. Consumer verantworten die angemessene Nutzung, melden Lücken und liefern Nutzungsevidenz.

Jede Governance-Regel wird an einer echten Entscheidung formuliert, nicht an einer abstrakten Rolle. Der Pilotprojekt beginnt mit einem repräsentativen Value Stream und wenigen kritischen Assets. Erst wenn Zuständigkeit, Aktualität, Eskalation und Evidenz dort funktionieren, wird auf weitere Domains skaliert.

Ein Operating Model beginnt mit Decision Rights

Entscheidungen statt Rollenlisten

Eine Rollenliste beantwortet „Wer ist beteiligt?“. Decision Rights beantworten „Wer darf und muss in dieser Situation entscheiden?“. Für einen ersten Flow reichen fünf bis sieben wiederkehrende Entscheidungen:

• Wer bestätigt die fachliche Definition einer Kennzahl?
• Wer entscheidet, ob ein Asset als vertrauenswürdig oder zertifiziert gilt?
• Wer priorisiert einen Datenqualitätsfehler?
• Wer genehmigt eine Änderung am Schema oder Datenvertrag?
• Wer entscheidet bei widersprüchlichen Quellsystemen über die autoritative Bedeutung?
• Wer kann eine Ingestion pausieren oder ändern?
• Wer eskaliert, wenn verantwortliche Person nicht reagieren?

Jede Entscheidung erhält einen Accountable Owner, ein erwartetes Ergebnis, eine Reaktionszeit und eine Evidenzquelle. Das verhindert, dass Verantwortung zwischen Teams wandert. Ein Platform Engineer kann beispielsweise den technischen Ingestion-Fehler beheben, aber nicht entscheiden, ob „aktiver Kunde“ fachlich korrekt definiert ist. Umgekehrt kann ein Sales Owner die Definition freigeben, aber keinen Warehouse-Zugriff erzwingen.

Entscheidungen nahe an der Arbeit platzieren

Entscheidungen gehören dorthin, wo das nötige Wissen und die Folgen liegen. Plattformweite Konventionen wie Naming, Ingestion-Sicherheit oder unterstützte Connector-Versionen liegen zentral. Fachliche Definitionen, Qualitätsprioritäten und Produkt-SLOs liegen in der Domain. Nutzungsentscheidungen – etwa ob ein Datensatz für eine Kampagnenanalyse geeignet ist – bleiben beim Consumer, gestützt durch sichtbare Metadaten.

Zentralisierung ist sinnvoll, wenn eine Entscheidung systemweit konsistent sein muss. Föderation ist sinnvoll, wenn Kontext und Auswirkungen domainspezifisch sind. Das Operating Model macht diese Grenze explizit, statt „föderiert“ als Synonym für unklare Zuständigkeit zu verwenden.

Rollen und RACI, die im Alltag funktionieren

Plattform, Domain und Consumer

Das Plattformteam betreibt OpenMetadata und seine Integrationen. Es verantwortet Upgrades, Verfügbarkeit, Authentifizierung, Rollenmodell, Connector-Laufzeit, Secrets, Logging und technische Datenqualität der Ingestion. Es stellt Vorlagen und Guardrails bereit, besitzt aber nicht automatisch die fachlichen Inhalte aller Assets.

Die Domain benennt einen accountable Owner für den betrachteten Datenbereich. Dieser Owner priorisiert Arbeit, entscheidet bei fachlichen Konflikten und sorgt für verfügbare Steward-Kapazität. Stewards pflegen Definitionen, Klassifikationen, Beziehungen und Nachweise. Verantwortung darf an Teams gebunden sein, doch für Eskalationen braucht es zusätzlich eine benannte Person oder ein eindeutig erreichbares On-call-/Funktionsmodell.

Consumer sind keine passiven Empfänger. Analysten, Data Scientists, BI-Entwickler und operative Nutzer bestätigen, ob Beschreibungen verständlich sind, melden unbrauchbare Assets und liefern Signale wie Nutzung, Queries, Bewertungen oder wiederkehrende Supportfragen. Sie entscheiden nicht über die offizielle Definition, aber ihre Evidenz bestimmt, wo Governance-Arbeit Wert schafft.

Ein pragmatisches RACI

Für „Customer Revenue wird zertifiziert“ könnte das RACI so aussehen:

• Accountable: Sales-Domain-verantwortliche Person bestätigt Definition, Umfang und Eignung.
• Responsible: Data Steward pflegt Beschreibung, Glossarbegriffe, Tests und Referenzen.
• Consulted: Finance-verantwortliche Person prüft Umsatzabgrenzung; Plattformteam prüft technische Evidenz.
• Informed: BI-Teams und relevante Nutzer erhalten Änderung und Gültigkeitsdatum.

Für „Metadaten der Sales-Pipeline sind aktuell“ verschiebt sich das RACI:

• Accountable: Platform Product Owner für den Metadatenservice.
• Responsible: Data Platform Operations betreibt Connector und Zeitplan.
• Consulted: Sales Data Engineer bestätigt erwartete Assets und Schemaänderungen.
• Informed: Domain Owner und Nutzer sehen Status und bekannte Lücken.

Ein RACI muss nicht jede Kleinigkeit abdecken. Es muss die Entscheidungen abdecken, bei denen Verzögerung, Konflikt oder Fehlinterpretation echten Schaden verursachen.

Abbildung in OpenMetadata

Teams, Owner, Domains und Data Products

OpenMetadata liefert Bausteine, aber das Operating Model bestimmt ihre Bedeutung. Teams bilden stabile organisatorische Verantwortung ab. Owner an Entities schaffen einen erreichbaren Einstiegspunkt. Domains gruppieren Verantwortung und fachlichen Kontext. Data Products beschreiben ein konsumierbares Bündel aus Assets, Erwartungen und Ansprechpartnern. Glossary Terms, Tags, Tiers und Klassifikationen ergänzen Bedeutung, Kritikalität und Schutzbedarf.

Diese Objekte sollten nicht jedes Organigrammdetail spiegeln. Eine Teamstruktur, die sich monatlich ändert, erzeugt Pflegekosten ohne bessere Entscheidungen. Modelliert werden nur Einheiten, die für Verantwortung, Zugriff, Eskalation oder Produktverantwortung relevant sind.

Aufgaben, Konversationen und Änderungen als Evidenz

Beschreibungen und Owner sind deklarative Metadaten: Sie sagen, wie es sein soll. Betriebsfähigkeit entsteht durch Evidenz: zuletzt erfolgreiche Ingestion, Testresultate, Profiler-Signale, Lineage, Nutzung, Change Events, Diskussionen und abgeschlossene Aufgaben. Ein zertifiziertes Asset ohne aktuelle technische Evidenz ist nur ein Label.

Für kritische Entscheidungen sollte der Katalog nachvollziehbar machen:

• Wer hat die Aussage freigegeben?
• Auf welcher Definition oder Quelle basiert sie?
• Welche Tests und Aktualitätswerte gelten?
• Wann wurde sie zuletzt geprüft?
• Welche bekannten Einschränkungen bestehen?
• Wo wird eine relevante Richtlinie tatsächlich durchgesetzt?

Nicht jede Evidenz muss in OpenMetadata erzeugt werden. Sie kann aus dbt, Warehouse, Orchestrierung, BI oder Incident Management stammen. Entscheidend ist, dass Nutzer den Zusammenhang vom Asset zur Evidenz finden.

Ingestion als internes Produkt

Metadatenfrische ist ein Serviceversprechen

Ingestion ist kein Hintergrundjob, den man nach dem Setup vergisst. Sie ist ein internes Produkt mit Nutzern, Abhängigkeiten und SLOs. Wenn Schemas, Lineage oder Testresultate veraltet sind, treffen Consumer Entscheidungen auf falscher Grundlage. Deshalb braucht jeder produktive Connector mindestens einen Owner, einen dokumentierten Scope, einen Zeitplan, Fehlerbenachrichtigung und ein Frischeversprechen.

Ein einfaches SLO könnte lauten: „Technische Metadaten der Sales-Warehouse-Assets sind an Werktagen spätestens zwei Stunden nach dem nächtlichen Transformationslauf aktualisiert; fehlgeschlagene Ingestion wird innerhalb von vier Betriebsstunden triagiert.“ Das ist messbarer als „Connector läuft täglich“.

Autoritative Quellen pro Metadatenfeld

Nicht jedes Feld sollte überall editierbar sein. Legen Sie pro wichtigem Metadatentyp die autoritative Quelle fest:

• Schema und technische Typen kommen aus dem Quellsystem.
• Transformation Lineage kommt bevorzugt aus dbt oder dem Orchestrator.
• Fachliche Definitionen werden von der Domain in OpenMetadata gepflegt.
• Klassifikationen können aus Scannern vorgeschlagen, aber fachlich bestätigt werden.
• Nutzungssignale kommen aus Query Logs oder BI-Systemen.
• Zugriffsentscheidungen und Richtlinien bleiben im Zugriffsverwaltung-, Warehouse- oder BI-System.

Diese Zuordnung verhindert „Last writer wins“. Überschreibt ein Connector kuratierte Beschreibungen oder divergieren Tags zwischen Systemen, braucht es eine bewusst konfigurierte Merge- und Verantwortung-Regel.

Durchgängiges Beispiel: Sales und Customer Revenue

Ausgangslage

Sales nutzt CRM-Opportunities, Finance bucht Rechnungen, Marketing arbeitet mit Accounts und das Warehouse erzeugt eine Tabelle customer_revenue_monthly. Drei Dashboards zeigen „Customer Revenue“, aber mit unterschiedlichen Filtern. Der häufigste Supportfall lautet: „Welche Zahl ist richtig?“

Der Pilotprojekt definiert eine konkrete Consumer-Entscheidung: Ein Regional Sales Lead soll bis 9 Uhr erkennen können, welcher Monatsumsatz für Forecast und Pipeline Review freigegeben ist. Der Scope umfasst CRM-Account und Opportunity, Finance-Invoice, zwei Transformationsmodelle, die kuratierte Revenue-Tabelle und ein führendes BI-Dashboard.

Entscheidung und Evidenz

Der Sales Domain Owner ist accountable für die operative Revenue-Sicht; Finance bleibt accountable für gebuchten Umsatz. Ein Steward dokumentiert die Abgrenzung: Sales Revenue basiert auf gewonnenen Opportunities mit definierter Storno- und Währungslogik, während booked revenue aus Rechnungen stammt. Beide Begriffe werden verbunden, nicht künstlich vereinheitlicht.

Die Plattform ingestiert Schema, Lineage, dbt-Tests und BI-Nutzung. Der Data Engineer verantwortet die technische Transformation. Der Steward verknüpft Glossarbegriffe, Owner und Einschränkungen. Der Domain Owner zertifiziert erst, wenn Definition, Lineage, Aktualität und zwei kritische Tests sichtbar sind. Bei einem fehlgeschlagenen Freshness-Test bleibt das Asset auffindbar, verliert aber nicht stillschweigend seine Bedeutung: Status und Warnung zeigen, dass die aktuelle Nutzung eingeschränkt ist.

Betriebsablauf

Eine Schemaänderung im CRM erzeugt einen technischen Hinweis. Der Data Engineer bewertet die Transformation; der Steward prüft, ob die Definition betroffen ist. Ein Qualitätsvorfall wird innerhalb der Domain priorisiert. Bei Konflikten zwischen Sales und Finance entscheidet nicht das Plattformteam: Die beiden accountable Owner klären die Semantik, während ein Governance Lead nur moderiert und die Entscheidung dokumentiert.

Nach vier Wochen wird gemessen: sinkende „Welche Tabelle?“-Fragen, Anteil der kritischen Assets mit erreichbarem Owner, Ingestion-Frische, Reaktionszeit auf Aufgaben und Nutzung des zertifizierten Dashboards. Diese Evidenz entscheidet über die Skalierung.

Einfachste tragfähige Implementierung

Scope für vier Wochen

Starten Sie nicht mit allen Domains. Wählen Sie einen Flow mit sichtbarem Consumer-Nutzen, fünf bis fünfzehn Assets und einem Konflikt, den Beteiligte tatsächlich lösen wollen. Benennen Sie:

1. eine Consumer-Entscheidung,
2. einen Domain Owner und einen Steward,
3. einen Platform Owner für Ingestion,
4. autoritative Quellen je Metadatentyp,
5. zwei bis vier nachweisbare Vertrauenssignale,
6. eine Eskalationsfrist,
7. einen Review-Termin.

Konfigurieren Sie nur die OpenMetadata-Objekte, die diese Vereinbarung unterstützen. Eine Domain, ein kleines Data Product, relevante Teams und Owner, wenige Glossarbegriffe sowie Ingestion-Status reichen. Breite Taxonomien, komplexe Policy-Automation und flächendeckende Zertifizierung können warten.

Review-Cadence

Ein wöchentliches 30-Minuten-Review genügt im Pilotprojekt. Geprüft werden offene Aufgaben, fehlgeschlagene Ingestion, ungeklärte Verantwortung, neue Schemaänderungen und Consumer-Feedback. Monatlich bewertet das Team, ob SLO, RACI oder Scope angepasst werden müssen. Quartalsweise kann die Domain die Gültigkeit zertifizierter Assets bestätigen.

Der Review ist kein Statusmeeting. Jede offene Frage braucht Entscheidung, Owner und Termin. Wiederkehrende Ausnahmen werden entweder als akzeptierte Grenze dokumentiert oder in den Standard überführt.

Anti-Patterns und klare Grenzen

Schein-Governance

Ein zentrales Council, das Namenskonventionen beschließt, aber keinen konkreten Datenkonflikt lösen kann, erzeugt Schein-Governance ohne Wirkung. Ebenso problematisch sind hundertprozentige Verantwortung-KPIs, die durch generische Sammelaccounts erreicht werden. Messen Sie Erreichbarkeit und Reaktion, nicht nur ausgefüllte Felder.

Zertifizieren Sie keine Assets allein wegen vollständiger Beschreibungen. Kopieren Sie keine Glossarbegriffe massenhaft auf Tabellen, wenn niemand ihre Verwendung prüft. Modellieren Sie nicht jede Organisationseinheit als Domain. Und machen Sie Plattformadministratoren nicht zu fachlichen Freigebern.

Katalog ist nicht Betrieb Durchsetzung

OpenMetadata dokumentiert Kontext, Policies, Klassifikationen und Verantwortlichkeit. Je nach Integration kann es Workflows auslösen oder Metadaten zurückspielen. Die effektive Zugriffskontrolle liegt jedoch typischerweise in Warehouse, Lakehouse, BI, IAM oder Datenfreigabeplattform. Maskierung, Row-Level Security, Löschung, Retention und Credential Rotation müssen dort implementiert und getestet werden.

Im Katalog sollte deshalb für jede relevante Regel stehen: Was ist die fachliche Absicht? Welches System setzt sie durch? Wer betreibt die Kontrolle? Welche Evidenz bestätigt ihre Wirksamkeit? So wird der Katalog zum Navigationspunkt für Governance, ohne falsche Sicherheit zu erzeugen.

Abgrenzung zu Connectors und Getting Started

Dieses Betriebsmodell ersetzt keine Connector-Auswahl, Authentifizierung oder Produktionsarchitektur. Connector-Entscheidungen beantworten, welche Metadaten zuverlässig verfügbar werden. Getting Started beantwortet, wie OpenMetadata installiert und ein erster Service eingerichtet wird. Das Operating Model beantwortet, wie Menschen mit diesen Informationen Entscheidungen treffen und Verantwortung tragen.

Technische Breite ist kein Ersatz für fachliche Tiefe. Ein sauber betriebener Sales-Flow liefert mehr Lernwert als 50 halb konfigurierte Services ohne Owner. Erst das Betriebsmodell gibt der Connector-Roadmap eine Priorität.

Hilfe beim Umsetzen

Führen Sie einen 90-minütigen Working Session mit Domain Owner, Steward, Data Engineer, Platform Owner und einem echten Consumer durch. Bringen Sie einen konkreten Asset-Pfad mit. Arbeiten Sie nicht zuerst am Organigramm, sondern an einer Entscheidung, die heute Zeit oder Vertrauen kostet.

In den ersten 30 Minuten formuliert der Consumer die Entscheidung und zeigt den aktuellen Umweg. Danach markieren die Beteiligten Assets, autoritative Quellen und Durchsetzung Points. Im letzten Drittel werden RACI, Evidenz, Reaktionszeiten und Review-Cadence festgelegt. Alles, was nicht für das Pilotprojekt nötig ist, kommt auf eine spätere Liste.

Übertragen Sie das Ergebnis in OpenMetadata und in einen kurzen Decision Record. Testen Sie anschließend mit einer Person, die nicht im Workshop war: Findet sie das richtige Asset, versteht sie Bedeutung und Einschränkungen, erreicht sie den Owner und erkennt sie den tatsächlichen Durchsetzung Point? Wenn nicht, ist das Modell noch nicht betriebsfähig.

Checkliste

• Eine konkrete Nutzer- oder Betriebsentscheidung definiert den Umfang.
• Platform Owner, Domain Owner, Steward und Nutzer sind namentlich oder als erreichbare Teams benannt.
• Für kritische Entscheidungen existiert genau eine accountable Rolle.
• RACI, Reaktionszeiten und Eskalationsweg sind dokumentiert.
• Für Schema, Lineage, Definitionen, Klassifikationen und Nutzung ist je eine autoritative Quelle festgelegt.
• Ingestion besitzt verantwortliche Person, Umfang, Zeitplan, Monitoring und ein Frische-SLO.
• Kritische Assets zeigen Definition, verantwortliche Person, Lineage, Qualität und bekannte Einschränkungen.
• Zertifizierung basiert auf überprüfbarer fachlicher und technischer Evidenz.
• Betrieb Durchsetzung Points sind benannt und werden nicht mit Katalog-Metadaten verwechselt.
• Ein realer Nutzer hat den Flow ohne Workshop-Unterstützung getestet.
• Review-Cadence und Skalierungskriterien sind vereinbart.
• Ausnahmen besitzen verantwortliche Person, Begründung und Ablauf- oder Review-Datum.

Artefakt

Das Ergebnis ist ein einseitiger Governance Operating Model Record:

• Decision und Umfang: Welche Entscheidung wird für welche Nutzer und Assets verbessert?
• Decision Rights: Wer entscheidet Definition, Zertifizierung, Qualitätspriorität, Schemaänderung und Eskalation?
• RACI: Accountable, Responsible, Consulted und Informed pro kritischem Vorgang.
• Autoritative Quellen: Herkunft von Schema, Lineage, Definition, Klassifikation, Nutzung und Richtlinien.
• Operating Nachweis: Ingestion-Frische, Tests, Lineage, Nutzung, Freigabe und bekannte Einschränkungen.
• Durchsetzung Map: Fachliche Regel, ausführendes System, kontrollOwner und Prüfnachweis.
• Serviceversprechen: Ingestion-SLO, Reaktionszeiten und Supportkanal.
• Cadence: wöchentlicher Betriebsreview, fachliche Rezertifizierung und Eskalationsforum.
• Ausstieg Assumptions: Bedingungen, unter denen das Pilotprojekt skaliert, geändert oder beendet wird.

Der Record ist kein separates Governance-Handbuch. Er verlinkt auf die entsprechenden OpenMetadata-Entities und wird bei relevanten Änderungen aktualisiert.

Tools

• OpenMetadata-Domain- und Produkt-Generator — Domain-/Produkt-Steckbrief und Verantwortung-Felder.
• OpenMetadata-Ingestions-Generator — Ingestion als Betriebsprodukt im Operating Model.
• Governance Starting-Point Decision — Einstieg und Rollengrenzen.

Ressourcen

• OpenMetadata-Dokumentation
• OpenMetadata: Domains und Data Products
• OpenMetadata: Teams und Users
• OpenMetadata: Ingestion
• OpenMetadata: Data Quality