How SAP BW and HANA will merge over time -- and why it matters

Though SAP swears HANA won't replace Business Warehouse (BW), there are good reasons to believe the in-memory analytics platform will eventually absorb BW. But I think it is more accurate to say thatSAP BW and HANA will begin to merge. If this scenario plays out as I believe it will, the murkiness surrounding skill and technology decisions between BW and HANA starts to clear.

This article describes the likely paths of BW and HANA and outlines three possible scenarios for their convergence, or lack thereof. While this discussion of roadmaps is speculative, it's informed by carefully watching SAP's moves and a good understanding of the products and technologies involved. I've linked to public statements from SAP. Anything not referencing such public statements is speculative.

Where BW and HANA stand now

As I explained in the last article, SAP has taken the first steps to move its main data management platforms into position to fully use HANA's capabilities. This means moving BW onto HANA as a primary persistence database and allowing the BusinessObjects tools to natively connect to HANA.

This first step has been very basic. For the most part, BW treats HANA as a pure database. BW on HANA introduces relatively minor schema changes inInfoCubes and data store objects (DSOs) to optimize performance on HANA. The only truly unique optimization for HANA is in the DSO data activation procedure, which in many scenarios runs completely in-database and not on the BW application server.

Under this configuration, we see good performance improvements for BW on HANA, but not a lot else. BW doesn't leverage HANA's integration or security features, and HANA doesn't leverage BW's numerous capabilities. Furthermore, HANA has little to offer in architecture, data quality or support for adding meaning on top of data.

Where they're going in the next few years

As SAP continues to build out its integration between BW and HANA, we can expect to see BW leverage more features of HANA (and vice versa), and HANA add features to support BW. We are already starting to see this trend play out in BW 7.3 Support Package (SP) 8, which supports many mixed scenarios in which BW consumes HANA data (often virtually, with no data replication), or in which HANA makes HANA-native views available on data in BW InfoProviders. In its own update SP5, HANA provides a feature for marking data as "not active," which will keep that data out of memory unless it is accessed, thereby saving significant memory. BW systems on SP8 will automatically make use of this feature.

In the future, further integrations should come as the ABAP application server makes progress on supporting HANA natively. With the exception of ABAP routines, transformation execution will likely be pushed down to the HANA system. The complex BW analytic engine handles everything from complex time-dependent hierarchy reporting to identification of "not assigned" master data values. This engine has already outsourced some calculations to HANA, but we can expect more analytical processing to be pushed to HANA in the future.

Eventually, BW's ABAP layer will become less oriented toward executing data transformations and queries and more oriented toward maintaining metadata and semantic information, along with execution plans to be carried out in the HANA layer.

BW and HANA in their final state

As BW and HANA both mature and converge, I think the process will conclude in one of three ways:

1. The ABAP application server, along with the heavily evolved BW application running on it, remains separate from the HANA database. This end point differs from the direction of SAP's current strategy: offering application services directly on HANA, thus making HANA into a combination database and application server. Nonetheless, it is a likely scenario, despite some disadvantages, as the three-tier database-application-client architecture offers significant advantages compared to the two-tier architecture.
2. The remaining pure-ABAP BW services (metadata, semantics and execution plans) are ported to HANA, making this next-generation BW a fully HANA-native application.
3. The ABAP application server architecture is ported to run natively on the HANA cluster, bringing the remaining ABAP layer of BW along with it. This could happen either at the operating system level or by writing a version of the ABAP application server to run within HANA's application services. The former would be, in effect, running the ABAP application server side by side with HANA on the same system while the latter is a more native scenario. The level of effort to achieve either scenario would be immense. I'm not even sure the native scenario is technically possible. But it would be a huge achievement that could deliver further performance improvements and landscape simplification to SAP's customers.

At this point, no one can say what will happen. In any of the above scenarios, the result may not be called BW, but I believe SAP will continue to provide the much-needed capabilities of BW in one of these forms. For the moment, SAP users should watch and wait while developing at least some familiarity with both platforms. The process of integrating BW and HANA will be a long one, with many twists and turns along the way.