Thema
Data Governance
6 Beiträge zu diesem Thema
Data Governance — belegtes Verhalten, nicht Richtlinien auf Papier
Data Governance ist eine Menge von Entscheidungen über Daten — plus die Nachweise, dass diese Entscheidungen tatsächlich gelebt werden. Cordatas Betriebsmodell-Hälfte des Fabric + Mesh Hybrids, mit der DORA-Wende (persönliche Verantwortung auf Vorstandsebene), föderierter computergestützter Governance als Antwort und den DACH-Anforderungen (BaFin § 25b, Betriebsrat, DSGVO Art. 28-30), die sie erfüllen muss.
AI Readiness — ein Ergebnis von Data Governance, kein eigenes Programm
KI-Initiativen geraten meist aus einem von zwei Gründen ins Stocken, und der eine bringt oft den anderen hervor: Das Modell wird gewählt, bevor jemand sagen kann, welche Daten es rechtmäßig lesen darf, und die Antwort wird dann von einem parallelen KI-Governance-Programm hergestellt, dessen Register vom Verarbeitungsverzeichnis abdriftet, das es ergänzen sollte. Readiness ist eine Eigenschaft der Nachweise über die Daten, und die KI-Pflichten sind Projektionen dieser Nachweise.
Von der These zum Nachweis, hands-on — Cordatas OSS-Projekte
Unsere vier Open-Source-Tools, eine IBAN-Spalte: Der Katalog kennt jede Tabelle, die ihm gemeldet wurde, und die Lineage findet die Kopie, die nie registriert wurde. Jeder Schritt läuft ab pip install und ist so zitiert, wie die veröffentlichten Versionen ihn ausgeben.
Der Katalog ist die API — ein Governed Mesh über MCP
Die Fabric-+-Mesh-Referenz endete mit einem Versprechen: ein über MCP bereitgestelltes Katalog-Tool, das beantwortet, welche Sensitivitätsstufe für eine Spalte mit einer EU-IBAN gilt — aus der aktiven LF-Tag-Policy statt aus einem veralteten Wiki. Das ist dieser Entwurf. Tools gegen Resources als die Entscheidung, an der alles Weitere hängt, Output-Schemas aus dem bereits veröffentlichten Descriptor-Modell, warum eine Read-only-Hülle erzwungen und nicht annotiert werden muss, und warum die Autorisierung — nicht die Tool-Liste — die Governance-Ebene ist. Geprüft gegen MCP-Revision 2026-07-28.
Die Pipeline-Hälfte, Teil 2 — OpenLineage, Great Expectations und der Nachweis, den eine Pipeline emittiert
Teil 1 behandelte, was eine Pipeline liest. Dieser Teil behandelt, was sie emittiert — und warum genau das die ganze Governance-Geschichte ist: OpenLineage als herstellerneutrales Lineage-Rückgrat, der AWS-native Einführungspfad über die PostLineageEvent-API von DataZone, Assertion-Ergebnisse als Data-Quality-Facet, auf dem ein Grant ausgesetzt werden kann, und das Provenance-Facet, das die Prüferfrage „welcher Code hat diese Zahl erzeugt“ beantwortet. Dazu, warum der Scheduler zentral bleibt, während Compute dezentralisiert, und der eine Sprung, den diese Architektur nicht sieht. Durchgehend echte Payloads und echte Emitter-Konfiguration.
Behaviour-first Governance in der Praxis — Artefakte aus Plattform-Ereignissen erzeugen
Der Data-Governance-Grundpfeiler etabliert das Konzept: Artefakte sind Nebenprodukte von Verhalten, keine Lieferergebnisse an sich. Dieser Beitrag geht die vier Mechanismen durch, die es Realität werden lassen — RoPA aus Lineage, RACI aus Katalog-Eigentum, Audit-Bericht aus Subscription-Log und ein Änderungs-Autorisierungs-Workflow, in dem der Commit der Nachweis ist. Echtes Terraform, SQL und YAML durchgehend.