Long live the data warehouse

Long live the data warehouse

10 reasons why the strategic enterprise architect will include BW/4 in their S/4 programme



The opinions within this article are my own and do not reflect those of my clients, past or present. 


S/4 brings a wealth of capabilities.  These capabilities include stellar performance, CDS views and purpose orientated Fiori apps. The combination of CDS views and reporting apps comprise Embedded Analytics.  This availability of Embedded Analytics has led some enterprise architects to conclude that a data warehouse is an unnecessary expense and have hung their reporting strategy on S/4 alone.  In this article, I will put the argument that S/4 is not a panacea, that the data warehouse is still a valid component of the landscape, and that the reporting architecture should be included in the overall architecture from the outset – not introduced as an afterthought.

No S/4 is an Island

Arguably the three common processes in all organisations are Finance, purchasing and HR. Whilst a programme might start with just S/4, a theoretical modern SAP-centric landscape might easily comprise the following systems:

A group of logos with text

Description automatically generated


Efficiency of the individual processes is enhanced by these best-of-breed tools but the data that their transactions generate needs to be brought together and blended for high level managerial reporting and analysis.  Suddenly, reporting out of S/4 becomes a bit more problematic as, to do this reporting, one would need to start loading the relevant data to it and perform the necessary harmonization and transformation.

Include data from any other functional and line of business systems and the argument for a purpose-built data warehouse becomes compelling.

Alternatives such as replicating data across the landscape and data federation bring a host of challenges; loss of one source of the truth, sub-optimal performance and loss of agility to name but a few.

Additional Historical Data

Data take-on for an S/4 project is a major consideration.  Ideally, only data that is absolutely necessary will be loaded into the transaction system.  This might be open documents, current fiscal year or, at a stretch, current fiscal year plus one.

On the reporting side of things, year on year comparisons are a given, however, there are many KPIs which only become meaningful over considerably longer periods of time.  This information has no place in the transaction processor.  BW/4 supports the loading of summarized historical data and blending it virtually with the latest information loaded at transaction level from S/4.

Reduce Load on the Transaction Processing Systems

The original function of the data warehouse is to take the ‘heavy lifting’ from the transaction processor and move it to an environment which is technically orientated towards rapid mass-processing of data.  The HANA database supports very fast reporting both in S/4 and in BW/4, however, in the data warehouse much of the work is done during ETL.  Even in S/4, memory consumption and CPU can still be a significant resource bottleneck.  At no point should transaction processing be jeopardized by reporting activity.  This fundamental purpose is still valid today, especially when reporting on long-term data, cross-application functions or where complex calculations or look-ups are required.


Data Security

Data security has never been more important. High profile data breaches result in negative corporate publicity and/or significant fines through legislation such as GDPR.  The authorisation concept in BW/4 HANA packages the query permissions with the data permissions.   The authorisation concept is simple and transparent. The models and the access to them is all contained and controlled in one system with one technological basis. 

A federated data approach, for example, relies on each source system performing its own checks which means different technology and different underlying data sets.  This in turn means more moving parts to coordinate during access provision.  The risk of incorrect or partial access being granted is significantly higher, as is the administrative overhead.



Archiving is not something that generally gets thought about at the start of any project, however, at some point it is likely to become necessary.  BW/4 enables archiving without compromising critical reporting.

Reduce the Overall Data Footprint

It seems counter-intuitive that a data warehouse will reduce the overall data footprint, however, S/4 transactions typically reference many tables (and table columns) that are useful only for the period that the transaction is active.  By extracting the useful information and archiving old documents a data warehouse can reduce the overall footprint.

Lower Cost Long Term Data Storage

Concepts such as dynamic data tiering and near-line storage allow an organisation to store information in BW/4 long after it would be useful in the transaction processing system.  The data is still available for reporting, but the storage cost reflects how regularly it needs to be accessed. Whilst it is theoretically possible to utilise this functionality in S/4, the organisation and partitioning of BW/4 objects makes this much more practical to achieve.  Typically, in S/4 transactions must be reloaded from the archive before the data in them becomes available.


BPC is an excellent, mature and well understood planning solution whose latest edition comes embedded inside BW/4.  Implementing BPC provides the significant advantage that plan data can be reported on in situ. 

Separating reporting and planning into different systems is, in my mind, a major mistake. It inevitably results in competition between the two systems.  More and more reporting moves to the planning solution resulting in two sets of the same data and a loss of one source of the truth.  There is an associated rise in the total cost of ownerships as two teams grow and battle it out to deliver the same information.

Time Dependency and Snapshots

Multiple iterations and views of data are often required.  Examples of these are as follows:

Versions of Forecasts

BW/4 is the ideal place to create and store versions without impacting your transaction processor.  This is especially true if the planning is being done in BPC.

It is not unusual to have 13 versions of a given plan type for one year (the budget, plus twelve, monthly snapshots). The volumes associated with this can be significant.

Historical months in forecast versions are typically filled with 'actuals' numbers.  Clever BW/4 modelling capabilities allow these periods to be provided virtually rather than needing to persist the same information in multiple versions.

There is often more pressure to reduce disk space on the transaction processor, so the shelf-life of the versions is likely to be shorter in this environment.  The benefits of keeping versions for extended periods are not always immediately obvious, however, this data can often be valuable.  Having ready access to an old forecast allowed one previous client to support an insurance claim of significant proportions.

As Is and As Was Reporting

Different reporting perspectives are needed when the sales representative for a customer changes mid-year.  The current sales rep wants to see the history for that customer to make appropriate sales pitches.  They also need to see what their personal sales were across their current and previous customers so that they can achieve their targets.  There are many examples of where this dual view of data is required, and data warehouses are inherently designed to support this. This is particularly complicated where hierarchies are involved, BW/4 HANA comes with out-of-the-box functionality to meet that challenge.

Point-In-Time Positions

Whilst real or near-time data is the demand of many requirements, there are many situations where the opposite is desired:  Weekly snapshots of open positions to reveal the changing blend of that picture. Frozen HR or finance positions to support requests for more information on publicly published top-line figures, and where the total of the follow-up details are expected to match the original headline numbers.  S/4 is not the place to store this information.


The data that is collected into a data warehouse is typically enterprise data from shared service systems supporting core functions.  There may be many parts to the business which perform different functions (line of business) and have their own needs of this data.  Multiple interfaces to multiple systems using different technology is expensive, both in creation and support.  Using BW as a centralised data hub provides the opportunity to connect to the source systems once, collect and transform the data once and to make it available from one source to the downstream consumers using a consistent approach.

Reduced Rework

Failing to plan the business intelligence strategy and incorporation of reporting requirements at the outset can result in many negative outcomes:

·         Reports being built in the transaction processor which later have to be moved to the data warehouse.

·         Failure to build functionality into business processes in S/4 that is necessary to support report requirements.

·         Fundamental overhauls in report provision as more systems come online.

Business Continuity

Where it is understood that system outages will be required for upgrades and project go-lives, one approach to mitigate the business impact is to keep the data warehouse up for planning and reporting whilst the transaction systems are maintained. A BW/4 system provides flexibility.

Bonus Reason – Business Content

BW/4 was designed and developed as the stable-mate to S/4.  The business logic is built into the solution.   There is a huge amount of reporting capability ready out-of-the-box.  This simplifies design, encourages best practices and reduces the delivery time.


A number of reasons to use a data warehouse have been put forward.  Many of these will not be obvious at the outset of any programme. 

With SAP’s 2027 deadline for ECC support looming, many organizations are about to set out on their own transformation.  Hopefully, this article will support architects in their decisions regarding their target system landscape.


This article is the first in a series and is written on the premise that an on-premises S/4 HANA solution requires an on-premises BW/4 HANA data warehouse counterpart.  SAP have a strategic direction to go to SAAS products.  The following articles will discuss the pros and cons of these and suggest tactical approaches to getting the best from both worlds.