Hana SQL DWH vs SAP BW vs Mixed Scenario - Quick Guide -

Traditionally, the SAP Business Warehouse (BW) is the Data Warehouse (DWH) solution of choice. For companies with an SAP ERP system, this is the most obvious solution for any reporting requirements due to their strong integration. The AnyDB approach in the BW environment is disappearing and giving way to an integrated approach with SAP's in-house database: SAP HANA data warehouse. In parallel, there is a development of end-to-end cloud offerings with the Datasphere [formerly known as SAP Data Warehouse Cloud (DWC)] and the HANA Cloud.

As the functional scope of HANA increases, so do the possible applications. For example, for a few years now, with HANA 2.0, the XSA and some tools such as the Data Warehouse Foundation, it has been possible without any problems to operate a native Data Warehouse solution, i.e. without an additional application layer such as BW, in other words:

HANA SQL Data Warehouse a.k.a. HANA Native Data Warehouse

In this article, we present the HANA SQL DWH approach - a high-performance and modern alternative to the traditional Business Warehouse. We analyze the differences and similarities in relation to SAP BW and then describe different usage scenarios depending on the business situation, especially in relation to the most recommendable Data Warehouse solution.

What is a HANA SQL Data Warehouse?

A HANA SQL DWH is a SQL-based, analytical database. Database objects can be generated and manipulated using SQL. A SQL dialect designed by SAP called "SQLScript" is used, which extends the OpenSQL standard with a variety of functions and, among other things, imperative logic. In addition, selected database object types, such as calculation views, can be modeled via a graphical context menu, which enables developers without SQL know-how to present a basic range of modeling scenarios that cover the most common use cases.

By using Extended Application Services Advanced Model, or XSA for short, SAP HANA also has a platform that brings decisive advantages.

It achieves a fundamental division of runtime and devtime - a technical architecture that has been common practice in conventional software development for decades. Specifically, development does not take place directly on the runtime of the database, but in a dedicated development environment (WebIDE). Here, the database objects are defined and then only applied to the database in a subsequent deployment process. In terms of development this involves a change from commands to definitions. For example, instead of creating a table using the CREATE command, it is defined using the CORE DATA SERVICES (CDS) syntax. During deployment, this target state definition is automatically compared with the as-is state of the database and the necessary SQL commands are executed to implement the changes.

This concept results in the XSA specific HANA Deployment Infrastructure (HDI) and, in combination with GIT as an established tool for versioning and collaboration, leads to a number of advantages in the areas:

• Collaboration

A large number of developers can work on the same objects as well as on dependent objects. The combination of automatic detection of resulting conflicts, as well as functionalities to resolve these conflicts, minimizes the effort of harmonization.

• Versioning

An established and integrated solution for the history of all changes and simple rollback possibilities are provided.

• Deployment

The HDI architecture enables a platform-independent deployment.

Differences and similarities

Scope of functions

The basic functionalities for modeling standard data warehouse scenarios are provided both in BW and on a native HANA solution.

Where ADSOs are used in BW for the physical storage of data, tables are used in the HANA DWH. Any kind of internal data transfer between persistent objects is realized in HANA via procedures or flowgraphs, whereas BW uses Data Transfer Processes (DTP) and Transformations. Composite Providers are the virtual objects of choice in BW and are mainly used in the Reporting Layer - the HANA DWH provides Calculation Views for this purpose.

With the release of the Data Warehouse Foundation toolset for the HANA platform, some essential data warehousing functionality - including request handling, scheduling and delta management - has now been delivered by SAP, replacing previously required third-party tools.

Apart from these similarities, the HANA platform also offers additional special support for machine learning applications with PAL, while SAP BW provides extensive business content based on decades of use across a wide range of industries. HANA SQL DWH has no integrated business content, but SAP's first efforts in this direction can be seen with Financial Services Data Management (FSDM), a complete, preconfigured data model for the banking industry. 

A comparison of SAP BW, HANA Native and SAP Datasphere - 
Download our whitepaper now!

Time-to-Market

HANA offers modern development tools free from legacy issues. Each database object can be developed purely by coding (SQL/CDS/XML). The most common scenarios can also be mapped using graphical development tools (Calculation Views, Flowgraphs). Together with the collaboration, versioning and deployment features provided by the XSA platform, the HANA Native development process offers high flexibility and efficiency.

BW has become increasingly complex and confusing due to the need to support legacy functionality and technical limitations. Development takes place primarily via graphical development tools, while ABAP coding is used in complex scenarios that exceed graphical development capabilities.

In summary, the development process in the HANA SQL DWH environment is more straightforward and time efficient, resulting in a faster time-to-market for reporting applications.

Performance

 Concept of Code Pushdown

The concept of code pushdown - compute-intensive operations needing to be executed on the database layer instead of on the application layer - is used natively in the HANA SQL DWH environment and is the standard scenario. In this way, the performance-limiting input/output (I/O) bottleneck between the database and application layers is bypassed. Furthermore, the central advantages of the HANA database compared to other databases are exploited: the column store concept and the use of main memory as a central storage medium. In the BW environment, this concept is not exploited by default. However, the former can be achieved using ABAP Managed Database Procedures (AMDP) and the latter is handled in the same way in the background in new BW versions.

Usage scenarios 

Based on the individual situation and technical system landscape of a given company, there are three basic variants for the use of an on-premise SAP Data Warehouse:

• BW only

For companies with already high technical, personnel and monetary investments in an SAP BW landscape, it is advisable to stay with the established concept. Especially if time-to-market of new reporting developments does not play a central role, the business content of the Business Warehouse is used extensively and the modern infrastructure does not show any synergies with, for example, machine learning applications and UI5 applications.

This also avoids a risk in the area of know-how, because SAP BW and HANA SQL DWH have intersections in this regard, but also significant gaps. The talent pool for experts in the SQLScript and HANA Native area is significantly narrower than the amount of BW and ABAP experts that can be drawn on - both internally in the company, externally and within the applicant pool. On the other hand, the use of modern solutions and development platforms, as it is a given in the HANA SQL DWH environment, offers a non-negligible recruiting and self-training incentive. There is also a significant overlap between HANA SQL development and the know-how of traditional database development to draw upon.

• Standalone HANA database

A HANA database can also be operated without a BW system as a central Data Warehouse. This scenario is particularly suitable for migrating an existing analytical SQL DWH from another provider (e.g. an MSSQL server), with the aim of using the tools of the HANA platform and the performance advantages of the hardware and technical architecture, as well as consolidating the software providers used.

This solution is also suitable for companies that have made very little investment in their previous Data Warehouse platform or are just setting up their first Data Warehouse. The lean, modern and flexible HANA Native solution is much more user-friendly for the setup of a new Data Warehouse.

Special attention is also required in the Financial Services sector, where SAP Financial Services Data Management (FSDM) is offered. This software solution provides a ready-made data model for the HANA SQL DWH, which covers the extensive external reporting requirements of banks - similar to the Business Content in BW.

• Hybrid solution

Experience shows that the most common variant is a hybrid solution, i.e. the use of an existing BW (on HANA, or BW/4HANA) system and additional native development on the HANA database side of the same system. Historically grown companies will for the most part have already made heavy investments in their BW system - for a complete migration to a HANA SQL DWH, the costs outweigh the benefits many times over. At the same time, the upgrade to an on HANA or BW/4HANA version has either already been carried out, or is planned anyway due to the relatively low effort and strong benefits, as well as the avoidance of restrictions in support. Therefore, it makes sense for such companies to take a low risk and make smaller investments with initial prototypes in a HANA SQL DWH environment. In this way, the advantages of the HANA SQL DWH can be used in the applications where they make up the greatest benefit and a complete migration can be avoided.

It is also conceivable to use additional, independent HANA databases in addition to the central BW system. 

Do you have questions about how to get the best use out of your BW? Are you trying to build up the necessary know-how in your department or do you need support with a specific question? We are happy to help you. Request a non-binding consulting offer today!