雖然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的集成流程比較漫長，且不會一帆風順。