The tools are ready. Are the models ?

I am sure most of you noticed the two announcements from the last two weeks. The Query Template Generator went generally available, and SAP Business Data Cloud Connect for Databricks was confirmed as generally available too. Both of them do something we have been asking for since the first SAP Business Data Cloud conversations started: they take logic you already built and carry it forward, instead of asking you to rebuild it from scratch.

So here is what I find interesting. In the same two weeks, almost every customer problem I saw discussed publicly was not a tooling problem at all. It was an ownership problem, a governance problem, or a "nobody agreed what this number means" problem. The tooling is arriving faster than the modelling discipline to use it - and that gap is where the next twelve months of rework gets created. Lets take a look at both sides.

Root cause. Teams are standing up AI-enabled and MCP-based data products on SAP Business Technology Platform quickly, because it is now easy to do. What is not being decided at the same speed is who owns each one, who approves access to it, and how it fits the governance model that already exists for everything else.

The fix. Name a product owner per data product before it goes anywhere near a consumer, and pull the new landscape into the governance framework you already run - the same policies, the same lineage, the same access control. To me, the pragmatic move is to start with a small governed portfolio rather than a broad one: get stewardship and guardrails working on a handful of high-value products, then widen. A governed portfolio of five beats an ungoverned portfolio of fifty.

MCP becomes governed infrastructure inside SAP Integration Suite and SAP BTP

Root cause. The end-of-support date is doing what deadlines do, and a lot of organisations are moving before they have a migration and modelling strategy. The result is a rush to extract, and technical tables landing in a modern platform looking exactly as they looked in the old one.

The fix. Pick a small number of domains rather than everything at once, and define the target data products and semantic models before you move a single table. Then stage the extraction into SAP Datasphere or your cloud platform of choice, keeping the legacy structures as interim sources only. The thing that makes the difference here is designing around decision flows - margin, stock, service KPIs - rather than lifting the source structures as-is. If the target model looks like the source system, the migration has not really happened yet.

The ECC end-of-support deadline is creating an analytics gold rush

Root cause. Plenty of teams are experimenting with agentic AI against SAP processes. Far fewer have decided what the agent is allowed to touch, which semantic layer it reads from, and what counts as acceptable automation in an environment that gets audited.

The fix. Define the guardrails before the pilot, not after it: approved scenarios, approved data domains, and a named semantic layer the agent reads through. Route the interactions through governed interfaces that respect the SAP authorisations you already have, so the agent inherits your access model instead of quietly bypassing it. Start with low-risk operational cases, document the lineage and the decision points, and treat all of it as part of normal data product governance rather than a separate AI project.

Agentic AI lands in SAP operations as regulators tighten the frame

SAP Business Data Cloud

The Query Template Generator reached general availability for SAP Business Data Cloud and SAP BW customers, shipping with TCI 4.0. It converts existing SAP BW queries into SAP Business Data Cloud and SAP Datasphere artifacts automatically.
Why it matters: Rebuilding your analytical and semantic models from scratch just became optional. If you have years of query logic and KPI definitions sitting in SAP BW, there is now a supported path to carry that forward rather than re-deriving it from memory - which is where most of the "the numbers changed after migration" problems come from.

Source: community reporting, not an official SAP statement.

SAP Databricks

SAP's Innovation Guide confirms general availability of SAP Business Data Cloud Connect for Databricks, supporting secure bi-directional zero-copy sharing of SAP data products into Databricks environments.
Why it matters: If your organisation has standardised on Databricks, your SAP data products can now be treated as first-class assets there while keeping their business context. That matters more than it sounds: the usual failure mode is data arriving in the lakehouse stripped of the semantics that made it meaningful.

SAP BW/4HANA

A BW Migration Assistant is described as a planned tool for moving SAP BW ETL - process chains and transformation logic - into SAP Business Data Cloud, targeted for late 2026. It is explicitly not available yet.
Why it matters: Together with the now-generally-available Query Template Generator, this is SAP describing the full picture: query semantics with one tool, backend data flows with the other. Worth factoring into your planning, but please note the status - this one is roadmap, not something you can use this quarter.

Source: community reporting, not an official SAP statement.

SAP Datasphere

A July 2026 update highlights a SAP Datasphere and SAP HANA SQL-centric migration approach for customers moving off legacy warehousing, built around reusing existing SQL logic and structures rather than re-engineering them.
Why it matters: The appeal is obvious if you have a large body of working SQL: less re-engineering, and business semantics preserved on the way in. I would still test it against one real domain before committing a programme to it, and note that the reporting here is community commentary rather than a formal SAP release, so treat the status as unconfirmed.

I have been asked this several times in the last few months, usually after Finance and Sales have arrived at a meeting with two different numbers for the same measure. So lets take a concrete example and work through where the model belongs, criterion by criterion.

I have been asked this several times over the last few months, and it almost always arrives the same way. Finance and Sales turn up to the same meeting with two different numbers for what everybody assumed was the same measure. Somebody asks where the calculation lives. And it turns out the answer is "both places" - once in a SAP Datasphere view, once again in a SAP Analytics Cloud story, and the two have quietly drifted apart over about nine months.

So the question people actually ask me is: should we model in SAP Datasphere, or in SAP Analytics Cloud ?

Let me start by saying that this isn't a black or white answer. Both layers can model, both are supposed to model, and anybody who tells you "always do it in the warehouse" has not had to ship a dashboard against a deadline. But there are a few criteria worth knowing before you decide - so lets take a concrete example and work through them together.

Read the full article (6 min)

You are reading SAP Data & Analytics Field Notes on beehiiv — if this issue was forwarded your way, feel free to subscribe and get each new issue straight in your inbox.

Subscribe to Field Notes

Browse past issues