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.
Why start with the connection?
Lets start with the least glamorous part, because it quietly decides everything downstream.
When you connect SAP Analytics Cloud to SAP Datasphere, connect to an Analytic Model. The connection to Analytical Datasets is deprecated, so if you still have stories pointing at one, that is technical debt with a clock on it — worth putting on the backlog now rather than discovering it during an upgrade.
This matters beyond housekeeping. The Analytic Model is the thing that actually carries semantics into SAP Analytics Cloud. It supports calculated and restricted measures, exception aggregation, pruning of attributes and measures, nested dimensions, variables, time-dependency, semi-additive measures, currency conversion after aggregation, and exposure through the public OData API.
Read that list again, because it is the whole argument. Every one of those is a piece of business logic you would otherwise have to rebuild — in every story, by every designer, slightly differently. And one more constraint worth knowing before you draw your architecture: tunnel live connections do not work when the two tenants sit in different SAP BTP regions. Check region placement in your architecture review, not in your first performance test.
The "Thin SAP Analytics Cloud" principle
So what does thin actually mean in practice? Concretely, define all of this in SAP Datasphere:
Measures with their aggregation rules — including exception aggregations where you need them
Calculated columns for derived values
Associations to dimension tables, rather than joins
Data Access Controls, so security travels with the model
Semantic types — and mark entities deliberately as FACT, Dimension, Hierarchy. Do not just leave the default. The default is a decision too, it is just one nobody made on purpose.
And create Analytical Models per use case. I know the temptation to build one generic model that covers everything, and I understand where it comes from — it feels efficient. But a model carrying 120 columns because four teams each needed a different thirty is not efficient for anyone. Slim the dimensions, measures and attributes down to what that consumer actually needs.
Adopt a layered approach (remember LSA++?)
Some of you will remember LSA++ from your SAP BW days. The idea travels perfectly well:
Layer 1 — raw data and ingestion. Remote tables land here.
Layer 2 — filtered, clean, enriched. Relational modelling.
Layer 3 — business ready. Analytical modelling: your Fact Model, Analytical Model, dimensions, hierarchies, associations, restricted measures, exception aggregation, non-cumulative measures.
What I find interesting is that this argument is being made right now well outside the SAP world. Modern Data 101 published a piece a few weeks ago called "The Layering Obsession in Data Architecture", and its central point is a good discipline to borrow: a layer should only exist if it changes the state of the data. If a layer is just passing rows along unchanged, it is not architecture, it is overhead. They followed it with a piece on structuring the consumption layer, arguing that this is where a data architecture succeeds or fails.
To me that is the same conclusion this article reaches, arrived at by people with no SAP stake at all. That is usually a sign you are on solid ground.
Calculations — where do they belong?
This is the question I get asked most often, so here it is criterion by criterion.
Define it in SAP Datasphere when:
It is a standard measure used across multiple stories. Revenue, margin, discount rate. One definition, consumed everywhere.
It is a derived attribute — a customer classification, an aging bucket assignment.
It is a KPI with specific aggregation rules or a semi-additive measure — headcount, stock on hand. Exception aggregation and non-cumulative measures belong in the model, not in a story.
Define it in SAP Analytics Cloud when:
The calculation involves SAP Analytics Cloud input controls. If the user's on-screen selection is an input to the formula, the formula has to live where the selection does.
It is a genuine one-off analysis in a single story. Somebody needs an answer this week, for one meeting. That is a legitimate use of a story calculation — the mistake is leaving it there for two years.
So the line is not "never calculate in SAP Analytics Cloud". The line is: if two people could ever need the same number, it belongs in SAP Datasphere.
A few things that help hold that line in practice. Use restricted measures for filtered measures — open orders, active customers — with variables to keep them flexible. Consider the Catalog as your KPI glossary. And establish a calculation repository so the next designer can find the certified version instead of writing their own. Some customers go further and name their certified metrics as such, and visually differentiate them in stories, so a consumer can see at a glance whether they are looking at a governed number or somebody's working draft. That is a small piece of design work with a very good return.
General modelling recommendations
A handful of habits that consistently pay off:
Transfer only the data that is needed. Avoid the "100 columns just in case" model. Use variables to remind users to filter.
Filter before you join, and before you calculate. In the graphical editor this is just node ordering, and it is one of the cheapest performance wins available.
Use associations instead of joining dimensions.
Build smaller sub-models rather than putting everything into a single view.
Query optimization — the three levers
When something is slow, there are really three places to look.
Filter push down. Plan your filter dimensions as part of model design rather than discovering them later. Where possible use SAP Datasphere input prompts and variables rather than SAP Analytics Cloud variables, because that is what gets pushed down. Avoid calculated columns as filters. And for very large dimensions, consider making the prompt mandatory.
Persistency. For complex models or complex calculations, consider view persistency, or an interim persistency in local tables. Consider aggregate-aware modelling — daily, monthly, yearly. For large source data sets, consider table replication. One caveat worth writing on the wall: view persistency is not possible in combination with Data Access Controls. And when you serve persisted data, show the consumer a "Data as of ..." stamp. It takes five minutes and prevents a surprising number of awkward conversations.
Partitioning. Remote table partitioning, local table partitioning, and partitioning as part of persistency.
Common pitfalls (and how to avoid them)
SAP Analytics Cloud over-fetching data — optional or mandatory variables in the SAP Datasphere model, a default filter, pre-aggregated or persisted data, and a default story that does not open with every column.
The "everything just in case" model — regular inspection of models, tables and columns to find the outliers, plus an approval step before anything reaches production.
"Calculations everywhere" — certified metrics in SAP Datasphere, named and visually marked as certified, with an approval process.
Complex Data Access Controls — simplify the logic. Fewer dimensions, or a higher-level dimension such as Region instead of a list of countries.
Story complexity, too many widgets — the SAP Analytics Cloud performance analysis tool, and comparing the SAP Datasphere preview against the story.
When it is slow, where do you look?
Start with the SAP Analytics Cloud performance analysis tool and read the split: high frontend time points at widget count or scripting, high network time points at the network, high backend time points at the model. That one split saves an enormous amount of guessing.
On the SAP Datasphere side, the system monitor gives you top statements and tasks, out-of-memory errors, the top MDS requests coming from SAP Analytics Cloud, and admission control queuing or rejection. In the Data Builder you have runtime metrics and PlanViz, and the View Analyzer result. A PlanViz file can be evaluated in Eclipse, or with the SQL Analyzer extension for Visual Studio Code. And if you need to go deeper, a HAR file filtered on GetResponse calls tells you how much time is spent waiting for the server, with a payload that identifies the SAP Datasphere model involved.
So — how thin?
Here is my verdict, marked clearly as a preference: as thin as you can make it without making your designers miserable. Reserve SAP Analytics Cloud calculations for input-control-dependent logic and genuine one-offs, and treat everything else as belonging in SAP Datasphere. Establish the layers, name your certified metrics, avoid the single model that tries to serve everybody, and inspect your models and statements on a schedule rather than after a complaint.
None of this is exotic. It is mostly a series of small decisions that nobody was assigned to make — which is exactly why they get made by default, and why the drift only becomes visible nine months later when Finance and Sales bring two different numbers to the same meeting.
What is your experience on this? I am particularly curious where you have drawn the line on story-level calculations, and whether it held.