商業世界對業務績效的各個方面的近實時洞察的需求不斷增長。這意味著傳統的BI解決方案，以及其長的部署周期，繁重的資本支出以及對IT生成報告的持續依賴正在迅速讓位于云托管解決方案。后者以更低的總體擁有成本為企業提供更快的見解。對于大多數IT主管而言，現在的問題不在于何時以及何時以及如何將其商業智能基礎架構的至少某些方面轉變為云。

在本文中，提供了一個與工具無關的框架，以幫助IT經理快速解決上述所有問題。使用這樣的框架，管理人員可以輕松地將圍繞云BI的戰略愿景轉化為戰術實施項目，每個項目都有明確的議程，里程碑，交付方法，成本/資源要求和依賴關系。請注意，此框架完全是概念性的，可以應用于任何云平臺或軟件，而且變化可以忽略不計。

概念架構概述-分層方法

在軟件架構中，關注點分離是一個古老的原則。我們在下面介紹的分層方法受到相同原則的啟發，并試圖將整個商業智能交付流程劃分為完全分離的，邏輯上獨立的層，這些層可以幾乎獨立地構建，設計和開發。這些層包括：

1.物理托管層

規劃此層的注意事項很大程度上歸結為選擇正確的平臺。這里的一個具體考慮是檢查每個平臺的按需定價模型上的關鍵BI工具的可用性。

如果您計劃將這些工具用作BI技術堆棧的一部分，這應該是一個強有力的考慮因素。

從概念規劃的角度來看，構建物理托管層意味著：

• 在上述某些方面基于盡職調查選擇平臺。
• 確定您需要運行哪些特定軟件以及它將如何互連。
• 根據指示性硬件定價得出運營成本的初步估計（這些將在您完成其他層的架構時進行細化）。

?

2.數據存儲層

規劃數據存儲層將涉及選擇數據將如何存儲在物理層中。一些考慮包括：

• 如何存儲從外圍系統中提取的原始數據？使用數據倉庫嗎？一個數據集市？或兩者的結合？
• 最好還是使用大數據存儲，然后運行ETL腳本將處理就緒數據提供給數據倉庫？
• 是否存在使用No-SQL數據庫的情況？
• 將來自外圍系統的高級數據流定義到通常聚合原始數據的臨時區域。
• 定義報告數據庫的結構，其中包含為特定業務查詢建模的數據。
• 我們將為每個邏輯組件使用哪種特定產品？
• 優化成本估算，技能要求和流程依賴性，作為物理層架構的第一個切入點。

雖然上述活動列表并不全面，但上述活動清單應為管理人員提供有關如何存儲數據以及成本，技能要求，部署時間表和任何流程依賴性的初步估算的可靠概述。

3. ETL層

ETL（或ELT，取決于您處理數據的方式）層涉及從包含要分析的數據的各種外圍工具中提取數據。構建此層的典型考慮因素包括：

• 我們將哪種工具用于ETL？各種腳本的高級概述，可將數據提取到暫存區域，然后將其提供給報告孤島。
• 如何處理脫機數據訪問（例如，存儲長期令牌，基本身份驗證等）。我們如何處理不提供離線數據訪問的API？我們可以使用FTP下載嗎？預定的電子郵件？
• 架構是否會受益于使用規范數據模型？例如，如果目標數據模型是固定的但源數據格式差別很大，那么使用規范數據模型將提供長期成本節省和更快的交付時間。

上述考慮因素可以根據計劃階段所需的估算和資源預測的準確性進行放大和縮小。

4.可視化層

數據被提取，安全存儲，現在以報告就緒格式提供。現在是決定如何將其轉換為信息的時候了。構建可視化層可歸結為用于報告和儀表板的工具的選擇。一些考慮因素包括：

• 我們使用構建或購買方法嗎？如果用戶數量很大，和/或要生成的報告很大程度上是靜態的（不需要太多的交互或向下鉆取功能），則可能值得考慮使用圖表庫。構建自己的可視化層。另一方面，如果報告要求具有高度互動性，那么投資商業BI工具將更為合適。
• 如果你決定使用商業工具，它會是哪一個？除預算外，此處的考慮因素還包括第三方應用程序的適配器可用性，它們提供的REST API服務的能力，文檔/支持的質量以及技能可用性。

使用上述框架，管理人員不僅可以計劃詳細的實施，還可以準確估算項目成本/時間表。這些可能有助于做出是否遷移到云或將內容保留在場所的早期階段決策。