本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

任務 4：定義應用程式深入探索程序

現在您已完成建立應用程式優先順序的規則和程序，您可以執行應用程式深入探索，以協助您精簡每個應用程式的優先順序。您一次對一個應用程式執行應用程式深入探索，從最高到最低的優先順序。對於具有多個產品組合團隊的專案，每個團隊可以同時對不同的應用程式執行應用程式深入探索。

在深入探討期間，您可能會遇到一些非預期的問題，例如會影響遷移應用程式的複雜性的相依性。發生這種情況時，您應該修改您在上一個步驟中定義的複雜性評分標準，並相應地更新評分表，以便為未來的應用程式取得更準確的複雜性分數。然後，您可以使用新的複雜性分數來更新應用程式優先順序。

此任務包含下列步驟：

步驟 1：定義應用程式研討會程序

研討會程序是應用程式深入探索最有效率的方法之一。使用此程序，您可以與利益相關者、應用程式擁有者和產品組合團隊合作，以評估和分析應用程式。目標是清楚地了解應用程式的目前狀態，包括其架構、業務目的、相依性和環境。然後，您可以使用有關應用程式大小和複雜性的詳細資訊來設計應用程式的目標狀態。

每個研討會通常持續 1-8 小時，雖然您可能會發現高複雜度的應用程式需要額外的時間。您也可以根據資源的可用性、您的偏好，以及應用程式的大小和複雜性，將研討會分成多個會議。

識別預期結果

在進行應用程式研討會之前，您應該設定議程並定義研討會的預期成果，或需要在研討會中收集的資訊。這可讓研討會參與者為研討會做好準備，協助將會議保持在目標上，並確保研討會結束時，您擁有排定優先順序、動盪計畫和遷移應用程式所需的所有必要資訊。

我們建議您定義一組標準預期結果，並將其記錄在應用程式的優先順序 Runbook 中。準備研討會時，您可以使用標準預期成果，並為特定應用程式新增成果。

定義應用程式研討會的標準預期結果集，如下所示：

以下是應用程式研討會預期成果的範例。

定義應用程式研討會規則

在進行應用程式研討會之前，您應該定義管理研討會的規則。常見規則包括研討會長度、研討會中可能需要的工具，以及任何需要考慮的排程考量或截止日期。這有助於讓會議保持在目標上，並確保研討會中所做的決策符合遷移排程。

我們建議您在應用程式優先順序 Runbook 中記錄應用程式研討會規則。

定義您的應用程式研討會規則，如下所示：

以下是應用程式研討會的規則範例。

定義應用程式研討會程序

請務必定義執行應用程式研討會的標準程序。這可確保一致的體驗，並為研討會參與者設定期望，這可以提高研討會的效率。

應用程式研討會程序有三個階段：

應用程式優先順序的 Runbook 範本包含準備、執行和完成應用程式研討會的標準step-by-step程序。定義您的應用程式研討會程序，如下所示：

步驟退出條件

步驟 2：定義應用程式映射程序

應用程式映射是將每個應用程式指派給您在 中識別和驗證的遷移模式的程序步驟 4：驗證遷移模式。在此步驟中，您會定義用來評估應用程式的規則。然後，定義您將用來評估每個應用程式的程序。將每個應用程式映射到遷移模式的使用案例，可協助您識別遷移工具、完成遷移所需的任何技能，以及遷移模式的複雜性。

您不一定會將應用程式遷移至單一模式。如需有關何時可能需要相同應用程式多個模式的詳細資訊，請參閱本節定義應用程式映射程序稍後的 。

應用程式映射規則

應用程式映射規則可協助您評估應用程式，並識別適當的遷移模式。每個規則都包含任何您應該用來評估應用程式的資訊，以及模式的比對條件。

在產品組合手冊範本中，應用程式優先順序的 Runbook 範本包含用於記錄應用程式映射規則的區段。定義您的程序，如下所示：

下表提供應用程式映射規則的範例。

定義應用程式映射程序

當您將應用程式映射至遷移模式時，向探索團隊請求應用程式的探索資料會很有幫助。此資料通常包含建議遷移模式 （有時稱為 R 模式或 R 分數)、使用率資訊、應用程式相依性，以及您可以在評估中使用的其他資訊等資訊。當您詳細探索此應用程式時，可能會決定變更先前識別的遷移模式。

當您擁有資料時，您可以將應用程式與您在 中識別的業務和技術條件進行比較步驟 2：識別業務和技術驅動因素。您在應用程式優先順序 Runbook 中記錄驅動程式。根據條件評估應用程式可能會導致您為應用程式選取多個遷移模式，或者可能會導致您根據成本、排程或其他限制來消除模式。

以下是商業驅動程式的範例，需要您在單一應用程式上使用多個遷移模式。您想要將現場部署 SQL Server 資料庫遷移至 Amazon DynamoDB，但由於資料中心的合約即將到期，因此企業想要比提議的排程更快地遷移該資料庫，以便進行複寫。為了解決此業務驅動因素，您將應用程式的遷移計劃修訂為兩模式方法。首先，您將應用程式重新託管到雲端，以便從資料中心將其移除。稍後，應用程式在雲端後，您可以根據提議的排程進行複寫。

您也應該考慮應用程式是否為 n 層應用程式，這是由多個層組成的應用程式。應用程式層是一組實體伺服器，可託管應用程式的水平層。N 層應用程式更為複雜，因為每個層可能需要不同的策略，而且您可以選擇在不同波浪中遷移應用程式層。例如，如果您的應用程式由簡報、商業服務和資料庫層組成，則您可能可以對應每個層的不同模式。

然後，您可以根據應用程式映射規則來評估應用程式，這是您在應用程式優先順序 Runbook 中定義的規則。如需詳細資訊，請參閱本節先前所述的應用程式映射規則。

將應用程式映射至一或多個模式後，請與應用程式擁有者檢閱並驗證此決策。應用程式擁有者應確認選取的模式，且應協助您規劃和執行遷移。目前，應用程式擁有者也可能根據他們的經驗提供洞見，或分享他們預期遷移的任何問題。

當您已將應用程式映射至一或多個遷移模式，並與應用程式擁有者確認模式時，您可以在應用程式優先順序 Runbook 中的應用程式映射資料表中記錄應用程式、模式 ID、模式名稱和相關驅動程式。

在產品組合手冊範本中，應用程式優先順序的 Runbook 範本包含應用程式映射的標準step-by-step程序。定義您的程序，如下所示：

下表是範例應用程式映射表。提供的應用程式優先順序 Runbook 範本包含空白資料表，您可以在其中記錄應用程式映射程序的結果。

步驟退出條件

步驟 3：（選用） 定義應用程式目標狀態

在此步驟中，您會定義用於記錄應用程式目標狀態或待定狀態的屬性和程序。目標狀態是應用程式在遷移後在目標雲端環境中的運作方式。目標環境會根據您的目標平台或服務與業務需求而有所不同。目標環境可以是 AWS 雲端 或 AWS Managed Services (AMS)。

定義目標狀態有助於專案經理、遷移顧問、架構師、應用程式擁有者和利益相關者有效地協作。透過使用此程序，團隊可以事先識別和解決問題，並更有效率地實作目標狀態環境。

對於某些應用程式，此步驟是選用的。如果您要遷移的應用程式是獨立或低複雜度的應用程式，您可以略過此步驟。不修改應用程式的遷移策略，例如 Rehost，可能不需要此步驟。不過，對於更複雜的遷移策略，例如 replatform 和 re-architect，您應該在開始遷移之前定義目標狀態。

研討會可讓您深入了解應用程式的目前狀態，因此最好在完成研討會後草擬目標狀態。此外，將應用程式映射至其遷移模式提供額外的洞見，並協助您識別是否需要定義目標狀態。例如，如果您使用 Application Migration Service 或 Cloud Migration Factory 將應用程式映射到模式 Rehost 到 Amazon EC2，則表示策略是 Rehost，您可能不需要定義此應用程式的目標狀態。

目標狀態屬性

定義目標狀態並對應用程式做出決策時，建議您考慮下列目標狀態屬性：

定義目標狀態程序

若要定義應用程式目標狀態，建議您使用提供的範本應用程式目標狀態工作表 (Excel 格式），其可在產品組合手冊範本中使用。範本包含您可以使用或修改的標準屬性。定義記錄應用程式目標狀態的程序，如下所示：

應用程式目標狀態的範例

下表顯示如何使用應用程式目標狀態工作表來記錄應用程式目標狀態的範例。

步驟退出條件

步驟 4：完成應用程式深入探索程序

現在，您可以定義產品組合工作流程如何使用您在此任務中建立的研討會、規則和程序，以深入了解應用程式。這是產品組合工作流程在遷移實作階段參考的程序。

在應用程式優先順序 Runbook 中自訂此程序，如下所示：