平衡組合

雲端採用巧妙地偽裝成技術實作，但其實是組合管理工作。 就像任何組合管理練習一樣，平衡組合十分重要。 在策略性層級，這表示您必須平衡移轉、創新和實驗以充分運用雲端。 雲端採用工作朝某個方向過度傾斜時，採用工作就會變得複雜。 本文將引導讀者完整了解實現組合平衡的方法。

一般範圍擴充

平衡組合的本質具有策略性。 因此，本文所採用的方法也同樣具有策略性。 為了讓策略聚焦在資料驅動決策，本文會假設讀者已評估現有數位資產 或已開始該程序。 此方法的目標是要協助評估工作負載，以透過定性問題和組合改善來確保組合之間有適當的平衡。

記錄業務成果

在平衡組合之前，請務必記載並分享可促進雲端移轉工作的業務成果。 下表可協助記載及分享所需的業務成果。 請務必注意，大部分企業都會一次追求數個成果。 此練習的重要性是要釐清與雲端移轉工作最直接相關的成果：

結果	測量依據	目標	時間範圍	此工作的優先順序
降低 IT 成本	資料中心預算	減少 2 百萬美元	12 個月	#1
資料中心的退出	從資料中心退出	2 個資料中心	6 個月	#2
提升業務敏捷性	改善上市時間	將部署時間減少 6 個月	2 年	#3
改進客戶體驗	客戶滿意度 (CSAT)	改善 10%	12 個月	#4

重要

上表是虛構的範例，請勿將其用來設定優先順序。 在許多情況下，此表可能會因將節省成本放在客戶體驗上，而被視為是反模式。

上表可以精確地呈現雲端策略小組和雲端採用小組的優先順序。 由於受到期限不長的限制，此小組會更加著重在降低 IT 成本，並且會優先採用資料中心退場作為實現所需 IT 成本降低的手段。 不過，藉由在此表中記載下彼此競爭的優先順序，雲端採用小組因此能夠協助雲端策略小組找出機會，以更好的方式來讓整體組合策略的實作能夠保持配合。

既快速移動又維持平衡

有關數位資產增量合理化的指引建議了從不平衡的位置來開始進行合理化作業的方法。 雲端策略小組應該以重新裝載方法來評估每個工作負載是否相容。 之所以建議使用這種方法，是因為其可根據量化資料快速評估複雜的數位資產。 進行這類初始假設可讓雲端採用小組快速進行作業，進而縮短實現業務成果的時間。 不過，如本文所述，定性問題會在組合中提供必要的平衡。 本文會記載用於建立所承諾平衡的程序。

廢止和淘汰決策的重要性

記載業務成果一節中的表格遺漏了一項重要成果，此成果可支援減少 IT 成本這個首要目標。 當您將降低 IT 成本列於業務成果清單任一順位時，請務必考慮您有可能需要廢止或淘汰工作負載。 在某些案例中，能夠節省成本可能是因為並未移轉無法擔保短期投資的工作負載。 某些客戶回報，其已藉由淘汰使用率過低的工作負載來節省成本，其金額超過所減少總成本的 20%。

為了平衡組合，從而更清楚地反映廢止和淘汰決策，應該鼓勵雲端策略小組和雲端採用小組在評量和移轉階段對每個工作負載詢問下列問題：

• 在過去六個月內，終端使用者是否曾使用過此工作負載？
• 終端使用者的流量保持一致還是在成長？
• 從現在起的 12 個月內，公司是否必須有此工作負載？

如果上述問題有任何一個的答案是「否」，則可以考慮淘汰該工作負載。 如果應用程式擁有者已確認可以淘汰，則不需要再移轉該工作負載。 這又會引發一些限定條件的問題：

• 是否可以為此工作負載建立淘汰計劃或廢止計劃？
• 此工作負載是否可以在資料中心退場前就先淘汰？

如果這兩個問題的答案都是「可以」，則最好考慮「不要」移轉該工作負載。 這種方法有助於符合降低成本和資料中心退場的目標。

如果有任一問題的答案是「否」，則最好先建立方案來裝載該工作負載直到其淘汰。 此計劃可能包括將資產移至成本較低的資料中心或替代資料中心，而這也會達成降低成本並讓一個資料中心退場的目標。

採用程序變更

平衡組合時需要在「採用」階段期間進行額外定性分析，以協助驅動簡單組合合理化。

根據上述的記載業務成果一節的資料表資料，組合若過度傾向聚焦在移轉的執行模型，將可能產生風險。 如果客戶體驗是最優先事項，則創新的繁重組合更可能會如此。 這沒有對錯，但過度往某個方向傾斜一般都會導致報酬遞減，並增加與雲端採用工作有關的執行時間。

為了降低複雜性，您應該遵循傳統方式來進行組合合理化，但透過反覆模型來進行。 下列步驟概述了這種方法的定性模型：

• 雲端策略小組會為要遷移的工作負載保留一份給出優先順序的待辦項目。
• 雲端策略小組和雲端採用小組在每個發行完成之前，主持發行計劃會議。
• 在發行計劃會議中，兩個小組會同意給出優先順序的待辦項目中居首的 5 到 10 個工作負載。
• 除了發行計劃會議外，雲端採用小組會向應用程式擁有者和主題專家詢問下列問題：
  • 此應用程式是否可由同等的平台即服務 (PaaS) 取代？
  • 此應用程式是否為第三方應用程式？
  • 預算是否已通過核准，而會在未來 12 個月內對持續開發應用程式做出投資？
  • 此應用程式的額外開發是否可改善客戶體驗？ 創造競爭優勢？ 為企業帶來額外收益？
  • 此工作負載內的資料是否會對與 BI、機器學習、IoT 或相關技術有關的下游創新做出貢獻？
  • 工作負載是否能與現代應用程式平台 (例如，Azure App Service) 相容？
• 上述問題的答案以及任何其他必要的定性分析，隨後將會影響給出優先順序的待辦項目要如何進行調整。 這些調整可能包括：
  • 如果工作負載可由 PaaS 解決方案取代，則可以從移轉待辦項目中整個移除。 最不濟也可以新增額外的審查評鑑工作來決定是要重新裝載還是取代，以暫時降低該工作負載在移轉待處理項目中的優先順序。
  • 如果工作負載正在 (或應該正在) 進行開發，則可能最適合重構/重新建構/重建模型。 因為創新和移轉需要不同的技術技能，所以應該透過創新待處理項目 (而非移轉待處理項目) 來管理可配合重構/重新建構/重建方式的應用程式。
  • 如果工作負載是下游創新的一部分，則適合重構資料平台，但請將應用程式層留作重新裝載候選方案。 您通常可以在移轉或創新待辦項目中稍微重構工作負載的資料平台。 此合理化成果可能會在待辦項目中產生更詳細的工作項目，但不會變更優先順序。
  • 如果工作負載並非策略性，但與新式雲端式應用程式裝載平台相容，則最好對應用程式執行稍微重構，以將其部署為現代應用程式。 這可藉由減少雲端移轉的整體 IaaS 和 OS 授權需求，而有助於整體成本的節省。
  • 如果工作負載是第三方應用程式，而且不打算將該工作負載的資料用於下游創新，則最好將其留作待辦項目上的重新裝載選項。

這些問題不僅可完成每個工作負載的定性分析，還可協助引導有關解決不平衡組合複雜性的交談。

移轉程序變更

在移轉期間，組合平衡活動會對移轉速度 (資產移轉速度) 產生負面影響。 下列指導方針將會詳述必須讓工作配合的原因和配合方式，以避免移轉工作遭到中斷。

組合合理化需要多樣性的技術工作。 您當然會想要讓雲端採用小組在移轉工作內符合該組合多樣性目標。 業務專案關係人會要求單一雲端採用小組處理整個移轉待辦項目。 這不是常見的建議方法，在許多情況下，這可能會適得其反。

這些多樣化工作應該分割為兩個以上的雲端採用小組。 使用有兩個小組的模型作為執行模式範例，小組 1 是移轉小組，小組 2 則是創新小組。 對於大型工作，這些小組可以進一步分割以處理其他方式，例如取代/PaaS 工作或稍微重構。 以下內容概述要重新裝載、重構或稍微重構所需的技能和角色：

重新裝載：重新裝載需要小組成員實作聚焦在基礎結構的變更。 一般會使用 Azure Site Recovery 之類的工具將 VM 或其他資產遷移至 Azure。 此工作適合由資料中心系統管理員或 IT 實作者來進行。 雲端移轉小組有良好的結構，因此能大規模提供此工作。 此方法能以最快的速度遷移大部分案例中的現有資產。

重構：重構需要小組成員修改原始程式碼、變更應用程式的結構，或採用新的雲端服務。 一般來說，此工作會使用 Visual Studio 之類的開發工具和 Azure DevOps 之類的部署管線工具來將經過現代化的應用程式重新部署至 Azure。 此工作適合由應用程式開發角色或 DevOps 管線開發角色來進行。 雲端創新小組的結構最好，因此能提供此工作。 以這種方式將現有資產取代為雲端資產可能需要較長的時間，但應用程式可以利用雲端原生功能。

稍微重構：有些應用程式可以透過在資料或應用程式層級進行稍微重構來進行現代化。 若要執行此工作，小組成員必須將資料部署至雲端式資料平台，或對應用程式的設定進行些許變更。 這可能需要對資料或應用程式開發主題專家提供有限程度的支援。 不過，此工作類似於 IT 實作者在部署第三方應用程式時所進行的工作。 此工作非常適合由雲端移轉小組或雲端策略小組來進行。 雖然此工作不像重新裝載移轉那麼快速，但執行時間會比重構工作還短。

在移轉期間，工作應該以上面列出的三種方式進行分割，並由適當的小組於適當的反覆運算執行。 當您應該讓組合多樣化時，也請確保工作保持在最專注和隔離的狀態。

後續步驟

了解全球市場決策如何影響您的轉換旅程圖。

了解全球市場