Governance in IT und Plattform — technische Obhut ohne falsche Verantwortung

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• 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.

Sizing: KMU — ein Betriebsvereinbarung und Isolation für das kritische Tool. Mid-Market — Steward für Inventar vs. Glossar. Enterprise — föderierte Workspaces, Publish-Gate ohne Semantik-Mandat.

Die Serie Governance auf der Datenplattform gibt dir den Einstieg und den roten Faden für die folgenden Teile. IT-Security verantwortet Grants, IT-Betrieb verantwortet Tool-SLO. Diese Landschaft hält Custodian ≠ Owner, Isolation, Inventar und Publish.

IT betreibt Systeme. Plattformteams bewegen, speichern, schützen und beobachten Daten. Deshalb sehen sie mehr Datenassets als fast jede andere Funktion.

KMU — ein Betriebsvereinbarung und Grants nur mit Sponsor. Mid-Market — Custodian-Pfad getrennt vom fachlichen A. Enterprise — Isolation und Berechtigungsprodukt, Semantik bleibt Fachbereich.

Diese Seite ist der Function-Schnitt, keine Landscape-Serie. Operating-Tiefe: Warehouse, Contracts, DQ auf der Plattform.

Diese Nähe führt zu einem gefährlichen Kurzschluss:

Wer die Plattform betreibt, sei Owner aller Daten auf der Plattform.

Das ist falsch. Technische Obhut ist Data Custodianship. Fachliche Verantwortung entscheidet über Zweck, Bedeutung, Risiko und Nutzung. Ein Custodian kann einen unsicheren Job stoppen. Er kann Backup und Recovery verantworten. Er kann Masking technisch erzwingen. Er darf aber nicht allein entscheiden, wofür Beschäftigten-, Kunden- oder Finanzdaten genutzt werden.

Custodian ist nicht weniger verantwortlich als Owner. Die Verantwortung liegt nur auf einer anderen Achse.

Konzept halten — Last-Säulen: Metadata und Access tragen diese Kette; Verantwortung ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierungskarte — Plattform setzt um — Semantik bleibt Fachbereich

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Lane-Kasten — IT/Plattform im Mischprojekt

Tiefe bleibt diese Serie. Übersicht: Lanes und Delegation.

Produkte und Entscheidungen

Ingestion-Service

Der Ingestion-Service bietet:

• Connectoren; Extraktionsmuster; Change Data Capture; Scheduling; Schema-Erkennung; Quarantäne; Betriebsüberwachung.

Plattformentscheidungen:

• Welche Connectoren werden unterstützt?; Welche SLOs gelten?; Wie werden Secrets verwaltet?; Was geschieht bei Schema Drift?

Domain-Entscheidungen:

• Welche Quelle wird geladen?; Welcher Zweck rechtfertigt den Umfang?; Welche Felder sind erforderlich?; Welche Daten dürfen nicht ingestiert werden?

Storage- und Compute-Service

Dieser Service umfasst:

• Warehouse; Lakehouse; Object Storage; Compute; Workspaces; Kostensteuerung; Backup.

Plattformentscheidungen:

• Isolation; Verschlüsselung; Lifecycle Richtlinien; Recovery; Skalierung; technische Quotas.

Domain-Entscheidungen:

• Retention; fachliche Kritikalität; zulässige Nutzer; akzeptables fachliches Risiko.

Transformation- und Orchestration-Service

Das Produkt bietet:

• Deployments; Scheduling; Tests; Lineage; Environments; Rückbau; Observability.

Der Service definiert technische Standards. Die Domain definiert fachliche Regeln und Abnahmekriterien.

Access- und Policy-Durchsetzung-Service

Der Custodian setzt um:

• Rollen; Gruppen; Grants; Row-Level Security; Column Masking; Tokenisierung; Logging; Rezertifizierungs-Workflows.

Der Owner entscheidet:

• Zweck; zugelassene Nutzergruppen; Freigaberegeln; Ausnahmen; Restrisiko.

Catalog- und Metadata-Service

Ein Plattformkatalog kann technische Metadaten erfassen:

• Datenbanken; Schemas; Tabellen; Spalten; Jobs; Lineage; Nutzung; technische verantwortliche Person; Quality-Signale.

Fachlicher Kontext kommt aus den Domains:

• Begriffe; Zweck; Data Owner; Data Steward; Produktstatus; Nutzungsbedingungen; Quality-Erwartungen; Zertifizierung.

Der Katalog ist ein gemeinsamer Service. Er ist nicht automatisch das Governance Operating Model.

Data-Product-Publishing-Service

Dieser Service ermöglicht:

• Produktregistrierung; Vereinbarung-Versionierung; Quality Gates; Dokumentation; Freigabe; Nutzer-Kommunikation; Deprecation.

Er trennt Plattformfähigkeit und Domain-Accountability.

Wo Governance hängt

Am Intake

Ein Ticket wie „Salesforce komplett laden“ enthält keine belastbare Entscheidung.

Der Intake muss mindestens fragen:

• Welcher Nutzer?; Welche Entscheidung?; Welche Grundgesamtheit?; Welcher fachliche Ebene?; Welche Aktualität?; Welche Sensitivität?; Welche Retention?; Welcher fachliche verantwortliche Person?

An der Grenze Source zu Product

Eine replizierte Quelltabelle ist noch kein konsumierbares Data Product.

Es fehlen häufig:

• stabile Semantik; Quality-Erwartung; Serviceversprechen; Nutzer-Schnittstelle; Change-Prozess; verantwortliche Person.

An Zugriffsfreigaben

Plattformteams erhalten Anträge und klicken Grants. Wenn die fachliche Freigabe fehlt, werden sie zu unfreiwilligen Risikoentscheidern. Der Workflow muss Owner-Entscheidung und Custodian-Umsetzung getrennt nachweisen.

An Schemaänderungen

Der Source Owner ändert ein Feld. Die Pipeline läuft weiter. Der Datentyp passt technisch. Die Bedeutung hat sich trotzdem geändert. Schema Drift Detection ersetzt keinen semantischen Contract.

An Incident Response

Ein technischer Incident und ein Data Incident sind nicht identisch.

Beispiele:

• Job fehlgeschlagen; Daten verspätet; Werte fachlich falsch; personenbezogene Daten unzulässig sichtbar; Definition widersprüchlich; Nutzer nutzte veraltete Version.

Der Custodian stabilisiert die Plattform. Der Owner entscheidet über fachliche Auswirkung und Nutzung. Der Steward koordiniert Kontext und Kommunikation.

An Kosten

Plattformkosten sind technisch messbar. Ihre Wertentscheidung ist fachlich. Der Custodian kann ineffiziente Workloads identifizieren. Der Product Owner priorisiert Optimierung. Der Owner oder Sponsor entscheidet über Nutzen und Budgetkonflikte.

Am Katalog

Automatisches Scanning erzeugt Inventar.

Es erzeugt nicht automatisch:

• verständliche Definitionen; Zweck; Verantwortung; Nutzungsbedingungen; Quality-Vertrag; Produktgrenzen.

Governance hängt, wenn Catalog Coverage mit Vertrauen verwechselt wird.

Rollen-Mapping

Data Custodian

In IT und Plattform ist Custodianship die zentrale Betriebsrolle.

Sie verantwortet:

• Plattformverfügbarkeit; Speicher; Compute; technische Zugriffsumsetzung; Verschlüsselung; Backup; Recovery; Monitoring; technische Audit Logs; Incident Response.

Der Custodian besitzt ein technisches Stop-Recht bei Sicherheits- oder Stabilitätsgefahr. Er setzt Policy um. Er erfindet keinen fachlichen Zweck.

Data Owner

Der Data Owner bleibt in der Business Domain. Für Plattform-Telemetrie kann IT selbst fachlicher Owner sein. Für Sales-, Finance- oder HR-Daten ist IT jedoch Custodian.

Der Owner entscheidet:

• wofür Daten genutzt werden; wer fachlich Zugriff erhalten darf; welche Qualität akzeptabel ist; welches Risiko getragen wird; wann ein Produkt eingeschränkt wird.

Data Steward

Der Steward verbindet Domain und Plattform.

Er:

• pflegt Definitionen; übersetzt Quality-Erwartungen; triagiert Issues; koordiniert Klassifikation; verfolgt offene Entscheidung der verantwortlichen Personen; hält Katalogkontext aktuell.

Ein zentraler Metadata Steward kann Standards unterstützen. Er ersetzt keine Domain Stewards.

Data Product Owner

Zwei Product-Owner-Typen müssen unterschieden werden:

• Platform Product Owner für Plattformfähigkeiten; Domain Data Product Owner für konsumierbare Datenprodukte.

Der Platform Product Owner priorisiert Self-Service, Reliability und Developer Experience. Der Domain Product Owner priorisiert Consumer-Value und fachlichen Lifecycle.

Data Architect

Der Architect steuert:

• Plattform- und Domain-Schnittstellen; fachliche Ebene; Data Vereinbarungen; Identitätsmuster; Cross-Domain-Modelle; Breaking Changes; Architekturleitplanken.

Architecture und Custodianship können in kleinen Teams dieselbe Person tragen. Die Entscheidungsarten bleiben getrennt.

Data Consumer

Consumer nutzen Plattformservices oder Datenprodukte.

Sie liefern Signale zu:

• Auffindbarkeit; Dokumentation; Qualität; Performance; Kosten; fehlenden Interfaces; ungeplanten Breaking Changes.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

SMB versus Enterprise

SMB

Ein SMB braucht eine kleine, verlässliche Plattformoberfläche.

Praktische Besetzung:

• Business Lead als Data Owner; Analyst als Steward und Nutzer; Analytics Engineer als Product Owner und Architect; IT Admin oder Cloud Engineer als technischer Betreiber.

Das Minimum:

• drei bis zehn kritische Produkte; ein einfacher Katalog; klarer Anfrageweg; rollenbasierter Zugriff; getestetes Backup; Job Monitoring; wenige Data Vereinbarungen;
• ein Incident-Kanal;
• dokumentierte Freigabe durch die verantwortliche Person.

Ein SMB sollte keinen Enterprise-Katalog ausfüllen. Eine versionierte Produktseite pro kritischem Produkt kann genügen. Die Plattform sollte wenige Golden Paths anbieten. Ausnahmen bleiben sichtbar.

Enterprise

Ein Enterprise benötigt Platform-as-a-Product und föderierte Domains.

Typische Struktur:

• Platform Product Owner;
• Plattform-Custodians je Service;
• Enterprise und Domain Architects;
• Domain Data Owner;
• Domain Stewards;
• Domain Product Owner;
• Security und Privacy als Kontrollregel Partner;
• Nutzer Communities.

Zentrale Plattformstandards:

• Identität und Zugriffsverwaltung;
• Logging;
• Verschlüsselung;
• Backup und Recovery;
• Deployment;
• Metadata APIs;
• Vereinbarung-Format;
• Observability;
• Kosten-Tags;
• Mindestkontrollen.

Domain Accountability:

• Zweck;
• Definition;
• Produkt-Umfang;
• Quality-Erwartung;
• Nutzer-Nutzung;
• fachliche Ausnahmen;
• Lifecycle.

Plattformkataloge sinnvoll schneiden

Ein einziger Katalog kann mehrere Sichten anbieten.

Technischer Service-Katalog

Er beschreibt:

• verfügbare Plattformservices;
• SLOs;
• Support;
• Kostenmodell;
• Onboarding;
• Grenzen;
• Betriebsstatus.

Asset-Inventar

Es erfasst automatisiert:

• Systeme;
• Tabellen;
• Spalten;
• Jobs;
• Lineage;
• Nutzung;
• technische Zustände.

Data-Product-Katalog

Er beschreibt konsumierbare Verträge:

• Zweck;
• verantwortliche Person;
• Steward;
• Nutzer;
• Interface;
• fachliche Ebene;
• Qualität;
• Zugriff;
• Version;
• Lifecycle.

Glossar

Es hält fachliche Begriffe und Beziehungen. Diese Sichten dürfen technisch integriert sein. Sie sollten konzeptionell nicht vermischt werden.

Kritische Übergaben

Mini-Fall

Anwendungsbeispiel (Lehrfall, keine Kundendaten).

Symptom: Das Plattformteam gilt als verantwortliche Person jeder Tabelle, weil es Grants sieht. Ein ungeprüfter Export läuft ohne Sponsor.

Typischer Fehlstart: Catalog-Coverage als Mandat verkaufen.

Vereinbarung: Technischer Betreiber und fachlich verantwortliche Person sind getrennt. Jede Zugriffsfreigabe braucht eine benannte fachliche Verantwortung. Für jedes produktive Tool gibt es eine Betriebsvereinbarung.

Anti-Patterns

Plattformteam als Owner aller Assets

Das verschiebt fachliches Risiko zu Personen ohne Mandat.

Katalog-Scan als fertige Governance

Inventar ist notwendig, aber nicht ausreichend.

Zugriffsticket ohne Owner-Freigabe

Der Custodian wird zum Schattenentscheider.

Jede Tabelle zum Data Product erklären

Ein Produkt braucht Consumer, Vertrag und Lifecycle.

Architect als Gatekeeper jedes Changes

Automatisierte Standards und risikobasierte Reviews skalieren besser.

Self-Service ohne Guardrails

Ohne Golden Paths entsteht Plattform- und Definitionssprawl.

Controls nur auf Folien

Ein Control braucht Ausführung, Evidenz, Owner und Review.

Backup mit Recovery verwechseln

Ein vorhandenes Backup beweist keine erfolgreiche Wiederherstellung.

Lineage ohne Impact-Prozess

Ein Graph hilft erst, wenn Änderungen Consumer erreichen.

Kosten dem Custodian allein zuschreiben

Technische Effizienz und fachlicher Wert brauchen gemeinsame Entscheidungen.

Mini-Scorecard

Bewerte jede Aussage mit 0, 1 oder 2 Punkten.

Grenzen

• technischer Betreiber und verantwortliche Person sind getrennt definiert.
• Platform- und Domain-Produkte sind unterscheidbar.
• technische und fachliche Entscheidungen haben eigene Freigaben.

Services

• Plattformservices besitzen SLOs und Supportpfade.
• Golden Paths sind dokumentiert.
• Backup und Recovery werden getestet.

Katalog und Contracts

• Inventar, Glossar und Produktkatalog sind klar geschnitten.
• kritische Produkte besitzen Vereinbarungen.
• Breaking Changes erreichen Nutzer.

Betrieb

• Incidents trennen technische und fachliche Auswirkungen.
• Zugriffe bleiben nachweisbar.
• Kosten- und Nutzungssignale fließen in Backlogs.

0–7 Punkte: zentraler Betrieb mit unklarer Accountability.

8–16 Punkte: stabile Plattform mit Governance-Lücken.

17–24 Punkte: föderierte, produktorientierte Plattform-Governance.

Erster Umsetzungsschnitt

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 — Datenplattform-Landscape
• Lernpfad — Datenplattform-Landscape

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.

Woche 1

• fünf kritische Plattform- und Domain-Produkte auswählen;
• technische und fachliche Entscheidungen trennen;
• heutige verantwortliche Person- und technischer Betreiber-Zuweisungen prüfen.

Woche 2

• Service- und Product Vereinbarungen skizzieren;
• Anfrageweg um Zweck, Owner und Retention ergänzen;
• Catalog-Sichten sauber benennen.

Woche 3

• einen Access Flow end-to-end testen;
• einen Schema Change simulieren;
• Restore und Incident-Eskalation prüfen.

Woche 4

• Wartezeiten, Ausnahmen und manuelle Übergaben messen;
• einen Golden Path verbessern;
• überflüssige Katalogpflichten entfernen;
• drei kritische Kontrollregeln mit Evidenz versehen.

Weiterlesen

• Rollen-Hub
• RACI für Data Governance
• Stewardship-Kapazität
• Serie: Mails & Dokumente vor KI

Weiter in dieser Serie: Betriebsvereinbarung pro Tool. Die Datenplattform-Landscape hat fünf Teile — Grants und Tool-SLO liegen in den Geschwister-Serien.