虽然SAP一直宣称HANA不会取代BW，但我们有充足的理由相信内存分析平台最终一定会吞并BW;更准确一点说，SAP BW和HANA会开始合并。如果不出意外的话，BW和HANA之间的技术决策难题将会迎刃而解。
基于这一论断，我们在本文中大胆预测二者的结合与缺陷。尽管为预测，也不能毫无凭据，为此我们针对SAP的举动和相关产品技术进行了详细的研究，其中包含一些SAP的公开声明;当然，与公开声明无关的就纯属预测范畴了。
BW与HANA的现状
我们看到，SAP已经跨出了第一步，将主要的数据管理平台完全带到了HANA中;也就表示，SAP将BW迁移到作为主要持久性数据库的HANA中并允许BusinessObjects工具很自然地与HANA连接。
这只是一小步。总体来说，HANA对于BW只是一个纯粹的数据库。为了优化HANA性能，BW给HANA在InfoCubes和DSOs中带来了一些较小的模式变更。HANA真正独一无二的优化方式在于DSO数据激活流程，该流程在许多场景中完全运行在数据库内部，而不是BW应用服务器上。
在这样的配置下，我们能够看到性能在一定程度上的改进，不过也仅此而已。BW并没有提升HANA的集成或安全特性，HANA也没有提升BW的多重性能。此外，HANA在架构、数据质量以及对于在数据之上添加意义的支持方面几乎没有任何帮助。
BW和HANA近几年的走向
随着SAP不断构建BW与HANA之间的集成能力，我们可以期待看到二者更多的性能支持与提升。其实，在BW 7.3 Support Package (SP) 8中我们就已经看到了这样的趋势，该版本支持多种混合场景——BW从实质上消耗着HANA的数据，而不是数据复制;HANA自带视图可用于BW InfoProviders的数据。在HANA的SP5更新版中，它提供了一项为不活跃数据添加标记的特性，在这些数据不被激活的情况下将其排除在内存之外，从而节约了可观的内存。BW系统的SP8版本将自动应用这一特性。
未来，随着ABAP应用服务器在HANA支持方面能力的提升，集成会进一步发展。除了ABAP以外，HANA系统很有可能还会添加转换执行功能。高级BW分析引擎将掌控各项事务，涵盖复杂的时间层级报告和“未分配”主数据价值的识别。该引擎已经将部分运算转给了HANA，但今后我们应该还能看到HANA承担起更多的分析流程。
到时候，BW的ABAP层将减少数据转换和查询的执行，而更多倾向于维护元数据和语义信息，HANA的层则会实施更多的执行计划。
BW和HANA的最终发展
随着BW和HANA的成熟与合并，我认为它们将会向以下三个方向中的其一发展：
1. ABAP应用服务器和相当高级的BW应用依然与HANA数据库处于分离状态，这与当下SAP的策略方向不大一致。目前，SAP直接在HANA中提供应用服务，使HANA成为一个整合数据库和应用服务器。尽管如此，这种结果还是有可能发生的;虽然有一些缺点，但是与二级架构相比，三级式的从数据库到应用再到客户的架构还是具备明显的优势。
2. 纯粹的ABAP BW服务(元数据、语义和执行计划)植入HANA，使下一代BW完全成为一个HANA应用。
3. ABAP应用服务器架构在HANA集群中运行，BW中的ABAP层也同理。这种情况要么发生在操作系统层面(ABAP应用服务器与HANA在同一系统中运行)，要么通过在HANA应用服务中编写并运行一个ABAP应用服务版本实现(偏向自带场景)。无论哪一种场景，实现起来都相当困难，我甚至认为自带场景在技术层面上是不可实现的，但一旦实现，将为性能和SAP客户的简单化体验带来巨大提升。
就现在来看，谁也说不准哪一种情况会成为现实。如果是上述三种的其中一种，BW肯定不会再被称作BW了，但我相信SAP会以某种形式继续提供BW的所需性能。目前，SAP的用户应当等待并关注两个平台的发展。总之，BW和HANA的集成流程比较漫长，且不会一帆风顺。
