翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

優先順位付けと移行戦略

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

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

この評価ステージでは、初期基準を確立して、低リスクおよび低複雑さのワークロードを優先することに重点を置いています。これらのワークロードは、パイロットアプリケーションに適しています。初期移行で低リスクで複雑さの低いワークロードを使用すると、リスクが軽減され、チームは経験を積むことができます。これらの基準は、移行ウェーブプランの作成時にビジネスの推進要因に合わせて、さらなる評価段階で進化します。

初期基準では、クラウドでサポートされているインフラストラクチャで実行され、非本番環境から実行される、少数の依存関係を持つアプリケーションを優先する必要があります。たとえば、開発環境またはテスト環境で 0～3 個の依存関係をそのままリホストできるアプリケーションです。これらの基準は、クラウド導入の成熟度と信頼度のレベルに応じて、パイロットアプリケーションと、最初と 2 番目の移行ウェーブを定義するために有効です。

使用する初期基準の決定

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

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

次の表は、最初のいくつかの移行ウェーブで低リスクのシンプルなアプリケーションを優先する戦略に基づいて、属性の選択例とその値の割り当てを示しています。

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

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

初期の優先順位付けのもう 1 つの重要な側面は、クラウドの早期導入者になることに関心を示す内部チームまたはビジネスユニットを含めることです。これらは、特に初期に特定のアプリケーションを移行するためのビジネスサポートを取得するためのかなりの手段になる可能性があります。組織でその場合は、上の表にビジネスユニット属性を含めます。アプリケーションを進んで進めるビジネスユニットに高いスコアを割り当てます。ビジネスユニット属性を使用すると、これらのアプリケーションがリストの先頭に表示されます。

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

移行用の R タイプの決定

各アプリケーションおよび関連するインフラストラクチャの移行戦略を決定することは、移行速度、コスト、および利点のレベルに影響します。ビジネスドライバー、技術指針、優先順位付け基準、ビジネス戦略など、バランスの取れた要素の組み合わせに基づいて戦略を決定することが重要です。

これらの要因によって、ビューが競合することがあります。例えば、移行の主な要因はイノベーションと俊敏性です。同時に、コストを迅速に削減する必要がある場合があります。範囲内のすべてのアプリケーションをモダナイズすると、長期的にコストを削減できますが、事前により大きな投資が必要になります。この場合、1 つのアプローチは、リホストやリプラットフォームなど、労力の少ない戦略を使用してアプリケーションを移行することです。これにより、短期間で迅速な効率とコスト削減を実現できます。次に、コスト削減を後の段階でアプリケーションのモダナイズに再投資し、さらなるコスト削減を実現します。

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

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

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

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

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

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

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

アタッチメント

attachment.zip