With the introduction of the HANA technology (2012), SAP was given the opportunity to take a critical look at the systems they offered and the associated platform. Forced by market developments and pushed by technological developments, SAP looked at the possibilities of simplification and acceleration. In this article we look at the consequences of the introduction of HANA technology on the systems involved and their role, function and contribution to the business intelligence domain.
SAP BW includes backend functionality for data modeling, data storage and ETL (Extraction, Transformation, Load) as well as front end functionality such as Query Designer, Web application Designer and Bex Analyzer. Although this is a big advantage compared to other BI systems and solutions, there are also a number of limitations to mention of SAP BW:
- Performance: the structure and the way in which the data model is set up in combination with the underlying database has a strong influence on the performance of the system. This applies not only to the response times of running the reports but also to the turnaround times of the loading of the data.
- Complexity and flexibility: up to and including SAP BW 7.5 the Layered Scalable Architecture (LSA) structure can be used. In this structure, +/- 10 technical objects can be used to store data (info object, DSO, Info cube) or to view the data (eg info set and multi provider). Due to the large number of technical objects it is not clear when which technical object is best to use.
- Interaction with non-SAP systems: SAP BW, like all other SAP systems, is based on NetWeaver, where SAP ABAP is the basic programming language. As a result, the interaction with non-SAP systems is not optimal.
SAP BW on HANA
The introduction of HANA has in the first place ensured that SAP BW can be installed on a HANA database (SAP BW on HANA). With this, part of the performance problems have disappeared. Through the in-memory technology, processes of data loading and running reports from the application server (where the software runs on) are moved to the HANA database (the database in which the data is stored). The latest version of BW, SAP BW 7.5 is largely optimized to make use of all functionalities of SAP HANA. This version also contains various conversion tools to prepare the migration of the tool to the new system, BW/4 HANA.
SAP BW/4 HANA was introduced in 2016 and is not a successor of SAP BW, but a completely new system that can benefit fully from the HANA in memory technology. This system runs completely in the HANA database and can therefore take full advantage of the performance improvements in the area of loading data and running reports. It also still contains functionality for data modeling, data storage and ETL (extraction, transformation, transfer). It no longer contains front-end tools for running reports and analyzing the data. For example, the BeX analyzer is not available in BW/4 HANA. These have been moved externally, for example by using the SAP Business Objects tools such as Lumira 2.0 and Analysis for Office.
With the introduction of HANA a new architecture (LSA ++) is introduced. This architecture has fewer layers and a number of layers have become virtual. This allows direct reporting on data from the source systems. The advantage of this is that it is no longer need to load data physically to BW/4 HANA. This makes it possible to arrange a so-called hybrid data model. Setting up a hybrid data model makes it possible to combine data with data from S/4HANA Embedded Analytics, SAP HANA Native but also in combination with non-SAP systems. The latest is possible because BW/4 is SQL based as most of the non-SAP systems. Besides the introduction LSA++, the number of data objects that can be used for data modeling is reduced from 10 to 4. All this simplifies the data model and accelerates the development times. As a side effect of all this, the business content (standard data structures in BW) has also been adjusted for BW/4 HANA, business content optimized for HANA. This makes the connection with other SAP systems as a source system still optimal.
S/4HANA Embedded Analytics
In S/4 HANA, transactions are processed faster and easier. This is due to the in-memory technology and the simplification of the data model. If data was previously stored in many different tables, combined data is now recorded in a limited number of tables. An additional side effect is that S/4 HANA besides the recording of transactions also has analytical possibilities. This is called S/4 HANA Embedded Analytics. With Embedded Analytics reporting is done directly on the source data as it is stored in the tables. Data does not have to be loaded to another database first and is therefore ideal for running operational reports. For operational reports, therefore, no use needs to be made of an Enterprise Data Warehouse, such as SAP BW or BW/4 HANA. Moreover, Embedded Analytics is very flexible. To adjust a report, only the CDS view (based on SQL code) needs to be adjusted. Because of this simplification it is possible to quickly respond to a changing information need. If needed the CDS view can be used as a data source for loading the data into BW/4 HANA in case of tactical and strategic reporting (management information).
SAP HANA Native
Although HANA is basically a database, it can also be used and arranged as a separate application. This is called SAP HANA Native. Compared to, for example, SAP BW and BW/4 HANA, the disadvantage is that it lacks a number of standard functionalities of an (enterprise) data warehouse. Here you have to use tools and / or functionalities in the field of data modeling, data storage and the planning and monitoring of data directories. For each of the functionalities, a specific tool will have to be chosen and it will also have to be set up. The big advantage is that SAP HANA Native is based on SQL in which you are completely free to develop and create your own data models. This makes this environment extremely suitable in combination with non-SAP source systems because in many cases these are also based on SQL code.
Initially the introduction of HANA's in-memory technology enables optimum benefit to be gained from performance improvement when loading data and running reports for the BW system. These are the so called BW on HANA systems. At a later stage, the introduction of HANA technology has helped to change the role and function of the systems involved to the business intelligence domain within an organization:
BW/4 HANA: a new BW system with almost all of the old data warehouse functionalities (except reporting) and which can be used as an enterprise data ware house (or as part of it) for tactical and strategic reporting (management information). It fits best in combination with SAP source systems.
S/4 HANA Embedded Analytics: the successor of SAP ECC and as well as recording transactions it can be used for operational reporting. Data no longer needs to be loaded into a data warehouse but can be reported directly on the source data. If necessary the data can be loaded into a data warehouse for management information (tactical and strategic level).
SAP HANA Native: As well as a database, HANA can also be set up / used as a separate application, in this case as an Enterprise Data Warehouse. For this, various tools will have to be implemented to get the required data warehouse functionalities for transferring and monitoring the data for example. SAP HANA Native fits best in combination with non-SAP systems.
It is possible to set up BW/4 HANA and SAP HANA Native or a combination of both as the Enterprise Data Warehouse. This system can be used for reporting on a tactical and strategic level. For operational reporting S4/HANA Embedded Analytics can be used. The integration of data can be done both physically (data storage) and virtually with views. This brings great benefits with visibility:
- Flexibility: loading data from the source to the data warehouse is faster and there are fewer layers that have to be physically loaded.
- Data virtualization: real-time data can be reported and not every data warehouse layer has to be physically loaded. Logic can be defined in the views instead of transformations in ETL (extract, transform and load) processes.
- Shorter development times: no more data needs to be loaded to see the outcome of a transformation. Views can also be modified more easily because they contain no data.