Concept card

BARC — Data Products and Data Contracts in 2026: The Foundation for AI Success

As of 2026-10-06

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is BARC?

A data product without a contract just drifts and silently breaks downstream consumers; a contract without a product framework is governance theater — the pairing is what creates real accountability between producer and consumer teams.

What it is

A data product is the atomic unit of governed data sharing: a bounded dataset — with an owner, a schema, a service-level agreement, and a semantic contract — that is produced intentionally for consumption by others. It is not a query result, not a pipe, not a staging table. It is a named, versioned artifact that answers a specific business question reliably and repeatedly, regardless of which source system it draws from. The data contract is the formal agreement that makes a data product trustworthy: it specifies the schema (field names, types, nullability), the freshness SLA (how often it refreshes and with what lag guarantee), the quality rules (accepted ranges, referential integrity checks), the owner (the team accountable for breaking changes and incident response), and the access terms (who may read it and under what classification).

Understanding why these two concepts matter together is the starting point. A data product without a contract is just a dataset with a friendly name — it will drift, break downstream consumers silently, and erode trust over time. A contract without a product framework is governance theater: nobody reads the spec because the underlying data is still a shared mutable table nobody owns. The pairing creates the accountability loop: the producer team signs the contract and runs the quality checks; consumers build on the SLA and escalate when it is violated; the platform enforces versioning so that breaking schema changes require a new version rather than silent breakage.

Why it matters

The contract is defined precisely, not vaguely: schema (names, types, nullability), freshness SLA, quality rules (ranges, referential integrity), owner, and access terms — five named components, not "governance."
The failure mode of each half alone is named specifically: a product without a contract drifts and erodes trust; a contract without a product framework goes unread because the underlying table is still shared and mutable.
In an SAP estate, the mapping is concrete: a Datasphere analytic model with row-level access controls, a stable OData/SQL endpoint, and a documented refresh cadence already is a data product in substance, whether or not it's labelled one.

Key points

BARC frames data products + data contracts as the foundation of AI success — not optional.
Data product = versioned, owned, SLA-bound consumer-ready dataset.
Data contract = machine-readable schema + quality + semantic guarantees between producer and consumer.
Maps directly to BDC: Joule, Knowledge Graph and AI workloads only succeed on productised foundations.
Adoption rates and tool rankings paywalled — title gives the framing only.
Since 22 Sep 2026, SAP's AI Agent Hub inventories agents, LLMs and MCP servers but not data products or data contracts as its own asset type — that accountability loop still lives in Datasphere/BDC's own catalog tooling.
SAP Knowledge Graph reads a data product's business-object relationships to ground Joule's reasoning — a drifted schema degrades AI answers silently, not just BI dashboards with a visible error.
The Open Data Contract Standard (ODCS, maintained by Bitol) is a vendor-neutral reference format a Datasphere or BDC data product's contract metadata can be mapped onto.

Terms used on this page

Data product: Versioned, owned, consumer-ready dataset with SLAs on freshness, quality, schema stability — managed like a software product, not a pipeline.
Data contract: Machine-readable agreement between a data producer and consumer fixing schema, quality, ownership, and breaking-change policy.
AI foundation: BARC's term for the data-quality + data-product + governance prerequisites that AI workloads silently depend on.
Open Data Contract Standard (ODCS): A vendor-neutral YAML specification, maintained by Bitol, defining the sections a machine-readable data contract should carry — schema, quality, SLA, roles, support and more — usable as a governance overlay on a Datasphere or BDC data product.
Delta Sharing / OpenSharing: Databricks' open protocol for sharing governed data and AI assets across organisations and platforms without copying data — the closest native Databricks analogue to a data product share.
MCP Gateway (SAP Integration Suite): SAP's capability exposing enterprise APIs, including a data product, as MCP-compatible endpoints so external AI clients such as Joule or Claude can discover and call them under governed access.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →