对于Twitter上关于SAP HAHA有潜力取代BW的那些争论，我表示并不意外。写这篇博客是想回应下周五对这个话题的50个相关转发。感谢来自IBM的Vijay Vijayasankar的贡献。在这篇博文中，我计划讨论4个场景,希望能给大家些启发。
这4个场景是：
1. 我有SAP ECC 和BW我该怎么办？
2. 我有SAP ECC，可能需要BW，我该怎么办？
3. 我有SAP ECC但是其他人告诉我SAP BusinessObjects Rapid Marts 更好，我该怎么办？
4. 我有SAP ECC，但是有人告诉我他们将为我设计个数据仓库，我该怎么办？
要回答这些问题，最简单的切入点是先定义BW。原因是很显然，大家对BW的定义均各抒己见。有人甚至不称她为BW，而以SAP BIW或BI取而代之。在定义BW的过程中，我首先要引用各类参考信息：
*： “SAP NetWeaver Business Warehouse (SAP NetWeaver BW) 是由 SAP AG推出的，集分析、报告、数据仓库于一体的商业智能解决方案的名称。原名是SAP BIW (Business Information Warehouse),后被简写为SAP BW，但现在被用户们称为SAP BI。另一方面，BW仍被用来描述底层的数据仓库领域及加速组件。她经常被应用SAP业务系统的公司所使用。
*上的帖子都谈到SAP的BW解决方案采用了广泛应用的数据仓库并包含大量以信息立方体，信息对象、授权角色及查询等形式存储的业务内容（pieces），这些业务内容是事先定义好的。这些技术帮助提升SAP的用户体验及降低实施周期。其中“业务内容”可根据企业的具体要求进行优化，但在事先定义阶段需要更长的客户化定制流程。
最后*称BW包含但不限于如下几个组件：
优化的数据提取，转化，加载(ETL)层，更有助于转移数据。
数据仓库领域：在星形模式设计中存储数据
一个应用数据仓库中信息的报告组件
计划及分析模拟业务，例如预算计算。
在这里我并不想过多的抄袭*的内容，因为我在写一篇关于HAHA是否能取得BW的博文，而对于BW的定义却没有一直说法的前提下，多一些论据也无伤大雅。
既然我们已经已经了解了对BW的官方定义，那么我说说我的看法：BW是一个系统，包含了数据仓库，预定义业务模式及用来提升分析能力的内容和相关工具从而更好的分析存储在SAP商业套件中的数据。
简单的说，这个系统部分或全部的应用在1万3千名客户上。有数千个SAP认证的第三方应用运行在这个系统上，她提供可靠性（注意我没有说快速）而且BW是免费的。但她不是个数据库。她运行在数据库上，这点区别大家要记住。在今天你也许会投资一个缓慢的基于磁盘的数据库来运行你的BW，但是更多时候用像 Business Warehouse Accelerator (BWA)这样的硬件方案来加速她。
此外，在过去的15年中，我们通过BW的内容来把在商业套件中几乎每个模块的4字符表名在SAP ECC中都赋予了商业意义。所以在您读这个博文时要思考的是：人们应该重建SAP花了15年来为您建的表名，仅因为他们被大家理解为“难”吗？
我对SAP HAHA的定义：它是个数据库（请在读完下面的内容后在引用这点）
的确，SAP HAHA是一种特殊的内存数据库，当她跟像BW这样的系统连接的时候她传递快速和高效的性能。但在她的最底层，她是个数据库。HAHA不能替代BW，她能提高BW的性能。在速度方面，我见过在传统关系数据库上运行BW的情况，其运行速度跟性能面临很大的挑战。运行在HANA上的BW在很多方面性能明显提升。如果你能用 SAP BusinessObjects (BOBJ) 作为 BW的前端, 效果将更好.
我的整体观点是：BW在HANA运行性能将更好，另外BW是免费的，在BW中有很多事先建立的内容，而且在BW上你还能获得即时的认证解决方案，如果你没有BW的话，不觉得应该“考虑”使用她吗?
请记住没有废止BW的计划，如果有人声称有废止计划，那么明显他是错误的。我是个支持BW加HANA的倡导者，而不是BW PK HAHA的人。
我明白BW有些替代品。一些有急切需求的客户，他们发现BusinessObjects Rapid Mart是一种非常快速的方式，通过应用数据服务将数据转移到比BW更易于管理的“存储”中。
但同时你还需要建立（或者定制化，主要看Rapid Mart的情况而定）抽取，转化，报告等等。你需要更高效。我知道SAP在HANA中建立了些新的内容,包括Operational Reporting RDS.所以大家可能想SAP是不是一个“开关装置”，在其中内容被创造然后存储。（再次声明，答案是“不是”我们完全没有这样做）
我明白一些人会说“就设计你自己的数据仓库好了”但同样的问题还是会出现。这些经典问题包括：“是自己建还是买”；“是BW跟HANA的情景还是其他数据库”。
接下来我将讨论前面提到的四个场景：
场景1：我有SAP ECC 跟BW我该怎么办？
简短的回答是：这样的公司决定应该升级到HANA作为BW的实施数据库。在前面我提到过没有HANA的BW其产生报告的速度是个硬伤，然而这真的是端到端的性能-下载，报告，简单的愿景图，改变管理。由于并行下载我们能极大的降低从SAP HANA上为BW下载数据的时间，这对于大量业务的公司非常重要。（应用HANA，把时间用在陪家人上而不是坐等数据下载上！）ETL跟报告的速度只是HANA适合作为BW数据库的一个方面，另一个相应重要甚至更重要的方面是简化。
BW有些而外的层，处于性能因素考虑而单独建立的，当HANA作为底层数据库时这些层是没必要建立的。一个设计简洁的BW能更有效的在其内部建立各种功能并管理内部生产环境。对BW的分层可扩展架构包括高效应用HANA作为其数据库的优势。
原来在BW ABAP层的功能现在被移植到了HANA层，这使得整个模型和处理工作变得更加高效。以DSO激活为例，当应用非HANA数据库的BW系统时需要启动DSO激活这就占用了一部分时间。
更多时候，许多BW客户应用SAP Business Warehouse Accelerator来加速他们应用在BW下的慢磁盘关系数据库。SAP HANA提供了一个更简单的愿景来降低TCO和复杂性。她能极大的降低你硬件的占用空间，例如加速5T的BW数据，在BWA中你需要21个刀片服务器，但作为统一的永久型数据库，1个HANA服务器且不需要第三方数据库就可以完全不伤脑筋的搞定！
变更管理相对容易一些，可以选择建立更多的逻辑层而非物理层，这样就无需重新索引结果，那样恐怕会在变更起效前花费数个小时的时间。
除了本文所提到的所有观点之外，我们来看看真正的结果。对于大多数主要投资BW的客户来说，真正将与任务密切相关的数据仓库投资利用起来，并开发其潜力一直是我们的目标。我相信机会就在BW 和HANA联合的时候到来了。
我们50多个 BW/HANA 的优先使用客户中，大部分已经得到了令人印象深刻的结果和快速的投资回报。今天对于HANA作为BW数据库的投资，已经为他们日后进一步扩展HANA作为实时分析的基础，同时作为创新应用的平台做了一个铺垫。这就是说，今天的HANA的BW应用是您未来平台的雏形。同样，HANA平台将会确保您的高级应用分析案例得以实现，并且运行计划类的应用，如决策支持、预测分析、文本挖掘和搜索。同样，这也是您的数据库和SAP的一个简单集成，SAP提供了 cookbook 帮您完成这项工作。
场景2：我目前使用SAP ECC但是有使用BW 的意向，该如何？
简要回答：视情况而定。
当总体挑选数据管理工具、数据基础以及未来的分析策略时，需要考虑多个因素及注意事项。例如，您有计划方面的需求，则可以使用基于BW基础的解决方案。因此，您可以考虑BPC on HANA和 S&OP on HANA作为可能的解决方案 (这就使BW成为必然)。
对于多数在SAP ECC上投入了大量资金的企业来说，为了建立企业及数据仓库来整合企业数据，建立一个数据真实的可靠地分析平台，SAP BW是正确的选择。如果有人告诉您他们可以建立一个与BW相似的定制化数据仓库，并将包含BW中所有“好的”特性且摒除其缺点，那我倒真想见见这个人。
如果SAP业务系统是您报表信息的主要来源，那么使用BW作为您的数据仓库，利用其业务内容及层级扩展架构，将会使您大受裨益。
同时，您也没有理由拒绝BW on HANA 或是独立的HANA系统，如果与您的业务相关，这两者都是您前景图的一部分。同时拥有二者会使您得以决定您所需要的BW功能。也就是说，对于那些公司特有的痛点，可以通过定制数据仓库或是SAP BusinessObjects Rapid Mart来解决。
场景3: 我目前在使用SAP ECC,但是有人跟我讲SAP BusinessObjects Rapid Marts 更好，我该怎么办?
简要回答：还是视情况而定。
转载于SAP学习门户网，原文链接：http://www.sap6.com/erp/hana/735805172014/349.html