Data Engineering — der Fabric + Mesh Hybrid

Arbeitsentwurf — Prüfung vor Veröffentlichung. Dieser Grundpfeiler trägt die Fabric-Hälfte von Cordatas Argument über Datenplattformen. Die Mesh-Hälfte — organisatorische Adoption, Domain-Ownership, kultureller Wandel — liegt im Governance-Grundpfeiler (ebenfalls in Arbeit).

Datenplattformen können aus vielen Gründen scheitern — zwei stechen heraus

Ein DACH-Versicherer im Mittelstandssegment entscheidet Anfang 2023, seinen Analytics-Stack zu konsolidieren. Snowflake gewinnt die Evaluierung. Ein achtköpfiges Team migriert in vierzehn Monaten 200 Pipelines, baut 40 Dashboards neu und konsolidiert das Master-Datenmodell. Der Go-live landet termingerecht und im Budget. Es gibt Sekt.

Achtzehn Monate später laufen etwa die Hälfte dieser Pipelines noch ihre nächtlichen Ladevorgänge. Die andere Hälfte wurde von den Fachbereichen, für die sie gebaut worden waren, abgekündigt und durch bereichseigene Ad-hoc-SQL und Excel-Exports ersetzt, die die Plattform komplett umgehen. Zwei Dashboards wurden im letzten Quartal angerührt. Das Master-Datenmodell wurde bereits im ersten Jahr eingefroren, weil zu niemandes Aufgabe gehörte, es zu betreuen.

Wir bei Cordata haben dieses Muster über die Jahre immer wieder gesehen — in Variationen, quer durch Banking, Versicherung und Telekommunikation, als Engineers auf diesen Projekten. Der Vendor-Logo wechselt. Der Consultancy-Logo wechselt. Die zwei Fehlerarten nicht:

(a) Die Organisation war nicht bereit, ihre Struktur an eine Arbeitsweise anzupassen, bei der die Datenplattform im Mittelpunkt steht. Ownership blieb zentral; die Fachbereiche, die die Daten produzierten, akzeptierten nie Produktverantwortung dafür; Schatten-IT blieb billiger als Plattformnutzung.
(b) Die Plattform war nicht metadatengetrieben genug, um mit dem Wachstum handhabbar zu bleiben. Jede neue Pipeline war ein Custom-Build; jede Zugriffsanfrage lief durch eine Ticket-Queue; der Katalog driftete innerhalb eines Quartals nach dem Launch von der Realität ab.

Die üblichen Ausreden — falscher Vendor, falsche Cloud, unzureichendes Training, schlechtes Change-Management — sind nachgelagerte Symptome dieser beiden. Das eigentliche Problem: Die Branche verkauft weiterhin Halb-Antworten auf ein Zwei-Hälften-Problem.

Warum ausgerechnet DACH-Mittelstand — und warum jetzt

Zwei Begriffe müssen zuerst geklärt werden.

Data Fabric ist eine technische Architektur, die verteilte Daten durch aktive Metadaten, automatisierte Lineage, einheitlichen Katalog und Policy-as-Code-Zugriff vereinheitlicht — nennen Sie es die Maschinerie.

Data Mesh ist ein Betriebsmodell, in dem jeder Fachbereich seine Daten als Produkt mit SLAs und Konsumenten besitzt, während das zentrale Team Self-Service-Werkzeuge statt Gates bereitstellt — nennen Sie es die Verantwortlichkeit.

Fabric adressiert Fehlerart (b); Mesh adressiert (a). Alles Folgende setzt beide voraus.

Zwei Kräfte lassen die beiden Fehlerarten im DACH-Mittelstand härter zuschlagen als anderswo — und eine davon ist neu.

DORA ist neu. Der Digital Operational Resilience Act ist im Januar 2025 in Kraft getreten, die Durchsetzung ist Ende 2025 scharfgestellt worden. Für alles, was EU-Finanzdienstleistungen berührt, verlangt er, in einfachen Worten:

ein kritisches ICT-Asset-Inventar, das jederzeit aktuell sein muss
Incident-Reporting mit Downstream-Blast-Radius-Analyse innerhalb enger regulatorischer Fristen (Sie müssen innerhalb von Stunden wissen, was ausfällt, wenn Komponente X ausfällt)
bedrohungsgeführte Resilienz-Tests gegen dieses Inventar
einen Third-Party-Processor- und Data-Flow-Katalog mit vertraglich durchsetzbaren Exit-Strategien

Jeder dieser Punkte ist eine Data-Fabric-Fähigkeit, die reife Teams sowieso aus technischen Gründen aufgebaut haben. DORA verlangt nicht, dass Sie neue Dinge bauen; DORA verlangt, dass Sie beweisen können, dass die vorhandenen Dinge vollständig, aktuell und einem Aufseher auf Zuruf vorlegbar sind. DORA verschiebt Data Fabric von „nice to have" zu „Aufsichtsbefund, wenn nicht vorhanden".

Die älteren Kräfte sind nicht verschwunden:

BaFin- und FINMA-Auslagerungsvorschriften machen zentrale Gatekeeping-Modelle zu einem faktischen Compliance-Ansatz, der jenseits von hundert Pipelines schlecht skaliert.
Betriebsrats- und Personalratsdynamiken verwandeln zentrale RBAC-Änderungen in Kalendermonate statt Sprints; dezentralisiertes Ownership verkleinert den Scope und beschleunigt die Zustimmung.
DSGVO-Rechenschaftspflicht bei Datenverarbeitungen belohnt föderiertes Ownership: Nur wenn jeder Fachbereich seine eigenen Verarbeitungsverzeichnisse (RoPA) pflegt, bleibt das Ganze im Maßstab aktuell. Ein zentrales Register driftet.
On-prem-Legacy, die auf absehbare Zeit nicht verschwinden wird, macht Hybrid-Architektur zur Realität, mit der man arbeiten muss — nicht zu einer Aspiration, aus der man herauswächst.

Jede dieser Kräfte verstärkt beide Fehlerarten. Zusammen mit DORA machen sie den Fabric + Mesh Hybrid — als Stack betrachtet, nicht als Shopping-Liste — zur einzigen stabilen Antwort für einen DACH-Mittelständler heute.

Das korrelierte Scheitern

Die Branche behandelt die beiden Fehlerarten als unabhängige Variablen. Vendors verkaufen Ihnen Data-Mesh-Workshops oder Data-Fabric-Plattformen; Beratungen bieten Strategie-Engagements oder Implementierungs-Engagements. Jede Hälfte ist ein reales Produkt mit einer verteidigbaren These. Keine der beiden Hälften hat für sich allein je verhindert, dass sich die Geschichte weiter oben abspielt.

Warum beide Hälften gebraucht werden, lässt sich in einem Satz sagen — einem Satz, den Sie der nächsten Vendor-Folie entgegenhalten können:

Eine perfekt automatisierte Plattform, die keine Domäne besitzt, ist ein verlassenes Museum. Ein perfektes Ownership-Modell auf einer manuellen Plattform ist ein verschlossener Engpass.

Automatisierung ohne Ownership entartet zu Stagnation: Jede Pipeline ist technisch in Ordnung, und niemand fühlt sich verantwortlich dafür, ob sie noch eine Geschäftsentscheidung unterstützt. Ownership ohne Automatisierung entartet zu Gatekeeping: Jede Schema-Änderung ist technisch verantwortet und bewegt sich in der Geschwindigkeit der Ticket-Queue. Keine dieser Formen ist stabil, und keine ist das, wonach eine ernstzunehmende Datenplattform 2026 aussieht.

Der Rest dieses Grundpfeilers zeigt, wie Data Mesh und Data Fabric sich zu einer Antwort zusammensetzen, warum die Komposition mehr ist als die Summe ihrer Teile, und was Cordata sich als Ersatz zu verkaufen weigert.

Data Mesh — kurz gefasst

Data Mesh, 2019 von Zhamak Dehghani geprägt und ab 2023 Mainstream, ruht auf vier Prinzipien: domänenorientiertes Ownership (das Fraud-Team besitzt Fraud-Events; das Policy-Team besitzt den Policy-State; nicht „das Datenteam besitzt alles"); Data-as-Product (SLAs, Doku, Versionierung, Auffindbarkeit — dieselbe Disziplin wie bei einer öffentlichen API); Self-Service-Plattform (das zentrale Team stellt Werkzeuge bereit; Domänen konsumieren sie ohne Tickets); und föderierte computational Governance (Regeln gelten überall, werden aber gemeinsam vereinbart, nicht von einer zentralen Instanz verordnet).

Data Mesh zu adoptieren, ohne Teamstrukturen und Anreize zu ändern, ist der teuerste Weg, einen Monolithen zu behalten. Der Governance-Grundpfeiler (in Arbeit) entfaltet die organisatorische Seite — die RACI-Verschiebungen, die Anreizänderungen, die Betriebsrats-Gespräche, die kulturelle Arbeit, die eine Umbenennung nicht ersetzt. Dieser Grundpfeiler setzt Ownership als gegeben voraus und wendet sich der Maschinerie zu.

Data Fabric — kurz gefasst

Data Fabric ist eine technische Architektur, kein Produkt. Es ist die Schicht, die eine verteilte Datenlandschaft — Multi-Cloud, On-prem, hybrid — überhaupt handhabbar macht. Fünf Fähigkeiten tragen sie:

Aktive Metadaten — Metadaten, die kein Wiki sind. Schemata, Frische-Signale, Datenqualitätsprüfungen, Drift-Alarme leben als First-Class-Bürger, werden von Pipelines aktualisiert und nicht per Hand eingetippt.
Einheitlicher Katalog — ein Ort, an dem jedes Datenprodukt zu finden ist, über Clouds und On-prem hinweg. Katalogeinträge werden aus der Quelle generiert (dbt-Modelle, Delta-Table-Eigenschaften, Snowflake information_schema) — nicht separat gepflegt.
Automatisierte Lineage — jede Transformation meldet ihre Inputs und Outputs; der resultierende DAG beantwortet „was speist diesen KPI stromaufwärts?" und „was bricht, wenn ich diese Spalte ändere?" ohne menschlichen Eingriff.
Knowledge-Graph-Überlagerung — Entitäten und Beziehungen über Domänen hinweg (Kunde ↔ Police ↔ Schaden) als Graph, nicht als Tabellenliste. Ermöglicht semantische Suche, Impact-Analyse und (zunehmend) LLM-gestützte Retrieval-Zugriffe.
Policy-as-Code-Zugriff — Berechtigungen in versionsverwalteter Konfiguration (Open Policy Agent, LakeFormation-Permissions, Unity-Catalog-Grants), wie Code reviewt, automatisch angewendet.

Werkzeuge, die das heute realisieren, nicht erschöpfend: OpenLineage + Marquez oder DataHub für Lineage + Katalog; Atlan, Collibra, Alation für Enterprise-Katalog + Governance-UX; AWS LakeFormation + DataZone, Databricks Unity Catalog, Microsoft Purview für Cloud-native Governance; Open Policy Agent für querschnittliche Policy. Dieser Grundpfeiler weigert sich, einen Sieger zu küren — der Begleitartikel zu AWS diskutiert den LakeFormation + DataZone vs. Unity Catalog-Kompromiss in Produktivform.

Der Hybrid — wie sie sich zusammensetzen

Fabric und Mesh lösen unterschiedliche Hälften desselben Problems. Zusammengesetzt schließen sie beide. So sieht die Komposition aus:

Diagramm-Ausleseversion. Drei Schichten, von unten nach oben. Das Data-Fabric-Substrat (unten) enthält den einheitlichen Katalog, den Aktive-Metadaten- + Lineage-Graphen, die Policy-as-Code-Engine und die Self-Service-Provisionierungs-Oberfläche — das ist, was das zentrale Plattformteam baut und betreibt, und es exponiert drei Schnittstellen zur darüberliegenden Schicht: ein Katalog-SDK zum Registrieren von Datenprodukten, eine Provisionierungs-API zum Ausrollen von neuem Storage / Compute / Zugriffsberechtigungen und eine Policy-Engine, gegen die die Domänen selbst schreiben. Das Data Mesh (Mitte) ist ein Knoten pro Fachbereich — Fraud, Policy, Schaden usw. — jeder veröffentlicht ein oder mehrere Datenprodukte über diese Schnittstellen. Ein Datenprodukt ist ein versioniertes Schema plus SQL- oder API-Endpunkt plus Dokumentation plus deklarierte SLA, im Katalog registriert, damit Konsumenten es finden. Die Konsumenten-Schicht (oben) sind alle, die diese Produkte lesen: Analytics-Teams, ML-Modelle, Downstream-Domänen, externe Partner.

Fabric ist das Substrat. Das zentrale Plattformteam baut und betreibt Katalog, Lineage-Graph, Policy-Engine und Self-Service-Provisionierungs-Oberfläche. Es besitzt keine Daten. Es besitzt die Sanitärarbeit, die es Domänen erlaubt, Daten sicher im Maßstab zu besitzen.

Mesh ist das Betriebsmodell. Fachbereiche — Fraud, Policy, Schaden, Marketing, Finanzen usw. — besitzen jeweils ein oder mehrere Datenprodukte. Sie veröffentlichen über den Katalog, deklarieren SLAs und Konsumenten, registrieren Lineage, drücken Zugriffs-Policies als Code aus. Sie besitzen den Inhalt ihrer Daten — Korrektheit, Aktualität, Bedeutung — weil sie die Systeme besitzen, die die Daten produzieren.

Die entscheidende Eigenschaft ist: Fabric ist was das Plattformteam baut, Mesh ist wie die Domänen es konsumieren. Fabric ohne Mesh ist eine Self-Service-Plattform ohne Mieter. Mesh ohne Fabric ist eine Aspiration auf einer Folie. Die Komposition ist kein Kompromiss zwischen zwei Ideologien; sie ist die Form, die die Antwort immer schon hätte annehmen müssen, sobald beide Fehlerarten gelöst werden mussten.

Die Komposition konzentriert außerdem die DORA-Compliance an der richtigen Stelle: Die Fabric hält das technische Inventar (Assets, Lineage, Third-Party-Datenflüsse), nach dem ein Aufseher fragt; das Mesh hält die Verantwortlichkeit (wer welches Produkt besitzt, wer Risiken akzeptiert, wer Änderungen abzeichnet), nach der ein Aufseher ebenfalls fragt. Keine Seite allein beantwortet DORA.

Was jede Hälfte der anderen schuldet

Die Komposition ist nur unter einem beidseitigen Vertrag stabil. Beide Hälften haben nicht verhandelbare Verpflichtungen gegenüber der anderen.

Fabric schuldet Mesh:

Self-Service-Provisionierung eines neuen Datenprodukts in unter einem Tag, nicht einem Sprint — sonst umgehen Domänen die Plattform.
Pro-Domäne Kontingent- und Kostentransparenz, damit eine Domäne die Frage „gebe ich Budget für die richtigen Dinge aus?" ohne Anfrage an das zentrale Team beantworten kann.
Drift-Alarme auf den betroffenen Fachbereich gescoped, nicht in einen zentralen Posteingang gesprüht, den niemand liest.
Eine Policy-Engine, gegen die Domänen selbst schreiben können, nicht nur konsumieren — eine Policy-Sprache, die Domain-Engineers direkt beherrschen, schlägt eine, die eine zentrale Team-Übersetzung erfordert.

Mesh schuldet Fabric:

Produktverantwortung für jedes Datenprodukt: SLA deklariert, Doku aktuell, Konsumenten gelistet, Versionierung eingehalten, Breaking Changes angekündigt.
Katalog-zuerst: Schemata und Lineage fließen durch den Katalog, nicht via DM an nachgelagerte Teams.
Föderierte Governance-Entscheidungen werden durchgesetzt, nicht umlobbyiert — wenn die Community sich auf eine Regel einigt, erfordern Ausnahmen denselben Governance-Weg wie die Regel selbst.

Wo eine Seite ihren Teil des Vertrags nicht mehr erfüllt, entartet die Komposition zu Fehlerart (a) oder (b) aus dem ersten Abschnitt. Cordata-Engagements beginnen damit zu prüfen, welche Verpflichtungen bereits erfüllt sind, welche aspirational sind und welche stillschweigend zusammengebrochen sind — denn genau das bestimmt, ob die Plattform reparabel ist oder eine Neu-Gründung braucht.

Leitplanken, keine Quality Gates

Cordatas Position zur Governance: Automatisierung macht Fachbereiche schneller und sicherer und zwingt sie nie durch einen zentralen Engpass.

Die Unterscheidung ist konkret. Ein Gate ist eine Ticket-Queue des zentralen Teams für Schema-Änderungen — jede Änderung wartet auf Review, und die Review-Kapazität ist fest. Eine Leitplanke ist ein CI-Check auf die Schema-Änderung, der fehlschlägt, wenn sie einen nachgelagerten Konsumenten brechen würde, und durchgeht, wenn nicht. Gates schützen durch Veto und werden zu dem Engpass, den sie verhindern sollten. Leitplanken schützen durch Information — das Domain-Team erfährt sofort, was seine Änderung bewirken würde, und passt sie entweder an oder koordiniert das nachgelagerte Update.

Jedes Governance-durch-Veto-System, das Cordata auditiert hat, ist innerhalb eines Jahres in Schatten-IT-Workarounds entartet, weil die Veto-Queue ihre menschliche Kapazität schnell übersteigt. Governance-durch-Information skaliert mit der Plattform, weil die Information automatisch aus denselben aktiven Metadaten generiert wird, die die Fabric ohnehin pflegt. Das ist einer der Gründe, warum die aktive Metadaten-Fähigkeit tragend ist.

Was Cordata sich weigert zu verkaufen

Cordata weigert sich, (a) Strategie-Engagements ohne Umsetzungsverantwortung zu verkaufen — oder (b) Plattform-Builds ohne einen organisatorischen Adoptionsplan. Beide Absagen kommen aus Erfahrung.

Strategie ohne Umsetzung ist eine Foliensammlung. Sie überlebt den Workshop, wird herumgereicht und ist sechs Monate später stillschweigend ignoriert, wenn die empfohlenen strukturellen Änderungen mit den Q3-Zielen von jemandem kollidieren.

Umsetzung ohne Adoption ist ein Museum. Sie geht termingerecht live, gewinnt einen internen Award und stagniert. Die Fachbereiche, für die sie gebaut wurde, umgehen sie weiterhin, weil niemand sie gefragt hat, was sie brauchen, und weil nach dem Go-live keine Ownership-Anreize gesetzt wurden.

Cordata bringt beides mit, weil beide Fehlerarten korreliert sind. Wir sind bereit, den Deal zu verlieren, wenn ein Klient nur eine Hälfte will — weil wir wissen, wie diese Geschichte endet, und es ist kein Klient, dem das Engagement hilft.

DACH-spezifische Anknüpfungspunkte

Der DACH-Mittelstand hat regulatorische und organisatorische Realitäten, die Fabric + Mesh besonders passend machen. Kurz gefasst:

DORA (Digital Operational Resilience Act) — seit Januar 2025 müssen EU-Finanzdienstleister ein jederzeit aktuelles kritisches ICT-Asset-Inventar führen, Incident-Berichte mit Downstream-Blast-Radius-Analyse innerhalb enger Fristen liefern, sich bedrohungsgeführten Resilienz-Tests (TIBER-EU) unterziehen und einen Third-Party-Processor- und Data-Flow-Katalog mit Exit-Strategien halten. Jeder Punkt entspricht direkt einer Fabric-Fähigkeit.
BaFin- und FINMA-Auslagerungsvorschriften — zentrales Gatekeeping ist ein faktisches Compliance-Modell, das jenseits von hundert Pipelines schlecht skaliert. Föderiertes Ownership skaliert sauber.
Betriebsrats- und Personalratsdynamiken — die Zustimmungsdauer für eine Datenzugriffsänderung skaliert mit dem Scope der Änderung. Dezentralisiertes Ownership verkleinert Scope und damit auch die Zustimmungszeit pro Änderung.
DSGVO-Rechenschaftspflicht bei Datenverarbeitungen — pro-Domäne geführte Verarbeitungsverzeichnisse bleiben im Maßstab aktuell. Ein zentrales Register driftet.
Multinationale Organisationsstrukturen — HQ München, Betrieb Zürich, Backoffice Bratislava ist ein häufiges Muster. Ein zentrales Team kann das nicht halten.
On-prem-Legacy, die noch ein Jahrzehnt nicht verschwindet — Hybrid-Architektur ist eine zu entwerfende Realität, keine Aspiration, aus der man herauswächst.

Der Governance-Grundpfeiler (in Arbeit) entfaltet die organisatorische Seite jedes Punkts: Betriebsratspfade, Pflege der Verarbeitungsverzeichnisse (RoPA), DORAs Berichtskette bis in die Geschäftsleitung.

Wo KI in einem Fabric + Mesh Hybrid hingehört

KI gehört ins Fabric-Substrat, als Aktive-Metadaten-Infrastruktur. Konkret:

Agentische Datenkataloge, die Typen inferieren, PII-Kandidaten am Ingest klassifizieren, Drift erkennen, wenn sich die Verteilung einer Quelle verschiebt, und Lineage-Verbindungen zwischen ähnlich benannten Spalten über Domänen vorschlagen.
Natürliche-Sprache-Lineage-Anfragen — „was speist stromaufwärts den quartalsweisen Regulator-Bericht?" — beantwortbar von einem LLM, das im Lineage-Graphen gegroundet ist, ohne dass ein Mensch durch einen DAG-Viewer klickt.
LLM-gestütztes Schema-Mapping beim Landing einer neuen Quelle — das Modell schlägt Spalten-Mappings gegen das kanonische Schema der Domäne vor, ein Mensch reviewt, das Mapping wird Katalog-Metadaten.
Automatisierte Dokumentation — aus Lineage plus Query-Mustern kann der Katalog erste Entwürfe der Doku für ein Datenprodukt generieren, die die zuständige Domäne verfeinert.

Es gibt ein weiteres Stück, das der Hybrid braucht, bevor KI-Konsum sicher ist: eine semantische Schicht — eine regierte, versionierte Definitionsebene (dbt Semantic Layer, Cube, Malloy), die über den Datenprodukten liegt und typisierte Metriken mit besitzergeführter fachlicher Bedeutung exponiert. Agenten, die rohes SQL abfragen, halluzinieren Joins und missdeuten Spalten; Agenten, die eine semantische Schicht abfragen, fragen nach monthly_recurring_revenue je Dimension und erhalten die Definition — die eine, versionsverwaltet in Git, verantwortet von einem Fachbereich. Cordatas Position: die semantische Schicht ist nicht optional, wenn die Plattform KI-Konsumenten bedienen soll. Ein Begleitbeitrag behandelt sie im Detail.

Jeder dieser Punkte muss sich verdienen. Das Muster, das wir ablehnen, ist „wir haben KI hinzugefügt, weil alle das tun" — das LLM, das an einen Workflow geklebt wird, den es nicht verbessert, dessen einzige messbare Wirkung eine Token-Rechnung ist. Wenn das KI-Feature nicht eine konkrete Menschenstunde pro Woche einspart oder nicht die mittlere Zeit bis zur Erkennung einer konkreten Fehlerklasse verkürzt, gehört es nicht in die Plattform. Der Governance-Grundpfeiler (in Arbeit) behandelt die Kehrseite — wo KI innerhalb von Governance-Workflows hingehört.

Wo KI nicht hingehört

KI gehört auf die Plattform. Sie gehört nicht in Entscheidungspfade, die Compliance-Artefakte erzeugen, und sie gehört niemals in eine Form, die die Plattform in einen verdeckten Datenexfiltrations-Kanal verwandelt.

Nicht LLMs verwenden, um Datenzugriffsanfragen automatisch zu genehmigen. Der Audit-Trail überlebt kein LLM in the loop.
Nicht agentische Systeme Domain-übergreifende Datenteilungs-Entscheidungen treffen lassen. Teilungsentscheidungen sind Governance-Entscheidungen und gehören zu Menschen mit benannter Verantwortlichkeit.
Nicht Vektor-Speicher mit Produktivdaten in Drittanbieter-APIs einbetten — die Daten verlassen Ihre Compliance-Grenze in dem Moment, in dem sie den Embedding-Aufruf betreten. Wenn Retrieval-augmented Use-Cases legitim sind, betreiben Sie die Embedding-Infrastruktur innerhalb der Grenze.

Jeder DACH-Interessent, mit dem wir über KI-Features gesprochen haben, stellt diese Fragen innerhalb der ersten fünfzehn Minuten. Sie überzeugend zu beantworten ist Grundvoraussetzung.

Referenzimplementierung — Vorschau

Der Fabric + Mesh Hybrid lässt sich auf jeder großen Cloud sauber bauen. Cordatas kanonische Referenzimplementierung läuft auf AWS: LakeFormation + DataZone für Governance und die Domain-Publishing-Oberfläche, mit Databricks Unity Catalog für Fälle, in denen Multi-Cloud-Lineage eine Rolle spielt.

Die Entscheidung, die dieser Grundpfeiler bewusst nicht trifft: ob LakeFormation + DataZone oder Unity Catalog die richtige primäre Governance-Schicht für einen bestimmten Shop ist. Sie konkurrieren; sie ergänzen sich nicht. Die Falle ist, beide gleichzeitig zu betreiben und sie um dieselbe Governance-Rolle streiten zu lassen.

Der Begleitartikel — Fabric + Mesh auf AWS geht den Kompromiss mit echtem Terraform, einer zweischichtigen DataZone-Segmentierung (Plattform-verantwortete Wurzel, Fachbereichs-verantwortete Sub-Domänen), der Katalog-über-Katalogen-Falle und den drei DACH-spezifischen Compliance-Checkpoints entlang. Er ist eine geteilte Referenz — derselbe Walkthrough wird auch aus dem kommenden Governance-Grundpfeiler als dessen Governance-Ebenen-Begleiter verlinkt. Lesen Sie ihn für den „wir haben das gebaut, nicht nur gezeichnet"-Beweis.

Wann Fabric + Mesh die falsche Antwort ist

Fabric + Mesh Hybrid ist für mindestens drei Shop-Formen falsch, und etwas anderes zu behaupten verbrennt das Geld des Klienten:

Single-Domain-Shops, in denen „die Organisation" ein Team von zehn Personen ist. Es gibt kein Mesh zu bauen — alle besitzen alles, und einer Gruppe, die in einen Slack-Kanal passt, Data-Mesh-Vokabular überzustülpen, ist Theater. Eine gut geführte zentralisierte Plattform ist die richtige Antwort.
Greenfield-Teams unter sechs Engineers. Der Fabric-Overhead — Katalog, Lineage, Policy-Engine — kostet in dieser Größenordnung mehr aufzusetzen, als die manuelle Koordination ersetzt. Wachsen Sie hinein. Nach sechs Monaten neu prüfen.
Enge Single-Source-of-Truth-Anforderungen, insbesondere im aufsichtsrechtlichen Reporting, wo eine kanonische Zahl existieren muss. Zentrales Ownership dieser Scheibe ist oft die richtige Antwort auch innerhalb eines Fabric + Mesh Shops. Der Grundpfeiler verbietet Zentralisierung nicht; er verbietet die Zentralisierung von allem.

Ein Grundpfeiler, der nie „nein" sagt, ist nicht verteidigbar. Dieser tut es.

Cordatas Einsatzmodell

Cordata-Engagements beginnen mit einer gemeinsamen Diagnose, welche Fehlerart derzeit dominiert. Das ist ein zweiwöchiges Discovery: Architekturreview der aktuellen Plattform, strukturierte Interviews mit zwei Fachbereichen und einem zentralen Team, eine ehrliche Karte, wo (a) und (b) heute jeweils sitzen.

Danach sind Engagements auf 6–12 Wochen begrenzt, nicht offen. Deliverables sind immer beide:

Organisatorisch — ein RACI für Datenprodukt-Ownership, Entscheidungsrechte über die föderierte Governance, ein Change-Plan, den der Betriebsrat abnehmen kann.
Technisch — Katalog + Lineage + Policy-Engine in Produktion, ein oder zwei Domänen end-to-end onboarded als Referenzform.

Handover-first. Jedes Engagement baut unsere Ersetzbarkeit ins Lieferergebnis ein. Der Maßstab eines erfolgreichen Engagements ist, ob das Team des Klienten die Plattform sechs Monate später ohne uns erweitern kann.

Wenn das nach einem Fit für das aussieht, was Sie bauen, nehmen Sie Kontakt auf — das erste Gespräch ist ein 30-minütiges Discovery-Gespräch, kostenfrei.