Das Daten Dilemma, Teil 2

This blog post is also available in English

TL;DR

• Teil 2 macht das Minimum Viable Data Mesh konkret: vier Schichten, vom ehrlichen Inventory über kuratierte Views bis zum Agentenzugriff, durchgängig am Beispiel eines Einkaufsagenten.
• Alles beginnt mit einem kleinen, aber fachlich relevanten Use Case; die vier Schichten bauen aufeinander auf, müssen aber nicht streng sequenziell durchlaufen werden.
• Kern ist Schicht 2: kuratierte Views als komponierte Datenprodukte mit ODCS-Contracts, expliziter Nutzungssemantik (suitable_for / not_suitable_for) und prüfbaren Quality-Regeln, die Fachbereich und Engineering über das Sign-off im Pull Request zusammenhalten.
• Den Zugriff bündelt ein MCP-Server (analytisch über Views, operativ über eng geschnittene Tools); ein Feedback-Loop lässt das System entlang realer Nutzung wachsen. Die eigentliche Hürde ist Disziplin, nicht Tooling.

Dieser Blogpost ist Teil einer Reihe.

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

Der erste Teil dieses Artikels hat das Dilemma beschrieben: Agenten brauchen Daten mit dokumentierter Bedeutung. Genau die fehlt in den meisten Datenlandschaften, weil das Wissen über Semantik und Sonderfälle in den Köpfen der Fachexperten steckt. Data Mesh wäre die passende Antwort, setzt aber Domain Teams und einen organisatorischen Reifegrad voraus, den viele mittelständische Unternehmen nicht haben. Als Ausweg hat Teil 1 ein Minimum Viable Data Mesh (MVDM) skizziert: Data as a Product, fachliche Ownership und explizite Contracts bleiben erhalten; Domain Teams, Polyglot Persistence und die Plattform als Produkt werden zunächst durch einfachere Mittel ersetzt. Dieser zweite Teil zeigt das Vorgehen in der Praxis, in vier Schichten und an einem durchgängigen Beispiel.

Start mit einem konkreten Use Case

Bevor irgendetwas an Daten passiert, braucht es einen klaren Use Case. Der Einstieg sollte klein, aber fachlich relevant sein: eine klare Aufgabe mit klaren Grenzen und einem Nutzen, den die Fachabteilung messen kann. Ohne diesen Anker driftet jede Dateninitiative schnell in den Modus „wir müssen erst alles sauber modellieren". Use Cases geben der Datenarbeit Richtung und Priorität.

Ein konkretes Beispiel, das uns durch den Rest des Artikels begleiten wird: Ein Einkaufsagent soll Anbieter für bestimmte Produkt vergleichen, technische Anforderungen gegen Lieferantenspezifikationen prüfen und dabei historische Preise, Rabatte sowie frühere Einkaufsbedingungen berücksichtigen. Der Fall ist fachlich relevant, hat klare Datenquellen wie Lieferantenstamm, Bestellhistorie und Produktdaten und lässt sich messen: etwa durch Zeitersparnis pro Einkaufsvorgang, bessere Konditionen oder weniger Rückfragen.

Ein guter erster Use Case ist fachlich relevant genug, dass jemand in der Fachabteilung ihn sich wirklich wünscht, und technisch klein genug, dass er in einigen Wochen umgesetzt werden kann. Und er berührt drei bis fünf Datenquellen, nicht zwanzig.

Vier Schichten von minimal zu reif

Daraus ergibt sich ein Vorgehen in vier Schichten. Die Schichten bauen aufeinander auf, müssen aber nicht streng sequenziell durchlaufen werden. Schicht 3 entsteht oft parallel zu Schicht 2.

Schicht 1: Inventory

Am Anfang steht der Überblick: Was ist überhaupt da? Ein simples Repository hält pro Datenquelle die wichtigsten Informationen fest: Name, System, fachlicher Owner, technischer Ansprechpartner, Zweck, wichtigste Entitäten, Aktualisierungsfrequenz, grobe Qualitätseinschätzung, bekannte Probleme, sensible Datenklassen, historische Besonderheiten. Keine Schema-Auto-Discovery, keine vollständige Lineage. Für den Anfang reicht die Aussage: „Wir haben diese 30 bis 80 Tabellen und Endpoints, und das sind die wichtigsten 15."

Für den Einkaufsagenten heisst das konkret: Lieferantenstamm aus dem ERP, Bestellhistorie, Artikelstamm mit technischen Spezifikationen, vielleicht eine gewachsene Access-Datenbank mit Rahmenverträgen, von der nur der Einkauf weiss. Vier Quellen, vier Einträge im Inventory, und schon die erste Erkenntnis: Für die Rahmenverträge gibt es keinen technischen Ansprechpartner mehr.

Ein solches Inventory entsteht in zwei oder drei Workshops mit den Bereichen. Der Output ist ein Katalog, der ehrlich über Lücken ist. Ein Git-Repository mit Markdown-Dateien reicht dafür aus. Wer will, kann DataHub oder OpenMetadata nehmen, aber für den Anfang ist das nicht entscheidend.

Wichtig ist Ehrlichkeit. Ein gutes Inventory darf Lücken zeigen: unklarer Owner, fragliche Datenqualität, historische Sonderfälle, fehlende Dokumentation. Gerade diese Informationen sind wertvoll. Für Agenten ist ein unvollständiges, aber ehrliches Inventory besser als ein vollständiger Katalog, der Sauberkeit suggeriert.

Ehrlichkeit betrifft auch die Herkunft des Wissens selbst. Nicht jede Definition, die im Inventory landet, ist fachlich verbürgt. Manche muss das zentrale Team aus den Daten rekonstruieren: „Dieses Feld ist vor 2019 zu 40 Prozent leer, vermutlich eine Migration." Die Fachseite kann solche Hypothesen oft nur plausibilisieren, nicht autorisieren, weil das ursprüngliche Wissen nicht mehr vorhanden ist. Dann sollte genau das im Eintrag stehen: Definition rekonstruiert aus Code und Daten, nicht fachlich bestätigt.

Der Wert dieser Schicht ist nicht nur technisch. Sie zwingt die Organisation, sich gemeinsam einen Überblick über ihre eigene Datenlandschaft zu verschaffen. Die Lücken, die dabei sichtbar werden, sind oft der eigentliche Erkenntnisgewinn.

Schicht 2: Curated Views für die Top-Use-Cases

Statt alle Daten zu kuratieren, wählt man drei bis fünf konkrete Agenten-Use-Cases und baut dafür saubere Views.

Nicht alles ist eine View. Vor dem Bau der Views braucht es eine einfache Unterscheidung. Geht es um historische, analytische Daten wie Preishistorie, Bestellvolumen der letzten Monate oder Reporting-Fragen? Oder geht es um operative Echtzeitdaten wie aktuellen Lagerbestand, letzte Messwerte oder offene Tickets von heute? Curated Views eignen sich für Ersteres. Für aktuelle Daten greift man besser direkt auf das operative System zu; dazu mehr in Schicht 3. Der Agent sieht später beides als gleichberechtigte Tools, unter der Haube sind es aber zwei unterschiedliche Pfade mit unterschiedlichen Anforderungen an Refresh, Konsistenz und Performance.

Für den Einkaufsagenten fällt die Preishistorie klar auf die analytische Seite, der aktuelle Lagerbestand eines Lieferanten auf die operative.

Der Weg in die Views. Für die analytischen Daten braucht es eine Ingestion-Strategie pro Quelle. Vier Muster haben sich in der Praxis bewährt:

• Direkter Pull aus der Quelle. Die Curated View ist eine SQL-View auf einer Datenbank, die ohnehin abfragbar ist, etwa operatives Postgres, eine Replica der Salesforce-DB oder SAP-BW. Das ist der einfachste Fall und funktioniert, wenn Performance und Last unkritisch sind. Aber Vorsicht: Die Informationen in der Tabelle sind nicht immer identisch mit dem, was man in der UI sieht. Häufig aggregiert der Prozess oder die UI verschiedene Werte.
• ELT-Replikation in eine zentrale Stelle. Tools wie Airbyte, Fivetran oder Meltano, notfalls auch ein Python-Skript mit Cron, ziehen Daten aus den Quellsystemen in eine zentrale DB. Darauf bauen dann dbt-Modelle die Curated Views.
• Native Export- oder API-Schnittstellen. Viele Standardsysteme, gerade ERPs, bringen offizielle Export- oder Integrationsschnittstellen mit, etwa SAP OData, Salesforce Bulk API, REST- oder CSV-Exporte aus der Anwendung. Wo sie existieren, sind sie der saubere Weg: dokumentiert, versioniert, oft inkrementell und mit klaren Rechten. Ein Job zieht über die Schnittstelle in die zentrale DB, dbt baut darauf die Views. Das ist robuster als ein selbstgebauter Export und meist die erste Wahl, wenn das Quellsystem eine solche Schnittstelle anbietet. Auch wird die korrekte Prozesslogik auf die Daten angewendet.
• Föderation über Datei-Exporte. Wenn das Altsystem weder DB-Zugang noch brauchbare Schnittstelle hat, bleibt der nächtliche Dump: Ein Job legt CSV in einen Bucket, DuckDB liest die Dateien direkt, dbt baut die Views darauf. Das ist unsexy, funktioniert aber für Daten, die sich einmal pro Tag ändern. Die Access-Datenbank mit den Rahmenverträgen aus unserem Beispiel landet genau hier.

Heterogenität auf der Ingestion-Seite ist akzeptabel. Eine Quelle, ein Pattern. Wichtig ist, dass die Curated-View-Schicht darüber einheitlich aussieht. Dort liegt die Entkopplung: Die View ist der Vertrag mit dem Agenten, der Weg dorthin ist ein Implementierungsdetail und darf sich später ändern.

Views als Komposition. Es wäre ein Missverständnis, Curated Views als dokumentierte Kopien bestehender Tabellen zu verstehen. Der eigentliche Wert liegt tiefer. Viele Werte in operativen Systemen sind für sich genommen nicht interpretierbar, sondern erst im Zusammenspiel mit anderen. Eine Lieferantenbewertung von 5,0 Sternen sagt wenig, wenn sie auf einer einzigen Bewertung beruht. Ein Durchschnittspreis ist irreführend, wenn er Kleinstmengen und Rahmenvertragskonditionen mischt. Die Interpretationsregel steckt in solchen Fällen weder in einem einzelnen Feld noch in einer einzelnen Tabelle. Sie liegt in einer Join-Beziehung plus einer fachlichen Regel: „Bewertungen unter zehn Stimmen sind nicht belastbar."

Menschen wenden solche Regeln implizit an, wenn sie sie kennen. Ein Agent kennt sie nicht, und eine feldweise Dokumentation hat keinen natürlichen Ort für sie. Die Curated View ist dieser Ort. Sie liefert bewertung zusammen mit anzahl_bewertungen und einem abgeleiteten Feld wie bewertung_belastbar, dessen Schwelle die Domäne deklariert und das Engineering kodiert. Daraus folgt ein einfaches Designkriterium: Eine Curated View sollte ohne weitere Joins fachlich interpretierbar sein. Wenn ein Konsument zusätzliche Tabellen braucht, um einen Wert richtig einzuordnen, ist die View nicht fertig komponiert.

Was an den Views selbst zählt. Jede View braucht drei Dinge: Spalten in Business-Sprache (lieferanten_id statt lfrnr, bestellt_am statt dt_best), eine Beschreibung pro Spalte mit Bedeutung, Einheit, Wertebereich, Beispielwerten und bekannten Problemen sowie eine View-Beschreibung mit Zweck, Grain (also der Granularität: was eine Zeile fachlich repräsentiert), Refresh-Frequenz und Owner der Pipeline.

Im Kern ist das ein Data Contract pro View. Dafür gibt es vorhandene Standards: Der Open Data Contract Standard (ODCS) ist ein etabliertes, offenes Format unter dem Dach der Linux Foundation, das genau diese Felder vorsieht, von der Schema-Beschreibung über Klassifikation bis zu Quality und SLA. dbt baut die View, der ODCS-Contract beschreibt und prüft sie. Die eigentliche Investition liegt in diesen Metadaten, nicht in der SQL-Logik dahinter.

Nutzungssemantik: wofür geeignet, wofür nicht. Klassische Datendokumentation beschreibt, was eine Tabelle enthält. Für Agenten reicht das nicht. Sie brauchen zusätzlich Nutzungssemantik: Für welche Fragen ist diese View geeignet, für welche nicht? Viele Fehlinterpretationen entstehen genau an dieser Stelle: Ein Agent findet eine technisch passende View und nutzt sie für eine fachlich unpassende Frage.

Ein konkretes Beispiel für unseren Einkaufsagenten als ODCS-Contract, gekürzt:

apiVersion: v3.1.0
kind: DataContract
id: 5a9b2c14-1e7d-4f0a-9d3e-7b2c1f8e4a10
name: lieferanten_preishistorie
version: 1.0.0
status: active
domain: einkauf
dataProduct: lieferantenvergleich
description:
  purpose: Historische Netto-Einkaufspreise pro Lieferant und Artikel ab Januar 2021.
  usage: Preisvergleiche zwischen Lieferanten und Analyse der Preisentwicklung.
  limitations: Nicht für aktuelle Angebotspreise, laufende Verhandlungen oder Verfügbarkeit.
tags: ['einkauf']
schema:
  - name: lieferanten_preishistorie
    logicalType: object
    physicalType: view
    physicalName: v_lieferanten_preishistorie
    dataGranularityDescription: Eine Zeile pro Lieferant, Artikel und Bestellmonat
    properties:
      - name: lieferanten_id
        businessName: Lieferantennummer
        logicalType: string
        physicalType: varchar(10)
        primaryKey: true
        primaryKeyPosition: 1
        classification: internal
        description: Eindeutige Lieferanten-ID aus dem ERP
        examples: ["L-30017", "L-40233"]
      - name: artikel_id
        businessName: Artikelnummer
        logicalType: string
        physicalType: varchar(12)
        primaryKey: true
        primaryKeyPosition: 2
        examples: ["A-778102"]
      - name: monat
        businessName: Bestellmonat
        logicalType: date
        physicalType: date
        primaryKey: true
        primaryKeyPosition: 3
        examples: ["2024-01", "2024-02"]
      - name: netto_preis_eur
        businessName: Netto-Einkaufspreis
        logicalType: number
        physicalType: decimal(12,2)
        classification: confidential
        description: Durchschnittlicher Netto-Einkaufspreis pro Einheit im Monat, ohne Rahmenvertragsrabatte
      - name: bestell_anzahl
        businessName: Anzahl Bestellungen
        logicalType: integer
        physicalType: int
        description: >
          Anzahl Bestellvorgänge, auf denen der Durchschnittspreis beruht.
          Preise aus weniger als 3 Bestellungen gelten als nicht belastbar.
customProperties:
  - property: suitable_for
    value:
      - "Preisentwicklung eines Artikels bei einem Lieferanten über die letzten 12 Monate"
      - "Vergleich historischer Einkaufspreise zwischen Lieferanten"
  - property: not_suitable_for
    value:
      - "Aktuelle Angebotspreise oder Tagespreise"
      - "Gesamtkonditionen inkl. Rahmenvertragsrabatten (siehe rahmenvertrag_konditionen)"
      - "Lieferfähigkeit oder aktuelle Verfügbarkeit"

Quality-Regeln, Freshness und Retention haben in ODCS eigene Sektionen (quality, sla) und bleiben hier der Übersicht halber weg. suitable_for und not_suitable_for kennt ODCS nicht als Standardfeld, deshalb liegen sie unter customProperties. Für Agenten sind sie trotzdem wichtig: Sie machen die fachliche Intention explizit und geben ihm ein Signal, wann er eine andere Quelle suchen sollte. Der Verweis auf rahmenvertrag_konditionen zeigt zugleich das Kompositionsprinzip von oben: Der reine Bestellpreis ohne Rahmenvertragskontext wäre genau die Art von Wert, die für sich genommen in die Irre führt.

Man beachte auch das Feld bestell_anzahl: Es steht in der View, obwohl der Agent primär nach Preisen fragt. Ohne die Anzahl der zugrunde liegenden Bestellungen ist der Durchschnittspreis nicht einzuordnen; die View trägt ihre Interpretationsgrundlage mit sich.

Zwei ehrliche Einschränkungen zu not_suitable_for. Erstens ist eine Negativliste nie vollständig; Agenten finden Fehlnutzungen, die niemand antizipiert hat. Sie wächst deshalb am besten aus beobachteten Fehlgriffen, nicht aus Vorab-Brainstorming; dazu mehr in Schicht 4. Zweitens stellt sich mit wachsendem Katalog eine Retrieval-Frage: Bei fünf Views liest ein Agent alle Contracts in den Kontext, bei fünfzig wird die Auswahl der passenden View selbst zum Problem. Für den Einstieg ist das kein Hindernis, aber man sollte wissen, dass diese Grenze existiert.

Aktualität als Teil des Datenprodukts. Menschen wissen oft implizit, dass ein Reporting von gestern Nacht stammt oder bestimmte Zahlen erst nach Monatsabschluss belastbar sind. Agenten wissen das nur, wenn es explizit beschrieben ist. Jede Curated View sollte daher Angaben zur Frische enthalten: letzter Aktualisierungszeitpunkt, normale Latenz, fachlicher Stichtag, ab wann Daten als veraltet gelten. Eine schlichte last_refresh_at-Spalte oder ein entsprechender Metadateneintrag verhindert viele Missverständnisse. Der Agent kann sichtbar machen, ob er über Daten von heute Morgen, gestern Nacht oder letzter Woche spricht.

Dazu kommen Quality-Regeln, die direkt im Contract stehen: Eindeutigkeit von Schlüsseln, Pflichtfelder, akzeptierte Werte für Statusfelder, referenzielle Integrität, einfache Plausibilitätschecks. Das von INNOQ initiierte Data Contract CLI liest den ODCS-Contract, verbindet sich mit der Quelle und führt genau diese Prüfungen aus, in CI oder geplant. Wenn eine View bricht, fällt das auf, bevor ein Agent auf dieser Grundlage antwortet.

Zugriffsrechte: Metadaten beschreiben, die Datenbank erzwingt. Zugriffsrechte gehören zur Beschreibung eines Datenprodukts. Eine View sollte sichtbar machen, welche Art von Daten sie enthält und für welche Nutzung sie gedacht ist: unternehmensweit nutzbar, bereichsintern, vertraulich, personenbezogen, besonders schützenswert. Für Menschen ist oft aus dem Kontext klar, dass eine Quelle Konditionen oder vertrauliche Lieferantendaten enthält. Für Agenten muss die Einordnung explizit sein, sonst behandeln sie sensible Daten wie öffentliche.

Man darf sich dabei nichts vormachen: Ein classification-Feld ist ein Hinweis, keine Durchsetzung. Ein Agent respektiert es nur, solange nichts schiefgeht. Die eigentliche Zugriffskontrolle gehört dorthin, wo sie nicht umgangen werden kann: in die Datenbank und den Zugriffspfad. Konkret heisst das, dass der spätere MCP-Server nicht mit einem allmächtigen Service-Account auf alle Views zugreifen sollte. Sonst entsteht ein klassisches Confused-Deputy-Problem: Der Einkaufsagent eines Sachbearbeiters könnte plötzlich Konditionen aggregieren, die dieser Sachbearbeiter nie sehen dürfte. Stattdessen: Zugriff im Namen des jeweiligen Nutzers, Grants pro View, wo nötig Row-Level Security. Die Schutzstufe steht in den Metadaten. Durchgesetzt wird sie in der Datenbank.

Die Naht zwischen Fachlichkeit und Technik. Data Mesh geht davon aus, dass die Domäne das ganze Datenprodukt besitzt: Bedeutung und Implementierung liegen in einer Hand. Im MVDM haben wir das Engineering aus den in Teil 1 beschriebenen Gründen zentralisiert: Ein Mittelständler hat keine zehn Domänen-Teams. Damit entsteht eine Schnittstelle: Die Domäne kennt die Bedeutung, das zentrale Team baut das Datenprodukt.

Diese Trennung ist machbar, wenn die Verantwortlichkeiten explizit sind. Geht man einen ODCS-Contract Feld für Feld durch, fällt fast jedes Feld eindeutig auf eine Seite. ODCS ist dafür geeignet, fachliche Repräsentation und physische Implementierung in einem Artefakt zu tragen.

Die Domäne deklariert, was gelten soll, das Engineering kodiert und erzwingt es. Gemeinsam bleiben vor allem die Einigung über den Grain und Felder wie limitations, die fachlich, rechtlich und technisch zugleich sein können.

Es bleibt ein Dokument. Der ODCS-Contract trägt fachliche und technische Felder gemeinsam. Die Trennung läuft über das Ownership pro Feld. Zwei Dateien braucht es dafür nicht. Die Domäne verantwortet die fachlichen Felder, das Engineering die technischen, beide im selben Contract, getrennt durch das Sign-off im Pull Request.

So lässt sich auch die Rollenfrage pragmatisch lösen. Es braucht keinen Data Product Owner pro Domäne, eine Rolle, die im Mittelstand oft niemand besetzt. Die Domäne muss nicht den ganzen Contract schreiben, sie muss die fachlichen Aussagen bestätigen: Das zentrale Team entwirft ein Feld aus den Daten, eine benannte Person aus dem Fachbereich bestätigt es im Pull Request. Wer die fachliche Aussage verantwortet, muss sie nicht selbst geschrieben haben. Weil MVDM use-case-getrieben ist, liegt diese Verantwortung bei den Bereichen, die den jeweiligen Agenten einsetzen wollen. Und wo auch die Fachseite nur noch rekonstruieren kann, gilt das Prinzip aus Schicht 1: Die Unsicherheit wird Teil des Contracts, nicht wegdokumentiert.

Ein eigenes Glossar lohnt sich erst, wenn dieselbe Definition über mehrere Views auftaucht. Solange „Einkaufspreis" nur in einer View steht, lebt die Definition inline. Sobald mehrere Contracts denselben Begriff brauchen, zieht man die kanonische Definition in ein separates Artefakt und verlinkt sie über authoritativeDefinitions. Das Glossar wächst so aus dem Bedarf heraus.

Drift prüfbar machen. Der Preis ist Disziplin an dieser Schnittstelle. Wenn die fachliche Definition sagt „belastbar heisst mindestens drei Bestellungen" und die SQL auf >= 2 filtert, driften Definition und Implementierung still auseinander. Dann antwortet der Agent wieder überzeugend, aber falsch.

Appelle helfen dagegen wenig. Es braucht Prüfungen, die die fachliche Aussage direkt testen. Das wirksamste Mittel sind beispielbasierte Tests, die die Fachseite formuliert und abnimmt: „Der Preis von Lieferant L-30017 für Artikel A-778102 im März 2024 beruht auf zwei Bestellungen und muss als nicht belastbar markiert sein." Solche Fälle stehen als Quality-Regeln im Contract, das Data Contract CLI führt sie in der CI aus, und ein Fehlschlag blockiert das Deployment der View. Das Sign-off im Pull Request bestätigt damit konkrete, nachprüfbare Aussagen über die Daten. Fachliche Definition und technische Kodierung können so immer noch auseinanderlaufen, aber nicht mehr unbemerkt.

Schicht 3: Einheitlicher Zugriff via MCP

Ein MCP-Server, selbst gebaut oder bestehend für Postgres, Snowflake und ähnliche Systeme, bündelt den Zugriff für den Agenten. Er stellt zwei Arten von Tools bereit.

Analytische Daten auf Curated Views. Für historische und aggregierte Fragen. Der Agent kann den Katalog durchsuchen (list_datasets, describe_dataset), Read-only-SQL auf den kuratierten Views ausführen und optional Beispielzeilen abrufen. Die Metadaten der Views, inklusive suitable_for und not_suitable_for, müssen dabei für den Agenten zugänglich sein, nicht nur in einer Doku-Seite für Menschen. Nur dann kann er entscheiden, welche View für eine Aufgabe geeignet ist. Unser Einkaufsagent findet so lieferanten_preishistorie für den Preisvergleich und wird von deren not_suitable_for zu rahmenvertrag_konditionen weitergeleitet, wenn es um Gesamtkonditionen geht.

Operative Daten auf Live-Systeme. Für aktuelle Daten setzt man auf spezifische, eng geschnittene Tools statt freies SQL. get_current_inventory(article_id) greift direkt auf das Warenwirtschaftssystem zu. get_supplier_lead_time(supplier_id, article_id) fragt die Lieferzeit im ERP ab. get_open_orders(supplier_id) liefert offene Bestellungen. Diese Tools sind enger geschnitten als die analytischen: Punkt-Lookups statt Aggregationen, klare Parameter, keine offenen Queries. Das schützt die operativen Systeme vor Last und hält die Agenten-Interaktion vorhersehbar. Es ist zugleich ein Sicherheitsargument: Ein parametrisiertes Tool mit klarem Schnitt bietet keiner noch so kreativen Formulierung die Möglichkeit, per freiem Query auf produktive Systeme durchzugreifen.

In beiden Fällen gilt: kein direkter, ungebremster Zugriff auf Rohsysteme. Performance, Sicherheit und Datenqualität bleiben an einer Stelle kontrollierbar. Der Zugriff erfolgt, wie in Schicht 2 beschrieben, mit der Identität des jeweiligen Nutzers, nicht mit einem zentralen Sammel-Account. Der Agent sieht ein einheitliches Tool-Inventar, unabhängig davon, ob hinter einem Tool eine View oder eine Live-API steht. Darin liegt der Wert von MCP als Abstraktion.

Schicht 4: Feedback Loop

Man protokolliert, welche Queries Agenten stellen, wo sie scheitern und welche Datasets nie genutzt werden. Daraus entstehen Hinweise auf die nächsten Curated Views. So kann das System wachsen, ohne dass man vorab alles modellieren muss.

Agenten liefern dafür nützliche Signale. Wenn der Einkaufsagent wiederholt Preisdaten aus der falschen View zieht, fehlt wahrscheinlich eine bessere not_suitable_for-Beschreibung; die Negativliste wächst so entlang realer Fehlgriffe statt aus Vorab-Spekulation. Wenn Nutzer regelmässig nach Daten fragen, die noch nicht existieren, etwa nach Lieferantenzertifizierungen, ist das ein Hinweis auf das nächste Datenprodukt. Wenn eine View nie verwendet wird, ist sie vielleicht irrelevant, schlecht beschrieben oder redundant.

Zum Feedback gehört auch die Frage, ob der Agent richtig antwortet, nicht nur ob er Daten findet. Quality-Regeln testen die Daten; sie testen nicht das Zusammenspiel aus Daten, Metadaten und Agent. Dafür braucht es ein kleines Set von Referenzfragen mit bekannten Antworten: „Was hat Artikel A-778102 bei Lieferant L-30017 im ersten Quartal 2024 durchschnittlich gekostet?" mit dem erwarteten Ergebnis daneben. Diese Fragen laufen gegen jede Änderung an Views oder Contracts. Zehn solcher Fragen pro Use Case reichen für den Anfang und fangen die Fälle, in denen technisch alles grün ist, die Antwort aber trotzdem falsch.

Ein Wort zum Logging selbst: Agenten-Queries und ihre Ergebnisse enthalten unter Umständen genau die vertraulichen oder personenbezogenen Daten, deren Klassifikation man in Schicht 2 sorgfältig gepflegt hat. Das Protokoll ist damit selbst ein schützenswerter Datenbestand, für den die Klassifikation aus Schicht 2 ebenso gilt: Es braucht eine Rechtsgrundlage, eine Aufbewahrungsfrist und beschränkten Zugriff.

Das System wächst damit entlang realer Nutzung. Ein Use Case liefert den Einstieg, die Nutzung zeigt den nächsten Bedarf, die Datenprodukte werden schrittweise besser.

Pragmatisches Tooling

Eine knappe Tool-Auswahl für den Einstieg:

• Contracts und Katalog: ein Git-Repo aus ODCS-Contracts. Der Contract ist zugleich der Katalogeintrag; ein separates Katalogtool wie DataHub oder OpenMetadata ist optional und kommt später, wenn es gebraucht wird.
• Views: dbt Core, weil die Transformationen versioniert in Git liegen und sich sauber gegen die Contracts halten lassen.
• Storage: was ohnehin da ist. Postgres, SQL Server, BigQuery, Snowflake. Notfalls DuckDB als Föderationsschicht über CSV-Exporte.
• Agent-Zugriff: MCP-Server, oft fertig verfügbar für Postgres, dbt, Snowflake und andere.
• Contracts und Quality-Checks: das Data Contract CLI von datacontract.com, arbeitet nativ mit ODCS, validiert Contracts und führt Schema- und Qualitätstests gegen die Curated Views aus. Damit fallen Format, Katalog und Tests in ein einziges, offenes Werkzeug.

Wichtiger als die Toolauswahl ist die Disziplin, mit der man die Werkzeuge einsetzt und die DataContracts pflegt.

The bitter data lesson

Die entscheidende Hürde ist nicht primär technisch. Sie liegt in der Disziplin auf zwei Ebenen. Erstens muss man beim Use Case bleiben und vermeiden, in den Modus „wir modellieren erst einmal alle Daten sauber" zu verfallen. Zweitens muss die Schnittstelle zwischen Fachlichkeit und Technik gepflegt werden, damit fachliche Definition und technische Kodierung nicht auseinanderdriften. Beides ist der Preis für die pragmatische Abweichung vom Data-Mesh-Ideal.

Agenten einfach auf bestehende Systeme loszulassen, erzeugt Zugriff ohne Verständnis. Das Problem ist aus BI-Projekten bekannt. Bei Agenten wird es riskanter, weil fehlendes Verständnis in überzeugend formulierten Antworten verschwindet. Ein Agent, der die not_suitable_for-Hinweise einer View kennt, ist wertvoller als einer, der zehn Systeme erreicht, aber ihre Semantik erraten muss.

Der Titel dieses Abschnitts ist eine bewusste Umkehrung. Richard Suttons Bitter Lesson besagt, dass Skalierung von Rechenleistung am Ende jede mühsam von Menschen kodierte Wissensstruktur schlägt. Für Unternehmensdaten gilt das Gegenteil: Kein noch so grosses Modell kann erraten, dass „aktiv" in diesem Haus „Bestellung in den letzten zwölf Monaten" bedeutet oder dass eine Bewertung unter zehn Stimmen nichts wert ist. Diese Semantik steckt nicht in den Daten, sie steckt in der Organisation. Und sie entsteht erst, wenn jemand sie explizit macht. Die bittere Lektion der Daten ist, dass es hier keine Abkürzung über das nächste Modell gibt.

Das Ergebnis ist kein Data Mesh nach Lehrbuch. Es ist ein Minimum Viable Data Mesh: einige kuratierte Views mit klaren Contracts, explizite Nutzungssemantik, ein einheitlicher Zugriffspunkt für Agenten und ein Feedback-Mechanismus für organisches Wachstum. Die Grundidee bleibt erhalten: explizite Verträge und Verantwortung nahe an den Daten. Die organisatorische Komplexität sinkt, ohne den Anspruch auf saubere Semantik aufzugeben.

Einige wenige produktiv nutzbare Views sind oft wertvoller als eine umfassende KI-Strategie ohne belastbare Datenbasis. Agentenfähige Daten entstehen durch konkrete Datenprodukte mit klarem Geschäftsnutzen. Das Dilemma mit den Daten löst kein besseres Modell. Es löst sich erst, wenn Organisationen explizit machen, was ihre Daten bedeuten.