Multi-Stack Governance im Überblick

Entscheidung

Definiere einmal die globalen Outcomes und Policies, mappe sie dann auf stack-spezifische Controls. Dupliziere keine Owner, KPI-Definitionen oder Freigabegremien.

Workflow

1. Stacks und gemeinsame Datenprodukte inventarisieren. 2. Globale Entscheidungen markieren. 3. Lokale Durchsetzung-Punkte mappen. 4. Nachweisformat normalisieren. 5. Abweichungen zentral triagieren.

Handoffs

Anti-Patterns

Je Plattform neue Policies schreiben; Produkte als Gewinner ausrufen; zentrale Standards mit identischer Technik verwechseln; Ausnahmen lokal verstecken.

Umsetzung im Alltag

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 — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

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.

Wähle ein Datenprodukt auf zwei Stacks, mappe Owner, Metrik und drei Controls, normalisiere einen Nachweis und entscheide eine Abweichung im bestehenden Forum.

Das Zielbild

Der praktische Leitsatz lautet: zentral entscheiden, lokal ausführen, gemeinsam nachweisen. Zentral gehören das Datenprodukt, sein accountable Owner, Geschäftsbedeutung, Qualitätsziele, Klassifikation, Aufbewahrungsabsicht, Zugriffskriterien und Ausnahmebefugnis. Lokal bleiben Rollen, Maskierungsfunktionen, Jobs, technische Tests, Laufzeitüberwachung und Recovery. Lokal bedeutet nicht ungebunden; jedes technische Control referenziert eine gemeinsame Policy oder einen gemeinsamen Contract.

Eine Entscheidungslandkarte macht die Grenze sichtbar. Erfasse je Governance-Objekt die autoritative Entscheidung, den lokalen Durchsetzung-Punkt, den Custodian und die erwartete Evidenz. So wird eine Datenbankrolle nicht versehentlich zur zweiten Zugriffspolicy und ein lokaler Spaltenname nicht zur zweiten fachlichen Definition.

Gearbeitetes Beispiel: Customer Margin

Ein Händler berechnet „Customer Margin“ im Warehouse und stellt dieselbe Kennzahl in einer Lakehouse-Umgebung für Data Science bereit. Historisch pflegen zwei Teams getrennte Definitionen, Owner und Zugriffslisten. Abweichungen landen in zwei Monatsrunden. Snowflake, Fabric oder Databricks könnten dabei technische Umgebungen sein; für das Governance-Design ist entscheidend, dass keine davon die Bedeutung besitzt.

Im Zielmodell gibt es eine Produkt-ID, eine Metric-ID und einen Domain Owner. Der Metric Contract legt Grain, Währung, Retourenlogik und Periodenabschluss fest. Beide Plattformteams bauen je einen Adapter. Die Datenschutzpolicy fordert Maskierung der Kunden-ID außerhalb einer berechtigten Rolle. Die konkrete Technik darf differieren. Beide Stacks liefern jedoch denselben Nachweistyp: Policy-ID, Control-ID, Scope, letzter Test, Ergebnis, Zeitstempel und Custodian.

Weicht ein Ergebnis ab, eröffnet das Plattformteam keinen lokalen Governance-Fall. Es meldet über denselben Ausnahmeprozess an den Domain Owner. Dieser entscheidet, ob ein Implementierungsfehler, eine zulässige technische Differenz oder eine Contract-Änderung vorliegt. So bleiben zwei technische Wege möglich, ohne zwei Steuerungsmodelle zu erzeugen.

Sizing nach Organisationsgröße

SMB/SME: Beginne mit einem Produkt über zwei Stacks, einem Owner und drei Policies. Eine gepflegte Policy-Control-Tabelle genügt zunächst. Das bestehende Management- oder Datenforum entscheidet Ausnahmen. Plane je Plattform einen technischen Custodian und etwa einen halben Koordinationstag pro Woche ein.

Mid-Market: Nutze ein leicht föderiertes Modell. Ein Governance Lead pflegt Templates, Domain Owner entscheiden fachlich, Platform Owner liefern Mappings und Evidenz. Pro priorisierter Domain sind zehn bis zwanzig kritische Produkte realistisch. Automatisiere Statusrückmeldungen, bevor manuelle Nachweise wachsen. Ein monatliches Entscheidungsforum reicht, wenn operative Fehler asynchron triagiert werden.

Enterprise: Führe Registries für Policies, Produkte, Metriken und Owner sowie Crosswalks zwischen Catalogs und Plattform-IDs. Lege Mindestkontrollen nach Risikoklasse fest. Platform Councils dürfen technische Standards beschließen, aber keine zweite fachliche Verantwortung etablieren. Assurance prüft Stichproben und Trends. Skaliere domainweise statt über ein Big-Bang-Harmonisierungsprogramm.

Umsetzung in sieben Schritten

1. Produkte inventarisieren. Verfolge Quellen, Transformationen, Konsum und Durchsetzung über alle berührten Stacks.
2. Entscheidungsrechte markieren. Benenne für Bedeutung, Qualität, Zugriff, Aufbewahrung und Ausnahmen jeweils genau einen Accountable.
3. Gemeinsame IDs vergeben. Produkt-, Policy-, Metric- und Ausnahme-IDs verbinden technische Objekte zuverlässig.
4. Controls mappen. Dokumentiere je Stack lokales Objekt, Custodian, Testfrequenz und erwarteten Nachweis.
5. Evidenz normalisieren. Vereinheitliche Status, Scope, Zeitstempel und Ergebnis, nicht zwangsläufig jedes Rohformat.
6. Konflikte testen. Simuliere Metrikabweichung oder Zugriffsdrift und beobachte den echten Eskalationsweg.
7. Doppelarbeit entfernen. Schließe lokale Boards, Listen und Freigaben, sobald der gemeinsame Prozess trägt.

Handoffs mit Abnahmekriterien

Der Governance Council übergibt Policy, Risikoappetit und Entscheidungsrechte an den Domain Owner. Abgenommen ist der Schritt, wenn Intent und Ausnahmebefugnis eindeutig sind. Der Domain Owner übergibt Produktcontract und Control-Anforderung an Platform Owner; Scope und Frist müssen bestätigt sein. Technical Custodians liefern normalisierte Evidenz an Assurance. Diese akzeptiert sie nur mit ID, Ergebnis, Freshness und Verantwortlichem. Drift geht anschließend in das bestehende Forum zurück, inklusive Entscheidung und Follow-up.

Der Rhythmus bleibt bewusst leicht: wöchentliche technische Triage, monatliche fachliche Entscheidungen und quartalsweise Modellkontrolle. Eine neue Sitzung pro Plattform ist kein Reifezeichen.

Anti-Patterns und Gegenmaßnahmen

Plattform als Governance-Domain: Ein neues Tool erhält automatisch eigene Owner und Policies. Scope stattdessen über Produkte und Risiken.

Identische Konfiguration erzwingen: Teams kopieren Rollenmodelle trotz anderer Plattformfähigkeiten. Standardisiere Outcome, Test und Evidenz.

Twin Ops im Übergang: Alte und neue Freigaben bleiben „zur Sicherheit“ aktiv. Jede Doppelung braucht Owner, Kosten, Ablaufdatum und Abschaltkriterium.

Lokale Ausnahmen verstecken: Konflikte bleiben in Tickets oder Chat. Nutze eine gemeinsame Ausnahme-ID und Rückmeldung an den Domain Owner.

Tool-Ranking statt Governance: Der Pilot wird zum Produktwettbewerb. Bewerte Kontrollabdeckung, Nutzerwert, Aufwand und Betriebsfähigkeit.

Arbeitscheckliste

• Datenprodukte und Stack-Berührungspunkte sind bekannt.
• Jede Entscheidungsklasse hat genau einen Accountable.
• Gemeinsame Produkt-, Richtlinie- und Metric-IDs existieren.
• Lokale Kontrollregeln referenzieren die gemeinsame Richtlinie.
• Evidenz enthält Umfang, Status, Testzeitpunkt und verantwortliche Person.
• Abweichungen laufen durch einen gemeinsamen Prozess.
• Kein Stack besitzt ein paralleles fachliches Council.
• Übergangsdoppelungen haben ein Abschaltdatum.
• Nutzer sehen Bedeutung und Freshness unabhängig vom Stack.
• Aufwand für manuelle Nachweise wird gemessen.

Umsetzung im Alltag

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 — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

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.

In Woche eins wählst du ein relevantes Produkt und inventarisierst Owner, Metrik, Policy und bestehende Foren. In Woche zwei definierst du drei globale Outcomes und mapst je Stack die Controls. In Woche drei normalisierst du Qualitäts- und Zugriffsnachweis. In Woche vier simulierst du Drift, lässt sie im bestehenden Forum entscheiden und entfernst mindestens einen doppelten Prozess.

Bis Tag 60 erweiterst du auf drei bis fünf Produkte derselben Domain, automatisierst Statusrückmeldungen und misst Durchlaufzeit, manuelle Übergaben sowie offene Ausnahmen. Bis Tag 90 nimmst du eine zweite Domain hinzu und prüfst, ob lokale Listen geschlossen wurden. Das Scale-Gate verlangt aktuelle Evidenz, benannte Accountables, Ausnahmefristen und keine dauerhafte doppelte Freigabe.

Verwandte Playbooks

Vertiefe das Modell mit Ein Verantwortung-Modell über alle Plattformen, Geteilte Metriken über mehrere Stacks, Grenzen zwischen Catalog und Control Plane und Multi-Stack-Pilot ohne Twin Ops.

Messgrößen für den laufenden Betrieb

Miss nicht die Zahl gepflegter Policies als Erfolg. Aussagekräftiger sind die Zeit von Drift bis Erkennung, die Zeit von Eskalation bis Entscheidung, der Anteil aktueller Evidence, offene Ausnahmen nach Frist und manuelle Stunden pro Produkt. Ergänze den Anteil kritischer Produkte mit eindeutiger Produkt-, Policy- und Metric-ID. Diese Größen zeigen, ob das gemeinsame Modell tatsächlich Entscheidungen beschleunigt und Doppelarbeit reduziert.

Ein einfaches Monatsreview betrachtet fünf Fragen: Welche gemeinsamen Entscheidungen wurden lokal unterschiedlich umgesetzt? Wo fehlt ein Control-Mapping? Welche Evidence ist veraltet? Welche temporäre Doppelung hätte bereits beendet werden müssen? Welche Consumer erhielten widersprüchliche Bedeutung oder Status? Jede rote Antwort erhält einen bestehenden Owner und Termin, kein neues Gremium.

Dokumentiere außerdem bewusst, was nicht vereinheitlicht wird. Unterschiedliche Job-Orchestrierung, Speicherformate oder Monitoring-Werkzeuge können sinnvoll sein, solange Contracts und Outcomes bestehen. Diese Non-Goals schützen Teams vor unnötiger Standardisierung und halten das Governance-Modell auf Entscheidungen, Risiken und überprüfbare Resultate fokussiert.

Veröffentliche diese Non-Goals zusammen mit den gemeinsamen Mindeststandards. Dadurch erkennen neue Teams früh, welche Entscheidungen verbindlich sind und wo sie technische Gestaltungsfreiheit besitzen.