3 Major Reasons To Migrate To BW 7.4 on HANA..!!!

In the HANA 2014 conference, there is a special event focusing on BW 7.4 on  HANA. Preparing for this event, I've reflected on what to tell, say, a BW 7.0 customer on why he should look at upgrading and migrating that system to BW 7.4 on HANA. Fundamentally, I see 3 major reasons:

1. It becomes simpler.
2. It is more flexible (than previous versions of BW).
3. It performs better.

So let me quickly justify why I think that this is the case. Please note that all the arguments are based on the combination of BW and HANA.

 

It becomes simpler.

• Modern modeling environment
  There is a number of new Eclipse-based modeling editors, e.g. for the composite provider or the new query designer (planned). The modeling paradigms are harmonized with those of the HANA modeler which makes it a coherent modeling environment, especially when combining BW with HANA-native features.
• Less modeling objects
  The new composite provider can replace the old multi-provider and (partially) the old infosets. The in-memory DSO is suitable for many reporting scenarios making it obsolete to use infocubes in those case. The advanced DSO (planned for SP8) will further simplify the situation.
• BPC unified
  Classic BPC, BW integrated planning incl. PAK become one with the same software lifecycle and harmonized modeling environments. There is even synergies allowing functions from one end (approach) to be applied to the other. Examples are BPC's business process flows (BPFs) and the workstatus being used on BW-IP models or the performance boosts, especially via PAK, for the BPC models (cubes).

 

It is more flexible.

In general, BW provides a managed approach to data warehousing. While many cherish this "best-practice" guidance some critics argue it is difficult to deviate from the standard approach in case of special scenarios where it might be easier to program one or the other function, for instance, in SQL or SQL script rather than via complex modeling. BW 7.4 on HANA provides a number of options to do so:

• SQL → BW
  Any tabular HANA artifact that is accessible via SQL can be incorporated into BW, either for reporting or even the data warehousing layers that harmonize the data and create consistency across the many sources feeding into the data warehouse. Key features in BW 7.4 in that respect are the open ODS view or the composite provider. Both can be combined with HANA's smart data access (aka federation) feature.
• BW → SQL
  It is possible to expose BW models - i.e. infoproviders but it is planned to extend this to BW queries - as HANA views that can be consumed via SQL. Thereby BW security is also translated into HANA-based security. Thus BW data and (partially) semantics can be consumed via SQL-focused clients. Or additional models can be created on top of the generated views leading to more refined HANA models.
• Leverage highly specialized libraries
  HANA provides numerous specialized libraries like PAL, AFL, R to minion a few. Via BW's new HANA Analysis Process (HAP) capability it is possible to use all of these on top of BW models and consume the result as a BW model.

 

It performs better.

• Querying + Loading
  This is the traditional strength of HANA and especially it's underlying calculation engine. More of BW's OLAP features are now compiled into execution plans in HANA. A lot of loading related BW features are executed close to the data thereby avoiding data transport between application and HANA servers. Examples are the DSO activation and the option to compile transformations to be executed in the calc engine. The latter mechanism is also used for HAPs.
• Hardly Any Tuning
  Admitting, performance tuning has not vanished completely but it has become so much easier. Simply look at the blog 10 years of "no aggregates in #SAPBW. The decrease of support efforts (on the SAP end) correlate directly with the decrease of tuning and admin effort on the customer side. This is real world proof for reduced TCO!
• Big Data
  Data volumes are no issue, not even on the licensing end through HANA's extended storage capability. Have a look at this demo that queries on top of 2.5 PB of data.