View a markdown version of this page

ポートフォリオ分析と移行計画 - AWS 規範ガイダンス

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

ポートフォリオ分析と移行計画

このステージでは、ポートフォリオレベルのビューを反復処理し、データギャップを埋め、より多くのデータを取得して、ポートフォリオ全体の信頼性の高い移行ウェーブプランを作成することに重点を置いています。 

このステージのステークホルダーは通常、前の 2 つのステージの組み合わせです。これには、CxOs とシニアリーダー、移行チームとプラットフォームチーム、IT アーキテクトとエンタープライズアーキテクトが含まれます。重要なのは、反復と改良を通じてポートフォリオレベルのデータ忠実度を高めることです。

ヒント

詳細とガイダンスについては、「移行用 AWS クラウド アプリケーションポートフォリオ評価ガイド」の関連するセクションを参照してください。

高レベルの目標とアクション

  • アプリケーションポートフォリオと関連インフラストラクチャのベースラインを確立する – ポートフォリオレベルのデータを反復し、検出の加速と初期計画の段階から構築して、ギャップを埋め、アプリケーションポートフォリオ全体の大まかなビューを生成します。この段階では、application-to-infrastructureへのマッピング、使用状況データ、アプリケーションメタデータ属性を絞り込むことが重要です。これらの属性には、所有権、重要度、各アプリケーションのプライマリ関数が含まれます。

  • 依存関係データを取得して分析する (通常は特殊な検出ツールを使用) – アプリケーションを検証し、移行ウェーブプランの作成を支援するには、この段階で信頼性の高いアプリケーション依存データが重要です。依存関係データには、システム間の通信の量や頻度などの通信データや、運用上の考慮事項などの非技術的な依存関係が含まれます。これらの依存関係によって、同時に移動する必要があるアプリケーションと、異なる場所から操作できるアプリケーションが決まります。

  • コンプライアンスと規制要件を特定して検証する – フレームワーク、ルール、証拠、およびドキュメントの要件を特定して検証します。 

  • 仮定を事実に変換する - 前の段階でどのくらい引き受けられたか。この段階では、前提条件の数を最小限に抑えることが重要です。

  • 移行ポートフォリオ合理化モデルのベースラインを確立する – 以前のステージ (アプリケーションの優先順位付け基準や 6 Rs 決定ツリーなど) からモデルを反復処理します。モデルをアプリケーションポートフォリオ全体に適用して検証します。

  • 測定可能なビジネス成果を文書化する – 移行の波をビジネス目標に合わせるには、各移行ウェーブのビジネス成果と関連する主要主要指標 (KPI) を特定します。

  • 方向性のあるビジネスケースの進化 – ベンチマークを実際の使用率とコストデータに置き換え、更新されたウェーブプランに合わせて移行コストを絞り込みます。コスト削減、IT 生産性の向上、耐障害性の向上、俊敏性の向上など、期待される各ビジネス成果から期待される価値をすべて含めるようにカバレッジを拡大します。

  • 重要な日付を文書化して伝達する – 魅力的なイベント (データセンターの終了日、契約、ライセンス契約の更新など)、アプリケーションのリリースサイクル、回避すべき移行日、テクノロジーの更新サイクル、人員の可用性を文書化して伝達します。

  • ウェーブプランニングのコストとリスクを分析する — どの程度の並列変更をサポートまたは許容できますか? 人材の要件、リスクの特定と軽減、重要度、影響を分析します。

  • スキル要件の特定 — クラウド内のさまざまなワークロードタイプをサポートする準備状況の予測レベルを教えてください。移行ウェーブプランは、予想される準備状況と一致していますか? サポートチームはウェーブプランの要件を満たすことができますか?

  • 内部プロセスを文書化する – 変更管理、サービス管理、アーキテクチャレビューボード、リスク評価、承認ワークフローなど、クラウド移行に影響する現在のプロセスに関する情報を文書化します。

  • 移行ウェーブプランを作成する – ウェーブプランを作成するには、このリストで前述したすべての要素を組み合わせます。ポートフォリオに優先順位基準を適用し、依存関係を分析してアプリケーションの波を作成します。プラットフォームと移行準備を移行ウェーブプランに組み込みます。 AWS インフラストラクチャとサービスの実装にはどのくらいの時間がかかりますか? セキュリティと運用の準備には何が必要ですか? ウェーブ期間にはどのような影響がありますか? 移行ツールの実装にはどのくらいの時間がかかりますか? ネットワークとシステムの使用状況を考慮して、データのレプリケートにはどのくらいの時間がかかりますか? カットオーバーウィンドウとは ロールバックにはどのくらいの時間がかかりますか?

  • ワークストリームの更新 – ポートフォリオと詳細なアプリケーション評価データを移行およびランディングゾーンのワークストリームにフィードするプロセスを確立します。これらのワークストリームがデータ要件を明確に概説していることを確認します。

結果

  • 忠実度の高いアプリケーションとインフラストラクチャのインベントリ

  • 各アプリケーションの高レベルの移行戦略

  • 詳細なビジネスケース

  • 信頼性の高い移行ウェーブプラン

ベストプラクティス

  • 移行ウェーブプランでアプリケーションが均等に分散されていることを確認します。ブロッカーを作成したり、移行を遅らせたりする可能性のある複雑さを避けるため、重要度と複雑さを考慮してください。

  • 最初の 2 つのウェーブでは、重要でないシンプルなアプリケーションを優先します。

  • 優先順位、依存関係、ビジネス推進要因を組み合わせて、ウェーブプランを反復することに焦点を当てます。

  • ウェーブプランを作成するときは、クラウドインフラストラクチャ、セキュリティ、運用準備状況 (スキルを含む) を考慮します。

  • 通常 4~8 週間の移行ウェーブの長さがアプリケーションジャーニーの概要になるようにウェーブプランを作成します。各ウェーブは以下をカバーする必要があります。

    • 詳細な評価

    • 移行の準備状況

    • インフラストラクチャの構築とテスト

    • データ転送

    • ウェーブ内のアプリケーションのカットオーバー

    • ウェーブクロージャ (学習した教訓、移行後の問題の解決など)

デフォルトのウェーブ構造を定義して使用し、詳細な評価、設計、実装、テスト、カットオーバー、検証を含む移行ファクトリモデル を適用します。