優先順位付けと移行戦略

移行計画の重要な要素は、優先順位付けの基準を確立することです。この演習のポイントは、アプリケーションを移行する順序を理解することです。戦略は、反復的かつ漸進的なアプローチをとって優先順位付けモデルを進化させることです。

アプリケーションの優先順位付け

評価のこの段階では、リスクが低く複雑度の低いワークロードを優先するための初期基準を確立することに重点を置いています。これらのワークロードは、パイロットアプリケーションに適しています。初期移行でリスクが低く複雑性の低いワークロードを使用すると、リスクが軽減され、チームに経験を積む機会が与えられます。これらの基準は、移行ウェーブプランを作成する際には、ビジネス推進要因に合わせて優先順位を合わせるために、今後の評価段階でさらに発展させていく予定です。

最初の基準では、依存関係が少ないアプリケーション、クラウド対応のインフラストラクチャで実行されているアプリケーション、および非本番環境から実行されるアプリケーションを優先する必要があります。例としては、依存関係が 0 ～ 3 のアプリケーションを、開発環境またはテスト環境でそのまま再ホストできる場合が挙げられます。これらの基準は、クラウド導入の成熟度や信頼度にもよりますが、パイロットアプリケーションの定義や、場合によっては第 1、第 2 の移行の波を定義するうえで有効です。

どの初期基準を使用するかの決定

最初のワークロードの優先順位付けに使用するデータポイントを 2 ～ 10 個選択します。これらのデータポイントは、アプリケーションおよびインフラストラクチャの初期インベントリから取得されます (データ収集セクションを参照)。

次に、各データポイントの可能な値ごとにスコアまたは重みを定義します。たとえば、環境属性が選択されていて、設定可能な値がプロダクション、開発、テストの場合、各値にはスコアが割り当てられ、数字が大きいほど優先度が高くなります。オプションですが、各データポイントの重要度や関連性を倍率で割り当てることをお勧めします。このオプションのステップでは、より重要な点を強調するためのより高いレベルの差別化要因となり、値へのスコアの割り当てを繰り返し行う際に基準を一致させるのに役立ちます。

移行の最初の数段階では、リスクの低いシンプルなアプリケーションを優先させるという戦略に基づいて、次の表は属性選択と値の割り当ての例を示しています。

属性 (データポイント)	設定可能な値	スコア (0-99)	重要度または関連性の倍率
環境	テスト	60	ハイ (1倍)
	開発	40
	本番稼働用	20
ビジネス重要度	低	60	ハイ (1倍)
	中	40
	高	20
規制またはコンプライアンスの枠組み	なし	60	ハイ (1倍)
	FedRAMP	10
オペレーティング・システムサポート	クラウド対応	60	中〜高 (0.8x)
	クラウドではサポートされていません	10
コンピュートインスタンスの数	1 ～ 3	60	中〜高 (0.8x)
	4-10	40
	11 個以上	20
マイグレーション戦略	リホスト	70	ミディアム (0.6x)
	プラットフォーム変更	30
	リファクタリング、または再設計	10

アプリケーション間の主な差別化要因となる属性を選択してください。そうしないと、この基準によって多くのワークロードが同じ優先度を共有することになります。モデルを適用したら、結果のランキングの上位と下を見て、同意できるかどうかを確認することをお勧めします。おおむね同意できない場合は、作業負荷のスコアリングに使用した基準を再検討してください。

ランキングを取得したら、ポートフォリオ全体のスコアの分布を確認します。スコア自体は関係ありません。重要なのはスコアの違いです。たとえば、上位の合計スコアが 8,000 で、下位スコアが 800 である場合があります。結果のスコアをヒストグラムとしてプロットすることを検討してください。そうすれば、分布が良好であることを確認できます。理想的な分散は、優先順位が非常に高いワークロードがいくつかあり、優先順位が非常に低いワークロードがいくつかあるという、標準的なベルカーブのように見えます。アプリケーションの大半は中間のどこかにあります。

最初の優先順位付けのもう1つの重要な側面は、クラウドの早期導入に関心を示す社内チームまたはビジネスユニットを参加させることです。これらは、特に初期の段階では、特定のアプリケーションを移行するためのビジネスサポートを得る上で大きな手段となる可能性があります。これが組織に当てはまる場合は、前の表にビジネスユニット属性を含めてください。アプリケーションを積極的に提案してくれるビジネスユニットに高得点を割り当てます。ビジネスユニット属性を使用すると、それらのアプリケーションをリストの一番上に表示しやすくなります。

結果のランキングに同意したら、上位5〜10件のアプリケーションを選択します。これらが最初のアプリケーション移行候補になります。3 ～ 5 件の申請を確認するようにリストを絞り込みます。これにより、詳細なアプリケーション評価を実施する際に、的を絞ったアプローチをとることができます。詳細については、「優先アプリケーション評価」を参照してください。

移行用の R タイプの決定

各アプリケーションと関連インフラストラクチャの移行戦略を決定することは、移行のスピード、コスト、およびメリットのレベルに影響します。ビジネス推進要因、技術的指針、優先順位付け基準、ビジネス戦略など、さまざまな要因をバランスよく組み合わせて戦略を決定することが重要です。

これらの要因が相反する見解を生み出すことがあります。たとえば、移行の主な推進力はイノベーションとアジリティかもしれません。同時に、コストを迅速に削減する必要があるかもしれません。対象範囲内のすべてのアプリケーションをモダナイズすることで、長期的にはコストを削減できますが、事前に多額の投資が必要になります。その場合の 1 つの方法は、再ホストやリプラットフォームなど、手間がかからない戦略を使用してアプリケーションを移行することです。これにより、短期間で迅速な効率化とコスト削減が可能になります。そして、節約した分を後の段階でアプリケーションの最新化に再投資し、さらなるコスト削減を実現します。

ただし、すべてのアプリケーションを完全に再ホストすることから始めると、モダナイゼーションの大きなメリットが遅れます。重要なのは、移行戦略のバランスをとることです。そうすることで、ビジネス戦略的なアプリケーションをモダナイゼーションの対象とし、他のアプリケーションを最初に再ホストまたは再プラットフォーム化してからモダナイズできるようにすることです。

アプリケーションの移行戦略を決定する方法は?

評価のこの段階では、移行戦略の選択を導くための初期モデルを組み込むことに重点が置かれます。初期アプリケーションの移行戦略を検証するには、モデルをビジネス推進要因と優先順位付け基準と組み合わせて使用します。デシジョンツリーのデフォルトロジックは、スコープの初期処理を決定するのに役立ちます。ツリーでは、リファクタリングや再設計などの最も複雑なアプローチは、戦略的ワークロード専用です。

この図のカスタマイズ可能なdraw.ioバージョンは、添付ファイルセクションにあります。

初期モデルの最初のステップは、ツリーの最上部にあるビジネスドライバーを、組織で定義されているもので更新することです。次に、ツリーをアプリケーション全体ではなくアプリケーションコンポーネントに適用します。たとえば、3 つのコンポーネント (フロントエンド、アプリケーション層、データベース) で構成される 3 層アプリケーションの場合、各コンポーネントは独立してツリーを移動し、特定の戦略とパターンを割り当てる必要があります。これは、特定の階層を再ホストまたはリプラットフォームして、他の層をリファクタリング（再構築）したい場合があるためです。

コンポーネントを個別に割り当てることで、関連するインフラストラクチャの移行戦略を定義できるようになります。インフラストラクチャ戦略は、サポートするアプリケーションコンポーネントと同じ戦略である場合もあれば、異なる場合もあります。たとえば、新しいオペレーティングシステムを搭載した新しい仮想マシンに再プラットフォームされるアプリケーションコンポーネントは、その再プラットフォーム戦略に従い、そのコンポーネントをホストしている現在の仮想マシンは廃止されます。インフラストラクチャの移行戦略は、アプリケーションコンポーネント用に選択された戦略に基づいて計算されます。

デシジョンツリーを使用して移行戦略を確立する前に、いくつかのアプリケーションでロジックをテストし、結果に概ね同意できるかどうかを確認してください。7 R ディシジョンツリーは、その正しさを判断するために必要な分析に代わるものではありません。ツリーロジックは特定のケースには適用されない場合があります。このようなケースは例外として扱い、ツリーロジックを変更するのではなく、オーバーライドの理論的根拠を文書化することで、ツリーによる決定をオーバーライドしてください。これにより、管理が困難になる可能性のある複数のデシジョンツリーバージョンを防ぐことができます。一般的なガイダンスでは、ツリーは少なくとも 70～ 80% のワークロードで有効である必要があります。それ以外には例外があります。評価のこの段階でツリーロジックを調整する場合は、初期モデルの確立に重点を置く必要があります。ポートフォリオ分析や移行計画など、後の段階でさらなる反復と改良が行われる予定です。

添付ファイル

attachment.zip