From BW towards a Mixed Architecture

For the last few years, a couple of new data warehousing approaches are unfolding themselves. In this blog, I would like to address the most discussed scenarios: 1) the BW-scenario, 2) the HANA-scenario and 3) the mixed-architecture scenario. This blog is intended to provide an overview of what these scenarios entail, including some use cases. 

BW-scenario 

The BW-scenario is an application-driven approach where BW is the only application that is used to manage the EDW. It has integrated services like modeling, scheduling, monitoring, planning, ETL, OLAP, authorizations and Lifecycle management. So, no separate application for each service, but one integrated repository that has all the functionality already available within one single platform.

The BW application can run on several kinds of databases like Sybase and Oracle. However, more and more companies are migrating their BW application to a HANA database. The main reason for this is to speed up BW. And indeed, BW is acting a lot faster on HANA. Query performance can improve up to 15 times faster. But not only the query performance is improved by using BW-on-HANA, it has more benefits: up to 100 times faster data load processes, no BIA issues and the possibility to simplify the BW back-end, by making use of virtualization with new BW objects like Advanced DSOs and CompositeProviders.

HANA-scenario 

The HANA scenario, on the contrary, considers HANA as a platform where separate tools per service can be installed without any pre-packaged integration. So, separate tools for scheduling, for monitoring, for planning etc. This is the so-called SQL-driven approach where a combination of tools are used to build an EDW. This approach provides the opportunity to select best-of-breed applications based on the existing landscape and knowledge, preferences and requirements of the organization.

The most discussed tool within the BW community is HANA Studio. This is a basically a modeling application on top of the HANA platform which has some advantages over BW. The in-memory platform makes it faster and user friendly as it moves from batch to real-time processing of data. It is simple, as it reduces complexity by only using virtual objects. No data is stored persistently in HANA Studio, all persistent tables are stored in HANA, while in the HANA Studio application only Views are available for modeling. This also means data is only physically processed during reporting. This makes the model less error prone too, because there are no ETL processes involved. Considering all these advantages of HANA Studio over BW, the main topic of discussion is the future of the BW application. Especially considering that HANA Live and S/4HANA Analytics can take over some of the functionality related to modeling and analytics. With the launch of BW/4HANA, SAP has confirmed to keep investing in BW. In fact, SAP advises to keep maintaining both scenarios as they are complementary to one another. This is the so-called mixed scenario.

Mixed-scenario 

The mixed-scenario is a DWH architecture consisting of an overall data model that is implemented by BW and native HANA tools. The integration between BW-on-HANA and HANA Native let both applications act virtually as one DWH. The most common integration is BW with HANA Studio where the Views of HANA Studio can be consumed in BW and vice versa by using Views. The integration possibilities according to SAP are as follows:

• BW Query as HANA View 

• BW InfoProvider as HANA View 

• BW Master Data as HANA View 

• HANA View/Table as source for OpenODS View in BW 

• HANA View/Table as source for CompositeProvider 

• HANA View/Table as source for Master Data in BW 

• HANA View/Table as Source System/DataSource in BW 

There are various use cases that show that BW and HANA Native tools can be complementary to each other. For example, by using BW as a storage solution, by extracting and loading the data from the sources into the acquisition or integration layer while using HANA Studio for modeling and better integration with BI clients.

Another use case is to extract, transform and load (ETL) in BW, build the queries in the BEx Query Designer and report on HANA Views. So basically this is the normal modeling approach in BW where you generate a HANA View on the BEx Query at the end. In this case the Analytic Engine of BW is used for complex calculations while the HANA Views ensure a tight integration with the BI clients.

The previous scenarios cover integration from BW towards HANA. But it is also possible to go the other way around and expose the data residing in HANA to BW. One way to do this is to include a HANA View in a CompositeProvider and combine the BW and HANA data with a union or a join. This approach is best suited for reporting purposes. In staging scenarios it is better to expose the HANA View to an Open ODS View, from which modeling can be continued in BW. Of course it is also possible to implement this as a standalone scenario where the data is not exposed to BW at all.

Takeaways 

There are various use cases which prove that BW and HANA can perfectly co-exist, or better yet, can complement each other. Whether it is speed, BI client integration or storage, the mixed architecture approach gives you the flexibility to choose the best solution for each EDW related situation. With each release the functionality of HANA Native is improved, including the integration with BW. Even though the integration is already really easy (as generating a HANA View is done by just ticking one checkbox in BW), there still is room to improve. If you'd like to know which added value a mixed scenario can bring to your organisation, feel free to contact us