Three products, overlapping names, and one recurring confusion: who owns the semantic layer?
SAP’s analytics portfolio is easier to navigate than its naming suggests — but only once each product is reduced to the one job it actually owns. Presentations tend to describe them by feature list, which is precisely how the confusion starts: every feature list mentions data, models and dashboards.
Described by responsibility instead, the three barely overlap at all.
Analytics Cloud is where people consume and plan. Datasphere is where data is modeled and governed. Business Data Cloud is the umbrella that packages both with the data platform underneath.
One sentence each
SAP Analytics Cloud — where the numbers are seen and planned
Dashboards, stories and — its most underrated half — planning: budgets, forecasts and versions entered, spread and written back by business users. SAC is a consumption and planning layer. It is at its best when it is not also asked to be the data warehouse.
SAP Datasphere — where data is combined, modeled and governed
The business data fabric: connections and replication from SAP and non-SAP sources, modeling that preserves business semantics, and governance over who sees what. When one definition of “revenue” must serve every dashboard, this is the layer where that definition lives.
SAP Business Data Cloud — the umbrella offering
SAP positions Business Data Cloud as the packaging of this landscape into one SaaS offering — Datasphere and Analytics Cloud together with curated data products from SAP applications, and embedded data-engineering and machine-learning capability through the SAP Databricks partnership. It is a portfolio decision more than a new tool: the question it answers is “how do we buy and run this stack”, not “where do dashboards come from”.
The boundaries that actually matter
Product scope shifts as SAP develops the portfolio — the responsibilities above are the stable way to read it, and specifics should be checked against SAP’s current documentation at decision time.
The mistake each product invites
- Building the warehouse inside SAC — models multiply per dashboard, definitions drift, and two years later two stories disagree on the same KPI.
- Treating Datasphere as optional plumbing — skipping the semantic layer saves a quarter now and costs every quarter after, because each new consumer re-derives the business logic.
- Waiting for the umbrella to decide for you — packaging changes; responsibilities do not. A clean split of consumption, semantics and engineering survives any repricing.
Deciding without regret
The durable sequencing question is not which product to buy first — it is where your single source of business definitions will live. Put the semantic layer where it can serve every consumer, keep consumption tools thin, and the portfolio question above it becomes commercial rather than architectural.
Fix the definitions→Model them once→Let every dashboard consume→Buy the packaging that fits
VISCAP perspective
Products change names. Responsibilities do not. Architect on responsibilities and the naming stops mattering.
Most of the confusion we meet is not about capability — it is about teams having bought consumption tooling and then discovering the semantic work was never done anywhere. That work is unavoidable; the only choice is whether it happens once, in a governed layer, or repeatedly inside every dashboard.
The question that cuts through
For any proposed diagram, ask: “when finance changes the definition of margin, how many places must change?” If the answer is one, the architecture is right, whatever the products are called this year.