ポートフォリオ階層
ワークロード、資産、サポート サービスの
ワークロード
定義済みのビジネス価値を提供するテクノロジのコレクションは、ワークロードと呼ばれます。 コレクションには、アプリケーション、サーバーまたは仮想マシン、データ、デバイス、およびその他の同様にグループ化された資産が含まれる場合があります。 ほとんどの企業は、重要なビジネス機能を提供するために複数のワークロードに依存しています。
通常、ビジネス利害関係者と技術リーダーは、各ワークロードの継続的なサポートに対するアカウンタビリティを共有します。 ワークロード ライフサイクルの一部のフェーズでは、これらのロールが明確に示されます。 ワークロードのライフサイクルのより多くの運用フェーズでは、これらのロールが共有運用管理チームまたはクラウド運用チームに移行される可能性があります。 ワークロードの数が増えるにつれて、ロール (指定または暗黙的) がより複雑になり、マトリックス化されます。
ワークロードとそのサポート資産は、あらゆるポートフォリオの中核をなしています。 スコープまたはレイヤーは、これらのワークロードを表示する方法と、潜在的なサポート チームのマトリックスによってどの程度影響を受けるかを定義します。
用語は異なる場合がありますが、すべての IT ソリューションには資産とワークロードが含まれます。
- 資産: ワークロードまたはソリューションをサポートする技術的な機能の最小単位。
- ワークロード: ビジネスに対する IT サポートの最小単位。 ワークロードは、共通のビジネス目標または共通のビジネス プロセスの実行をサポートするインフラストラクチャ、アプリケーション、およびデータ資産のコレクションです。
最初のワークロードをデプロイする場合、ワークロードとその資産が唯一定義されたスコープである可能性があります。 他のレイヤーは、より多くのワークロードがデプロイされると明示的に定義される場合があります。
IT ポートフォリオ
企業がマトリックスアプローチまたは集中型アプローチを使用してワークロードをサポートする場合、これらのワークロードをサポートするためにより広範な階層が存在する可能性があります。
- ランディング ゾーン: ランディング ゾーンは、1 つ以上のワークロードをサポートするために必要な基本ユーティリティ (共有プラミング) をワークロードに提供します。 ランディング ゾーンはクラウドで非常に重要であるため、クラウド導入フレームワークの Ready 手法全体がランディング ゾーンに重点を置いています。 詳細な定義については、「ランディング ゾーンとは」を参照してください。
- 基本ユーティリティ: これらの共有 IT サービスは、ワークロードがテクノロジとビジネス ポートフォリオ内で動作するために必要です。
- プラットフォーム基盤: この組織構造は、基本的なソリューションを一元化し、すべてのランディング ゾーンに対してこれらのコントロールが確実に適用されるようにするのに役立ちます。
- クラウド プラットフォーム: 完全なポートフォリオをサポートするための全体的な戦略によっては、複数のリージョン、ハイブリッド ソリューション、さらにはマルチクラウド ソリューションを管理するために、プラットフォーム基盤の個別のデプロイを持つ複数のクラウド プラットフォームが必要になる場合があります。
- ポートフォリオ: テクノロジを通じて、ポートフォリオは、すべてのクラウド プラットフォームにまたがるワークロード、資産、サポート リソースのコレクションです。 ビジネスのレンズを通じて、ポートフォリオは、ビジネス成果を促進するためにテクノロジ ポートフォリオをサポートおよび管理するプロジェクト、人、プロセス、および投資のコレクションです。 これら 2 つのレンズが一緒にポートフォリオをキャプチャします。
階層の説明責任とガイダンス
アカウンタブル チームは、ポートフォリオ階層の各レイヤーを管理します。 次の図は、責任を負うチームと、そのビジネス上の決定、技術的な決定、および技術的な実装をサポートするためのガイダンスのマッピングを示しています。
手記
次の一覧に記載されているチームは、仮想チームまたは個人である可能性があります。 この階層の一部のバリエーションでは、この後のアカウンタビリティのバリエーションで説明するように、いくつかの説明責任チームを統合することができます。
- ポートフォリオ: クラウド戦略チームとクラウド センター オブ エクセレンス (CCoE) は、戦略 と 計画 手法を使用して、ポートフォリオ全体に影響を与える意思決定を導きます。 クラウド戦略チームは、クラウド ポートフォリオ階層のエンタープライズ レベルに対して責任を負います。 クラウド戦略チームには、環境、ランディング ゾーン、優先度の高いワークロードに関する決定も通知する必要があります。
- クラウド プラットフォーム: クラウド ガバナンス チームは、ガバナンスの 手法に沿って各環境間の一貫性を確保するガードレールに責任を負います。 クラウド ガバナンス チームは、すべての環境のすべてのリソースのガバナンスに対して責任を負います。 クラウド ガバナンス チームは、例外やガバナンス ポリシーの変更を必要とする可能性がある変更について相談する必要があります。 また、クラウド ガバナンス チームには、ワークロードと資産の導入に関する進行状況も通知する必要があります。
- ランディング ゾーンとクラウド基盤: クラウド プラットフォーム チームは、導入をサポートするランディング ゾーンとプラットフォーム ユーティリティを開発する責任を負います。 クラウド自動化チームは、これらのランディング ゾーンとプラットフォーム ユーティリティの開発と継続的なサポートを自動化する責任を負います。 どちらのチームも、Ready 手法を使用して実装をガイドします。 どちらのチームも、ワークロードの導入の進行状況と、企業または環境に対する変更を通知する必要があります。
- ワークロード: 導入はワークロードレベルで行われます。 クラウド導入チームは、Migrate と イノベーションの 手法を使用して、導入を促進するスケーラブルなプロセスを確立します。 導入が完了すると、ワークロードの所有権は、管理 手法を使用して運用管理をガイドするクラウド運用チームに転送される可能性があります。 どちらのチームも、Microsoft Azure Well-Architected Framework を使用して、サポートするワークロードに影響を与える詳細なアーキテクチャ上の決定を行う必要があります。 ランディング ゾーンと環境の変更については、両方のチームに通知する必要があります。 両方のチームがランディング ゾーンの機能に貢献する場合があります。
- 資産: 資産は、通常、クラウド運用チームの責任です。 そのチームは、管理 手法の管理ベースラインを使用して、運用管理の決定を導きます。 また、Azure Advisor と Azure Well-Architected Framework を使用して、運用要件を満たすのに必要な詳細なリソースとアーキテクチャの変更を行う必要があります。
アカウンタビリティバリアント
- 単一環境: 企業で必要な環境が 1 つだけの場合、通常は CCoE は必要ありません。
- 単一ランディング ゾーン: 環境にランディング ゾーンが 1 つしかない場合は、ガバナンスとプラットフォームの機能を 1 つのチームに組み合わせることができます。
- 単一のワークロード: 一部の企業では、単一のランディング ゾーンと 1 つの環境に 1 つのワークロードまたは少数のワークロードのみが必要です。 このような場合、ガバナンス、プラットフォーム、運用チームの間で職務を分離する必要はほとんどありません。
一般的なワークロードとアカウンタビリティの例
次の例は、ポートフォリオ階層を示しています。
COTS ワークロード
従来、企業はビジネス プロセスに力を入れる商用の既製 (COTS) ソフトウェア ソリューションを好んでいました。 これらのソリューションは、インストール、構成、操作されます。 構成後のソリューション アーキテクチャにはほとんど変更はありません。
これらのシナリオでは、COTS ソリューションのクラウド導入は、クラウド運用チームへの移行で終了します。 その後、クラウド運用チームはそのソフトウェアの技術所有者となり、構成、コスト、修正プログラムの適用サイクル、およびその他の運用ニーズを管理するためのアカウンタビリティを想定します。
これらのワークロードには、会計パッケージ、ロジスティクス ソフトウェア、または業界固有のソリューションが含まれます。 Microsoft の用語では、これらのパッケージのベンダーは独立系ソフトウェア ベンダー (ISV) と呼ばれます。 多くの ISV では、サブスクリプションにソフトウェア パッケージのインスタンスをデプロイして管理するためのサービスが提供されています。 また、独自のクラウドホスト環境で実行されるソフトウェア パッケージのバージョンを提供し、ワークロードに代わるサービスとしてのプラットフォーム (PaaS) を提供することもできます。
PaaS オファリングを除き、クラウド運用チームは、これらのワークロードの基本的な運用コンプライアンス要件を確保する責任を負います。 クラウド運用チームは、クラウド ガバナンス チームと協力して、コスト、パフォーマンス、およびその他のアーキテクチャの柱を調整する必要があります。
積極的な改訂を行いながら開発中
COTS ソリューションまたは PaaS オファリングがビジネス ニーズに合っていない場合、またはソリューションが存在しない場合、企業はカスタム開発されたワークロードを構築します。 通常、このワークロード アプローチを使用するのは、IT ポートフォリオのごく一部のみです。 しかし、これらのワークロードは、ビジネス成果、特に新しい収益ストリームに関連する結果に対する IT の貢献の割合が不釣り合いに高くなる傾向があります。 これらのワークロードは、新しい革新のアイデアにうまく適合する傾向があります。
アジャイル手法と DevOps プラクティスに根ざしたさまざまな動きを考えると、これらのワークロードは、従来の IT 管理よりもビジネス/DevOps の連携を優先します。 これらのワークロードでは、数年にわたってクラウド運用チームへの引き継ぎがない可能性があります。 このような場合、開発チームはワークロードの技術所有者として機能します。
時間と資本の制約が大きいため、カスタム開発オプションは多くの場合、価値の高い機会に限定されます。 典型的な例としては、アプリケーションのイノベーション、ディープ データ分析、ミッション クリティカルなビジネス機能などがあります。
開発の中断/修正または終了
カスタム開発ワークロードが成熟度のピークに達すると、開発チームが他のプロジェクトに再割り当てされる可能性があります。 このような場合、技術所有権は通常、クラウド運用チームに移行します。 小規模な修正が必要な場合、運用チームは開発者に参加してエラーを解決します。
場合によっては、開発チームは、最終的に現在のワークロードを置き換えるプロジェクトに移動します。 または、ワークロードでサポートされているビジネスチャンスが段階的に廃止されるため、チームが先に進む可能性があります。このようなサンセット シナリオでは、ワークロードが不要になるまで、クラウド運用チームが技術所有者として機能します。
どちらのシナリオでも、クラウド運用チームは通常、長期的な技術所有者および意思決定者として機能します。 運用上の変更でアーキテクチャの大幅な変更が必要な場合、そのチームはアプリケーション開発者を参加させる可能性があります。
重要任務のワークロード
どの会社でも、いくつかのワークロードがビジネスにとって重要すぎて失敗できません。 これらのミッション クリティカルなワークロードでは、通常、さまざまなレベルの責任を持つ運用と開発の所有者がいます。 これらのチームは、運用ソリューションの中断を最小限に抑えるために、運用上の変更とアーキテクチャの変更を調整する必要があります。
これらのシナリオでは、職務の分離に重点を置く必要があります。 運用チームは、通常、運用環境での日常的な運用変更に対するアカウンタビリティを保持します。 これらの運用上の変更にアーキテクチャの変更が必要な場合、運用チームが変更を運用環境に適用する前に、運用以外の環境で開発チームまたは導入チームによって完了されます。
職務の分離が必要なミッション クリティカルなワークロードの例としては、SAP、Oracle、社内の複数の部署にまたがる他のエンタープライズ リソース プランニング (ERP) ソリューションなどのワークロードがあります。
戦略ポートフォリオのアラインメント
クラウド導入作業の戦略的目標を理解し、その変革をサポートするためにポートフォリオを調整することが重要です。 いくつかの一般的なタイプの戦略的ポートフォリオアラインメントは、ポートフォリオ階層の構造を形成するのに役立ちます。 次のセクションでは、ポートフォリオの配置の例と、ポートフォリオ階層への影響について説明します。
イノベーションまたは開発主導のポートフォリオ
特に成長著しいスタートアップ企業の中には、カスタム開発プロジェクトの割合が平均より高い企業もあります。 開発負荷の高いポートフォリオでは、環境、ランディング ゾーン、ワークロードが圧縮されることが多いため、特定のワークロードに固有の環境が存在する可能性があります。 結果は、環境、ランディング ゾーン、ワークロードの間で 1 対 1 の比率になります。
環境はカスタム ソリューションをホストするため、DevOps パイプラインとアプリケーション レベルのレポートによって、運用およびガバナンス機能の必要性が置き換わる可能性があります。 これらのお客様は、おそらく運用、ガバナンス、またはその他のサポート役割への重点を減らすでしょう。 また、クラウド導入チームとクラウド自動化チームの責任に重点を置くことも一般的です。
ポートフォリオの調整: IT ポートフォリオは、重要なアーキテクチャの決定を推進するためにワークロードとワークロード所有者に焦点を当てる可能性があります。 これらのチームは、導入および運用アクティビティ中に Azure Well-Architected Framework ガイダンスでより多くの価値を見つける可能性があります。
境界の定義: エンタープライズ レベルであっても、論理境界は運用環境と非運用環境のセグメント化に焦点を当てる可能性があります。 また、会社のソフトウェア ポートフォリオ内の製品間に明確なセグメント化が存在する場合もあります。 場合によっては、開発とホストされた顧客インスタンスの間にセグメント化が存在する場合もあります。
運用主導のポートフォリオ
IT 運用チームが確立されている多国籍企業組織は、通常、開発よりもガバナンスと運用に重点を置きます。 これらの組織では、ワークロードの割合が高いほど、通常、クラウド運用チーム内の技術所有者によって維持される、COTS または中断/修正のカテゴリに合わせて調整されます。
ポートフォリオの調整: IT ポートフォリオはワークロードに合わせて調整されますが、それらのワークロードは、運用ユニットまたは事業単位に合わせて調整されます。 また、資金調達モデル、業界、またはその他のビジネス セグメント化要件に関する組織もあります。
境界の定義: ランディング ゾーンでは、アプリケーションをアプリケーションアーキタイプにグループ化して、同様のセグメント化で同様の操作を維持する可能性があります。 環境は、データセンター、国、クラウド プロバイダーリージョン、またはその他の運用組織標準などの物理的な構成要素を指す可能性があります。
移行主導のポートフォリオ
運用主導のポートフォリオと同様に、移行によって主に構築されるポートフォリオは、既存の資産の移行につながった特定のビジネス ドライバーに基づいています。 通常、データセンターは、これらのドライバーの最大の要因です。
ポートフォリオの配置: IT ポートフォリオはワークロードに合わせられる可能性がありますが、資産に合わせられる可能性が高いです。 会社の歴史の中で IT 運用への移行が行われると、多くのアクティブな使用資産が資金提供されたワークロードに簡単にマップされない可能性があります。 このような場合、移行プロセスの後半まで、多くの資産にワークロードが定義されていないか、ワークロード所有者が明確でない場合があります。
境界の定義: ランディング ゾーンでは、オンプレミスのセグメント化を反映する境界にアプリケーションがグループ化される可能性があります。 ベスト プラクティスではありませんが、環境は多くの場合、ネットワークセグメント化のプラクティスを表すオンプレミスのデータセンター名とランディング ゾーンと一致します。 運用主導のポートフォリオとより密接に一致するセグメント化に従う方が良い方法です。
ガバナンス主導のポートフォリオ
ガバナンス チームとの連携は、できるだけ早く行う必要があります。 ガバナンス プラクティスとクラウド ガバナンス ツールを通じて、ポートフォリオと環境の境界によって、イノベーション、運用、移行の取り組みのニーズのバランスを最も高めることができます。
ポートフォリオの調整: ガバナンス主導のポートフォリオには、ワークロード、運用所有者、データ分類、運用上の重要度など、イノベーションと運用の詳細をキャプチャするデータ ポイントが含まれる傾向があります。 これらのデータ ポイントは、ポートフォリオの適切なビューを作成します。
境界の定義: ガバナンス主導のポートフォリオの 境界は、ビジネス ユニットと開発環境の基準にマップされる管理グループ主導の階層を使用しながら、イノベーションよりも運用を優先する傾向があります。 階層の各レベルで、クラウド ガバナンスの境界には、開発と創造的な柔軟性を可能にするさまざまな程度のポリシー適用を設定できます。 同時に、運用レベルの要件を運用サブスクリプションに適用して、職務の分離と一貫性のある運用を確保できます。
次の手順
Azure 製品 ポートフォリオ階層をサポートする方法について説明します。