ポートフォリオ階層

ワークロード、資産、およびサポート サービスの ''ポートフォリオ'' がどのように連携するかを理解するには、ポートフォリオ階層を確立する必要があります。 この記事では、ポートフォリオ階層のレベルに関する明確な定義と共に、チームが各レベルに対して予期されるものを提供するためのガイダンスを示します。 この記事全体を通して、階層の各レベルは "スコープ" とも呼ばれます。

ワークロード

定義されたビジネス価値を提供するテクノロジのコレクションは、"ワークロード" と呼ばれます。 そのコレクションには、アプリケーション、サーバー、仮想マシン、データ、デバイス、その他の同様のグループ化された資産が含まれる場合があります。 ほとんどの企業は、複数のワークロードに依存して重要なビジネス機能を提供しています。

通常、ビジネス関係者と技術リーダーは、各ワークロードの継続的なサポートに対するアカウンタビリティを共有します。 ワークロードのライフサイクルのフェーズによっては、それらのロールが明確に示されます。 ワークロードのライフサイクルのより多くの運用フェーズでは、それらのロールは共有運用管理チームまたはクラウド運用チームに移行される可能性があります。 ワークロードの数が増えるにつれて、(明示または黙示の) ロールはより複雑になり、マトリックス化されます。

ワークロードとそれをサポートする資産は、すべてのポートフォリオの中核になります。 スコープまたはレイヤーでは、それらのワークロードの表示方法と、潜在的なサポート チームのマトリックスによって影響を受ける範囲を定義します。

異なる用語が使われることがありますが、すべての IT ソリューションには資産とワークロードが含まれます。

• 資産: ワークロードやソリューションをサポートする、技術的な機能の最小単位。
• ワークロード: ビジネスに対する IT サポートの最小単位。 ワークロードはインフラストラクチャ、アプリケーション、およびデータ資産のコレクションであり、一般的なビジネス目標または一般的なビジネス プロセスの実行がサポートされます。

最初のワークロードをデプロイするときは、そのワークロードと資産のスコープだけが定義されている場合があります。 デプロイされるワークロードが増えるにつれて、他のレイヤーが明示的に定義される場合があります。

IT ポートフォリオ

企業がマトリックス型アプローチまたは集中型アプローチを通じてワークロードをサポートする場合、それらのワークロードをサポートするために、より広範な階層が存在する可能性があります。

• ランディング ゾーン: ランディング ゾーンでは、1 つまたは複数のワークロードをサポートするために必要な基本ユーティリティ、または共有プラミングがワークロードに提供されます。 ランディング ゾーンはクラウドにおいて非常に重要であるため、クラウド導入フレームワークの ''準備'' 手法全体でランディング ゾーンが重視されています。 詳細な定義については、ランディング ゾーンに関する記事を参照してください。
• 基本ユーティリティ: これらの共有 IT サービスは、テクノロジとビジネスのポートフォリオ内でワークロードが動作するために必要です。
• プラットフォーム基盤: 基本ソリューションを一元化し、すべてのランディング ゾーンに対してそれらのコントロールが強制的に適用されることを確保するための組織コンストラクトです。
• クラウド プラットフォーム: 完全なポートフォリオをサポートするための全体的な戦略によっては、複数のリージョン、ハイブリッド ソリューション、またはマルチクラウド ソリューションを管理するために、プラットフォーム基盤が個別にデプロイされた複数のクラウド プラットフォームが必要になる場合があります。
• ポートフォリオ: テクノロジの観点からは、ポートフォリオは、すべてのクラウド プラットフォームにわたるワークロード、資産、サポート リソースのコレクションです。 ビジネスの観点からは、ポートフォリオは、ビジネスの成果を促進するテクノロジ ポートフォリオをサポートおよび管理するプロジェクト、人、プロセス、投資のコレクションです。 これらの 2 つの観点を合わせて、"ポートフォリオ" をとらえることができます。

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

責任者チームがポートフォリオ階層の各レイヤーを管理します。 次の図は、責任チームと、そのビジネス上の決定、技術的な決定、技術的な実装をサポートするためのガイダンスとの対応関係を示しています。

• ポートフォリオ: クラウド戦略チームおよびクラウドのセンター オブ エクセレンス (CCoE) では、''戦略'' と ''計画'' の手法を使用して、ポートフォリオ全体に影響を与える決定がガイドされます。 クラウド戦略チームは、クラウド ポートフォリオ階層のエンタープライズ レベルについて責任を持ちます。 クラウド戦略チームはまた、環境、ランディング ゾーン、優先順位の高いワークロードに関する決定について通知を受ける必要があります。
• クラウド プラットフォーム: クラウド ガバナンス チームは、''統制'' 手法に合わせて、各環境での一貫性を保証する統制に対して責任を負います。 クラウド ガバナンス チームは、すべての環境のすべてのリソースのガバナンスに対して責任を持ちます。 クラウド ガバナンス チームは、統制ポリシーに対する例外または変更が必要になる可能性がある変更について、相談を受ける必要があります。 また、クラウド ガバナンス チームは、ワークロードと資産の導入に関する進行についての通知を受け取る必要があります。
• ランディング ゾーンとクラウド基盤: クラウド プラットフォーム チームは、導入をサポートするランディング ゾーンとプラットフォーム ユーティリティの開発に責任を持ちます。 クラウド自動化チームは、これらのランディング ゾーンとプラットフォーム ユーティリティの開発と継続的なサポートの自動化に責任を持ちます。 どちらのチームも、''準備'' 手法を使用して実装をガイドします。 どちらのチームも、ワークロードの進捗状況と、企業または環境への変更に関して、通知を受け取る必要があります。
• ワークロード: 導入はワークロード レベルで行われます。 クラウド導入チームでは、''移行'' および ''イノベーション'' 手法を使用して、導入を促進するためのスケーラブルなプロセスを確立します。 導入が完了した後、ワークロードの所有権はおそらく、''管理'' 手法を使用して運用管理をガイドするクラウド運用チームに移管されます。 どちらのチームも、Microsoft Azure Well-Architected Framework を使用して、サポート対象のワークロードに影響を与える詳細なアーキテクチャ上の決定を行う必要があります。 どちらのチームも、ランディング ゾーンと環境に対する変更に関して、通知を受ける必要があります。 どちらのチームも、ランディング ゾーンの機能に関係することがあります。
• 資産: 通常、資産はクラウド運用チームの責任です。 そのチームでは、''管理'' 手法の管理ベースラインを使用して、運用管理の決定をガイドします。 また、Azure Advisor と Azure Well-Architected Framework を使用して、運用の要件に対応するために必要なリソースとアーキテクチャに関する詳細な変更を加える必要があります。

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

• 単一の環境: 企業が必要とする環境が 1 つだけの場合は、通常、CCoE は必要ありません。
• 単一のランディング ゾーン: 環境に含まれるランディング ゾーンが 1 つだけの場合は、ガバナンスとプラットフォームの機能を 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 製品によるポートフォリオ階層のサポート方法について学習します。