How SAP BW/4HANA Revolutionizes the BW Modeling You Know

For almost 20 years, every SAP Business Warehouse (SAP BW) project started with defining tens or hundreds of InfoObjects. This task was not only time consuming, but it also laid the foundation of your overall data model—for years!

SAP began to introduce new modeling objects with SAP BW 7.4 back in 2013. The newer releases of SAP BW 7.5 and especially SAP BW/4HANA added more and more functionality over time. However, most customers and consultants just looked at the new features and functions, and forgot to recognize the impact on business warehouse (BW) modeling in general. The effect is tremendous as the SAP BW modeling was silently revolutionized.

New Objects and Features

It all starts with the new SAP BW objects: CompositeProvider, Open ODS View, and DataStore Object (advanced). They were introduced with a purpose, not just to replace »classic« objects and to overcome their deficiencies. Most blogs and documents only talk about simplification with SAP BW/4HANA, cutting down from ten to four modeling objects. That is only half the truth and sounds more like taking away options.

Adding long missing flexibility to SAP BW data models is essential and enabling agile data warehousing capabilities was also long overdue. Field-based modeling and virtualization are key features in this context. Field-based models avoid creating the hundreds of InfoObjects before you can do anything valuable for a pilot or prototype data model. It is also a big plus if the data can be accessed directly without having to load it to the system first. Moreover, you can add native SAP HANA SQL-artefacts like calculation views to enable mixed modeling without having to move multiple copies of your data. The icing on the cake comes with optimized data tiering across hot, warm, and cold data stores all within one DataStore Object (advanced) based on partition level.

General Modeling Strategies

Virtual data modeling is one of the newer concepts introduced by SAP HANA virtual tables linking to data outside the system. It avoids persistent data storage and only reads the data when a query runs against that virtual table for instance using an Open ODS View or a CompositeProvider. This does not make persistent storage of data within SAP BW obsolete—it adds another dimension when modeling new scenarios.

For years, the traditional modeling followed a strict top-down approach, where those countless InfoObjects had to be created first before doing anything else. Now, the option to model based on fields allows bottom-up modeling. Fields and InfoObjects can also be mixed. This way you can have models very close to the structure of your source data and can analyze it without further processing. This raw data layer was previously the PSA and could not be queried directly.

As mentioned before, you can still plug-in InfoObjects for master data features to help building more robust models or use InfoObject associations within CompositeProviders and Open ODS Views to inherit InfoObject features in queries (wherever this makes sense). However, this gained flexibility could come with costs. If all models are virtualized and field based, this could potentially mean many joins and on-the-fly data access. The cost for this could be performance depending on the overall complexity, number of layers, and many other influencing factors.

Modeling Approaches

Plenty of books and articles have been written on data modeling in a data warehouse context. It started mainly with two approaches: dimensional data modeling and normalized data in third normal form (3NF). More recently data vault became a popular concept too. The superiority question is an academic discussion, as each method has its sweet spots and personal preferences differ.

SAP BW/4HANA now enhances the traditional dimensional modeling of SAP BW. The aforementioned features allow you to create more flexible models using concepts from data vault like the modeling of highly volatile master data now also in an SAP BW system. You can also build agile scenarios by using a direct connection to a source system with Smart Data Access and build virtual layers on top of that. Alternatively, you can replicate the data and persist it. In both cases, you very often get the data in 3NF. You can now mix those into hybrid models that fit your requirements and SLAs. (You can find more information about this in, LSA++ and BW on HANA Dynamic Dimensional Modeling.

Data Acquisition and Connectivity

The previous example of real-time access or replication brings data in a normalized format into the system as most OLTP systems are built on data models close to 3NF. On the other hand, traditional business warehouse extractors for SAP systems deliver data in a dimensional format. Hence, the data acquisition type and the data source itself often determine the lower layer(s) of your data model architecture. If you then start to harmonize and consolidate data across a heterogenous source system landscape, you can use the SAP BW/4HANA modeling capabilities to handle this with minimum persistency.

One popular feature is the usage of native SAP HANA views to replace complex transformations. Often hundreds of code lines in SAP BW can be replaced by a few SAP HANA views, which not only simplifies the overall data model, but also the maintenance aspect of your data model.

Connectivity was always a weak spot for SAP BW. The introduction of HANA Smart Data Integration (SDI) with SAP BW 7.5 on SAP HANA dramatically enhanced the connectivity of SAP BW to pretty much any source system out there. This includes open source data lakes like Hadoop and Spark. All with traditional batch load jobs but also direct access capabilities or real-time replication, depending on the source system.

Requirements

This is where it all comes together. The business requirements and service level agreements have a large impact on every data model. For example, the expected response times, global vs. divisional view, real-time vs. batch delivery, and so on, all have an influence on your data model. On top of that there are additional functional and non-functional requirements as well as internal governance rules and sometimes even external regulations the final data model must meet.

Conclusion

Balancing the diverse requirements is not an easy task. However, SAP BW/4HANA enables much more flexibility than SAP BW modelers ever dreamed of. It also helps greatly reduce operating costs since change requests can be handled much easier through fewer persistent layers. There’s not a single killer feature, but the innovations delivered over the past years in SAP BW powered by SAP HANA and SAP BW/4HANA together provide a toolset for a modern data platform that can handle today’s and tomorrow’s business requirements.