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.

We have a Net Revenue measure. It is Gross Revenue minus returns, minus customer rebates, and minus an allowance for credit notes issued after period close. Three departments consume it:

Three consumers, one measure. Where does the calculation belong ?

This is the one I would start with, because it settles most cases on its own.

If a measure has exactly one consumer and always will, modelling it in the consumption layer is defensible. A story-specific ratio, a chart-level restricted measure, something genuinely local - put it in SAP Analytics Cloud and move on. Not everything deserves to be promoted into the warehouse.

But our Net Revenue has three consumers, and one of them is not even a story. The moment a measure is consumed by something that is not SAP Analytics Cloud, the consumption layer is the wrong home for it, because that other consumer cannot see it. Your data science team cannot import a calculated measure that only exists inside a story.

Datasphere 1 - SAC 0.

Here is where the "two versions of the truth" problem is actually born.

A definition that Finance and Sales both depend on is a governed artifact. It needs an owner, a change process, and somewhere for people to go and read what it means. When that definition lives in a story, the owner is effectively whoever last edited the story - and the change process is "somebody changed it".

I have seen this play out more than once: the definition was correct on the day it was built, and then a rebate rule changed, and the warehouse view was updated, and the story was not. Nobody did anything wrong. There was just no single place where the definition lived.

Datasphere 2 - SAC 0.

Now the other side, because this is where the warehouse-first argument gets weaker than its advocates admit.

Modelling in SAP Datasphere means a change request, a view change, probably a transport, and quite possibly a two-week wait. Modelling in SAP Analytics Cloud means a Story Designer does it this afternoon. If you tell a business team that every calculation needs a warehouse change, you will not stop them calculating - you will just stop hearing about it, and the calculations will happen in spreadsheets where you cannot see them at all.

So delivery speed is a real criterion, not an excuse. In case you are in a situation where the business genuinely needs an answer this week, the consumption layer is the honest choice.

Datasphere 2 - SAC 1.

Ask yourself a simple question: when someone challenges a figure, how long does it take you to show them the derivation ?

If the calculation is in a view, you follow the lineage. If it is in a story, you open the story, find the calculated measure, read the formula, and then work out whether the same formula exists in three other stories. From a debugging perspective this is not close.

Datasphere 3 - SAC 1.

And last but not least - the criterion most people skip, which the last two weeks made newly relevant.

With SAP Business Data Cloud Connect for Databricks now generally available, and the Query Template Generator carrying SAP BW query semantics forward into SAP Datasphere, the direction of travel is clear: models are increasingly expected to be consumed by things that are not SAP Analytics Cloud. A model built in the consumption layer cannot follow you there.

If you think there is any chance a measure will be needed outside a story within the next two years, that is an argument for pushing it down.

Datasphere 4 - SAC 1.

Four to one is not "always model in the warehouse". It is a set of questions worth asking before you decide, and one of them genuinely favours the consumption layer.

My preference - and I will mark it clearly as a preference - is a version of what I have heard called the thin consumption layer. It works like this:

That third one is the part I would encourage you to steal. Most organisations do not have a modelling problem so much as a promotion problem - things start in the right place for the wrong reasons, and then never move.

Back to our Net Revenue: it has three consumers, two departments who must agree, and a data science team who cannot see stories. It belongs in SAP Datasphere. The regional variance percentage that Sales wants on one page of one story ? Leave it where it is.

One thing worth saying, given the two general availability announcements. A tool that carries your existing query logic forward is genuinely useful - but it carries forward whatever you had, including the duplication. If a measure was defined in four places in SAP BW, you will now have it defined in four places somewhere newer.

So if you are planning a migration this year, the cheapest moment to consolidate your definitions is before you run the generator, not after. I would treat it as a modelling exercise with a tooling step in the middle, rather than a tooling exercise.

I hope that this was useful. What is your experience on the topic - do you model in the warehouse first, or do you let the consumption layer take the first pass and promote later ? And has anyone actually made a promotion rule stick ? Feel free to share in the comments, and stay tuned for more.

SAP Data & Analytics Field Notes by Ingo Hilgefort.

Verify against official SAP documentation before acting.