SAP BW/4HANA is a fantastic enterprise data warehouse (EDW), not only for existing SAP users, but also for organisations who don’t have an SAP focus. Historically there were good reasons not to choose SAP Business Warehouse (BW) if you weren’t an SAP house. However, times have changed, and so has SAP’s BW solution, as Jan van Ansem explores…
Enterprise Data Warehousing and SAP
SAP Business Warehouse (SAP BW) has long been considered an EDW solution for organisations running their back-office processes on SAP. Organisations with little or no SAP in their back-office would typically build an EDW solution with a variety of generic tools (database, data load management, reporting, data quality management).
Such EDW solutions are often referred to as SQL EDW implementations, to distinguish them from solutions with the SAP BW application.
The latest Data Warehouse application from SAP (SAP BW/4HANA) uses new features which make the application far more attractive as an EDW platform, even to organisations who don’t run SAP in the back-office.
A brief history of enterprise data warehousing
Many companies started to build their data warehouse in the early and mid-1990’s. These data warehouses were built either using Bill Inmon or Ralph Kimball’s data warehouse approach.
The differences between the approaches are well documented so I won’t repeat them here. Right now, I would like to look at the tools used for building a data warehouse.
Up until 1998 there were no platforms which delivered all data warehousing functions, so you could only build a data warehouse with generic tools (Database and ETL tools as the core functionality). Then in 1998 SAP repeated the business model they had used 25 years earlier for enterprise resource planning software: it recognized that many companies were building the same solution, so it designed and delivered an out-of-the-box solution for data aarehousing. SAP BW was born.
SAP BW was, and arguably still is, the only application which delivers all DW functions in one application. For organisations with SAP in the back office, the SAP BW system has a big advantage: it comes with predefined ‘Business Content’ for data extraction, load processes, multi-dimensional data models and even out-of-the box reports. This goes a long way to explaining the success and high adoption rate of SAP BW in organisations running on SAP. Particularly in the early days, the effort of implementing a Data Warehouse was easily reduced by 50% just by using this Business Content.
But what was a deal-winner for SAP-oriented organisations became a deal-breaker for others. Non-SAP organisations saw the SAP content as irrelevant and therefore didn’t look further at the generic DW capabilities of SAP BW. Granted, SAP didn’t help this issue by locking in the data into the SAP ecosystem, which made it an unattractive offering if you were not SAP oriented to start with.
There are two forces at play which contribute to the adoption of the SAP BW/4HANA in organisations without an SAP footprint:
The market for DW applications is saturated. SAP’s only way to grow its market share is by finding greenfield customers. This has forced SAP to become more open and to provide attractive agreements to potential new customers.
The SAP BW/4HANA application is underpinned by the SAP HANA platform, which is incredibly powerful with a super-fast database (in-memory, column based), built-in advanced analytics functions (predictive, text analytics, to name just two), data integration, quality and streaming services, and much, much more.
The symbiosis between the SAP HANA Platform and SAP BW/4HANA results in a fast, flexible and easy to use Data Warehousing system, which is open to non-SAP data.
Data warehousing techniques
With this in mind, let’s have a look at some of the techniques which are widely used in the EDW world, and how these translate to the BW/4HANA system.
Architecture approach: Top-down or bottom-up?
This is one of the core differences between ‘Kimball’ and ‘Inmon’. Should you:
a. Start with a core data model, build the core layer and only build your datamarts afterwards, if and when you need them?
b. Start with datamarts and somehow make sure that data cleansing and business rules are implemented consistently across all datamarts?
Why not have your cake and eat it?
BW/4HANA uses a framework called ‘Layered Scalable Architecture ++’. This framework incorporates the use of virtual models, for example to create datamarts. The ability to create high performance virtual datamarts was out of reach when Kimball and Inmon came up with their models.
In fact it is still out of reach for many DW applications not underpinned by the SAP HANA platform.
This framework allows for incredible flexibility and enables the use of datamarts whilst building your core data warehouse layer. You see: have your cake and eat it.
We are in Kimball’s camp now, where logical integrated datamarts depend on conformed dimensions and facts, which are defined in something called a ‘Dimensional Bus’.
The SAP BW/4HANA application uses standard building blocks for this, called ‘Info Objects’. These Info Objects are business entities and have properties and attributes. These Info Objects are re-used throughout different models. For example, you can define ‘Customer’ once, and use it in many different models – either for physical or virtual data. All the ‘customer’ properties are automatically available wherever it is used.
This goes far beyond the normal attributes you see in data models. It also includes properties for time dependencies, hierarchies, multi-language support and even authorisation. Some of these properties are notoriously difficult to model in a generic DW, but in SAP BW this all comes as out-of-the-box functionality.
The ‘Data Vault’ methodology (which defines a modern approach to data warehousing) uses ‘Error Marts’ so records can be ‘put aside’ if their content does not comply with data integrity rules. The idea is that the content will be corrected at a later stage and subsequently loaded into the data warehouse system. Not only is it very useful but it is also very important, as there are usually more data integrity checks in a DW system compared to the system of origin.
In BW/4HANA you can simply switch on the feature for error handling in the load processes and define whether the offending data should cause the load to continue or fail, and if the data should simply be omitted or put aside so it can be loaded after a correction has taken place. Again, this is a standard feature of the application.
The three examples above are only a small selection of design guidelines from standard EDW methodologies which come as out-of-the-box features in the BW/4HANA application. I can easily think of many more (key generation, data snapshots, big data integration) but hopefully these are a good enough illustration of how well-suited BW/4HANA is as a generic EDW application.
If you are looking for a well performing, flexible and easy to use data warehousing platform then BW/4HANA must be on your list of options to consider, regardless of what source systems you are using. Many customers have been blown away by the power of SAP HANA and hopefully one day soon you can see it for yourself if you are not on HANA already.