Konzeptkarte

BARC — Data Products und Data Contracts 2026: Fundament für KI

Stand 6. Oktober 2026

Redaktion: Cédric Mary, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist BARC?

Ein Data Product ohne Contract driftet einfach ab und bricht nachgelagerte Konsumenten stillschweigend; ein Contract ohne Produkt-Rahmenwerk ist Governance-Theater — erst das Zusammenspiel schafft echte Rechenschaftspflicht zwischen Produzenten- und Konsumenten-Teams.

Worum es geht

Ein Data Product ist die atomare Einheit des governten Data Sharing: ein abgegrenztes Dataset — mit Owner, Schema, Service-Level-Agreement und semantischem Contract — das gezielt für den Konsum durch Dritte produziert wird. Es ist kein Query-Ergebnis, keine Pipe, keine Staging-Tabelle. Es ist ein benanntes, versioniertes Artefakt, das eine konkrete Business-Frage zuverlässig und wiederholbar beantwortet, unabhängig davon, aus welchem Quellsystem es gespeist wird. Der Data Contract ist die formale Vereinbarung, die ein Data Product vertrauenswürdig macht: Er spezifiziert das Schema (Feldnamen, Typen, Nullability), das Freshness-SLA (wie oft aktualisiert wird und mit welcher Lag-Garantie), die Qualitätsregeln (zulässige Wertebereiche, referenzielle Integritätsprüfungen), den Owner (das Team, das für Breaking Changes und Incident Response verantwortlich ist) sowie die Zugriffsbedingungen (wer unter welcher Klassifizierung lesen darf).

Zu verstehen, warum diese beiden Konzepte nur gemeinsam wirken, ist der Ausgangspunkt. Ein Data Product ohne Contract ist nur ein Dataset mit freundlichem Namen — es driftet ab, bricht nachgelagerte Konsumenten stillschweigend und untergräbt mit der Zeit das Vertrauen. Ein Contract ohne Produkt-Rahmenwerk ist Governance-Theater: Niemand liest die Spezifikation, weil die zugrundeliegenden Daten weiterhin eine geteilte, veränderliche Tabelle sind, die niemandem gehört. Erst das Zusammenspiel schafft die Rechenschafts-Schleife: Das Produzenten-Team unterzeichnet den Contract und führt die Qualitätsprüfungen aus; Konsumenten bauen auf dem SLA auf und eskalieren bei einer Verletzung; die Plattform erzwingt Versionierung, sodass Breaking Schema Changes eine neue Version erfordern, statt stillschweigend zu brechen.

Warum es zählt

Der Contract wird präzise definiert, nicht vage: Schema (Namen, Typen, Nullability), Freshness-SLA, Qualitätsregeln (Wertebereiche, referenzielle Integrität), Owner und Zugriffsbedingungen — fünf benannte Komponenten, nicht „Governance“.
Der Ausfallmodus jeder Hälfte allein wird konkret benannt: Ein Produkt ohne Contract driftet ab und untergräbt Vertrauen; ein Contract ohne Produkt-Rahmenwerk bleibt ungelesen, weil die zugrundeliegende Tabelle weiterhin geteilt und veränderlich ist.
In einer SAP-Landschaft ist die Zuordnung konkret: Ein Datasphere Analytic Model mit Row-Level-Zugriffskontrollen, einem stabilen OData/SQL-Endpunkt und einer dokumentierten Refresh-Kadenz ist der Substanz nach bereits ein Data Product, egal ob es so gelabelt ist oder nicht.

Kernpunkte

BARC stellt Data Products und Data Contracts als das Fundament des KI-Erfolgs dar — keine Option.
Data Product = versioniertes, besessenes, SLA-gebundenes, konsumfertiges Dataset.
Data Contract = maschinenlesbare Vereinbarung, die Schema, Qualität und semantische Garantien zwischen Produzent und Konsument festlegt.
Überträgt sich direkt auf BDC: Joule, Knowledge Graph und KI-Workloads gelingen nur auf produktisierten Fundamenten.
Adoptionsraten und Tool-Rankings kostenpflichtig — der Titel liefert nur den Rahmen.
Seit dem 22.09.2026 inventarisiert SAPs AI Agent Hub Agenten, LLMs und MCP-Server, aber nicht Data Products oder Data Contracts als eigenen Asset-Typ — dieser Verantwortlichkeitskreislauf lebt weiterhin im eigenen Katalog-Tooling von Datasphere/BDC.
Der SAP Knowledge Graph liest die Geschäftsobjektbeziehungen eines Data Products, um Joules Reasoning zu verankern — ein abgedriftetes Schema verschlechtert KI-Antworten still, nicht nur BI-Dashboards mit sichtbarem Fehler.
Der Open Data Contract Standard (ODCS, gepflegt von Bitol) ist ein anbieterneutrales Referenzformat, auf das sich die Contract-Metadaten eines Datasphere- oder BDC-Data-Products abbilden lassen.

Begriffe auf dieser Seite

Data Product: Versioniertes, besessenes, konsumfertiges Dataset mit SLAs zu Aktualität, Qualität und Schemastabilität — verwaltet wie ein Softwareprodukt, nicht wie eine Pipeline.
Data Contract: Maschinenlesbare Vereinbarung zwischen Datenproduzent und -konsument, die Schema, Qualität, Eigentümerschaft und Breaking-Change-Politik festlegt.
AI Foundation: BARCs Begriff für die Datenqualitäts-, Data-Product- und Governance-Voraussetzungen, von denen KI-Workloads still abhängen.
Open Data Contract Standard (ODCS): Eine anbieterneutrale YAML-Spezifikation, gepflegt von Bitol, die festlegt, welche Abschnitte ein maschinenlesbarer Data Contract tragen soll — Schema, Qualität, SLA, Rollen, Support und mehr — nutzbar als Governance-Überlagerung auf einem Datasphere- oder BDC-Data-Product.
Delta Sharing / OpenSharing: Databricks' offenes Protokoll zum Teilen governter Daten- und KI-Assets über Organisationen und Plattformen hinweg ohne Datenkopie — das nächstliegende native Databricks-Analogon zu einem Data-Product-Share.
MCP Gateway (SAP Integration Suite): SAPs Fähigkeit, Unternehmens-APIs, einschließlich eines Data Products, als MCP-kompatible Endpunkte bereitzustellen, damit externe KI-Clients wie Joule oder Claude sie unter governtem Zugriff entdecken und aufrufen können.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.