BW/4HANA is an evolution of BW that is completely optimized and tailored to SAP HANA. The BW/4HANA code can only run on SAP HANA as it is interwoven with SAP HANA engines and libraries. The ABAP part is several million lines of code smaller compared to BW-on-HANA. It is free of any burden to stay, e.g., within a certain, “common denominator scope” of SQL, like SQL92 or OpenSQL, but can go for any optimal combination with what the SAP HANA platform offers. The latter is especially important as it extends into the world of big data via SAP HANA VORA, an asset that will be heavily used by BW/4HANA.
So, what are BW/4HANA’s major selling points? What are the “themes” or “goals” that will drive the evolution of BW/4HANA? Here they are:
Depending on how one counts, BW offers 10 to 15 different object types (building blocks like infocubes, multiproviders) to build a data warehouse. In BW/4HANA, there will be only 4 which are at least as expressive and powerful as the previous 15. BW/4HANA’s building blocks are more versatile. Data models can now be built with less buildings blocks w/o compromising expressiveness. They will, therefore, be easier to maintain, thus more flexible and less error-prone. Existing models can be enhanced, adjusted and, thus, be kept alive during a longer period that goes beyond an initial scope.
Another great asset of BW/4HANA is that it knows what type of data sits in which table. From that information it can automatically derive which data needs to sit in the hot store (memory) and which data can be put into the warm store (disk or non-volatile RAM) to yield a more economic usage of the underlying hardware. This is unique to BW/4HANA compared to handcrafted data warehouses that require also a handcrafted, i.e. specifically implemented data life-cycle management.
BW/4HANA – as BW – offers a managed approach to data warehousing. This means that prefabricated templates (building blocks) are offered for building a data warehouse in a standardized way. The latter provides huge opportunities to optimize the resulting models for SAP HANA regarding performance, footprint, data life-cycle. In contrast to classic BW, it is possible to deviate from this standard approach wherever needed and appropriate. On one hand, BW/4HANA models and data can be exposed as SAP HANA views that can be accessed via standard SQL. BW/4HANA’s security is thereby not compromised by part of those SAP HANA views. On the other hand, any type of SAP HANA table or view can be easily and directly incorporated into BW/4HANA. It is thereby not necessary to replicate data. Both capabilities mean that BW/4HANA combines with and complements any native SQL data warehousing approach. It can be regarded as a powerful suite of tools for architecting a data warehouse on SAP HANA with all the options to combine with other SQL-based tools.
BW/4HANA will offer modern UIs for data modeling, admin, monitoring that run in SAP HANA Studio or a browser. In the midterm, SAP GUI will become obsolete in that respect. Similarly, SAP’s Digital Boardroom, SAP BusinessObjects Cloud, Lumira, Analysis for Office and Design Studio will be the perfect match as analytic clients on top of BW/4HANA.
4. High Performance
Excellent performance has been at the heart of BW since the advent of SAP HANA. As elaborated above, BW/4HANA will be free of any burdens and will leverage any optimal access to SAP HANA which will be especially interesting in the context of big data scenarios as SAP HANA VORA offers a highly optimized “bridge” between the worlds of SAP HANA (RDBMS) and Hadoop/SPARK (distributed processing on a file system). Most customers require to enhance and complement existing data warehouses with scenarios that address categories of data that go beyond traditional business process triggered (OLTP) data, namely machine generated data (IoT) and human sourced information (social networks).
The figure below summarizes the most important selling points. It is also available as a slide.