Every RISE or GROW business case buries a second, unpriced decision: where governed meaning ends and open-ended data science begins. In February 2025, SAP quietly changed the answer — and getting the boundary wrong is how you spend 2027 re-platforming the thing you just built.
The question nobody put in the business case
Ask a program sponsor why they’re moving to S/4HANA and you get a clean answer: standardize the processes, get to Business AI, retire the code jungle. Ask where the analytical and AI data layer sits, and the answer gets vague fast — usually “Datasphere, I think, or maybe we’re doing Databricks on the side.” That vagueness is not a rounding error. It is an architecture decision with a seven-figure cost of reversal, and most steering committees never put it on the record.
The reason it hides is historical. Datasphere and Databricks were pitched for years as competitors — one the SAP-native data fabric, the other the open lakehouse your data science team already ran — and both camps liked that framing because it forced a winner-take-all choice. Then, in February 2025, SAP and Databricks collapsed the framing themselves by launching SAP Business Data Cloud (BDC) with SAP Databricks embedded as a first-party, SAP-resold service inside it. That single move should make every S/4HANA program re-open the data-layer question — not skip it.
What actually changed in February 2025
SAP Business Data Cloud is a fully managed SaaS layer that folds Datasphere, SAP Analytics Cloud, and SAP BW into one governed surface — and it ships with Databricks built in rather than bolted on. Three facts matter for a buyer:
SAP sells it, and SAP prices it. SAP resells Databricks as the co-branded “SAP Databricks” inside BDC — the same reseller pattern Microsoft already runs — so an existing SAP customer adopts it without a separate Databricks contract. SAP sets the pricing and any discounts, through a Capacity-Unit model where CUs are consumed across the underlying BDC services. The commercial owner of your lakehouse, in this arrangement, is SAP.
The technical core is zero-copy Delta Sharing. SAP data products can be shared bidirectionally into a Databricks workspace, and non-SAP data can flow back, without duplicating or re-engineering pipelines. Databricks Unity Catalog then governs the combined estate — SAP and non-SAP alike — under one permissions model. The pipeline you used to maintain to drag SAP data into a lake is precisely what this deletes.
Databricks is putting money behind it. Databricks earmarked $250 million to help customers and system integrators deploy and migrate onto SAP Databricks — a clear signal it is treating SAP’s data gravity as a growth vector, not a checkbox.
One correction to the launch gloss, because it’s the detail buyers get wrong: this rolled out first on AWS (April 2025), with Google Cloud and Microsoft Azure following through the second half of 2025. It is delivered through RISE for cloud customers, not for on-premise estates. Hyperscaler alignment is therefore a real gating constraint on your timeline, not a footnote.
Where governed semantics belong — and why it isn’t optional
Datasphere’s real job inside BDC is not storage. It is the semantic layer: it takes S/4HANA’s internal structures — customer master data scattered across ERL, CRM, service, and commerce with inconsistent keys — and turns them into governed business objects with documented derivation rules, so “customer lifetime value” means the same thing in Finance, Marketing, and Strategy. SAP’s own architecture material is explicit that this harmonization, plus the auto-generated Knowledge Graph mapping relationships between entities, is the difference between data that is technically accessible and data that is usable by an AI agent without hallucinating.
That distinction gets more important, not less, once Joule and agentic AI arrive. An agent reasoning about supplier risk needs “open purchase order” and “supplier exposure” to be consistently defined and traceable to source — that’s a governance property, not a compute property. SAP is positioning the Knowledge Graph and semantic model as the trust layer beneath agentic AI, a prerequisite decision rather than an afterthought. So the business-critical semantics — chart of accounts, product hierarchies, customer definitions, planning logic — belong in Datasphere/BDC, not re-derived independently inside a lakehouse. Re-deriving them twice is exactly how an enterprise ends up with two “authoritative” definitions of revenue.
Where the lakehouse actually earns its keep
Databricks was never going to out-govern SAP on SAP’s own transactional semantics, and SAP is not trying to out-compute Databricks on large-scale engineering, exploratory data science, or MLOps. The division of labor both vendors describe — BDC as the trusted foundation for mission-critical SAP processes, Databricks as the operating system for all your data once it leaves that governed core — maps to what practitioners already know: Spark-scale feature engineering, custom model training, unstructured-data processing, and blending SAP data with genuinely external datasets (weather, market feeds, IoT telemetry) is lakehouse territory, not warehouse territory.
Where each layer should own the workload in a typical S/4HANA program:
| Workload | Owns it | Why |
|---|---|---|
| Chart of accounts, product/customer master harmonization | Datasphere / BDC | Needs governed, auditable definitions reused across Finance, Sales, Ops |
| Joule / agentic-AI grounding context | Datasphere Knowledge Graph | Hallucination risk drops when agents retrieve structured, governed relationships |
| Custom ML training, feature engineering | SAP Databricks | Unity Catalog + Spark tooling are built for it; SAP does not replicate it |
| Blending SAP data with third-party / unstructured data | SAP Databricks via Delta Sharing | Zero-copy sharing avoids duplicating governed SAP data into a separate lake |
| Regulatory and financial reporting | Datasphere / BDC | Must trace to a single governed source, not a data-science sandbox |
One caveat the launch decks skip: SAP Databricks is a curated, OEM build — not your unlimited enterprise workspace. Features including Workflows, Jobs, Delta Live Tables, Materialized Views, Autoloader, Partner Connect, and the Databricks Marketplace are not in it. If you already run a large Databricks estate, plan for two footprints and a bright line between them — the embedded one for SAP-governed workloads, your own for everything the OEM build won’t do.
What this means for your program specifically
If your RISE or GROW business case already budgets for Datasphere, February 2025 doesn’t invalidate that spend — Datasphere becomes the semantic core of BDC, not a product SAP is about to deprecate. The mistake would be reading that as a reason to skip the Databricks conversation. If you already run data science on Databricks outside SAP, zero-copy Delta Sharing removes the case for building a parallel extraction pipeline just to feed those models SAP data. Conversely, if you have no Databricks footprint today, don’t let SAP Databricks become an unexamined line item on the RISE contract — pay for lakehouse compute only where you actually have ML, unstructured-data, or cross-domain blending work that Datasphere’s semantic tooling isn’t built to do. And remember the commercial reality: SAP controls the pricing inside this arrangement, and existing non-SAP Databricks customers are not forced to migrate. Model both paths before you sign.
The practitioner takeaway
Before your data-architecture workstream is approved, force a one-page decision memo that assigns every planned analytical and AI workload to either the governed semantic layer (Datasphere/BDC) or the lakehouse (SAP Databricks) — never “both, TBD.” If a workload needs a single auditable definition that Finance, Sales, and an AI agent must all agree on, it belongs in Datasphere. If it needs Spark-scale engineering, custom model training, or blending with data SAP will never model, it belongs in Databricks — connected by zero-copy Delta Sharing, not a duplicate pipeline. Sign that memo before you sign the RISE contract. Programs that decide where meaning lives and where horsepower lives, on purpose and early, ship a data platform. Programs that leave it to whoever reaches the sandbox first inherit two sources of truth and a reconciliation meeting that never ends.
### Sources – SAP News Center — SAP and Databricks: A Bold New Era of Data and AI (Feb 2025): https://news.sap.com/2025/02/sap-databricks-open-bold-new-era-data-ai/ – Databricks — Introducing SAP Databricks (blog): https://www.databricks.com/blog/introducing-sap-databricks – Databricks Newsroom — Databricks Announces Launch of SAP Databricks (the $250M commitment): https://www.databricks.com/company/newsroom/press-releases/databricks-announces-launch-sap-databricks – Cloud Wars — Why Databricks Is Betting $250 Million on the Partnership: https://cloudwars.com/ai/who-is-new-sap-bff-databricks-and-why-is-it-betting-250-million-on-the-partnership/ – SAPinsider — Databricks and SAP Join Forces to Ready Data for AI: https://sapinsider.org/blogs/databricks-and-sap-join-forces-to-ready-data-for-ai-with-sap-databricks/ – SAP Community — SAP Business Data Cloud FAQs (availability, RISE delivery): https://community.sap.com/t5/technology-blog-posts-by-sap/sap-business-data-cloud-faqs/ba-p/14022781 – SAP Community — Here’s how Databricks fits into the SAP BDC landscape: https://community.sap.com/t5/technology-blog-posts-by-sap/here-s-how-databricks-fits-into-the-sap-business-data-cloud-landscape/ba-p/14026644 – SAP — SAP Databricks in Business Data Cloud (product page): https://www.sap.com/products/data-cloud/databricks.html – Qubika — SAP Business Data Cloud Connect for Databricks: Overview and roadmap (OEM feature limits): https://qubika.com/blog/sap-business-data-cloud-databricks-connector/ – Futurum — SAP and Databricks Launch SAP Business Data Cloud (reseller/pricing analysis): https://futurumgroup.com/insights/sap-and-databricks-launch-sap-business-data-cloud/