平衡競爭優先順序

任何數字轉型的成功取決於企業和技術項目關係人平衡競爭優先順序的能力。

與其他數字轉型一樣，雲端採用會在採用生命週期中公開競爭的優先順序。 與其他形式的轉型一樣，平衡這些優先順序的能力對實現商業價值具有重大影響。 平衡這些競爭優先順序需要專案關係人之間公開且有時困難的交談，有時需要與個別參與者進行交談。

本文概述每個方法實作期間經常討論的一些競爭優先順序。 當您開發雲端採用策略時，它可協助您為這些討論做好準備。

下列各節符合上述雲端採用生命週期圖表中的流程。 不過，請務必瞭解雲端採用是反覆的程式，而不是循序程式，而且這些競爭優先順序可能會在雲端採用旅程期間的各種點重新產生。

雲端採用架構 方法的一般主題

整合型解決方案和進階規劃都是建立在一系列假設之上，可能會隨著時間推移而不準確。 採用雲端通常是企業及其技術小組的新體驗。 和大多數新的體驗一樣，有一些可能性，即初始假設會被證明是不正確的。

遵循經過實證的延遲技術決策敏捷原則，是此架構中大部分指引的偏好方法。 這種方法遵循一致的模式：建立一般結束狀態、快速移至初始實作、測試及驗證假設，以及儘早重構以解決錯誤的假設。 這種類型的成長思維可將學習最大化，並將業務價值的風險降到最低，但需要一些模棱兩可的安慰。

模棱兩可有時比虛假假設更可怕或更危險。 雖然此架構會在實作期間優先學習並解決模棱兩可的問題，但許多情況都需要小組優先處理分析型或假設型方法。 下列各節提供至少一個「擴充範圍範例」，以說明何時第二個更深入的反覆專案可能很有價值。

策略階段期間的平衡

策略方法的核心目標是在專案關係人之間建立一致性。 定義之後，對齊的戰略位置會推動每個方法的行為，以確保技術決策符合所需的業務成果。 促進項目關係人之間的一致性，會建立一組常見的競爭優先順序： 理由 深度與 業務影響的時間。

競爭優先順序：

• 理由深度： 項目關係人通常會想要深入的財務分析和完整的業務理由，才能適應戰略方向。 不幸的是，該分析層級可能需要較長的時間，才能進行數據收集和分析。

• 業務影響的時間： 相反地，項目關係人通常會負責在定義的時間範圍內提供業務成果。 在技術工作開始之前，耗時的分析與評估可能會讓這些結果面臨風險。

最低範圍： 在程式中，尋找正確的平衡需要專案關係人討論。 策略方法建議在此早期努力期間限制對齊範圍。 在建議的方法中，項目關係人著重於圍繞一組核心動機、可衡量的結果，以及高階業務理由進行對齊。 然後，項目關係人應快速認可幾個初始專案或試驗，以推動必要的學習機會。

擴充範圍範例： 如果初始商務分析指出對業務造成負面影響的風險很高，項目關係人可能需要放慢速度，並在業務理由期間更謹慎地評估更深入的分析。

規劃階段期間的平衡

如同在策略階段，在規劃階段需要平衡初始規劃深度與延遲的技術決策。

競爭優先順序：

• 雲端中技術實作的初始規劃 深度通常是基於許多假設。 特別是當小組有技能差距時，環境會遭受探索差距，或工作負載沒有清楚定義的架構端狀態。 所有這些假設在詳細的雲端採用計劃中都是常見的。 必須進行實驗、試驗和定性分析，才能驗證或改善這些假設。

• 延遲的技術決策 是以稍後進行技術決策的假設為基礎，其精確度就越高。 遵循敏捷式產品規劃的原則有助於延遲技術決策，讓他們根據足夠的資訊在正確的時間進行。 不過，此方法在初始計劃中會產生更模棱兩可的情況。

最低範圍： 我們建議敏捷式產品開發方法，以推動可管理方案中的提示動作。 方案方法建議下列步驟來達成此平衡：

1. 使用自動化探索工具來清查完整的數字資產，但使用累加式合理化來規劃未來 1 到 3 個月的工作。
2. 確保適當的組織一致性，以快速移動。
3. 為指派的小組建立技能整備計劃。 使用策略和計劃範本快速部署初始待辦專案。

擴充範圍範例： 雲端採用方案的傳遞有時可能是為了回應時間敏感或高影響商務事件。 當成功需要在固定時間內移動大量資產時，上述步驟通常會經過更深入的規劃工作。 在這些案例中成功的關鍵是規劃足夠的專案，然後稍後規劃完整的參與。 這種方法可減少規劃會封鎖業務成果的可能性。

在整備階段進行平衡

當小組準備進行雲端採用的第一個步驟時，通常會在採用時間和長期作業之間競爭優先順序。 團隊可能會與適合在手邊的任務和妥善管理的工作之間取得平衡而苦苦掙扎。 在傳統IT環境中，這種鬥爭是必要的，其中開發平台的行為需要實體資產和取得週期。 不過，當整個 IT 平臺在程式碼中定義時，傳統開發策略，例如重構，從一開始就需要妥善管理。

競爭優先順序：

• 長期作業： 組織通常會因想要讓雲端環境符合目前作業管理、治理和安全性系統的功能同位而遭到封鎖。 在一項研究中，超過90%的組織需要支援才能擺脫這種心態。 此封鎖程式可能會造成數月的延遲、減緩或防止業務影響。

• 採用時間：雲端式工具，例如 Azure 原則、持續整合和持續傳遞（CI/CD）方法，例如基礎結構即程式代碼（IaC），以及管理群組，可以簡化跨 IT 平臺重構的程式。 此外，預先定義的登陸區域也提供建議，以加速針對已經符合許多功能同位需求的環境進行部署。 這些工具提供機會，以對長期作業的影響最小，加速上市時間。

最低範圍： 就緒方法概述從快速採用到長期作業的直接路徑。 此方法一開始會介紹可用來重構環境的工具基本簡介。 這些工具會考慮您的需求，並引導您選擇預先定義的登陸區域，每個區域都隨附 IaC 模型。 接著，您可以在雲端採用期間重構程序代碼，以改善作業、安全性和管理。

擴充範圍範例： 對於採用計劃要求中期目標（24 個月內）在雲端中裝載超過 1,000 個資產（應用程式、基礎結構或數據資產）的小組，我們建議更健全地檢視登陸區域。 在這些情況下，您應該在初始登陸區域交談期間考慮治理和管理方法。 不過，此更深入的考慮通常會在雲端採用計劃中增加數周或數月。 為了將業務成果的影響降到最低，採用小組應試驗雲端的實際工作負載，同時建立更成熟的登陸區域和中央架構解決方案。

移轉階段期間的平衡

在移轉期間，採用小組通常會假設工作負載會在其目前的設定中重新裝載於雲端中。 此假設與前瞻性計劃競爭，以重新架構每個工作負載，以更好地利用雲端功能。 這兩個檢視並非互斥，而且當您使用一般程式來管理這些檢視時，可以免費檢視。

競爭優先順序：

• 重新裝載：組織通常會將移轉與隨即轉移方法等同，以將所有資產復寫到其目前設定中的雲端。 這種方法在 IT 組合內產生很少的漂移。 這也是淘汰現有數據中心資產最快的方式。

• 重新架構： 將每個工作負載的架構現代化，可充分發揮跨成本、效能和作業的雲端採用價值。 不過，此方法的速度較慢，而且通常需要存取每個應用程式的原始程式碼。

最低範圍： 在早期規劃期間，使用重新裝載選項進行規劃，並清楚瞭解此選項是以初始商務假設為基礎，且不是技術決策。 在移轉方法中，雲端採用小組接著會針對每個已移轉的工作負載挑戰此假設。 此方法遵循每個工作負載或工作負載群組的評估/遷移/升階方法，以建立移轉處理站。 在評估階段，採用小組會評估每個工作負載的技術大小和架構。 該評估工作很少會產生純粹的隨即轉移方法，因為架構中的許多元件通常會選擇進行重構和現代化。

擴充範圍範例： 對於任務關鍵性或高敏感度工作負載，例如大型主機或多層微服務應用程式，可能需要在評估階段期間更徹底地評估工作負載。 在這些重新架構的情況下，您應該使用 Azure 良好架構檢閱和 Azure 妥善架構架構架構 ，在評量期間精簡工作負載需求。

創新階段的平衡

真正的客戶面向創新經常會在需要交付計劃的功能集和實作客戶同理心開發程式之間建立衝突的優先順序。

競爭優先順序：

• 功能焦點： 在現有數位資產和雲端功能上建置創新的初始計劃，以提供一組符合客戶需求的功能。 可讓您輕鬆地讓計劃驅動技術實作，進而進行以功能為主的開發工作。 這種方法通常會導致暫時項目關係人滿意，但可降低推動影響客戶行為創新的可能性。

• 客戶同理心： 初始計劃是開發業務端的重要組成部分，應納入定期報告。 不過，以客戶同理心作為目標來學習、測量及建置，是創新努力中成功更精確的衡量標準。 將焦點放在客戶身上的功能更有可能導致短期和長期客戶滿意度和業務影響。

最低範圍： 創新方法說明如何透過商業價值共識整合策略和計劃。 本指南接著會介紹雲端原生工具，以加速每個創新專業領域和實作的最佳做法。 最後，程式改進一節示範在跨雲端採用旅程中遵守方案和策略時，建置客戶同理心的方法。 這種方法著重於使用盡可能少的技術來提供創新。

擴充範圍範例： 創新有時取決於任務關鍵性或高敏感度工作負載。 當客戶是內部使用者時，開發工作在最早的反覆專案中可能是任務關鍵性和高敏感度。 在這些案例中，採用小組應該使用 Azure 良好架構檢閱和 Azure 妥善架構架構架構 ，在程式中早期評估進階架構設計。

在治理階段進行平衡

雲端治理的做法是兩個競爭優先順序之間的平衡：速度和靈活度與治理良好的環境。 雲端治理小組著重於透過統一控件來評估和將企業的風險降至最低，並將變更降至最低。 採用小組著重於推動業務成果，這需要新的風險，而且本質上會產生變更。

競爭優先順序：

• 妥善控管： 每個設計為將風險降至最低的控件都會封鎖變更或限制設計選項的一些層面。 控制對於妥善控管的環境至關重要。 不過，當控件以隔離方式設計及部署時，它們可能會像預期要防止的風險一樣有害。
• 速度和靈活度： 速度和靈活度是數字經濟中的基本商務需求。 兩者都需要能夠以最少的阻礙來推動變革，以創新或採用。 但是，在沒有治理的情況下推動變革時，它會產生新的風險，可能會以非預期的方式損害業務。

最低範圍： 治理方法表明，治理和採用都不應該隔離發生。 此方法從瞭解治理專業領域和商務風險、原則和程式的對話開始。 作為整個雲端採用的積极參與者，治理小組可以實作一組最少的保護措施，以解決雲端採用計劃內有形的風險。 經過一段時間后，治理小組可以重構和擴充這些保護措施，以符合新的風險。 這種方法可最大化學習和創新，同時將風險降至最低。

擴充範圍範例： 當業務風險很高，特別是在採用初期，雲端治理小組可能需要加快治理實作的擴充。 您可以使用相同的指引和練習來新增此更高層級的治理，但可能需要更快速地進行。 在某些情況下，您在開發第一個登陸區域時，甚至可能需要進階的治理狀態。

在管理階段進行平衡

過去十年來，營運管理的IT業務模型持續演進。 隨著硬體維護從 IT 的核心價值主張進一步移動，對營運管理的看法已經改變。 隨著IT增加對業務價值的關注，營運管理小組因需要平衡無營運和低營運與廣泛投資的需求而發生衝突。

競爭優先順序：

• 廣泛投資： 在整個環境中投資同樣避免中斷、快速復原和監視是傳統的作業管理方法。 這種方法的成本可能很高，有時會重複雲端廠商所提供的支持產品。

• 無作業和低作業： 使用雲端原生作業工具，將先前由員工提供的重複和週期性工作降到最低。 減少這些作業相依性可讓員工以其他方式推動價值。 不過，在隔離中，此方法可能會導致子剖析作業支援。

最低範圍： 管理方法建議建立雲端原生、無作業基準。 確認無營運基準不符合所有商務需求，請與企業合作，定義承諾，並更妥善地配合投資。 展開基準以符合所有工作負載的常見需求。 然後，讓平臺小組或特定工作負載小組在妥善管理的環境中維護妥善管理的解決方案。

擴充範圍範例： 在大部分環境中，少量工作負載的商業價值可讓IT對作業進行深入投資。 針對這些工作負載，IT 小組可能會想要使用 Azure 良好架構檢閱和 Azure 良好架構架構來引導更深入的作業。

在組織階段進行平衡

本文中所述的競爭優先順序反映了 IT 對於速度和敏捷性的業務需求的推動力。 組織圖表或虛擬小組結構的變更中會出現相同的轉變，為業務成果提供更好的支援。 當 IT 領導者反映小組結構時，通常會解決兩個競爭優先順序：集中式控制與委派的控制。

競爭優先順序：

• 集中式控制： 此作業模型著重於強制執行固定原則所需的所有控件的集中化。 在此模型中，IT 可作為創新、速度和靈活性的阻礙。 不過，IT 可以確保更高的穩定性、合規性和安全性。

• 委派控件： 在此分散式作業模型中，假設每個 DevOps 小組或商務應用程式小組都會根據交付商務目標所需的解決方案，提供自己的控件集。 在此模型中，IT 提供指導方針來協助小組避免風險，但盡可能將強制執行的技術條件約束數目降到最低。

最低範圍： 大多數組織經過一段時間的自然演進。 組織方法概述最常見的進化系列。 我們建議小組嘗試走向卓越雲端中心 （CCoE） 結構，以提供委派的控制方法。

擴充範圍範例： 許多情況會觸發集中式控制的需求。 第三方合規性需求和暫時安全性暴露是集中式控制的兩個觸發程式範例。 在這些情況下，通常需要建立限制原則和固定控件。 不過，為了讓創新和採用能夠繼續，我們鼓勵中央 IT 小組根據每個工作負載的嚴重性和敏感度來提供這些控件。 提供較少的控制環境，但範圍或風險配置檔降低，即使需要控制也允許彈性。

下一步

瞭解如何 平衡移轉、創新和實驗 ，以將雲端移轉工作的價值最大化。

平衡組合