ポートフォリオ階層を理解して整理するUnderstand and align the portfolio hierarchy

ビジネスニーズは、多くの場合、情報技術を通じてサポート、改善、または促進されます。Business needs are often supported, improved, or accelerated through information technology. 定義されたビジネス価値を提供するテクノロジのコレクションは、"ワークロード" と呼ばれます。A collection of technologies that delivers defined business value is called a workload. そのコレクションには、アプリケーション、サーバー、仮想マシン、データ、デバイス、その他の同様のグループ化された資産が含まれる場合があります。That collection might include applications, servers or virtual machines, data, devices, and other similarly grouped assets.

通常、ビジネス関係者と技術リーダーは、各ワークロードの継続的なサポートに対するアカウンタビリティを共有します。Typically, a business stakeholder and technical leader share accountability for the ongoing support of each workload. ワークロードのライフサイクルのフェーズによっては、それらのロールが明確に示されます。In some phases of the workload lifecycle, those roles are clearly stated. ワークロードのライフサイクルのより多くの運用フェーズでは、それらのロールは共有運用管理チームまたはクラウド運用チームに移行される可能性があります。In more operational phases of a workload's lifecycle, those roles might be transitioned to a shared operations management team or cloud operations team. ワークロードの数が増えるにつれて、(明示または黙示の) ロールはより複雑になり、マトリックス化されます。As the number of workloads increases, the roles (stated or implied) become more complex and more matrixed.

ほとんどの企業は、複数のワークロードに依存して重要なビジネス機能を提供しています。Most businesses rely on multiple workloads to deliver vital business functions. ワークロード、資産、サポートする要素 (プロジェクト、人、プロセス、投資) のコレクションは、"ポートフォリオ" と呼ばれます。The collection of workloads, assets, and supporting factors (projects, people, processes, and investments) is called a portfolio. ビジネス、開発、運用スタッフのマトリックスでは、ワークロードとサポート サービスがどのように連携するかを見せるためにポートフォリオ階層が必要です。The matrix of business, development, and operations staff requires a portfolio hierarchy to show how the workloads and supporting services all fit together.

この記事では、ポートフォリオ階層のレベルを明確に定義します。This article provides clear definitions for the levels of the portfolio hierarchy. この記事では、さまざまなチームを各レイヤーでの適切なアカウンタビリティと共に配置し、そのチームがそのレベルに対して予期されるものを提供するためのベスト ガイダンスのソースを提供します。The article aligns various teams with the appropriate accountability in each layer, along with the source of the best guidance for that team to deliver on the expectations for that level. この記事全体を通して、階層の各レベルは "スコープ" とも呼ばれます。Throughout this article, each level of the hierarchy is also called a scope.

ポートフォリオ階層Portfolio hierarchy


ワークロードとそれをサポートする資産は、すべてのポートフォリオの中核になります。Workloads and their supporting assets are at the core of any portfolio. 以下の追加のスコープまたはレイヤーでは、それらのワークロードの表示方法と、潜在的なサポート チームのマトリックスによって影響を受ける範囲を定義します。The additional scopes or layers below define how those workloads are viewed and to what extent they're affected by the matrix of potential supporting teams.


異なる用語が使われることがありますが、すべての IT ソリューションには資産とワークロードが含まれます。Although the terms can vary, all IT solutions include assets and workloads:

  • 資産: ワークロードやソリューションをサポートする、技術的な機能の最小単位。Asset: The smallest unit of technical function that supports a workload or solution.
  • ワークロード: ビジネスに対する IT サポートの最小単位。Workload: The smallest unit of IT support for the business. ワークロードは資産 (インフラストラクチャ、アプリケーション、データ) のコレクションであり、一般的なビジネス目標または一般的なビジネス プロセスの実行がサポートされます。A workload is a collection of assets (infrastructure, applications, and data) that supports a common business goal or the execution of a common business process.

最初のワークロードをデプロイするときは、そのワークロードと資産のスコープだけが定義されている場合があります。When you're deploying your first workload, the workload and its assets might be the only defined scope. デプロイされるワークロードが増えるにつれて、他のレイヤーが明示的に定義される場合があります。The other layers might be explicitly defined as more workloads are deployed.

IT ポートフォリオIT portfolio

企業がマトリックス型アプローチまたは集中型アプローチを通じてワークロードをサポートする場合、それらのワークロードをサポートするために、より広範な階層が存在する可能性があります。When companies support workloads through matrixed approaches or centralized approaches, a broader hierarchy likely exists to support those workloads:

パブリックとプライベートの複数のクラウド プラットフォームが含まれる IT ポートフォリオの画像

  • ランディング ゾーン: ランディング ゾーンによって、1 つまたは複数のワークロードをサポートするために必要な "プラットフォーム基盤" から提供される、必要な "基本ユーティリティ" (または共有プラミング) がワークロードに提供されます。Landing zones: Landing zones provide workloads with the necessary foundational utilities (or shared plumbing) that are provided from a platform foundation that's required to support one or more workloads. ランディング ゾーンはクラウドにおいて非常に重要であるため、クラウド導入フレームワークの準備手法すべてがランディング ゾーンを重視しています。Landing zones are so critical in the cloud that the entire Ready methodology of the Cloud Adoption Framework focuses on landing zones. 詳細な定義については、ランディング ゾーンに関する記事を参照してください。For a more detailed definition, see What is a landing zone?
  • 基本ユーティリティ: これらの共有 IT サービスは、テクノロジとビジネスのポートフォリオ内でワークロードが動作するために必要です。Foundational utilities: These shared IT services are required for workloads to operate within the technology and business portfolio.
  • プラットフォーム基盤: 基本ソリューションを一元化し、すべてのランディング ゾーンに対してそれらのコントロールが強制的に適用されることを確保するための組織コンストラクトです。Platform foundation: This organizational construct centralizes foundational solutions and helps ensure that those controls are enforced for all landing zones.
  • クラウド プラットフォーム: "ポートフォリオ" 全体をサポートするための全体的な戦略によっては、複数のリージョン、ハイブリッド ソリューション、またはマルチクラウド ソリューションを管理するために、プラットフォーム基盤が個別にデプロイされた複数のクラウド プラットフォームが必要になる場合があります。Cloud platforms: Depending on the overall strategy for supporting the full portfolio, customers might need multiple cloud platforms with distinct deployments of the platform foundation to govern multiple regions, hybrid solutions, or even multicloud solutions.
  • ポートフォリオ: テクノロジの観点からは、ポートフォリオは、すべてのクラウド プラットフォームにわたるワークロード、資産、サポート リソースのコレクションです。Portfolio: Through a technology lens, the portfolio is a collection of workloads, assets, and supporting resources that span all cloud platforms. ビジネスの観点からは、ポートフォリオは、ビジネスの成果を促進するテクノロジ ポートフォリオをサポートおよび管理するプロジェクト、人、プロセス、投資のコレクションです。Through a business lens, the portfolio is the collection of projects, people, processes, and investments that support and manage the technology portfolio to drive business outcomes. これらの 2 つの観点を合わせて、"ポートフォリオ" をとらえることができます。Together, these two lenses capture the portfolio.

階層のアカウンタビリティとガイダンスHierarchy accountability and guidance

責任者チームがポートフォリオ階層の各レイヤーを管理します。An accountable team manages each layer of the portfolio hierarchy. 次の図は、責任チームと、そのビジネス上の決定、技術的な決定、技術的な実装をサポートするためのガイダンスとの対応関係を示しています。The following diagram shows the mapping between the accountable team and the guidance to support its business decisions, technical decisions, and technical implementation.


次のリストで説明するチームは、仮想チームや個人である場合があります。The teams mentioned in the following list might be virtual teams or individuals. この階層の一部のバリエーションでは、以下でアカウンタビリティのバリエーションで説明するときに、いくつかの責任チームが折りたたまれていることがあります。For some variants of this hierarchy, some of the accountable teams can be collapsed as described later in the accountability variants.


  • ポートフォリオ: クラウド戦略チームおよびクラウドのセンター オブ エクセレンス (CCoE) では、戦略と計画の方法論を使用して、ポートフォリオ全体に影響を与える決定がガイドされます。Portfolio: The cloud strategy team and the cloud center of excellence (CCoE) use the Strategy and Plan methodologies to guide decisions that affect the overall portfolio. クラウド戦略チームは、クラウド ポートフォリオ階層のエンタープライズ レベルについて責任を持ちます。The cloud strategy team is accountable for the enterprise level of the cloud portfolio hierarchy. クラウド戦略チームはまた、環境、ランディング ゾーン、優先順位の高いワークロードに関する決定について通知を受ける必要があります。The cloud strategy team should also be informed of decisions about the environment, landing zones, and high-priority workloads.
  • クラウド プラットフォーム: クラウド ガバナンス チームは、統制手法に合わせて、各環境での一貫性を保証する統制に対して責任を負います。Cloud platforms: The cloud governance team is accountable for the disciplines that ensure consistency across each environment in alignment with the Govern methodology. クラウド ガバナンス チームは、すべての環境のすべてのリソースのガバナンスに対して責任を持ちます。The cloud governance team is accountable for governance of all resources in all environments. クラウド ガバナンス チームは、統制ポリシーに対する例外または変更が必要になる可能性がある変更について、相談を受ける必要があります。The cloud governance team should be consulted on changes that might require an exception or change to governing policies. また、クラウド ガバナンス チームは、ワークロードと資産の導入に関する進行についての通知を受け取る必要があります。The cloud governance team should also be informed of progress with workload and asset adoption.
  • ランディング ゾーンとクラウド基盤: クラウド プラットフォーム チームは、導入をサポートするランディング ゾーンとプラットフォーム ユーティリティの開発に責任を持ちます。Landing zones and cloud foundation: The cloud platform team is accountable for developing the landing zones and platform utilities that support adoption. クラウド自動化チームは、これらのランディング ゾーンとプラットフォーム ユーティリティの開発と継続的なサポートの自動化に責任を持ちます。The cloud automation team is accountable for automating the development of, and ongoing support for, those landing zones and platform utilities. どちらのチームも、準備の方法論を使用して実装をガイドします。Both teams use the Ready methodology to guide implementation. どちらのチームも、ワークロードの進捗状況と、企業または環境への変更に関して、通知を受け取る必要があります。Both teams should be informed of progress with workload adoption and any changes to the enterprise or environment.
  • ワークロード: 導入はワークロード レベルで行われます。Workloads: Adoption happens at the workload level. クラウド導入チームは、移行とイノベーションの方法論を使用して、導入を促進するためのスケーラブルなプロセスを確立します。Cloud adoption teams use the Migrate and Innovate methodologies to establish scalable processes to accelerate adoption. 導入が完了すると、ワークロードの所有権はおそらく、管理の方法論を使用して運用管理をガイドするクラウド運用チームに移管されます。After adoption is complete, the ownership of workloads is likely transferred to a cloud operations team that uses the Manage methodology to guide operations management. どちらのチームも、Microsoft Azure Well-Architected Framework を使用して、サポート対象のワークロードに影響を与える詳細なアーキテクチャ上の決定を行う必要があります。Both teams should be comfortable using the Microsoft Azure Well-Architected Framework to make detailed architectural decisions that affect the workloads they support. どちらのチームも、ランディング ゾーンと環境に対する変更に関して、通知を受ける必要があります。Both teams should be informed of changes to landing zones and environments. どちらのチームも、ランディング ゾーンの機能に関係することがあります。Both teams might occasionally contribute to landing zone features.
  • 資産: 通常、資産はクラウド運用チームの責任です。Assets: Assets are typically the responsibility of the cloud operations team. そのチームは、管理の方法論の管理ベースラインを使用して、運用管理の決定をガイドします。That team uses the management baseline in the Manage methodology to guide operations management decisions. また、Azure Advisor と Azure Well-Architected Framework を使用して、運用の要件に対応するために必要なリソースとアーキテクチャに関する詳細な変更を加える必要があります。It should also use Azure Advisor and the Azure Well-Architected Framework to make detailed resource and architectural changes that are required to deliver on operations requirements.

アカウンタビリティのバリエーションAccountability variants

  • 単一の環境: 企業が必要とする環境が 1 つだけの場合は、通常、CCoE は必要ありません。Single environment: When an enterprise needs only one environment, a CCoE is typically not required.
  • 単一のランディング ゾーン: 環境に含まれるランディング ゾーンが 1 つだけの場合は、ガバナンスとプラットフォームの機能を 1 つのチームに統合できます。Single landing zone: If an environment has only a single landing zone, the governance and platform capabilities can likely be combined into one team.
  • 単一のワークロード: 必要なワークロードが、1 つのランディング ゾーンと 1 つの環境内の 1 つだけ、または少数である企業があります。Single workload: Some businesses need only one workload, or few workloads, in a single landing zone and a single environment. このような場合、ガバナンス、プラットフォーム、運用チームの間で職務を分離する必要はほとんどありません。In those cases, there's little need for a separation of duties between governance, platform, and operations teams.

一般的なワークロードとアカウンタビリティの例Common workload and accountability examples

次の例では、ポートフォリオの階層を示します。The following examples illustrate the portfolio hierarchy.

COTS ワークロードCOTS workloads

従来、企業は、ビジネス プロセスに民生 (COTS) ソフトウェア ソリューションを使用するのを好みます。Traditionally, enterprises have favored commercial-off-the-shelf (COTS) software solutions to power business processes. このようなソリューションは、インストールされ、構成されてから、運用されます。These solutions are installed, configured, and then operated. 構成後にソリューションのアーキテクチャを変更することはほとんどありません。There is little change to the solutions architecture after configuration.

このようなシナリオでは、COTS ソリューションのクラウド導入は、クラウド運用チームへの移行によって終了します。In these scenarios, any cloud adoption of COTS solutions ends with a transition to a cloud operations team. その後、クラウド運用チームは、そのソフトウェアの技術所有者になり、構成、コスト、パッチ サイクル、その他の運用上のニーズの管理に対する責任を負います。The cloud operations team then becomes the technical owner for that software and assumes accountability for managing configuration, cost, patching cycles, and other operational needs.

これらのワークロードには、会計パッケージ、ロジスティック ソフトウェア、または業界固有のソリューションが含まれます。These workloads include accounting packages, logistics software, or industry-specific solutions. Microsoft の用語では、このようなパッケージのベンダーは独立系ソフトウェア ベンダー (ISV) と呼ばれます。In Microsoft terminology, the vendors of these packages are called independent software vendors (ISVs). 多くの ISV から、サブスクリプションにソフトウェア パッケージのインスタンスをデプロイして保守するサービスが提供されています。Many ISVs offer a service to deploy and maintain an instance of their software package in your subscriptions. また、独自のクラウド ホスト環境で実行されるソフトウェア パッケージのバージョンが用意されていて、ワークロードの代わりにサービスとしてのプラットフォーム (PaaS) が提供される場合もあります。They might also offer a version of the software package that runs in their own cloud-hosted environment, providing a platform as a service (PaaS) alternative to the workload.

PaaS オファリングを除き、クラウド運用チームは、それらのワークロードの基本的な運用コンプライアンス要件を確保する責任があります。With the exception of PaaS offerings, cloud operations teams are responsible for ensuring basic operational compliance requirements for those workloads. クラウド運用チームはクラウド ガバナンス チームと共同でコスト、パフォーマンス、アーキテクチャにおけるその他の柱を調整する必要があります。A cloud operations team should work with the cloud governance team to align cost, performance, and other architecture pillars.

アクティブなリビジョンを使用した開発In development with active revisions

COTS ソリューションまたは PaaS オファリングがビジネスニーズに適合しない場合、またはソリューションが存在しない場合、企業はカスタム開発ワークロードを構築します。When a COTS solution or PaaS offering isn't aligned to the business need, or no solution exists, enterprises build custom-developed workloads. 通常、このワークロード アプローチを使用するのは IT ポートフォリオのごく一部です。Typically, a small percentage of the IT portfolio uses this workload approach. ただし、このようなワークロードでは、ビジネスの結果 (特に新しい収益ストリームに関連する結果) に対する IT の貢献において、異常に高い割合を占める傾向があります。But these workloads tend to drive a disproportionately high percentage of IT's contribution to business outcomes, especially outcomes related to new revenue streams. このようなワークロードは、新しいイノベーションのアイデアに適切に対応する傾向があります。These workloads tend to map well to new innovation ideas.

アジャイル手法と DevOps プラクティスを起源とするさまざまな動きがある場合、これらのワークロードは従来の IT 管理よりビジネスおよび DevOps に配置する方が適しています。Given various movements that are rooted in agile methodologies and DevOps practices, these workloads favor a business/DevOps alignment over traditional IT management. これらのワークロードの場合、クラウド運用チームへの移管に数年もかかることはありません。For these workloads, there might not be a handoff to the cloud operations team for several years. そのような場合、開発チームはワークロードの技術所有者として機能します。In those cases, the development team serves as the technical owner of the workload.

長い時間と関連する資本の制約により、多くの場合、カスタム開発オプションは価値の高い機会に限定されます。Due to extensive time and associated capital constraints, custom development options are often limited to high-value opportunities. 一般的な例としては、アプリケーション イノベーション、ディープ データ分析、ミッションクリティカルなビジネス機能などがあります。Typical examples include application innovations, deep data analysis, or mission-critical business functions.

開発の中断/修正または終了Break/fix or sunset development

カスタム開発のワークロードの成熟度がピークに達すると、開発チームは他のプロジェクトに再割り当てされる可能性があります。After a custom-developed workload reaches peak maturity, the development team might be reassigned to other projects. このような場合、技術的な所有権は通常、クラウド運用チームに移行します。In these cases, technical ownership typically transitions to a cloud operations team. 小規模な修正が必要な場合、運用チームはエラーの解決に開発者の協力を求めます。When there's a need for small fixes, the operations team will enlist developers to resolve the error.

場合によっては、開発チームは、最終的に現在のワークロードを置き換えるプロジェクトに移行します。In some cases, the development team moves to a project that will eventually replace the current workload. または、ワークロードによってサポートされるビジネス機会が徐々に減少しているためにチームは先に進むことがあります。これらは、ワークロードが不要になるまで、クラウド運用チームが技術所有者として機能する、終了シナリオの例です。Alternatively, the team might move on because the business opportunity supported by the workload is being phased out. These are examples of sunset scenarios, where the cloud operations team serves as the technical owner until the workload is no longer needed.

どちらのシナリオでも、クラウド運用チームは通常、長期的な技術所有者および意思決定者として機能します。In both scenarios, the cloud operations team typically serves as the long-term technical owner and decision maker. そのチームは、運用上の変更に大きなアーキテクチャの変更が必要なとき、アプリケーション開発者におそらく協力を求めるでしょう。That team will likely enlist application developers when operational changes require significant architectural changes.

ミッションクリティカルなワークロードMission-critical workloads

どのような企業でも、ビジネスにとって非常に重要なため、失敗できないワークロードがいくつかあります。In every company, a few workloads are too important to the business for them to fail. このようなミッションクリティカルなワークロードには、通常、さまざまなレベルの責任を持つ運用と開発の所有者がいます。With these mission-critical workloads, there are usually operations and development owners with various levels of responsibility. そのようなチームは、運用ソリューションの中断を最小限に抑えるために、運用上の変更とアーキテクチャの変更を調整する必要があります。Those teams should align operational changes and architectural changes to minimize disruptions to the production solution.

これらのシナリオでは、職務の分離を重視する必要があります。These scenarios require a strong focus on separation of duties. 運用チームは、職務の分離を実現するために、通常、運用環境における日々の運用上の変更についての責任を負います。To achieve separation of duties, the operations team will generally hold accountability for day-to-day operational changes in the production environment. そのような運用上の変更でアーキテクチャの変更が必要なときは、運用チームが運用環境に変更を適用する前に、非運用環境において開発チームまたは導入チームによってこれらの変更が行われます。When those operational changes require an architectural change, they'll be completed by the development or adoption team in a nonproduction environment, before the operations team applies the changes to production.

職務の分離を必要とするミッションクリティカルなワークロードの例としては、社内の複数の事業単位にまたがる、SAP、Oracle、または他のエンタープライズ リソース プランニング (ERP) ソリューションが含まれます。Examples of mission-critical workloads with a required separation of duties include workloads like SAP, Oracle, or other enterprise resource planning (ERP) solutions, which span multiple business units in the company.

戦略ポートフォリオの調整Strategy portfolio alignment

クラウドの導入作業の戦略目標を理解し、その変換をサポートするようにポートフォリオを調整することが重要です。It's important to understand the strategic objectives of the cloud adoption effort and align the portfolio to support that transformation. いくつかの一般的な種類の戦略的ポートフォリオの調整は、ポートフォリオ階層の構造の形成に役立ちます。A few common types of strategic portfolio alignment help shape the structure of the portfolio hierarchy. 以下のセクションでは、ポートフォリオの調整とポートフォリオ階層に対する影響の例を示します。The following sections provide examples of the portfolio alignment and impact on the portfolio hierarchy.

イノベーションまたは開発主導のポートフォリオInnovation or development-led portfolio

企業によっては、特に急速に成長しているスタートアップ環境では、カスタム開発プロジェクトの割合が高くなります。Some companies, especially fast-growing established startups, have a higher-than-average percentage of custom development projects. 開発重視のポートフォリオでは、環境、ランディング ゾーン、ワークロードは多くの場合圧縮されるため、特定のワークロードには特定の環境 (運用または非運用) が存在する可能性があります。In development-heavy portfolios, the environment, landing zone, and workloads are often compressed, so there might be specific environments (either production or nonproduction) for specific workloads. これにより、環境、ランディング ゾーン、ワークロードの間の比率が 1:1 になります。This results in a 1:1 ratio between environment, landing zone, and workload.

環境によってカスタム ソリューションがホストされるため、DevOps パイプラインとアプリケーション レベルのレポートによって、運用機能やガバナンス機能の必要性がなくなる可能性があります。Because the environment hosts custom solutions, the DevOps pipeline and application-level reporting might replace the need for operations and governance functions. そのようなお客様の場合、運用、ガバナンス、またはその他のサポートの役割への注目は減ると考えられます。For those customers, a reduced focus on operations, governance, or other supporting roles is likely. また一般的に、クラウド導入チームとクラウド自動化チームの責任がいっそう大きくなります。A stronger emphasis on the responsibilities of the cloud adoption and cloud automation teams is also typical.

ポートフォリオの調整: IT ポートフォリオでは、アーキテクチャに関する重要な決定を推進するため、ワークロードやワークロードの所有者に重点が置かれることが考えられます。Portfolio alignment: The IT portfolio will likely focus on workloads and workload owners to drive critical architecture decisions. そのようなチームでは、導入と運用のアクティビティ中に、Azure Well-Architected Framework のガイダンスにより多くの価値を見出すと考えられます。Those teams are likely to find more value in the Azure Well-Architected Framework guidance during adoption and operations activities.

境界の定義: 論理的な境界では、エンタープライズ レベルであっても、運用環境と非運用環境のセグメント化に焦点が当てられます。Boundary definitions: The logical boundaries, even at an enterprise level, will likely focus on production and nonproduction environment segmentation. また、企業のソフトウェア ポートフォリオの製品間にも、明確なセグメント化が存在する場合があります。There might also be clear segmentation between products in the company's software portfolio. 場合によっては、開発とホストされた顧客インスタンスの間にも、セグメント化が存在する可能性があります。At times, there might also be segmentation between development and hosted customer instances.

運用主導のポートフォリオOperations-led portfolio

より確立された IT 運用チームがある多国籍企業組織では、通常、開発よりガバナンスと運用に大きな重点が置かれます。Multinational enterprise organizations with more established IT operations teams typically have a stronger focus on governance and operations than development. これらの組織では、一般に、クラウド運用チーム内の技術所有者によって管理される COTS や中断/修正のカテゴリに対して調整されるワークロードの割合が高くなります。In these organizations, a higher percentage of workloads typically align to the COTS or break/fix categories, maintained by technical owners within the cloud operations team.

ポートフォリオの調整: IT ポートフォリオはワークロードに合わせて調整されますが、それらのワークロードは運用ユニットまたは事業単位に合わせて調整されます。Portfolio alignment: The IT portfolio will be workload aligned, but those workloads are then aligned to operating units or business units. また、資金調達モデル、業界、またはその他のビジネス セグメントの要件に関する組織も存在する可能性があります。There might also be organization around funding models, industry, or other business segmentation requirements.

境界の定義: 多くの場合、ランディング ゾーンではアプリケーションがアプリケーション アーキタイプにグループ化され、似た運用は似たセグメント化で保持されます。Boundary definitions: Landing zones will likely group applications into application archetypes to keep similar operations in a similar segmentation. 環境は、データセンター、国、クラウド プロバイダーのリージョンなどの物理的な構造や、その他の運用組織の標準を指すことがあります。Environments will likely refer to physical constructs like datacenter, nation, cloud-provider region, or other operational organization standards.

移行主導のポートフォリオMigration-led portfolio

運用主導のポートフォリオと同様に、移行によって主に構築されるポートフォリオは、既存の資産の移行をもたらした特定のビジネス要因が基になります。Similar to operations-led portfolios, a portfolio that is largely built through migration will be based on specific business drivers that led to the migration of existing assets. 通常、そのような要因の最大のものはデータセンターです。Typically, the datacenter is the biggest factor in those drivers.

ポートフォリオの調整: IT ポートフォリオはワークロードに合わせて調整される場合もありますが、資産に合わせて調整される可能性の方が高くなります。Portfolio alignment: The IT portfolio might be workload aligned, but it's more likely asset aligned. IT 運用への移行が会社でかつて発生した場合、アクティブに使用される資産の多くは、資金調達されたワークロードに簡単にマップされない可能性があります。If transitions to IT operations have happened in the company's history, many active-use assets might not be easily mapped to a funded workload. このような場合、移行プロセスの最後まで、多くの資産に定義されたワークロードや明確なワークロード所有者が存在しないことがあります。In these cases, many assets might not have a defined workload or clear workload owner until late in the migration process.

境界の定義: ランディング ゾーンでは、オンプレミスのセグメント化を反映する境界に、アプリケーションがグループ化される可能性があります。Boundary definitions: Landing zones will likely group applications into boundaries that reflect on-premises segmentation. ベスト プラクティスではありませんが、多くの場合、環境はネットワーク セグメント化のプラクティスを表すオンプレミスのデータセンター名およびランディング ゾーンと一致します。Though not a best practice, environments often match the on-premises datacenter name and landing zones that represent network segmentation practices. 運用主導のポートフォリオとより密接に一致するセグメント化に従うことをお勧めします。It's a better practice to adhere to segmentation that more closely aligns with an operations-led portfolio.

ガバナンス主導のポートフォリオGovernance-led portfolio

ガバナンス チームに合わせた調整は、できるだけ早く行う必要があります。Alignment to governance teams should happen as early as possible. ガバナンス プラクティスとクラウド ガバナンス ツール、ポートフォリオ、および環境の境界を使用すると、イノベーション、運用、移行の各作業のニーズを最適なバランスにすることができます。Through governance practices and cloud governance tooling, portfolios and environmental boundaries can best balance the needs of innovation, operations, and migration efforts.

ポートフォリオの調整: ガバナンス主導のポートフォリオには、ワークロード、運用の所有者、データ分類、運用上の重要度など、イノベーションと運用の詳細を取得するデータ ポイントが含まれる傾向があります。Portfolio alignment: Governance-led portfolios tend to include data points that capture innovation and operations details, such as workload, operations owner, data classification, and operational criticality. これらのデータ ポイントにより、ポートフォリオの適切なビューが作成されます。These data points create a well-rounded view of the portfolio.

境界の定義: ガバナンス主導ポートフォリオにおける境界では、事業単位および開発環境の条件に対応する管理グループ主導の階層を使用しながら、イノベーションより運用が優先される傾向があります。Boundary definitions: Boundaries in a governance-led portfolio tend to favor operations over innovation, while using a management-group-driven hierarchy that maps to criteria for business units and development environments. 階層の各レベルで、開発およびクリエイティブな柔軟性を実現するため、クラウド ガバナンスの境界に、さまざまなレベルのポリシーを適用することができます。At each level of the hierarchy, a cloud governance boundary can have different degrees of policy enforcement to allow for development and creative flexibility. 同時に、運用レベルの要件を運用サブスクリプションに適用することで、職務と一貫性のある運用を確実に分離することができます。At the same time, production-grade requirements can be applied to production subscriptions to ensure separation of duties and consistent operations.