Practitioner Perspective, Modelling HANA vs BW7

[Former Member]

Practitioner Perspective, Modelling HANA vs BW7

Applies to:
Document is applicable to all systems on SAP HANA Platform.

Summary
This document provides an introductory and practical overview of HANA. It will provide a conceptual comparison as well as practical illustration.

Author Bio

He holds a Masters in ERP (Finance focus), Bachelor of Management (Australia) and a Diploma in Business InfoTech (Singapore). He is familiar with the Consulting and Support environments, with his various Project Lead & Consultant roles. He is situated in Singapore and is bilingual in English and Mandarin, conversational German.

During leisure, he enjoy documenting his experience and knowledge into conceptual model. As usual, the pdf version is in scribd (https://www.scribd.com/doc/248694989/Practitioner-Perspective-HANA-vs-BW7-Modelling)

This is his third whitepaper. Hope it helps the community

Practitioner Perspective, Modelling HANA vs BW7

Introduction
What is HANA? Despite all the buzz and media attentions given to HANA, it only brings more confusion as the definition continues to expand day-by-day.
I liken HANA as a proverbial elephant that has many version of truths for those have not seen it firsthand. This paper seeks to provide introductory and practical overview of HANA.

Apart from answering what is HANA, it also seeks to provide answers to the following questions:
• How is it different from traditional database?
• Can or should BW and HANA co-exist?
• How does it impact BI architecturing with the inclusion of HANA technology?

Definitions
What is HANA?
The term HANA is an acronym for "High-Performance Analytic Appliance“.

SAP® defines HANA as “a modern in-memory platform that is deployable as an on-premise appliance or in the cloud. As an appliance, SAP HANA combines software components from SAP optimized on proven hardware provided by SAP’s hardware partners”.
In short, HANA is SAP in-memory solution. It’s a database. You can run BW on it or you can run ERP (or other Business Suites) on it.

But in what sense is an in-memory database difference from a traditional database?

SAP HANA holds majority of its data in the memory for high performance. However, it still uses persistent storage to provide a fallback in case of failure. SAP promises a compliance to the ACID (Atomicity, Consistency, Isolation, Durability) expectation of traditional databases.
During normal database operation, data is automatically saved from memory to disk at regular intervals called savepoints. If a failure occurs, for example a power failure, the database will restarted in the same manner as any disk-based database, and it is returned to its last consistent state by replaying the redo log since the last savepoint.

SAP recommends that the Log file volume to be 3x – 5x of the Memory for HANA.
Within the HANA box, we can choose to load all tables into it or selective (because the HANA box will still have a size limit). At startup, all row-based table are fully loaded, but column-based table are loaded on-demand (default setting).

SAP HANA is not only just an innovative technology, it is packaged with additional tools (such as HANA Studio for modelling, HANA appliances for specific business requirements)

What are the benefits of HANA?
The speed benefit of HANA ranges in the thousands from 100x to 100,000x. At such performance improvement, organization can experience enablement that would never have been possible. The performance of HANA is achieve through a couple of factors: (details on the individual factors can be found in www.saphana.com)

What is BW-on-HANA?
As mentioned earlier, HANA is a database that BW or ERP can choose to run on. It is a logical step to move BW into HANA, due to its speed performance and scalable and agile modeling.
From personal experience, BEx reports can have an improvement of 500x – 3000x.

What are the benefits of BW-on-HANA?
We have two options to leverage on HANA’s high performance:
1) Using BW base on the optimized cubes – no modelling need, cubes are migrated
2) Using BW with HANA Modelling options.

HANA optimized infocubes have a different structure with traditional BW7 infocubes.
InfoCubes in BW are modeled using the BW-extended star schema with 2 fact tables (an E table with read-optimized partitioning, and an F table with write/delete-optimized partitioning), “Dimension tables” grouping sets of characteristics, and shared Master Data tables. This schema is optimized for classic RDBMS technology.
With HANA technology, the schema can be simplified to one fact table (HANA can perform read, write and delete operations equally fast on this layout) joined directly to the Master Data tables.

HANA optimized infocubes eliminate unnecessary joins and tables bringing in better performance. No modelling is needed.

However, to harness the power of on-the-fly in-memory advantage, we need to apply HANA modelling. HANA modelling comprises of “views”, these views generate real-time SQL statements behind the scene. The advantage is in its non-persistency nature: data is read and not staged, this data-modelling agility is coupled with native HANA DB in-memory speed.

HANA Modelling Concept

HANA Modelling uses 3 information “views”, namely:
(1) Attribute View
(2) Analysis View
(3) Calculation View

The information views from HANA Modelling draw parallel to BW7 concept of MasterData and InfoCube.
At the Attribute View level, we can combine several MasterData tables and appoint a primary key. At this stage, we can do Master Data reporting.
At the Analysis View level, we can combine several Transaction Data tables as the foundation, and enrich it with Attribute View. At this stage, we can already achieve analytical reporting.
If more complex scenario exist, such as merging two “infocubes”, we can create a Calculation View.

HANA Modelling vs BW7 Modelling
BW7 Modelling is based on persistent data storage hence will have loading “tasks” such as Infopackage, DTP. HANA Modelling based on in-memory data storage hence will focus more querying “tasks” such Join/Union, Aggregation, Projection (equivalent to SQL Select / Where).
Remodeling is a topic organization shun due to its risk and effort for data migration. However, in an ever-changing business environment, changing business strategies entails changing reporting and remodeling of datasources. In BW7, the Remodelling Toolkit helps cushion of quite a large portion of the pain but migratory effort still exist at a smaller scale.
With HANA Modelling having transient InfoProviders, it rids us the hassle of post-remodelling migration, cutting short deployment time, allowing agile response. Do note that the developer will still need to re-publish, activate the infocube when the model gets updated.

Bringing together HANA and BW7 Data

HANA Modelling bring in a very important benefits to the BI space, providing additional flexibility for discovery and agile response. However, the need for traditional standardization and structuring is also necessary. The use of HANA and BW7 Modelling depend on specific business scenarios.

Integrating HANA data with BW7 can be achieved with one of the 4 methods:
• Using BW7 MultiProvider in conjunction with VirtualProvider (HANA Model based)
• Using BW7 CompositeProvider in conjunction with TransientProvider
• Using multisource Universe
• Using merge queries in Webi

Getting Data at its Source: HANA Live
As mentioned earlier, HANA is a database. We can run BW on HANA, we can also run ERP on HANA (aka Business Suite on HANA).
The clear advantage of this is, we are nearer to the data – lesser overheads, more options.
In the past, having an OLAP in an OLTP is not recommended due to resource constraints. HANA, however, has removed this hurdle.

Once again the question, should we eliminate BW?
The answer: it depends.
I can think of one scenario that BW is relevant. Imagine a company archives its ERP tables annually will not be able to perform multi-year sales analysis directly at its source; BW on the other hand, being a staging data warehouse, will contain summarized multiyear information.

Conclusion
In the past, ERP is used as a competitive advantage for enterprise-wide effective consolidation. As ERP is becomes a norm for large enterprise, as well as, medium; this advantage has been diluted. The new advantage resides in the data that ERP has collected.
With the inclusion of HANA and Businessobjects, the BI landscape is not limited to only Traditional BW7 Modelling and BEx reporting. We are now presented with unprecedented versatility. For instance, we have options between Webi broadcasting capabilities versus traditional EP, BW MultiProvider versus Webi merge queries, BW workspace versus Webi ExcelProvider, and so on.
Our challenge now, is how to harness relevant and applicable information that has long been left out in our ERP treasure trove.
The emergence of ERP on HANA and HANA Live beautifully brings Analytics back to SAP ERP --- not as a peripheral extension but an intrinsic business process. We should come to the understanding that Analytics is the business process of “business processes” --- all “business processes” have KPI and needs to be measured.

Credits and Content Sources
1. SAP HANA Portal
www.saphana.com
2. SAP HANA Technical Operations Manual
help.sap.com/hana/sap_hana_technical_operations_manual_en.pdf