Planning Architecture with and without SAP Business Warehouse (BW)

Introduction

Several customers are currently reconsidering their planning architectures. If you are one of those, this blog might be interesting for you.

Let’s start with some building blocks you will find in almost every planning application:

  • Frontend
  • Data Modelling
  • Extraction/Retraction

In case a Business Warehouse is already established for reporting purposes, the probability is very high that you also used it for planning, specifically for data modelling and extraction/retraction.

As Frontend Bex Web was typically applied or Analysis for Office.

The introduction of SAP Analytics Cloud (SAC) into the system landscape changed the possibilities for planning architectures. With SAC there are roughly two flavors for planning.

Either you use SAC as frontend and for application development and still use your Business Warehouse for data modeling and extraction/retraction (BPC Live Approach).

Figure 1: BPC Live Approach

Or you use SAC for everything (SAC Native Approach).

Figure 2: SAC Native Approach

For the end-users there is not too much difference, as the unified experience with SAC as a frontend layer in both approaches is guaranteed. But from the architecture point of view, there are major differences, and you should consider the options very carefully before starting new projects.

Comparison SAC Native and BPC Live

With BPC Live you can still protect your investments from the past in case you implemented your planning applications with SAP IP/PAK. You can switch the frontend without too much effort (e.g., from WAD templates to SAC). You are not forced to re-model your planning applications.

With BPC Live you are also using very powerful tools for the different purposes. Business Warehouse is extremely powerful in data modeling and very powerful for extraction and retraction.

From the author’s perspective the BPC Live approach is the most powerful approach as you have the most extensive capabilities in all 3 areas (Frontend, Data Modeling and Extraction/Retraction).

With SAC Native you can create new planning applications quite fast and you use SAC as well for data Modelling and Extraction/Retraction. But it should be clear that the data modelling capabilities are not as extensive as with BPC Live. And the cost for interfaces might increase with the SAC Native approach as you have to synchronize master data and transaction data. The interface topics are often underestimated. In case you have stand alone planning applications with low complexity, SAC Native will be the right choice.

But what about more complex planning applications?

To be honest, in most of the planning projects, the complexity is higher than expected and increases during the project. Soon you will be confronted with requirements which require custom logic and also require complex data modeling. For such projects you will most probably not yet be able to implement them in SAC Native flavor. SAC Native comes with scripting, but for data modeling you will see limitations.

A very basic principle is also not to split the reporting from the planning system.

In case you have implemented major parts of your reporting in SAP Business Warehouse, why would you model the planning application in a different system and not reuse your reporting investment at least partly instead? You would have to recreate your KPI definitions and variables, etc.… another time in the planning system for reporting purposes and keep them in sync after the project phase during service support.

On the other hand, if your planning application is very isolated and there is no reporting system yet, SAC Native could be the way to go.

My recommendation is to analyze the requirements and afterwards judge which architecture fits best, the first questions could be:

  • How complex is the planning application
  • Where is the reference data?
  • Where is the reporting currently implemented?
  • Do I want to re-model my application or is it sufficient to switch to a state of the art frontend and improve the user experience?

The role of Datasphere

Let’s think about Datasphere in context of planning. The extraction and retraction could also be covered with Datasphere instead of Business Warehouse. Also, if SAC Planning inside Datasphere will allow to physically store the data inside datasphere, some interface topics will become smoother. But the questions from above will remain valid.

A game changer would be if there would be some kind of planning engine inside datasphere which could cover complex requirements. But so far, there is no such announcement that such a planning engine will be on the roadmap of Datasphere. This means that the boundaries of the SAC Native approach especially for complex planning applications will stay and you might not be able to fulfill your planning requirements with the SAC Native approach for all scenarios.

Summary and Recommendation

To summarize, the recommendation from the author’s point of view is to use the BPC Live scenario for complex planning applications, high amount of data and for scenario where your reference data and reporting solutions are already inside Business Warehouse.

For medium to low complex requirements go for the SAC Native approach.