In the last issue I argued that the tooling is arriving faster than the modelling discipline to use it. The community obligingly produced the evidence. The two most commonly reported customer problems I saw discussed publicly were "the same KPI calculated in several stories, and the numbers drifted apart" and "we pointed SAP Analytics Cloud straight at the source tables and now the reports are fragile".
Those are not two problems. They are the same problem, caught at two different moments in a project — and the fix for both is the same one: decide, deliberately, how much work your SAP Analytics Cloud model is allowed to do. This issue's article makes that case properly, and I will say up front where I land: SAP Analytics Cloud should consume, not compute.
What I did not expect was to find the same argument being made by people with no SAP stake at all. More on that in the Link Collection — it is the most useful thing I read while putting this issue together.
Common Customer Issues
The same KPI, calculated in several stories, quietly drifting apart
Root cause. Teams keep recreating the same business calculation in multiple SAP Analytics Cloud stories or models, because in the moment it is faster than finding out whether it already exists somewhere. The definitions then drift independently, and nobody notices until two of them are on the same slide.
The fix. Centralise the KPI logic in SAP Datasphere rather than recalculating it in each dashboard — one governed definition for revenue, margin, discount, consumed everywhere downstream. The part that makes it stick, though, is not technical: name the certified metrics as certified, put them somewhere findable like the Catalog, and mark them visually in the story so a consumer can see at a glance whether they are looking at a governed number or somebody's working draft. A definition nobody can find gets rewritten.
Bypassing the semantic layer and modelling too close to the source tables
Root cause. SAP Analytics Cloud gets connected directly to transactional tables, or stories get built before anyone has established a business semantic model. It works on day one, which is precisely the problem — the fragility and the inconsistent business meaning arrive later.
The fix. Model the business entities and hierarchies first in SAP Datasphere, then expose curated Analytic Models to SAP Analytics Cloud. To me the useful way to think about it is that the semantic layer is a contract between the source systems and the consumption layer: when the source changes shape, the contract absorbs it, and the stories carry on. Skip the contract and every source change becomes a reporting change.
Tunnel live connections break when the tenants sit in different SAP BTP regions
Root cause. A documented limitation blocks tunnel live connections between SAP Analytics Cloud and SAP Datasphere when the two tenants are hosted in different SAP BTP regions. It is an entirely reasonable hub-and-spoke design that simply cannot be built that way.
The fix. Co-locate the SAP Analytics Cloud and SAP Datasphere tenants in the same SAP BTP region when you need tunnel live connectivity, or design around a supported connectivity pattern instead. The reason I am including something this specific is the timing: region placement is nearly free to get right during architecture review, and expensive to discover during your first performance test. Put it on the checklist.
Product News
SAP Datasphere
Wave 2026.17 was released on 11 August 2026 and introduces a Data Remediation table along with changes that affect how Datasphere-based models are designed. An SAP support note confirms performance issues tied to the same wave — navigation and Data Builder search timeouts — with the fix scheduled for wave 2026.18 on 25 August 2026.
Why it matters: This one is worth knowing about in both directions. There is genuinely new capability to work with, and there was a short-term performance problem with a dated fix — so if the Data Builder felt slow to your team through the second half of August, that is very likely this and not something you did. Check which wave your tenant is actually on before you go looking for another explanation.
SAP Analytics Cloud
An SAP support knowledge article covering the 2026 QRC3 update lists "Modeling: reuse currency rate table from SAP Datasphere" as a planned enhancement to SAP Analytics Cloud modelling. Please note the status — this is roadmap, not something you can use this quarter.
Why it matters: Currency conversion is one of the most persistent places where the same logic ends up defined twice, once on each side. If this lands as described, it removes one of the last legitimate reasons to duplicate business logic in SAP Analytics Cloud — which is exactly the direction this issue's article argues for.
SAP Business Data Cloud
SAP's product page describes SAP Business Data Cloud as unifying SAP and third-party data into a single business data fabric. Community reporting through August adds the structural detail: SAP Datasphere ships as a core embedded capability, SAP Databricks as an embedded OEM component, and SAP Snowflake as a solution extension.
Why it matters: If you are drawing a target architecture right now, this is the sentence that matters: semantic modelling sits with SAP Datasphere, code-first processing with SAP Databricks, and the external lakehouse with SAP Snowflake. The reason to be clear about the split is that it tells you where your business logic belongs — and the answer is still the semantic layer.
Source: community reporting, not an official SAP statement.
SAP BW/4HANA
A community article published on 14 August outlines a modernization path from SAP BW to SAP Business Data Cloud, positioning SAP Business Data Cloud as the overarching ecosystem with SAP Datasphere and SAP Databricks embedded, and describing a staged transformation rather than a single cutover.
Why it matters: The staged framing is the useful part. A gradual transformation into the SAP Datasphere world is a very different planning exercise from a migration project with a go-live date, and it lets you get the semantic modelling right domain by domain instead of all at once. I would treat the specifics as community commentary rather than a committed SAP position, and check any dates that matter to your plan against an official source.
Source: community reporting, not an official SAP statement.
Blogs & Articles
Optimizing SAP Analytics Cloud and SAP Datasphere — how thin should your model be?
The connection, the calculations, the layers and the three places to look when it is slow — the full argument for a thin SAP Analytics Cloud model, criterion by criterion.
In the previous issue we asked where the model should actually live — SAP Analytics Cloud, or SAP Datasphere. Judging by what customers keep running into, plenty of you are living the consequences of having answered that question by accident rather than on purpose.
Two of the most commonly reported problems I saw discussed publicly in that window were "the same KPI calculated in several stories, and the numbers drifted apart" and "we connected SAP Analytics Cloud straight to the source tables and now the reports are fragile". Those are not two problems. They are the same problem, showing up at two different times in a project.
So let me put a stake in the ground, and then spend the rest of this article defending it: your SAP Analytics Cloud model should be a thin pass-through to a rich SAP Datasphere semantic layer. SAP Analytics Cloud should consume, not compute.
Now, before anybody objects — this isn't a black or white answer, and I am not saying you should never calculate anything in a story. I will come to exactly where the line sits. But the default has to be somewhere, and I have yet to see a landscape where "calculate it wherever is convenient today" aged well.
Link Collection
The Layering Obsession in Data Architecture — Modern Data 101, Other. The best thing I read while putting this issue together, and not an SAP article at all. The argument — a layer should only exist if it changes the state of the data — is a discipline worth borrowing the next time you review your LSA++ layers and find one that is just passing rows along.
How to Structure the Consumption Layer of Your Data Architecture — Modern Data 101, Other. Makes the case that the consumption layer is where a data architecture succeeds or fails. Read it as the vendor-neutral statement of this issue's whole argument — it lands at the thin consumption layer from a completely different direction.
CDS Views as the Semantic Backbone of SAP Analytics — Wagner Sabino, LinkedIn. A practitioner-level blueprint for layered CDS-based semantic models, with reuse, authorisation and performance designed in rather than added afterwards. Useful even if your semantic layer sits in SAP Datasphere rather than in CDS.
SAP Datasphere vs SAP Databricks - what is the actual difference? — Vartika Gupta, LinkedIn. Clarifies how the semantic and governance layer complements code-first processing. Handy if you are trying to explain to a data engineering team why the business logic should not live in their notebooks.
SAP Datasphere inside SAP Business Data Cloud — Vartika Gupta, LinkedIn. A clear explanation of how SAP Datasphere sits inside SAP Business Data Cloud as the core semantic modelling layer. Worth ten minutes before your next target-architecture conversation.
How to Control AI Agents With the Data Platform You Already Have — Modern Data 101, Other. Frames the semantic layer as the control plane for consistent meaning. In case you are being asked about agents at the moment, this reframes the work as something you are already doing rather than a separate AI project.
Not on the list yet?
You are reading SAP Data & Analytics Field Notes on beehiiv — if this issue was forwarded your way, subscribe and get each new issue straight in your inbox.
SAP Data & Analytics Field Notes by Ingo Hilgefort. Independent — not affiliated with SAP SE. Verify against official SAP documentation before acting.