Argonos neben BIG 5: Multi-Platform ohne Authority-Drift

Lösung: Erlaube bewusst unterschiedliche technische Umsetzung je Plattform.

In einem Satz: Erlaube bewusst unterschiedliche technische Umsetzung je Plattform.

Problem

Argonos ersetzt selten Snowflake, Fabric, Databricks, BigQuery oder den klassischen Warehouse-/Lakehouse-Stack. Typisch ist Koexistenz: Analytics und Reporting im BIG-5-/OSS-Umfeld, Decision und Intelligence auf Argonos, Quellen in ERP, CRM, Fachsystemen und offenen Quellen. Ohne Authority-Matrix entstehen doppelte Glossare, widersprüchliche Klassifikationen und unklare Owner bei jeder Kopie.

Der teuerste Effekt ist Authority-Drift an den Übergaben. Dieselbe Kennzahl heißt in Argonos anders als im Warehouse. Dieselbe PII-Klasse ist in der Decision-Fläche strenger maskiert als im Export. Derselbe Product Identifier existiert nur auf einer Seite. Jede Plattform wirkt lokal konsistent — und die Landschaft widerspricht sich global.

Hybrid- und Multi-Cluster-Muster aus dem CDP-Kontext gelten analog für Decision-Plattformen neben Analytics: Hybrid und Multi-Cluster. Das übergreifende Prinzip: Governance über mehrere Plattformen. Vorarbeit in dieser Serie: Evidence Pack, Betriebsgrenze.

Entscheidung

Erlaube bewusst unterschiedliche technische Umsetzung je Plattform. Gemeinsam müssen sein: Klassifikation, fachliche Rollen, Schutzziele, Product Identifier, Nachweisanforderungen und Ausnahmeprozess. Plattformspezifisch dürfen sein: Policy-Syntax, Workspace-Modell, Durchsetzung-Punkte und Betriebsverfahren.

Jede Kopie und jeder Export ist eine Übergabe von Accountability — mit Owner, Klassifikation, Zweck und Review. Eine Kopie ohne benannten Owner und ohne bestätigte Klassifikation gilt als nicht freigegeben und darf keine produktiven Consumer haben.

Nutze eine Authority-Matrix als Landkarte, nicht als Wunschdiagramm. Wo kein gemeinsames Control Plane möglich ist, wird Drift dokumentiert: Begründung, kompensierendes Control, Owner, Wiedervorlage. Bekannte Drift ist besser als unerreichbare Uniformität.

Der Pilot umfasst ein Datenprodukt über Argonos und genau eine Analytics-Plattform (zum Beispiel Warehouse oder Lakehouse) — nicht die gesamte BIG-5-Landschaft. Erfolgreich ist er, wenn Product Identifier, Klassifikation und Handover Owner auf beiden Seiten übereinstimmen und Drift namentlich geführt wird.

Scope und Abgrenzung

Scope-in sind alle Plattformen, in denen das Pilotprodukt oder seine Kopien liegen — inklusive nichtproduktiver Umgebungen mit echten Daten. Scope-in sind die Übergabepunkte: Ingest nach Argonos, Export nach BI/Warehouse, Replikation, Shared Storage und manuelle Dateipfade.

Scope-out sind Plattformen ohne Kopie und ohne Zugriff auf produktive Quellen, die nur über eine kontrollierte Schnittstelle konsumieren. Sie werden registriert, aber nicht in den Pilot gezogen. Scope-out ist auch die Vereinheitlichung aller Durchsetzung-Techniken: Das Ziel ist gemeinsame Aussage, nicht identische Syntax.

Ausdrücklich nicht Ziel ist „Argonos ersetzt den Catalog“ oder „das Warehouse beerbt Decision-Semantik“. Competing Authorities müssen sichtbar bleiben, bis eine Entscheidung getroffen ist — siehe Authority Matrix in der Praxis.

Rollen und Entscheidungsrechte

• Enterprise Data Governance: ist autoritativ für Klassifikationen, Schutzziele und das fachliche Rollenmodell über Plattformen hinweg.
• Plattform-technischer Betreiber (Argonos / Analytics): setzt Kontrollregeln lokal um und meldet Drift.
• Data Owner: bleibt für den fachlichen Inhalt verantwortlich — auch für Kopien auf anderen Plattformen.
• Handover verantwortliche Person: verantwortet eine konkrete Übergabe inklusive Klassifikation, Consumern und Evidenz.
• Plattformübergreifende Architektur: entscheidet, welche Plattform für welchen Zweckbereich maßgeblich ist.
• Nachweis verantwortliche Person: stellt sicher, dass der Nachweispaket beide Seiten der Übergabe referenziert.

Die häufigste Lücke ist der Handover Owner. Ohne ihn endet ein Export als technischer Job „grün“, während Accountability auf der Quellseite liegen bleibt und auf der Zielseite niemand bestätigt.

Authority-Matrix: Mindestset

Drift-Einträge nennen die abweichende Aussage, die maßgebliche Authority, das kompensierende Control und das Reviewdatum. Ohne maßgebliche Quelle entstehen zwei parallele Wahrheiten, die beide plausibel begründet werden können.

Übergabemuster

Source → Argonos

Ingest-Vertrag mit Klassifikation, Rechtsgrundlage/Herkunft, Refresh-Cadence und Löschkaskade. Fremd- und OSINT-Quellen brauchen Löschbarkeit vor dem ersten Workspace. Der Product Identifier entsteht oder wird übernommen — er wird nicht später „irgendwie“ nachgetragen.

Argonos → BI / Export

Freigegebenes Grain, Permitted Use, Masking-Erwartung und Revocation-Test. Ein Export ohne Widerrufstest ist eine einseitige Freigabe. Consumer bestätigen den neuen Pfad oder gelten als abgekündigt.

Argonos ↔ Warehouse / Lakehouse

Keine stille Doppelpflege von Metrics und Kennzahlen. KPI-Authority wählen und dokumentieren — siehe KPI Governance. Wenn das Warehouse unmaskiert auf dieselbe Quelle zugreift, die in Argonos maskiert konsumiert wird, ist das ein klassischer Übergabe-Blind-Spot.

Nichtproduktive Kopien und Sandboxes

Test- und Sandbox-Umgebungen mit echten Daten sind häufig die schwächste Stelle. Ohne Consumer-Register und schwächerem Schutz gelten sie als Scope-in der Multi-Platform-Governance — nicht als Ausnahme „nur Test“.

Gemeinsame Ebene versus lokale Drift

Die gemeinsame Ebene ist die Aussage: Klasse, Schutzziel, Zweck, Identifier, Nachweispflicht, Ausnahmeweg. Die lokale Ebene ist Durchsetzung: Rollen in Argonos, Grants im Warehouse, Workspace-Rechte, Tag-Policies.

Wo technische Vereinheitlichung fehlt, führt ein Drift-Register. Es ist keine Fehlerliste, sondern eine bewusste Landkarte — analog zum Muster in Hybrid und Multi-Cluster. Der wichtigste Eintrag ist die maßgebliche Quelle je Zweckbereich.

Praktisch reicht oft eine Seite pro Zweckbereich: „Maßgeblich ist X; Argonos übernimmt Y; Warehouse setzt Z um; Abweichung A ist bis Datum D akzeptiert.“ Wer mehr braucht, hat meist Competing Authorities noch nicht entschieden — und schreibt dann Prosa statt Matrix.

Evidence über Plattformgrenzen

Der Evidence Pack aus dem vorherigen Teil referenziert beide Seiten einer Übergabe: Policy-/Rollennachweis und Access-Test auf Argonos, entsprechendes Control und Test auf der Analytics-Seite, Residenznachweis je Dienst, Lineage inklusive Blind Spots. Eine Stichprobenrekonstruktion, die an der Plattformgrenze stoppt, ist unvollständig.

Der typische Fund: Auf Argonos ist der Deny-Test grün, im Warehouse existiert dieselbe Population unmaskiert für einen breiteren Analystenkreis. Beide Controls können lokal korrekt sein — der Pack muss den Widerspruch sichtbar machen, sonst gilt er als bestanden und ist es nicht.

Häufige Anti-Muster

Doppelte Catalog-Welten ohne Entscheidung

Zwei Glossare und zwei Klassifikationen ohne maßgebliche Authority erzeugen Drift, die niemand auflöst.

Export endet mit dem Job-Status

Ohne Übergabe von Owner, Klassifikation, Consumern und Revocation ist die Verlagerung governance-seitig offen.

KPI-Doppelpflege

Dieselbe Kennzahl in Argonos und Warehouse mit unterschiedlichen Definitionen ist ein Incident, der auf Folien gut aussieht.

Fremdplattform erbt Governance automatisch

Snowflake, Fabric, Databricks oder BigQuery setzen keine Argonos-Entscheidung durch. Jeder Übergabepunkt braucht ein eigenes Control.

Sandbox ohne Register

Kopien „zum Ausprobieren“ ohne Owner und Klassifikation sind produktive Schwachstellen mit schwachem Schutz.

Vereinheitlichung um jeden Preis

Jahre in Policy-Syntax-Harmonisierung investieren, statt gemeinsame Aussage und bekannte Drift zu führen, verzögert wirksame Governance.

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: Landschaft und Zweckbereichs

Plattformen mit Kopien des Pilotprodukts listen, zehn Kern-Zweckbereichs der Authority-Matrix besetzen, Handover Owner benennen.

Schritt 2: Maßgebliche Quellen

Je Zweckbereich die maßgebliche Authority festlegen, offene Konflikte als Drift-Einträge führen, Product Identifier plattformübergreifend vereinheitlichen.

Schritt 3: Übergaben absichern

Ingest- und Exportverträge für den Pilot, Revocation-Test, Nachfolge-Controls an der Grenze, Sandbox-Regeln.

Schritt 4: Evidence verbinden

Evidence Index um Querverweise zur Analytics-Seite erweitern, eine Stichprobe über die Grenze rekonstruieren.

Schritt 5: Standard festschreiben

Migrations-/Exportvorlage, Review-Cadence für Drift-Register, Backlog der ungelösten Competing Authorities.

Messung

• Anteil der Kern-Zweckbereichs mit eindeutig benannter Authority
• Anzahl und Alter der Drift-Einträge ohne Neubewertung
• Anteil der Übergabepunkte mit verantwortliche Person, Klassifikation und Nachfolge-Kontrollregel
• Anteil der Exporte mit dokumentiertem Revocation-Test
• Zeit bis zur Antwort „welche Kopie ist maßgeblich?“
• Anteil der Nachweis-Pack-Einträge mit Querverweis über die Plattformgrenze
• Anzahl nichtproduktiver Kopien mit echten Daten ohne Nutzer-Register

Checkliste

• Authority-Matrix für mindestens zehn Kern-Zweckbereichs ist beschlossen.
• Product Identifier ist plattformübergreifend identisch.
• Je Zweckbereich ist eine maßgebliche Authority benannt.
• Drift-Einträge haben verantwortliche Person, Begründung und Reviewdatum.
• Ingest-Übergabe hat Klassifikation, Refresh und Löschkaskade.
• Export-Übergabe hat fachliche Ebene, Permitted Use und Revocation-Test.
• KPI-/Metric-Authority ist eindeutig — keine stille Doppelpflege.
• Sandbox- und Testkopien mit echten Daten sind erfasst oder untersagt.
• Handover verantwortliche Person ist für den Pilot benannt.
• Nachweispaket referenziert Argonos- und Analytics-Seite.
• Eine Stichprobe über die Plattformgrenze wurde rekonstruiert.
• Competing Authorities sind sichtbar, nicht wegformuliert.
• BIG-5-/OSS-Durchsetzung ist lokal getestet, nicht „mitgemeint“.
• Review-Cadence für Drift-Register ist terminiert.

Artefakt

Das Ergebnis ist eine Landscape and Handover Map für Argonos neben dem Analytics-Stack. Sie listet je Plattform Custodian, enthaltene Produkte, Governance-Mindeststandard und offene Drift-Einträge. Ein zweiter Abschnitt beschreibt je Übergabepunkt fließende Daten, Klassifikation, Nachfolge-Control und Owner.

Ergänzt wird sie durch die Authority-Matrix (Export aus dem Builder) und durch die Export-/Ingest-Vorlage mit Abnahmekriterien: Klassifikation bestätigt, Consumer bestätigt, Revocation getestet, Evidence referenziert. Diese Vorlage schließt den häufigsten Verlustpunkt von Accountability.

Die Karte wird quartalsweise überprüft. Neue Plattformen, neue Exporte und neue Competing Authorities erzeugen eine neue Version.

Werkzeuge und Referenzen

• Authority Matrix Builder
• Architecture Fit
• Custom Stack Builder
• Governance Nachweis Register
• Governance über mehrere Plattformen
• Hybrid und Multi-Cluster (CDP)
• BIG 5
• Nachweispaket für Argonos
• Argonos als Betriebsgrenze
• Glossary: Data Mesh, Data Catalog, Data Governance