Concept card

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

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

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

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.

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.

The Space replaces the project silo. Every object lives inside a Space — a governed partition with its own security, connections and lifecycle. Cross-Space consumption goes through the Catalog as versioned Data Products, never ad-hoc table sharing. This is the part that reads as bureaucratic to a team used to a shared schema, and it is precisely the part that prevents the shared schema's eventual collapse.

The semantic layer is consumed by more than reports. An Analytic Model feeds SAP Analytics Cloud, but also Joule's grounding layer and external tools through Delta Sharing. A definition written for one report is now a definition several kinds of consumer read, which raises the bar on getting it right and lowers the tolerance for local variants.

Why this matters now, in the French market

Every large SAP customer running ECC or classic BW is on a clock: SAP's roadmap steers them toward S/4HANA and a cloud-native analytics layer, and Datasphere is the landing zone. The addressable population is large — roughly four thousand BW customers in the main European market plus around seventeen thousand ECC customers — and the resulting migration cycle is the biggest since BW moved onto HANA.

For a décisionnel practice, that is the whole pipeline for the next several years. It is also why the mapping error is costly: 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.

The decision that is actually yours

Not whether Datasphere — for an organisation already committed to S/4HANA and SAP Analytics Cloud the answer is effectively yes, because it is the layer SAP is investing in for federation, semantic modelling and AI grounding.

The real question is how much to build there. For a small reporting need touching one or two source tables with no reuse requirement, a live SAP Analytics Cloud connection straight to S/4HANA is faster to deliver and entirely legitimate. Datasphere earns its place through reuse and governance. A team that models everything in it, including the one-offs, has recreated the central-team bottleneck that made the classical décisionnel model unpopular in the first place.

Pitfalls

Calling it "the new BW" in front of a client. It sets the wrong migration expectation and licenses a lift-and-shift design that carries the debt across.

Loading by default. Federation exists; make replication a decision with a stated reason — latency, source load, availability — rather than a habit.

Treating Spaces as folders. They are governance boundaries; consumption across them is a Data Product with a version and an owner, and designing around that rule reintroduces the shared-schema failure.

Modelling the one-offs. Reuse is what justifies the layer. Without it you have added a hop and a team to a report that needed neither.

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 plus ~17,000 ECC customers, 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.

Common pitfalls

"The new BW" — Signal: The migration plan is a rehost. Fix: Frame Datasphere as a semantic and governance layer; decide per object whether the old model earns its place.
Loading by default — Signal: Every source is replicated with no reason recorded. Fix: Federate first; justify each replication by latency, source load or availability.
Spaces as folders — Signal: Direct table access across Space boundaries. Fix: Publish a versioned Data Product through the Catalog and give it an owner.
Everything modelled centrally — Signal: One-off reports queue behind the platform team. Fix: Let low-reuse needs go straight from SAC to the source; keep Datasphere for what is genuinely shared.
Definitions written for one report — Signal: A measure that only makes sense inside its original story. Fix: Write it knowing Joule and external tools will read it too.

Decision framework

Decision	Option A	Choose A when	Option B	Choose B when
Is there a reuse requirement	Yes — several consumers	Model it in Datasphere. The Analytic Model is read by SAC, Joule and external tools alike.	No — one report, 1-2 tables	SAC live to S/4HANA. Adding Datasphere adds a hop and a team for nothing.
Load or federate	Federate	Default. Nothing is copied and there is one version of the truth.	Replicate	Only with a stated reason — latency, source load, or source availability. Write it down.
How to treat Spaces	Governance boundaries	Correct. Cross-Space consumption is a Data Product with a version and an owner.	Folders in a shared schema	This is the classical failure re-imported; it collapses at the same scale it always did.
Framing for the client	A new semantic and governance layer	Sets the right expectation and the right design.	"The new BW"	Do not. It licenses lift-and-shift and carries the old estate's debt across.

Sources

Open in the app →