How to tactically think about your SAP BW conversion to SAP BDC – Part 2

In the last blog post, we covered how to think about converting a company’s BW data (contained in InfoProviders) into BW Data Products or SAP Data Products based on its S/4 HANA situation and how to consume data products from Delta Table (files).

In this blog post, we will focus more on space organization and modelling principals and a bit on how close SAP is getting in getting parity with BEx functionality as we know it from SAP BW.

ONE recommends its customers to work with a 3 + 2 space type concept for organizing and securing its Data Products. In short, the 3 space types that is always required are:

SAL spaces – or Source-Aligned Spaces: Larger sources should require its own space. We see too many customers bundling all sources into an inbound IT space, which creates issues later (performance reading artefacts, not sufficient security separation, etc.).

DOM spaces – or Domain-Aligned Spaces: These are business owned spaces with each own Data Product owner. Find an appropriate level of spaces by function, i.e. not just 1 finance spaces but closer to sub-modules you have in your ERP, e.g. FIN-AP, FIN-AR, FIN-PC, etc. The rule is to ensure that a company has single owner (or perhaps with a few delegates) to own all data product definitions modelled in those DOM spaces.

Global spaces: Here you will find security space, unit and/or currency conversion spaces, audit spaces and more. These are spaces tightly controlled by only a few trusted admin or design authority persons in your company

The additional 2 space types are:

SSV spaces – or Self-Service Spaces:  You can think about SSV in the shape of a 1:1 relationship with DOM spaces. The difference here is that models in here are non-transportable (i.e. created directly in prod), temporary in nature to explore new value cases (so do not need to adhere to naming convention) but hence, should also not be shared to adjacent DOM or SSV spaces, so only upward flow. If value is discovered, the idea is that those models would then be re-factored into the appropriate DOM space.

OUT spaces – or Outbound Spaces:  These are spaces to help trim what is exposed today in OpenSQLSchemas as default Datasphere security is lost when exposing artefacts to OpenSQLSchema. SAP is working on a 3^rd party JDBC, ODBC connector to run on top of Analytic Model (supporting SSO and standard Datasphere security features) so once that is live, this space type should no longer be required.

So how does this then come together as an example when I want to tap into my SAP BW Data Products in HANA DataLake?

In our SAL spaces we focus on Inbound and Harmonization. In rare cases, we can have some propagation with business logic but then it would be enterprise level, slow changing and no need for real data product ownership. It is in this space where we prepare abstractions of normalized artefacts to become de-normalized, e.g. attributes, text and hierarchies.

In our DOM spaces, we model the propagation logic, e.g. ledger linking, trimming of columns, filters and row-level logic (if required). These are still type relationship view and or fact view. For the reporting layer, we use analytic model and here is where SAP is now closing the gaps quickly with a bunch of analytic model features being delivered in Q2 and Q3 2025.  

Most important and significant innovations in the analytic model (4AM_%) area are secondary structures (re-useable structures as we know them from BEx), business functions for more complex restricted measures, e.g. YTD, stacking of analytic models and sharing of analytic models, e.g. from DOM spaces to SSV spaces. See links below to upcoming innovations at the bottom of this post.

Where ONE seems most challenges in front-end modelling is where companies use SAC to model more complex restricted, calculated measures on top of Datasphere. This will have a direct impact on Datasphere CPU, Memory consumption and yield slower query response times.

Companies should always model such restricted, calculated measures in the Analytic Model (or in Views if row-level oriented) to ensure best query performance as the MDS and SQL engine of Datasphere are well integrated. The issue with SAC, unless data is imported, is that SAC is no longer a traditional server based solution but a client solution where vast meta data is exchanged between SAC and a user’s client whilst data is retrieved directly from Datasphere so load is placed on a clients laptop, where too many variables are importing performance (laptop specs, network speed, geographic location from SAC tenant, etc). So, SACs primary role should be for the visualization and guided navigation. Also, building your restricted, calculated measures in analytic models would ensure agnostic access from any 3^rd party tool (once SAP delivers its 3^rd party connector, estimated by end of 2025).

If you want to learn more about ONE and our capability and how we work with customers, then please reach out to us at info@one-consultants.com

New features

Q2-2025:
Analytic model: stacking of analytic models and other improvements
Secondary structure for analytic models
Support for display attributes in analytic models
Analytic models: replacing fact source

Q3-2025:
Business functions for time period calculations in analytic models
Restricted measure based on node-level hierarchy
Sharing of analytic models
Unit conversion in analytic models
Variable value derivation for additional variable types