Ontologie, Metadaten und Lineage auf Argonos

zu, den Plattform-Graphen mit dem unternehmensweiten Catalog zu verwechseln. Ops-Semantik für ein Decision-Produkt wird zur stillen Business-Definition für das ganze Unternehmen. Doppelte Glossare entstehen, Klassifikationen widersprechen sich, und niemand kann sagen, welche Aussag.

Lösung: Lege fest, welche Metadata-Authority Argonos für welches Zweckbereich hat — und welche nicht.

In einem Satz: Lege fest, welche Metadata-Authority Argonos für welches Zweckbereich hat — und welche nicht.

Problem

Decision-Plattformen werben typischerweise mit Ontologien, Wissensgraphen und End-to-End-Traceability. Das ist wertvoll — und verleitet dazu, den Plattform-Graphen mit dem unternehmensweiten Catalog zu verwechseln. Ops-Semantik für ein Decision-Produkt wird zur stillen Business-Definition für das ganze Unternehmen. Doppelte Glossare entstehen, Klassifikationen widersprechen sich, und niemand kann sagen, welche Aussage autoritativ ist.

Die zweite Folge ist Lineage-Illusion. Traceability innerhalb von Argonos deckt typischerweise Ingest, Anreicherung und Arbeitsfläche ab. Exporte, Warehouse-Pipelines, manuelle Tabellen und parallele BI-Schichten bleiben unsichtbar — werden aber in Audits so behandelt, als wären sie „mitabgedeckt“. Die Organisation glaubt an End-to-End; tatsächlich existiert eine gut dokumentierte Insel.

Der dritte Fehler ist Ontologie als Dekoration: Entity-Typen wachsen, Beziehungen werden ad hoc ergänzt, Änderungen sind nicht versioniert, und Widersprüche zum Unternehmens-Glossary werden nicht als Gap geführt. Dann steuert die Ontologie Entscheidungen, ohne selbst governed zu sein. Konzept: Metadata, Catalog & Lineage, Multi-Stack: Governance über mehrere Plattformen, Vorläufer: Verantwortung und Stewardship auf Argonos.

Entscheidung

Lege fest, welche Metadata-Authority Argonos für welches Zweckbereich hat — und welche nicht. Eine Authority pro Zweckbereich. Duplikate nur mit explizitem Sync-Vertrag. Ontologie und Traceability sind Controls, wenn Owner, Versionierung, Product Identifier und Blind-Spot-Register existieren; sonst sind sie lokale Modellierungssprache.

Der Pilot umfasst ein Decision-Produkt in einem Tenant mit Ontologie-Ausschnitt, Product Identifier und Blind-Spot-Register. Erfolg: Eine unbeteiligte Person kann in unter 30 Minuten sagen, welche Metadatenaussage wo gilt, wie sie versioniert ist und wo Lineage bewusst endet.

Scope und Abgrenzung

Scope-in sind Metadaten und Lineage für ein Decision-Produkt: Ontologie-/Modell-Ausschnitte, Klassifikationen, die in der Plattform wirken, Traceability von Quelle bis Arbeitsfläche, Product Identifier in Graph/Metadaten und bekannte Blind Spots.

Scope-out sind vollständige Unternehmens-Catalog-Migrationen und Warehouse-Lineage-Ersatzprojekte. Bridge und Koexistenz: Bridge Solution, Einstieg: Argonos als Governance-Einstieg. Residenz der Metadaten-Stores und Supportzugriffe bleiben getrennte Nachweisspuren (Host vs Cloud).

Nicht Ziel ist „ein Graph für alles“. Ziel ist belastbare Authority und ehrliche Abdeckung — im Sinne der Eight Pillars.

Rollen und Entscheidungsrechte

• Metadata Authority verantwortliche Person (pro Zweckbereich): entscheidet, welches System die Wahrheit trägt.
• Ontology / Model verantwortliche Person: verantwortet Entity-Typen, Beziehungen und Änderungsprozess im Argonos-Umfang.
• Data Owner: bestätigt fachliche Bedeutung und erlaubte Nutzung der modellierten Objekte.
• Data Steward: hält Konflikte zu Glossary/Catalog sichtbar und bereitet Reviews vor.
• Platform technischer Betreiber: betreibt Anbindungen, Imports und technische Lineage-Erfassung.
• Nachweis verantwortliche Person: stellt Versionen, Bestätigungsdaten und Blind-Spot-Status auffindbar bereit.

Der Model Owner darf das Ops-Modell schärfen. Er darf nicht stillschweigend das Unternehmens-Glossary überschreiben. Konflikte werden als Gap geführt — nicht „im Graph bereinigt“.

Metadata-Authority-Matrix in der Praxis

Starte mit dem Ist-Zustand, nicht mit der Zielarchitektur. Nutze den Authority Matrix Builder und markiere unbekannte oder konkurrierende Authorities sichtbar. Typische Konflikte:

• Business-Term existiert im Catalog und als Label/Entity in Argonos mit abweichender Definition
• personenbezogene Daten-Tag in der Plattform ohne Bezug zur Privacy-Authority
• Lineage-Kante behauptet Vollständigkeit bis zum Nutzer, obwohl Export manuell läuft
• Product Identifier fehlt; Objekte sind nur über Anzeigenamen referenzierbar

Jede konkurrierende Authority braucht eine Entscheidung: Argonos lead, Catalog lead, oder Sync-Vertrag mit Richtung, Frequenz und Konfliktregel. Ohne Entscheidung bleibt Drift Programm.

Ontologie als Control, nicht als Dekoration

Eine Ontologie oder ein Domänenmodell ist governed, wenn:

• verantwortliche Person für Entity-Typen und Beziehungen benannt ist
• Änderungen versioniert und reviewbar sind
• Mapping zu Quellsystemen und Product Identifier existiert
• erlaubte Nutzung und Sensitivität referenziert — nicht neu erfunden — werden, wo eine andere Authority gilt
• Widersprüche zu Glossary/Catalog als Gap mit Owner und Frist geführt werden

Praktische Leitplanken:

• Stabile Identitäten vor hübschen Labels. Rename ohne Identifier bricht Lineage und Richtlinie-Bezüge.
• Weniger Typen, klarere Semantik. Ein überladenes Modell ohne verantwortliche Person ist schlechter als ein schmales mit Review.
• Änderungen wie Richtlinie-Änderungen behandeln, sobald das Modell Zugriff, Klassifikation oder Freigaben beeinflusst.

Ohne diese Regeln steuert die Ontologie Entscheidungen, ohne selbst entscheidbar zu sein.

Lineage und Blind Spots

Traceability innerhalb Argonos beantwortet: Welche angebundenen Quellen flossen wann in welche Arbeitsfläche? Sie beantwortet nicht automatisch: Wo liegen Exporte? Wer hat manuell angereichert? Welche parallele Pipeline im Warehouse speist dieselben Consumer?

Markiere systematisch:

• Quellen ohne Connector- oder Import-Nachweis
• Exporte und Downstream-Kopien
• manuelle Anreicherungen ohne Audit
• parallele Pipelines im Warehouse oder BI
• Support-/Admin-Eingriffe, die Daten oder Modelle ändern

Jede Kante außerhalb der Plattform ist eine Evidenzlücke, bis sie kontrolliert, bridged oder als akzeptiertes Restrisiko mit Ablauf geführt ist. Die Betriebsgrenze aus Teil 1 bleibt der Rahmen: Argonos als Betriebsgrenze.

Sync, Bridge und Multi-Platform

Wenn Argonos neben Catalog, Lake und Warehouse steht, ist Metadata-Koexistenz der Normalfall — nicht der Sonderfall. Wähle bewusst:

• Mirror: Argonos übernimmt ausgewählte Terms/Tags read-only
• Bridge: bidirektionaler Sync mit Konfliktregel und Steward-Review
• Federate: Verweis statt Kopie; Authority bleibt im Quellsystem

Kopien ohne Sync-Vertrag altern und widersprechen der Quelle. Das ist dasselbe Anti-Muster wie ein zentrales Nachweis-Kopierarchiv — nur für Semantik. Orientierung: Palantir und Argonos.

Häufige Anti-Muster

„Der Graph ist unser Catalog“

Ops-Semantik wird zur Unternehmensdefinition ohne Authority-Entscheidung. Doppelte Glossare und Audit-Streit folgen.

Lineage bis zur Plattformgrenze als End-to-End verkaufen

Exporte und parallele Stacks bleiben Blind Spots. Die Illusion ist gefährlicher als die Lücke.

Ontologie ohne Owner und ohne Version

Ad-hoc-Typen steuern Entscheidungen. Niemand kann sagen, welche Fassung wann galt.

Klassifikation lokal neu erfinden

PII-/Sensitivitäts-Tags in Argonos ohne Bezug zur Privacy-Authority erzeugen falsche Sicherheit.

Identifier nur als Anzeigename

Rename und Re-Ingest zerbrechen Lineage, Verantwortung-Spiegel und spätere Evidence Packs.

Sync ohne Konfliktregel

Zwei Systeme „stimmen überein“, bis der erste Widerspruch auftaucht — dann gewinnt der lauteste Ticket-Ersteller.

Umsetzung in 45 Tagen

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Argonos Governance
• Lernpfad — Argonos Governance

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Authority und Abdeckung klären

Für ein Decision-Produkt die Metadata-Zweckbereichs listen, Ist-Authorities eintragen, Ontologie-/Modell-Owner benennen, Product Identifier prüfen.

Schritt 2: Ontologie als Control schärfen

Änderungsprozess und Versionierung festlegen, Mapping zu Quellen und Product Record herstellen, Konflikte zum Catalog als Gap-Register öffnen.

Schritt 3: Lineage ehrlich machen

In-Plattform-Traceability gegen reale Pfade prüfen, Blind Spots benennen, mindestens einen Export- und einen parallelen Warehouse-/BI-Pfad bewerten.

Schritt 4: Sync oder Bridge entscheiden

Pro konkurrierendem Zweckbereich Mirror, Bridge oder Federate wählen, Konfliktregel und Review-Takt setzen, Nachtest der Abdeckung dokumentieren.

Messung

• Anteil der Metadata-Zweckbereichs mit eindeutiger Authority
• Anteil ontologischer Änderungen mit Version, Review und verantwortliche Person
• Anteil der Decision-Objekte mit stabilem Product Identifier
• Anzahl bekannter Lineage-Blind-Spots mit Status (kontrolliert / bridged / akzeptiert)
• Zeit bis zur Klärung „welche Definition gilt?“ durch eine unbeteiligte Person
• Anteil der Sync-/Bridge-Strecken mit dokumentierter Konfliktregel

Checkliste

• Metadata-Authority-Matrix deckt Glossary, Klassifikation, Ops-Semantik und Lineage ab.
• Pro Zweckbereich ist genau eine Authority gewählt oder ein Sync-Vertrag dokumentiert.
• Ontology-/Model-Owner und Änderungsprozess sind benannt.
• Änderungen am Modell sind versioniert und reviewbar.
• Product Identifier ist in Graph/Metadaten und Product Record identisch.
• Widersprüche zu Unternehmens-Catalog/Glossary sind als Gaps geführt.
• Lineage-Abdeckung ist gegen reale Pfade geprüft — nicht nur gegen Wunschdiagramme.
• Blind-Spot-Liste enthält Exporte, manuelle Schritte und parallele Stacks.
• personenbezogene Daten-/Sensitivitäts-Aussagen referenzieren die Privacy-Authority, wo sie gilt.
• Sync-/Bridge-Entscheidung (Mirror, Bridge, Federate) ist pro Konflikt dokumentiert.
• Nachweis für Modellversion und letzte Bestätigung ist auffindbar.
• Review-Termin für Authority-Matrix und Blind Spots ist gesetzt.

Artefakt

Das Ergebnis ist eine Metadata-Authority- und Lineage-Karte pro Decision-Produkt. Sie enthält Zweckbereich-Authority-Tabelle, Ontology-Owner und Versionsregel, Identifier-Mapping, Blind-Spot-Register, Sync-/Bridge-Verträge und das Datum der letzten Abdeckungsprüfung.

Ergänzt wird sie durch ein Gap-Register für Widersprüche zwischen Argonos-Modell und Unternehmens-Catalog. Das Register verhindert, dass Konflikte „im Graph verschwinden“.

Die Karte ist Betriebsvertrag. Authority-Wechsel, neue Exporte oder Modell-Breaking-Changes erzeugen eine neue Version und lösen gezielte Nachtests aus.

Werkzeuge und Referenzen

• Authority Matrix Builder
• Custom Stack Builder
• Architecture Fit
• Metadata, Catalog & Lineage
• Bridge Solution
• Argonos als Betriebsgrenze
• Verantwortung und Stewardship auf Argonos
• Argonos als Governance-Einstieg
• Governance über mehrere Plattformen
• Die 8 Säulen der Data Governance
• Palantir und Argonos — Vergleich