Why BW and HANA are such a good combination

There has been much talk and debate on whether HANA replaces BW. See Steven Lucas’s blog, the associated comments, discussions on Linkedin or Twitter (e.g. start somewhere around here) or some blogs (e.g. this one) and probably many other places. The sheer number and heat of those threads indicates, in my opinion, that the question is so relevant that it underlines how relevant BW is.

Figure 1: An EDW comprises a DB that is complemented with a application code (X).

Now, a lot has already been said about the matter. The origin of the controversy has a little bit to do with the perception that an enterprise data warehouse (EDW) basically is an DBMS. Actually, in a discussion with some well known analysts some time ago I popped the question whether they would see a difference and met a few seconds of silence. In my opinion, a DBMS is a fundamental component of a EDW, like an engine to a car. But the DBMS alone makes no EDW like an engine alone makes no car. The car’s chassis, body, interior, … provides the comfort for the consumer and makes sure that the engine is used in the most suitable way. Similarly, there is software surrounding a DBMS that makes it the heart of a EDW. BW is simply one such instance of software that can do that. Figure 1 shows a slide that I frequently use to create that awareness.
Why is BW such a good choice – in my opinion – to make HANA the heart of a EDW? Rather than answering this in a generic, philosophical and potentially non-tangible way I will give three instances that clearly underline that statement:

1. BW has the most capable code generator (for queries) to leverage HANA’s calculation engine in the most efficient way. Even experts will struggle to emulate this by handcrafted code. The trick is to issue a graph of related calculation instructions whose dependencies are in the calculation semantics (of an OLAP query) and exposed to the calculation engine which, in turn, can leverage that knowledge to optimize the processing. “Hello World” style or simple, SQL-style queries won’t see a notable difference but queries with calculations beyond a single row (YTD, hierchies, currentmember, normalizations to group totals, group-specific aggregations, …) will and these are neither esoteric nor rare but mainstream.
2. Changes in BW are creating the right context that allow HANA to process load operations in a way that translate into overall accelerations of factor 3 (on average) for process chains. Instances are translating single row to mass data operations or the HANA optimized versions of infocubes and DSOs. In fact, I’ve seen customer measurements that indicate that many process chains only yield equal performance (compared to classic DBMSs) but improve significantly by using the HANA optimized infocubes and DSOs.
3. In autumn, both, BW and HANA, are planned to ship a mechanism to distinguish between hot (= permanently used / queried), warm (= sporadically, e.g. in nightly batch processes) and cool (= rarely used, e.g. old requests in PSA) data. This is will translate into a significantly better usage of HANA’s memory, similarly as if the data compression algorithms were to yield higher compression rates. As the roles and semantics of tables in BW are well known they can be easily classified by a default configuration which means that a BW-on-HANA system will use HANA by default more effciently than an operational data mart where such settings can also be done but need to be set and derived manually.

This list can certainly be extended. It is meant to provide a non-marketing, down-to-earth flavour of what you gain with BW beyond the usual services. It is not surprising that some customers have lauded it the most genuine application on and for HANA that SAP provides.