CAF雲端採用框架比較 — Part 2

Azure篇 — 企業需要投資在準備上，而非預測上

本文將介紹Azre的CAF。一開始看到Azure的CFA文件時嚇一跳，因為PDF文件竟然有4千多頁，內容真的是鉅細靡遺。我還以為是一個核電廠的＂指導、操作與維運＂手冊咧。

Azure列出了CAF的整個流程:

1. 策略規劃 — 定義商業理由和預期的採用結果
2. 計畫 — 讓能運作的採用計劃與業務成果保持一致
3. 準備 — 為我們的已計畫好的變革準備雲端環境
4. 遷移 — 遷移與現代化既有的系統
   與
   創新 — 發展雲原生的系統(如果企業夠大人夠多，其實第四與第五步可以並行)
5. 安全 — 隨著時間的推移強化系統的安全
6. 治理 — 治理雲端環境與系統
7. 管理 — 管理雲端環境的維運
8. 組織 — 將組織調整成適合雲端運算的團隊與角色

Azure的CAF提供企業最佳實踐、文件與工具來建立與實行企業在雲端要達成的業務與技術策略。CAF協助決策者調整"業務、文化和技術"變革策略，以實現預期的業務成果。整個Azure CAF的生命週期如下:

Azure CAF說: 它們的CAF是通用的，不論用哪一朵雲，甚至用在多雲的策略。Azure CAF的野心一開始就很大，要企業一開始就考量大型且複雜的雲端採採用旅程。在雲端的使用場景中，Azure給出了相關的組件(如下圖)。

我們可以看到Azure除了給出CAF之外，還另外加上了其他的組件。這意味著Microsoft也希望客戶能夠更準確的使用Azure相關的資料。但本文只會著重在CAF這一段。

策略規劃階段

這一階段的目標是將利害關係人的需求轉化為策略，而這程序步驟我們在雲端運算的治理與管理一文中已經說得很清楚了。在這一部分Azure的策略規劃比較像是為後面的技術決策鋪路，這也是微軟的經營者思維(總要優先推薦自家產品)所產生的策略規劃。另外在進行策略規劃時，Azure CAF也建議企業從較小的變革且符合利害關係人的需求開始企業的雲端專案。

Azure CAF提出使用雲端運算能有:

• 強化業務的敏捷性
• 減低成本(這得視狀況而定，要算一算TCO)
• 加速產品上市時間
• 擴展到新市場

以上的要點來說，簡單的講就是"又快又好又便宜"。Azure CAF在這一部分也給出了一個策略規劃流程步驟。目的是雲端採用策略可以對應到特定的雲端能力。

1. 定義與紀錄上雲的動機 —
   與主要利害關係人和C-Level開會，記錄要上雲背後的動機(依筆者的雲端經驗，動機只有這七個字 — 又快又好又便宜)
2. 紀錄想達成的業務成果 —
   跟比較積極的利害關係人開會並記錄想要的業務成果
3. 進行財務評估 —
   學習使用雲端如何讓企業的財務結構(現金流)能夠有彈性，並有一個商業案例。詳細的商業案例可以參考本部落格建立雲端運算的投資回報率一文
4. 了解技術上的議題 —
   探索可幫助企業建立"雲端採用"業務案例的技術靈活性、效能和能力。

Azure 提供了一種問卷式的評估工具"Cloud Adoption Strategy Evaluator"來協助企業建立一個上雲的商業案例。隨後使用評估後的結果，並通過下載"strategy and plan template"這一份word文件來追踪上述四個步驟中每個步驟的產出，並記錄企業的商業策略，繼續構建雲端採用策略。可以觀看以下影片，學習如何使用這一個工具。

Microsoft Assessments 真的提供了非常多的工具與範本讓企業無腦的使用，這是好處也是壞處。好處是讓員工有一定的規範可以使用，不必從零開始。壞處在於可能失去了一些彈性。 這些評估工具可協助您企業評估雲端策略的現行狀態，並彌補企業在技能、利害關係人的支持、業務 KPI 和預算目標方面的任何差距。

如我們在本系列文章Part 1提到的，企業策略基本上分為四類(詳情請參閱本部落格雲端運算的治理與管理一文)。如何讓雲端採用切合企業的策略才是重要的，因為利害關係人與C-Level才有感。

業務成果範本

這裡值得一提的是Azure提供了"business outcomes templates"文件，讓我們跟非技術人員進行關於上雲的專案討論。該份文件聚焦在三個主題:

1. 與利害關係人或業務決策者保持一致
2. 了解業務驅動因素和目標
3. 將業務成果對應到特定的解決方案和技術能力

策略規劃的反面模式

Azure CAF給了企業一些在做策略規劃時的反面模式。

1. 雲端採用計畫沒有設立目標 —
   企業的雲端策略通常是cloud-first或cloud-only，但沒有清楚的定義相關的KPI與目標。企業需要可量測的指標或要達成的特定狀態。
2. 未能傳達動機 —
   企業知道採用雲端的效益，但無法將這一類變革動機傳達給IT單位，造成雲端專案失敗。但老實說，這其實還是整個企業的文化問題，非戰之罪不能怪IT單位。

計畫(Plan)階段

這一階段將策略轉換為可實行的計畫。該計畫指導技術團隊的作業，這些技術作業能與企業的業務策略保持一致。

這一階段，Azure CAF給出了以下幾個步驟來產出技術策略。這些步驟同時也產生了雲端採用計畫的工作優先事項。整個步驟完成之後就能對應到企業在策略規劃階段產生的＂指標和動機＂。

步驟1: 數位資產

Azure CFA的說法是： 根據符合組織動機和業務成果的假設，清點並合理化企業的數位資產。不過筆者認為應該是根據策略規劃所產生的專案範圍來清點資產。畢竟企業業務所涉及到的系統/數位資產才是我們應該關注的。

另外Azure 也提供了五種雲端採用的方式協助企業採用雲端，這五種方式是通用於所有的CSP。

步驟2:初步的組織調整

因應雲端專案而進行的組織調整，像是大家目前一窩蜂的搞DevOps/DevSecOps/SRE。

步驟3:技能就緒計畫

看看組織中還缺那些人才或技能需要補齊的。這裡Azure給了我們一張從傳統的IT角色朝向雲端化的角色(如下圖)。

步驟4:雲端採用計畫

根據前面三個步驟的產出統整成一個雲端採用計畫。Azure CFA給了出了以下六個步驟來產出雲端採用計畫。

1. 先期準備 — 在創建計劃之前確認所有先決條件步驟都已完成
2. 定義workload(也就是我們的系統:例如ERP系統)並確定其優先順序
3. 使資產與worload是一致的 — 確定需要哪些數位資產來支援workload
4. 檢視決策是否合理 — 檢視決策以改進雲端採用路徑決策：遷移或創新
5. 建立迭代和發布計劃 — 迭代是分配給待辦事項的時間區間。發布是在觸發生產流程變更之前要完成的工作的定義
6. 估算時間表：根據初步估算，為發布計劃制定粗略的時間表

在這裡，微軟又很好心的提供了範本讓我們使用 — strategy and plan template。另外也有Strategic Migration Assessment and Readiness Tool (SMART)這一類問卷式的工具。

計畫的反面模式

Azure CAF給了企業一些在做策計畫時的反面模式。

1. 錯誤的雲端運作模型 — 錯誤的模型會導致錯誤的責任與義務、錯誤的landing zone、錯誤的聚焦
2. 錯誤的雲端服務模型 — 該選擇Iaas?PaaS?還是SaaS?
3. 整個架構面的更換 — 基於 PaaS 和SaaS的應用程式相對易於維護甚至不須維護，因為不用管理一堆底層的東西，相對就不用哪麼多人力。 因此，許多企業通過用 SaaS 和雲原生概念取代舊的、複雜的架構環境來重新設計它們。 這種架構變化通常會導致重大的替換專案。 管理和執行這些專案可能是一項複雜且成本高昂的任務。因為它通常也意味著改變流程和運營模式(一次大量且重大變動是員工不喜歡的)與涉及其他重大風險。

預備(ready)階段

這一階段是在將我們的系統或要做雲原生系統之前就要把雲端環境準備好 — 也稱作Landing Zone。以下為製作一個Landing zone的步驟。

步驟1:雲端運作模型

如何選擇符合我們的雲端運作模型，Azure CFA給了我們一些指引。正確的模型選擇必須基於我們理解企業的策略方向，包含組織結構、治理、風險與合規需求，然後就會產生適合雲端的人員、流程與技術的運作模型。這裡Azure CFA沒有提到關於＂人員、流程與技術的運作模型＂成熟度，相關成熟度目標控制可參閱本部落格COBIT系列文章。

Azure CAF也給了我們一個運作模型的紙，從最簡單(Decentral Operations)到最複雜的(Distributed Operations)如下圖。這些通用模型是根據我們定義出的當下的策略來選擇的。

步驟2:Azure Landing zone

這是關於Azure Landing zone的概念性架構與加速器。Azure的Landing zone有8個設計領域，分別是:

• Azure Active Directory tenant
• identity and access management
• resource organization
• network topology and connectivity
• security
• management
• governance
• platform and DevOps

並且分為Application與Platform 兩類的Landing Zone。其架構基本上可以針對大型企業搞得很複雜(如下範例圖)。

步驟3:前進到目標架構

根據start、align和enhance這三個核心概念驗證landing zone實施的起點。

步驟4: Azure Landing zone的設計區域

設計 Azure landing zone的流程和指南。

遷移與創新

這是實際將我們的系統轉移到Azure Cloud的作業。Azure在整個企業雲端旅程不同階段提出了四種流程(Migrate/Modernize/Innovate/Relocate)。每個階段都有著不同的目標、解決方案與效益。

Migrate(Rehost)

這個流程是讓企業可以將舊有系統遷移到Azure雲端中的遷移策略指南。流程所產生的遷移策略可以實際符合企業的目標，選用合適的Azure解決方案與產生的主要效益。Azure在這裡提供了企業一個Migrate流程判斷圖。

Modernize(Replatform)

這一流程是將遷移到Azure雲端中的系統進行強化，讓它更符合雲端系統，也能朝向PaaS服務前進。目標是減少技術債並將應用程式與資料平台現代化。目標當然是"又快又好又便宜"。Azure在這一流程分成兩個子階段，分別是:

Phase 1. Business alignment
Phase 2. Modernization strategies

Innovate

當企業的系統變成雲原生的技術後，企業就能轉變成業務成果。能夠重新定位企業的"業務，技術解決方案"，並找到創新的資料運行方式。主要效益是能強化預測能力、效能與適應力。最重要的是能在Azure Cloud上進行MVP(minimum viable product)的價值。

在構建 MVP 時，企業應該考量使用數位發明(digital inventions)的五個學科，包括：

• Democratize data
• Engage via applications
• Empower adoption
• Interact with devices
• Predict and influence

Relocate

當企業的系統在Azure中運行時，企業就可以根據需求將系統在Azure不同的區域中任意地進行移動。這麼做的原因通常是要將資料放在該區域所在的國家或是降低網路的延遲性。

安全 — 隨著時間的推移強化系統的安全

資安是永遠不斷在進行的工作，不論在雲端或地端機房都是一樣。只是在雲端中的資安不同於地端。最大的不同點在於企業與CSP有Shared responsibility，企業與CSP根據服務模型的不同需要有各自負責的部分(如下圖)。

Azure CAF的資安是根據微軟自身與客戶的經驗還有NIST ZTA與Cybersecurity framework、The Open Group ZTA core principle還有CIS(Center for Internet Security)集合而成的。更多的雲端安全可參閱本部落格其他的資安文章。在此就不在贅述Azure的雲端資安論點了。

但Azure給了企業在雲端中以下幾種資安運作方法:

• Risk insights — 所謂的風險管理
• Security integration — 在企業中關於各種職位與角色的資安職責
• Business resilience — 為資安衝擊做好準備(通常是資安事故管理)
• Access Control
• Security Operation — 建立一個SoC(security operation center)
• Security Governance — 關於治安治理可參考本部落格資訊安全治理(Information Security Governance)一文
• Innovation security — 大意是指DevSecOps團隊，

治理與管理

關於於雲端的治理與管理，在Azure CAF提供的較多是執行細節與對應其Azure服務的的部分。但較高階的雲端治理與管理可以參閱本部落格雲端運算的企業治理及其後續COBIT的系列文章。

組織 — 將組織調整成適合雲端運算的團隊與角色

Azure CAF提及的組織架構比較像是大企業才能產生出來的組織結構。也就是你想得到想不到的組職架構、團隊、人員技能通通都規定出來了。但是老實說，中小企業沒有哪麼有資源可以搞出Azure所定義出來的。

結論

與其說這是Azure CAF的”框架”，倒不如說這是企業要上Azure雲端的”指導手冊或叫做工具書”比較適合，因為它把所有可能的狀況與對應方式幾乎都列出來了。從Azure CAF的文件來看，它應該可以涵蓋絕大多數的企業在進行雲端採用時所遇到的所有議題與狀況，並且還給出了範例。企業架構師與雲端架構師其實可以把這一個SOP拿來使用。

但是，所謂”框架”是指讓企業又足夠的彈性去修改成適合個別企業來使用，又能修改成涵蓋全部企業的議題。Azure CAF列出了一個固定流程(Azure說它是一個交互過程)與一堆定義好的條件老實說彈性不足。

但這個手冊很適合大企業(因為有一定的流程可供參考)，因為大企業的彈性本來就不好。另外如果出了事，IT單位可以通通甩鍋給微軟，因為他們全部按照微軟的指導手冊進行的。不過讚許的一點是，Azure提供了非常多的雲端採用工具來協助企業進行上雲的專案。這讓大企業的IT單位與完全沒有經驗的IT人然可以照著Azure的步驟流程走。