Das Daten Dilemma, Teil 1

This blog post is also available in English

TL;DR

• Wenn KI-Agenten scheitern, liegt es selten am Modell, sondern an den Daten: Semantik, Qualität und Kontext sind nirgends dokumentiert, sondern stecken im Erfahrungswissen der Fachbereiche.
• Data Mesh löst dieses Problem konzeptionell, überfordert mittelständische Unternehmen aber organisatorisch: fehlende Domain-Teams, Datenschnitt entlang von Standardsoftware, IT als reiner Unterstützungsprozess.
• Ein Minimum Viable Data Mesh (MVDM) übernimmt den Kern (Data as a Product, fachliche Ownership, explizite Contracts, konsequent auf die Konsumenten ausgerichtet) und vereinfacht oder verschiebt alles, was einen organisatorischen Umbau voraussetzt.
• Der Einstieg ist use-case-getrieben und schrittweise, mit etablierten Tools (dbt, MCP, Git, Contract-Format); Teil 2 zeigt die Umsetzung in vier Schichten.

Dieser Blogpost ist Teil einer Reihe.

• Teil 1: Das Daten Dilemma, Teil 1 (dieser Blogpost)
• Teil 2: Das Daten Dilemma, Teil 2

In Diskussionen über agentische Systeme geht es oft um Modelle, Frameworks und Orchestrierung. Daten erscheinen dabei schnell wie eine vorhandene Ressource, die man nur noch anschliessen muss. Wer agentische Use Cases in einem mittelständischen Unternehmen umsetzen will, erlebt meist etwas anderes: Das Modell ist selten das grösste Problem.

Agenten brauchen mehr als Tabellenzugriff. Sie brauchen Daten mit gutem Signal-to-Noise-Verhältnis, klarer Semantik, Beispielen und Metadaten zu Bedeutung, Aktualität und Zugriffsrechten. Sie müssen wissen, wofür Daten gedacht sind, welche Lücken sie haben und wann sie nicht belastbar sind. Ein Feld wie kunde_aktiv = true ist nur hilfreich, wenn klar ist, was „aktiv" fachlich bedeutet: letzte Bestellung im vergangenen Jahr, laufender Vertrag, nicht archivierter CRM-Eintrag oder etwas anderes. Genau diese Information ist in vielen Datenlandschaften nicht dokumentiert. Sie steckt in den Köpfen der Fachexperten.

Data Mesh als Zielbild

Konzeptionell liefert Data Mesh eine überzeugende Antwort auf dieses Problem. Die Verantwortung für Daten wandert zu den Produzenten, analog zu DevOps und API-First. Domänenteams verstehen ihre eigenen Daten am besten, kennen Migrationen und dokumentieren die Semantik. Sie liefern Daten als Produkt: mit Owner, Vertrag und Qualitätsversprechen.

Eine Plattform ermöglicht Data Discovery, idealerweise so, dass auch Agenten damit arbeiten können. Verträge sind explizit, Owner sind benannt, Annotation ist verbindlich. Wer eine neue Datenquelle braucht, findet sie über einen Katalog, liest die Beschreibung, prüft die Qualitätsindikatoren und konsumiert sie. Verantwortlichkeiten sind klar verteilt, Änderungen kommunizieren die Produzenten aktiv an ihre Konsumenten.

In so einer Umgebung können Agenten produktiv arbeiten. Viele Unternehmen sind davon allerdings weit entfernt.

Warum die meisten Firmen dort nicht ankommen

Wer Data Mesh in mittelständischen Unternehmen einführen will, stösst schnell auf praktische Grenzen.

Daten sind in den meisten Unternehmen nicht fachlich geschnitten, sondern entlang von Standardsoftware. Was in Salesforce liegt, gehört organisatorisch zu Salesforce, nicht zur Domäne Kunde. Was in SAP liegt, gehört zu SAP, nicht zu Logistik oder Finance. Der Datenschnitt folgt dem Lizenzvertrag, nicht der Fachlichkeit. Daneben existieren oft gewachsene Custom-Lösungen: alt, kaum gepflegt, aber fachlich wichtig. Das Wissen über diese Systeme lebt in den Köpfen der Mitarbeiter. Wenn eine Kundennummer komisch aussieht, weiss eine Kollegin, dass dieser Kunde noch aus der Zeit vor Salesforce stammt und seine Vertragsdetails in einem anderen System zu finden sind. Genau dieses implizite Wissen fehlt einem Agenten.

Und dieses Wissen ist fragiler, als man annehmen möchte. Es ist oft fragmentiert: Der Vertrieb weiss, was „aktiver Kunde" fachlich heisst, aber nicht, wie das Feld in der Salesforce-Replica befüllt wird. Der Entwickler, der die Custom-Lösung gebaut hat, ist seit drei Jahren nicht mehr im Unternehmen. Manche Verknüpfungsregeln existieren nur noch als Gewohnheit einzelner Personen, die kurz vor der Pensionierung stehen. Wer wartet, bis die Datenlandschaft transformiert ist, wartet möglicherweise, bis niemand mehr da ist, der sie erklären kann.

Den Fachteams, die ihre Daten semantisch verstehen, fehlt häufig das Engineering-Know-how, um sie als Produkt zu liefern. Sie wissen, was aktiver_kunde bedeutet, können aber keine Datenpipeline und kein technisches Datenmodell bauen. Den Engineering-Teams wiederum fehlt oft das fachliche Wissen, um die Daten korrekt zu interpretieren. Die Domain-Team-Konstellation, die Data Mesh voraussetzt, gibt es in vielen Unternehmen schlicht nicht.

Hinzu kommt ein organisatorisches Argument, das oft unterschätzt wird. In vielen produzierenden Unternehmen ist IT ein Unterstützungsprozess. Kritisch, ja, aber nicht unmittelbar wertschöpfend. Wer eine Transformation vorschlägt, die die Wertschöpfung verzögert oder belastet, wird dafür schwer Mehrheiten finden. Eine Dateninitiative muss sich deshalb über konkreten, kurzfristig sichtbaren Nutzen legitimieren.

Data Mesh bleibt eine sinnvolle Zielrichtung, ist für viele mittlere Unternehmen aber schwer zu erreichen. Es braucht eine Grösse und einen organisatorischen Reifegrad, den viele schlicht nicht haben.

Die Frage neu gestellt

Dieser Artikel richtet sich nicht an Firmen mit funktionierenden Domain Teams und Plattform-Engineering. Er richtet sich an alle anderen: an Unternehmen, die agentische Use Cases umsetzen wollen, aber nicht erst zwei Jahre warten können, bis ihre Datenlandschaft transformiert ist.

Die Frage lautet daher: Wie versorgen wir KI-Systeme mit Daten, die Agenten finden, verstehen und sicher einordnen können? Was ist ein Minimum Viable Data Mesh (MVDM), das den Kern von Data Contracts übernimmt, ohne die Organisation vorher umzubauen?

Ziel ist ein machbarer Einstieg: use-case-getrieben, schrittweise und ohne den Anspruch, zuerst die perfekte Zielarchitektur aufzubauen. Dieser erste Teil klärt, was ein MVDM aus Data Mesh übernimmt und was es bewusst weglässt. Die Umsetzung in vier Schichten folgt in Teil 2.

Was wir aus Data Mesh übernehmen, was wir vereinfachen

Ein Minimum Viable Data Mesh ist keine beliebige Light-Version von Data Mesh. Es ist eine bewusste Auswahl: Was vom ursprünglichen Konzept ist für agentenfähige Daten unverzichtbar, was kann zunächst vereinfacht werden? Wenn man diese Trennung sauber vornimmt, entsteht ein Ansatz, der fachlich tragfähig und organisatorisch machbar ist.

Was wir übernehmen. Das Kernkonzept Data as a Product bleibt. Jede kuratierte View, die wir bauen, ist ein kleines Produkt mit Owner, Beschreibung, Qualitätsversprechen und klar benannten Konsumenten. Eine schnell zusammengebaute SQL-Abfrage für den nächsten Use Case reicht nicht. Die View ist ein expliziter Vertrag mit dem Agenten als Hauptkonsumenten. Diese Disziplin entscheidet darüber, ob eine View nur technische Abkürzung ist oder als Datenprodukt betrieben werden kann.

Auch die fachliche Ownership bleibt erhalten. Die fachliche Hoheit über die Bedeutung der Daten liegt bei der Domäne, auch wenn die technische Umsetzung in der IT bleibt. Was aktiver_kunde bedeutet, entscheidet nicht der Datenbankadministrator, sondern der Vertrieb. Die Engineering-Arbeit lässt sich zentralisieren. Bei der Definitionshoheit wäre das ein Fehler. Diese Trennung ist entscheidend für die Qualität der Datenprodukte.

Der Self-Service-Gedanke bleibt, wird aber auf Agenten ausgerichtet. Das ursprüngliche Konzept zielte auf Self-Service-BI für Endnutzer. Für Agenten zählen vor allem strukturierte Metadaten und klar beschriebene Datenprodukte. Ein gut beschriebenes Datenprodukt ist für einen Agenten direkt nutzbar. Für Menschen braucht es oft zusätzlich eine UI.

Federated Computational Governance wird oft auf das föderierte Governance-Board verkürzt. Der Kern ist ein anderer: Governance-Entscheidungen sollen so nah wie möglich am Produkt getroffen und automatisiert im Code durchgesetzt werden. Data Contracts sind dafür das primäre Werkzeug. Genau diesen Kern behalten wir. Die Standards dafür, etwa für View-Metadaten, Naming-Konventionen und verpflichtende Tests, definiert und pflegt ein kleines zentrales Team. Was entfällt, ist der organisatorische Überbau: kein Governance-Board, keine Stewards-Organisation, keine regelmässigen Komitee-Sitzungen. Governance steckt im Entwicklungsprozess selbst: Templates, Linter, Tests und Code-Reviews ersetzen zusätzliche Abstimmungsrunden.

Was wir vereinfachen. Vollständige Domain Teams mit eigenem Plattform-Engineering sind in den meisten mittleren Firmen unrealistisch. Die Engineering-Arbeit bleibt bei einem kleinen zentralen Team, die Domänen liefern Semantik und Validierung. Das kostet Autonomie, macht die Umsetzung aber realistischer. Wer keine zehn Engineering-Teams aufbauen kann, sollte seine Architektur nicht so planen, als hätte er sie.

Polyglot Persistence, also die Freiheit jeder Domäne, ihre Storage-Technologie selbst zu wählen, vereinfachen wir ebenfalls. Ein gemeinsamer Data Store für alle Datenprodukte ist ohnehin die bessere Wahl, weil er die Interoperabilität der Datenprodukte sichert. In einem MVDM nimmt man dafür, was im Haus etabliert ist. Eine zentrale Postgres- oder Snowflake-Instanz reicht für den Anfang. Eine Warnung gehört allerdings dazu: Die Wahl des Stores ist eine Architekturentscheidung, die sich später nur teuer korrigieren lässt. Wer sie trifft, sollte die mittelfristigen Anforderungen mitdenken: erwartete Datenmengen, Zugriffsmuster und die Frage, ob neben strukturierten auch semistrukturierte oder unstrukturierte Daten anstehen.

Auch auf einen vollständigen Domain-Schnitt der Daten verzichten wir zunächst. Solange Standardsoftware die Realität diktiert, lassen sich Daten an der Quelle nicht entlang von Fachdomänen schneiden. Wir abstrahieren in der View-Schicht und lassen die Quellsysteme, wie sie sind. Die fachliche Abstraktion entsteht stattdessen in den kuratierten Views.

Auch die Plattform als Produkt stellen wir nicht an den Anfang. Eine echte Data-Plattform mit Self-Service-Onboarding für neue Datenprodukte ist ein eigenes grosses Projekt. Für den Einstieg reicht eine Kombination etablierter Werkzeuge: ein Transformations-Tool wie dbt, ein Agenten-Zugriffsprotokoll wie MCP, Git und ein Contract-Format. Wer später eine echte Plattform daraus bauen will, hat die richtigen Bausteine. Eine Plattform-Investition rechnet sich erst, wenn es genügend Datenprodukte gibt, die sie nutzen.

Damit bleibt der relevante Kern von Data Mesh erhalten: explizite Verträge und semantische Verantwortung nahe an der Domäne, beides konsequent auf die Konsumenten als Abnehmer ausgerichtet.

Was explizit nicht auf dem kritischen Pfad liegt

Ein Minimum Viable Data Mesh beruht auf bewusster Reduktion. Deshalb sollte klar sein, was nicht auf dem kritischen Pfad liegt:

• Kein zentrales Data Warehouse als Voraussetzung. Vielleicht entsteht später eines, vielleicht auch nicht.
• Keine flächendeckende Schema-Migration der Quellsysteme. Die Quellen bleiben, wie sie sind; die Abstraktion liegt in der View-Schicht.
• Keine Data-Governance-Organisation mit Boards und Stewards. Governance steckt im Entwicklungsprozess.
• Keine vollständige Lineage über alle Systeme. Vielleicht für die Curated Views, sicher nicht für die ganze Landschaft.
• Kein Self-Service-BI für Endbenutzer. Das ist ein anderes Problem mit anderen Anforderungen. Auch Agentenaktionen, Schreibzugriffe und transaktionale Sicherheit liegen ausserhalb des Fokus. Hier geht es zuerst um die Grundlage: Agenten müssen Daten überhaupt erst finden und korrekt einordnen können. Wer die weiterführenden Themen an den Anfang stellt, erhöht das Risiko langer Vorarbeiten ohne sichtbaren Nutzen.

Fazit und Ausblick

Data Mesh beantwortet die richtige Frage: Es macht Bedeutung, Qualität und Verantwortung von Daten explizit, genau das, was Agenten brauchen. Die Voraussetzungen dafür sind allerdings hoch: Domain Teams mit eigenem Engineering, eine Self-Service-Plattform, eine Governance-Organisation. Viele mittelständische Unternehmen erfüllen sie nicht und werden sie auf absehbare Zeit auch nicht erfüllen. Ein Minimum Viable Data Mesh setzt deshalb tiefer an. Es behält Data as a Product, fachliche Ownership und explizite Contracts bei. Die organisatorischen Voraussetzungen ersetzt es durch einfachere Mittel: ein kleines zentrales Engineering-Team, die Datenbank, die ohnehin im Haus ist, eine View-Schicht über den unveränderten Quellsystemen und etablierte Standardwerkzeuge.

Wie sich dieser Rahmen füllen lässt, zeigt der zweite Teil. Dort begleitet ein Einkaufsagent, der Lieferanten vergleicht und Preishistorien auswertet, das Vorgehen durch vier Schichten: vom Inventory der vorhandenen Quellen über kuratierte Views mit expliziten Data Contracts und den einheitlichen Zugriff via MCP bis zum Feedback aus dem laufenden Betrieb.