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

タスク 4: アプリケーションのディープダイブプロセスを定義する

アプリケーションの優先順位付けのルールとプロセスの確立が完了したら、各アプリケーションの優先順位を絞り込むのに役立つアプリケーションの詳細な説明を実行します。アプリケーションのディープダイブは、優先度が最も高いものから低いものまで、一度に 1 つのアプリケーションで実行します。複数のポートフォリオチームを持つプロジェクトの場合、各チームは異なるアプリケーションに対して同時にアプリケーションのディープダイブを実行できます。

詳細な分析中に、依存関係など、アプリケーションの移行の複雑さに影響する予期しない問題が発生する可能性があります。この場合、前のステップで定義した複雑さスコア基準を変更し、それに応じてスコアシートを更新して、将来のアプリケーションのより正確な複雑さスコアを取得する必要があります。その後、新しい複雑さスコアを使用してアプリケーションの優先順位を更新できます。

このタスクは、次のステップで構成されます。

ステップ 1: アプリケーションワークショッププロセスを定義する

ワークショッププロセスは、アプリケーションのディープダイブに対する最も効率的なアプローチの 1 つです。このプロセスを使用して、ステークホルダー、アプリケーション所有者、ポートフォリオチームと協力してアプリケーションを評価および分析します。目標は、アーキテクチャ、ビジネス目的、依存関係、環境など、アプリケーションの現在の状態を明確に把握することです。次に、アプリケーションのサイズと複雑さに関するこの詳細情報を使用して、アプリケーションのターゲット状態を設計します。

各ワークショップは通常 1～8 時間かかりますが、複雑性の高いアプリケーションにはさらに時間が必要になる場合があります。また、リソースの可用性、好み、アプリケーションのサイズと複雑さに応じて、ワークショップを複数の会議に分割することもできます。

期待される成果を特定する

アプリケーションワークショップを実施する前に、アジェンダを設定し、ワークショップの期待される成果、またはワークショップで収集する必要がある情報を定義する必要があります。これにより、ワークショップ参加者はワークショップの準備ができ、会議を目標に維持し、ワークショップの終了までに、アプリケーションの優先順位付け、ウェーブプラン、移行に必要なすべての情報を確実に取得できます。

期待される結果の標準セットを定義し、それらをアプリケーションの優先順位付けランブックに記録することをお勧めします。ワークショップを準備するときは、標準的な期待される結果を使用し、特定のアプリケーションに新しい結果を追加します。

アプリケーションワークショップで期待される成果の標準セットを次のように定義します。

以下は、アプリケーションワークショップで期待される成果の例です。

アプリケーションワークショップルールを定義する

アプリケーションワークショップを実施する前に、ワークショップを管理するルールを定義する必要があります。一般的なルールには、ワークショップの長さ、ワークショップで必要になる可能性のあるツール、考慮すべきスケジューリング上の考慮事項や期限などがあります。これにより、会議を目標に保ち、ワークショップで行われた決定が移行スケジュールに沿ったものになります。

アプリケーションワークショップルールは、アプリケーションの優先順位付けランブックに文書化することをお勧めします。

アプリケーションワークショップルールを次のように定義します。

アプリケーションワークショップのルールの例を次に示します。

アプリケーションワークショッププロセスを定義する

アプリケーションワークショップを実施するための標準プロセスを定義することが重要です。これにより、一貫したエクスペリエンスが保証され、ワークショップ参加者に期待が設定されます。これにより、ワークショップの効率が向上します。

アプリケーションワークショッププロセスには 3 つのステージがあります。

アプリケーションの優先順位付け用のランブックテンプレートには、アプリケーションワークショップの準備、実施、最終化のための標準的なstep-by-stepのプロセスが含まれています。アプリケーションワークショッププロセスを次のように定義します。

ステップ終了基準

ステップ 2: アプリケーションマッピングプロセスを定義する

アプリケーションマッピングは、各アプリケーションを移行パターンに割り当てるプロセスであり、 で特定して検証しますステップ 4: 移行パターンを検証する。このステップでは、アプリケーションの評価に使用するルールを定義します。次に、各アプリケーションの評価に使用するプロセスを定義します。各アプリケーションを移行パターンのユースケースにマッピングすることで、移行ツール、移行を完了するために必要なスキル、移行パターンの複雑さを特定できます。

必ずしもアプリケーションを 1 つのパターンに移行するわけではありません。同じアプリケーションに複数のパターンが必要な場合の詳細については、このセクションのアプリケーションマッピングプロセスを定義する後半の「」を参照してください。

アプリケーションマッピングルール

アプリケーションマッピングルールは、アプリケーションを評価し、適切な移行パターンを特定するのに役立ちます。各ルールは、アプリケーションの評価とパターンの一致基準に使用する必要がある情報で構成されます。

ポートフォリオプレイブックテンプレートでは、アプリケーションの優先順位付け用のランブックテンプレートに、アプリケーションマッピングルールを文書化するためのセクションが含まれています。プロセスを次のように定義します。

次の表に、アプリケーションマッピングルールの例を示します。

アプリケーションマッピングプロセスを定義する

アプリケーションを移行パターンにマッピングする場合、検出チームからアプリケーションの検出データをリクエストすると便利です。このデータには、通常、推奨される移行パターン (R パターンまたは R スコアと呼ばれることもあります）、使用率情報、アプリケーションの依存関係、および評価で使用できるその他の情報が含まれます。このアプリケーションを詳しく調べる際に、以前に特定した移行パターンを変更する場合があります。

データを取得したら、アプリケーションと、 で特定したビジネスおよび技術基準を比較できますステップ 2: ビジネスと技術の推進要因を特定する。アプリケーションの優先順位付けランブックにドライバーを記録しました。基準に照らしてアプリケーションを評価すると、アプリケーションの複数の移行パターンを選択したり、コスト、スケジュール、その他の制限に基づいてパターンを排除したりする可能性があります。

以下は、1 つのアプリケーションで複数の移行パターンを使用する必要があるビジネスドライバーの例です。オンプレミスの SQL Server データベースを Amazon DynamoDB に移行したいが、データセンターの契約が期限切れになるため、ビジネスは提案されたスケジュールよりも早く移行してリプラットフォームしたいと考えています。このビジネスドライバーに対処するには、アプリケーションの移行計画を 2 パターンのアプローチに修正します。まず、アプリケーションをクラウドにリホストして、データセンターから削除します。その後、アプリケーションがクラウド内にあると、提案されたスケジュールに従ってアプリケーションを再プラットフォームできます。

また、アプリケーションが複数の階層で構成されるアプリケーションである n 階層アプリケーションであるかどうかも考慮する必要があります。アプリケーション層は、アプリケーションの水平レイヤーをホストする物理サーバーのグループです。N 層アプリケーションは、各層が異なる戦略を必要とする場合があり、アプリケーション層を異なるウェーブに移行することを選択できるため、より複雑になります。たとえば、プレゼンテーション、ビジネスサービス、データベース階層で構成されるアプリケーションがある場合、階層ごとに異なるパターンをマッピングできる可能性があります。

次に、アプリケーション優先順位付けランブックで定義したアプリケーションマッピングルールに対してアプリケーションを評価します。詳細については、このセクションの前半の アプリケーションマッピングルール を参照してください。

アプリケーションを 1 つ以上のパターンにマッピングしたら、この決定を確認してアプリケーション所有者に確認します。アプリケーション所有者は選択したパターンを確認し、移行の計画と実行に役立ちます。現時点では、アプリケーション所有者は、経験に基づいてインサイトを提供したり、移行で予想される問題を共有したりすることもできます。

アプリケーションを 1 つ以上の移行パターンにマッピングし、アプリケーション所有者にパターンを確認したら、アプリケーション、パターン ID、パターン名、および関連するドライバーをアプリケーションの優先順位付けランブックのアプリケーションマッピングテーブルに記録します。

ポートフォリオプレイブックテンプレートでは、アプリケーションの優先順位付け用のランブックテンプレートに、アプリケーションマッピングの標準的なstep-by-stepプロセスが含まれています。プロセスを次のように定義します。

次の表は、アプリケーションマッピングテーブルの例です。アプリケーションの優先順位付け用に用意されているランブックテンプレートには、アプリケーションマッピングプロセスの結果を記録できる空のテーブルが含まれています。

ステップ終了基準

ステップ 3: (オプション) アプリケーションターゲットの状態を定義する

このステップでは、アプリケーションのターゲット状態または to-be 状態をドキュメント化するために使用する属性とプロセスを定義します。ターゲットの状態は、移行後のアプリケーションがターゲットクラウド環境でどのように動作するかです。ターゲット環境は、ターゲットプラットフォームまたはサービスやビジネス要件によって異なります。ターゲット環境は、 AWS クラウド または AWS Managed Services (AMS) です。

ターゲットの状態を定義すると、プロジェクトマネージャー、移行コンサルタント、アーキテクト、アプリケーション所有者、ステークホルダーが効果的にコラボレーションできるようになります。このプロセスを使用することで、チームは事前に問題を特定して解決し、ターゲット状態環境をより効率的に実装できます。

一部のアプリケーションでは、このステップはオプションです。移行するアプリケーションがスタンドアロンまたは複雑さが低い場合は、このステップをスキップできます。リホストなど、アプリケーションを変更しない移行戦略では、このステップを必要としない場合があります。ただし、リプラットフォームや再設計など、より複雑な移行戦略の場合は、移行を開始する前にターゲットの状態を定義する必要があります。

このワークショップでは、アプリケーションの現在の状態を深く理解できるため、ワークショップの完了後にターゲット状態をドラフトすることをお勧めします。さらに、アプリケーションを移行パターンにマッピングすると、追加のインサイトが得られ、ターゲット状態の定義が必要かどうかを特定できます。例えば、Application Migration Service または Cloud Migration Factory を使用してアプリケーションをAmazon EC2 Rehost にマッピングすると、戦略がリホストであることが特定され、このアプリケーションのターゲット状態を定義する必要がない可能性があります。

ターゲット状態属性

ターゲット状態を定義し、アプリケーションに関する決定を行うときは、次のターゲット状態属性を検討することをお勧めします。

ターゲット状態プロセスを定義する

アプリケーションターゲットの状態を定義するには、提供されたテンプレートであるアプリケーションターゲット状態ワークシート (Excel 形式) を使用することをお勧めします。このワークシートは、ポートフォリオプレイブックテンプレートで入手できます。テンプレートには、使用または変更できる標準属性が含まれています。アプリケーションターゲットの状態を次のように文書化するプロセスを定義します。

アプリケーションターゲットの状態のサンプル

次の表は、アプリケーションターゲット状態ワークシートを使用してアプリケーションのターゲット状態を文書化する方法の例を示しています。

ステップ終了基準

ステップ 4: アプリケーションのディープダイブプロセスを完了する

次に、ポートフォリオワークストリームが、このタスクで確立したワークショップ、ルール、プロセスを使用して、アプリケーションについて詳しく説明します。これは、ポートフォリオワークストリームが移行の実装段階で参照するプロセスです。

アプリケーション優先順位付けランブックでこのプロセスを次のようにカスタマイズします。