Concept card

SAP Datasphere for a Décisionnel Practice — Mapping the Classical Model Without Breaking It

As of 2026-08-02T22:40:00Z

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

What is SAP Datasphere for a Décisionnel Practice — Mapping the Classical Model Without Breaking It?

Arriving at Datasphere with the classical décisionnel model in mind produces one costly mapping error — treating it as "the new BW". Three differences break the analogy: federation is first-class, the Space replaces the project silo, and the semantic layer feeds more than reports.

French SAP teams still say décisionnel where an English deck says BI, and the word carries a whole architecture with it: a warehouse, universes, a semantic layer maintained by a central team, and reports that a business user requests rather than builds. Anyone arriving at SAP Datasphere with that model in their head will map it wrongly — usually by treating Datasphere as "the new BW" — and the mapping error is expensive because it survives into the design.

Datasphere is not the new BW, and not a universe layer

Datasphere is the unified data and semantic layer at the centre of SAP's modern analytics estate: federation, replication and modelling in one product, built on HANA Cloud with an integrated Delta Lake. What it replaces is not one predecessor but a pattern — the patchwork of point-to-point extracts, hand-built warehouses and brittle BEx queries that a long-lived décisionnel estate accumulates.

Three differences matter for anyone carrying the classical model across.

Federation is first-class. A live query can pass through to the source with nothing copied. In the classical warehouse model, everything is loaded before it can be modelled; here, loading is a choice you justify, not a default you inherit.

Why it matters

A team that models Datasphere as a rehosted BW ships the old estate's debt into the new platform and pays for it in every consuming application afterwards.

Key points

"Décisionnel" carries a whole architecture — warehouse, universes, central semantic team, requested reports — and mapping it onto Datasphere naively is the costly error.
Datasphere is federation + replication + modelling in one product, on HANA Cloud with an integrated Delta Lake.
What it replaces is not one predecessor but a PATTERN: point-to-point extracts, hand-built warehouses, brittle BEx queries.
Difference 1 — federation is first-class: a live query passes through with nothing copied. Loading becomes a choice you justify, not a default you inherit.
Difference 2 — the Space replaces the project silo; cross-Space consumption is a versioned Data Product through the Catalog, never ad-hoc table sharing.
Difference 3 — an Analytic Model feeds SAC, Joule's grounding layer AND external tools via Delta Sharing. Several consumer kinds read one definition.
The market context: ~4,000 BW customers in the main European market, on SAP's roadmap clock toward S/4HANA.
The decision is not WHETHER Datasphere — for an S/4HANA + SAC commitment it is effectively settled — but HOW MUCH to build there.
A one-off report over one or two tables is legitimately an SAC live connection straight to S/4HANA. Datasphere earns its place through reuse.
Modelling the one-offs in Datasphere recreates the central-team bottleneck that made classical décisionnel unpopular in the first place.

Terms used on this page

Décisionnel: The French term for business intelligence, carrying the classical architecture with it: warehouse, universes, a central semantic team and requested rather than self-built reports.
Federation: Live query pass-through to a source with no data movement — first-class in Datasphere, and the reason loading should be a justified choice.
Space: Datasphere's governed partition, with its own security, connections and lifecycle. A governance boundary, not a folder.
Data Product: The versioned, catalogued unit through which one Space consumes another's semantics. The alternative to ad-hoc table sharing.
Analytic Model: The Datasphere object carrying business semantics; read by SAC, by Joule's grounding layer and by external tools through Delta Sharing.
BEx query: The classical BW reporting object. Its brittleness is part of the pattern Datasphere replaces, not a component to be rehosted.
Delta Lake: The open storage format integrated into Datasphere's HANA Cloud foundation, and what makes external multi-consumer sharing possible.
Landing zone: The platform SAP's roadmap steers ECC and classic-BW customers toward for analytics — which is what puts the migration cycle on a clock.

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 →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.