投資組合層次結構

若要瞭解工作負載、資產和支援服務的 組合 如何一起運作，您需要建立組合階層。 本文提供投資組合層級的明確定義，並為團隊如何達成每個層級的預期提供指導。 階層的每個層級在本文中也稱為 範圍。

工作量

傳遞已定義商業價值的技術集合稱為 工作負載。 集合可能包含應用程式、伺服器或虛擬機、資料、裝置和其他類似群組的資產。 大部分的企業都依賴多個工作負載來提供重要的商務功能。

通常，業務關係人和技術主管會共同對每個工作負載的持續支持負責。 在工作負載生命週期的某些階段中，那些角色被清楚定義。 在工作負載生命週期的更多作業階段中，這些角色可能會轉換為共用作業管理小組或雲端作業小組。 隨著工作負載數目增加，角色（已陳述或隱含）變得更加複雜且矩陣化。

工作負載及其支持資產是任何組合的核心。 範圍或層會定義這些工作負載的檢視方式，以及它們受到潛在支援小組矩陣的影響程度。

雖然條款可能會有所不同，但所有IT解決方案都包含資產和工作負載：

• 資產： 支援工作負載或解決方案的最小技術功能單位。
• 工作負載： 企業IT支援最小的單位。 工作負載是基礎結構、應用程式和數據資產的集合，可支援一般商務目標或執行一般商務程式。

當您部署第一個工作負載時，工作負載及其資產可能是唯一定義的範圍。 其他層可能會在部署更多工作負載時被明確定義。

IT 資產組合

當公司透過矩陣方法或集中式方法支援工作負載時，可能會有更廣泛的階層來支持這些工作負載：

• 登陸區域： 登陸區域為工作負載提供支援一或多個工作負載所需的必要基礎公用程式或共用管道。 登陸區域在雲端非常重要，因此整個 就緒 雲端採用架構的方法著重於登陸區域。 如需更詳細的定義，請參閱 什麼是登陸區域？
• 基礎公用程式： 這些共用IT服務，工作負載必須在技術和業務組合內運作。
• 平台基礎： 此組織建構會集中基礎解決方案，並協助確保對所有登陸區域強制執行這些控件。
• 雲端平臺： 根據支援完整組合的整體策略而定，客戶可能需要多個具有平臺基礎不同部署的雲端平臺，以控管多個區域、混合式解決方案，甚至是多重雲端解決方案。
• 組合： 從技術的角度來看，這個組合是跨所有雲端平台的工作負載、資產和支援資源的集合。 從商業角度來看，投資組合是包括專案、人員、流程和投資的集合，用於支援和管理技術組合，以推動業務成果。 這兩個鏡頭一起來捕捉著作品集。

階層責任和指引

每一層投資組合的階層都由負責的團隊來管理。 下圖顯示責任小組與支援其商務決策、技術決策和技術實作的指引之間的對應。

注意

下列清單中提及的小組可能是虛擬小組或個人。 對於此階層的一些變體，某些責任小組可以折疊，如責任變數稍後所述。

• 組合： 雲端策略小組和卓越雲端中心（CCoE）使用 策略 和 計劃 方法來指導影響整體組合的決策。 雲端策略小組負責雲端組合階層的企業層級。 雲端策略小組也應該瞭解有關環境、登陸區域和高優先順序工作負載的決策。
• 雲端平臺： 雲端治理小組負責保護護欄，以確保每個環境的一致性與 治理 方法一致。 雲端治理小組負責治理所有環境中的所有資源。 應諮詢雲端治理小組，以了解任何可能需要例外或更改治理政策的變更。 雲端治理小組也應該知道工作負載和資產採用的進度。
• 登陸區域和雲端基礎： 雲端平臺小組負責開發支持採用的登陸區域和平臺公用程式。 雲端自動化小組負責自動化這些登陸區域和平臺公用程序的開發，並持續支援這些登陸區域和平臺公用程式。 這兩個小組都使用 就緒 方法來引導實作。 這兩個小組都應該知道工作負載採用的進度，以及企業或環境的任何變更。
• 工作負載： 採用發生在工作負載層級。 雲端採用小組會使用 Migrate 和 Innovate 方法來建立可調整的流程，以加速採用過程。 採用完成之後，工作負載的擁有權可能會轉移至雲端作業小組，該小組會使用 管理 方法來引導作業管理。 這兩個小組都應該熟悉使用 Microsoft Azure Well-Architected Framework，以做出影響其支援工作負載的詳細架構決策。 這兩個小組都應該知道登陸區域和環境的變更。 這兩個小組偶爾可能會參與登陸區域功能。
• 資產： 資產通常歸屬於雲端作業小組的責任。 這個小組使用 管理 方法中的管理基準來指導作業管理決策。 它也應該使用 Azure Advisor 和 Azure Well-Architected Framework，以執行滿足運營需求所需的詳細資源和架構變更。

責任變數

• 單一環境： 當企業只需要一個環境時，通常不需要 CCoE。
• 單一登陸區域： 如果環境只有單一登陸區域，治理和平臺功能可能會合併成一個小組。
• 單一工作負載： 某些企業在單一登陸區域和單一環境中只需要一個工作負載或幾個工作負載。 在這些情況下，在治理、平臺和營運小組之間，不需要區隔職責。

常見的工作負載和責任範例

下列範例說明投資組合階層。

商用現成工作負載

傳統上，企業傾向於使用商用現成軟體解決方案來支援業務流程。 這些解決方案會安裝、設定，然後運作。 在設定之後，解決方案架構幾乎沒有變更。

在這些案例中，任何雲端採用的COTS解決方案都以轉換至雲端作業小組結束。 接著，雲端作業小組會成為該軟體的技術擁有者，並假設負責管理設定、成本、修補週期和其他作業需求。

這些工作負載包括會計套件、物流軟體或產業特定解決方案。 在Microsoft術語中，這些套件的廠商稱為獨立軟體廠商（ISV）。 許多ISV提供一項服務，以在您的訂用帳戶中部署和維護其軟體套件的實例。 它們也可以提供在自己的雲端裝載環境中執行的軟體套件版本，以提供工作負載的平臺即服務 （PaaS） 替代方案。

除了 PaaS 供應專案之外，雲端作業小組會負責確保這些工作負載的基本作業合規性需求。 雲端作業小組應與雲端治理小組合作，以符合成本、效能和其他架構要素。

活躍修訂中進行開發

當COTS解決方案或 PaaS 供應專案不符合業務需求，或沒有任何解決方案存在時，企業會建置自定義開發的工作負載。 一般而言，只有一小部分的 IT 組合會使用此工作負載方法。 但這些工作負載往往導致 IT 對業務成果的貢獻比例不成比例高，尤其是與新營收流相關的結果。 這些工作負載通常會妥善對應到新的創新想法。

由於各種以敏捷方法和 DevOps 實務為基礎的趨勢，這些工作負載比起傳統 IT 管理更傾向於企業和 DevOps 的一致性。 針對這些工作負載，可能在數年內不會交接這些工作負載給雲端作業小組。 在這些情況下，開發小組會擔任工作負載的技術擁有者。

由於時間廣泛和資本限制，自定義開發選項通常受限於高價值的機會。 典型的範例包括應用程序創新、深入數據分析或任務關鍵性商務功能。

故障排除或終止開發

自定義開發工作負載達到尖峰成熟度之後，開發小組可能會重新指派給其他專案。 在這些情況下，技術擁有權通常會轉換為雲端作業小組。 當需要小型修正時，作業小組會征召開發人員來解決錯誤。

在某些情況下，開發小組會移至最終將取代目前工作負載的專案。 或者，團隊可能會向前發展，因為工作負載所支援的商機正逐步淘汰。在這些結束階段的情況中，雲端運營團隊會擔任技術負責人，直到不再需要工作負載為止。

在這兩種情況下，雲端作業小組通常擔任長期技術擁有者和決策者。 當作業變更需要重大架構變更時，該小組可能會登記應用程式開發人員。

任務關鍵性工作負載

在每個公司中，一些工作負載對企業來說非常重要，不容失敗。 針對這些關鍵任務的工作負載，通常會有各種責任層級的作業和開發的負責人。 這些小組應讓作業變更和架構變更保持一致，以將生產解決方案的中斷降到最低。

這些情況需要高度重視職責分離。 營運小組通常會對生產環境中的日常作業變更負責。 當這些營運變更需要架構變更時，在營運團隊將變更套用至生產環境之前，開發或採用團隊會在非生產環境中完成這些變更。

任務關鍵性工作負載與必要的職責區隔範例包括 SAP、Oracle 或其他企業資源規劃 （ERP） 解決方案等工作負載，這些工作負載橫跨公司中的多個業務單位。

策略組合調整

務必瞭解雲端採用工作的策略目標，並調整資產組合以協助該轉型。 一些常見的策略組合對齊類型有助於塑造組合階層的結構。 下列各節提供組合對齊方式與組合階層效果的範例。

創新或開發主導的組合

一些公司，特別是快速增長的初創公司，擁有高於自定義開發專案的平均百分比。 在開發密集的項目組合中，環境、著陸區域和工作負載通常會被壓縮，因此可能會為特定的工作負載提供特定的環境。 結果是環境、登陸區域和工作負載之間的 1：1 比率。

因為環境裝載自定義解決方案，因此 DevOps 管線和應用層級報告可能會取代作業和治理功能的需求。 這些客戶可能會減少對作業、治理或其他支援角色的關注。 更強調雲端採用和雲端自動化小組的責任也是典型的。

組合對齊： IT 組合可能會專注於工作負載和工作負載擁有者，以推動重要的架構決策。 在採用和作業活動期間，這些小組可能會在 Azure Well-Architected 架構指引中找到更多價值。

界限定義： 邏輯界限，即使在企業層級，也可能會專注於生產和非生產環境分割。 公司軟體組合中的產品之間也可能有明確的分割。 有時，開發與託管的客戶實例之間也可能有分割。

營運主導的產品群組

擁有更成熟的 IT 營運小組的跨國企業組織通常更注重治理和作業，而不是開發。 在這些組織中，工作負載的較高百分比通常屬於商用現貨軟體或故障/修復類別，並由雲端營運團隊裡的技術負責人來維護。

投資組合對齊： IT 投資組合將與工作負載對齊，但這些工作負載接下來會與營運單位或業務單位對齊。 也可能有圍繞資金模式、產業或其他業務分割的需求的安排。

界限定義： 登陸區域可能會將應用程式分組為應用程式原型，以將類似的作業保留在類似的分割中。 環境可能會參考實體建構，例如數據中心、國家/地區、雲端提供者區域或其他作業組織標準。

遷移主導的投資組合

與營運主導的投資組合類似，主要透過移轉建構的投資組合會以導致現有資產移轉的特定業務推動因素為基礎。 一般而言，數據中心是這些驅動程式中最大的因素。

投資組合調整： IT 投資組合可能以工作負載為基礎調整，但更可能是以資產為基礎調整。 如果轉換至 IT 作業已在公司歷史上發生，則許多使用中資產可能不容易對應到已資助的工作負載。 在這些情況下，許多資產可能直到遷移過程的後期，才會有明確的工作負載或明確的工作負載擁有者。

界限定義： 著陸區可能會將應用程式分組為反映內部部署劃分的界限。 雖然不是最佳做法，但環境通常會符合代表網路分割做法的內部部署數據中心名稱和登陸區域。 最好遵循更貼近以營運為主導的組合的劃分方式。

治理主導的組合

應儘早與治理小組保持一致。 透過治理做法和雲端治理工具，專案組合和環境邊界可以最佳地平衡創新、作業和遷移工作的需求。

產品組合一致性： 治理主導的產品組合通常會包含涵蓋創新和營運詳細數據的數據點，例如工作負載、營運負責人、數據分類和營運關鍵性。 這些數據點會建立組合的全面觀點。

界限定義： 在治理主導的投資組合中，界限傾向於偏向營運而非創新，同時使用一個由管理群組驅動的階層，該階層映射到業務單位和開發環境的準則。 在每個層級的階層中，雲端治理界限可具有不同程度的政策執行，以允許開發和創造性的靈活性。 同時，可以將生產級別的要求套用到生產訂閱，以確保職責分離和作業的一致性。

後續步驟

瞭解 Azure 產品 如何支援組合階層。