本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 任務 4：定義應用程式深入探索程序
現在您已完成建立應用程式優先順序的規則和程序，您可以執行應用程式深入探索，以協助您精簡每個應用程式的優先順序。您一次對一個應用程式執行應用程式深入探索，從最高到最低的優先順序。對於具有多個產品組合團隊的專案，每個團隊可以同時對不同的應用程式執行應用程式深入探索。
在深入探討期間，您可能會遇到一些非預期的問題，例如會影響遷移應用程式的複雜性的相依性。發生這種情況時，您應該修改您在上一個步驟中定義的複雜性評分標準，並相應地更新評分表，以便為未來的應用程式取得更準確的複雜性分數。然後，您可以使用新的複雜性分數來更新應用程式優先順序。
此任務包含下列步驟：
+ [步驟 1：定義應用程式研討會程序](#deep-dive-1)
+ [步驟 2：定義應用程式映射程序](#deep-dive-2)
+ [步驟 3：（選用） 定義應用程式目標狀態](#deep-dive-3)
+ [步驟 4：完成應用程式深入探索程序](#deep-dive-4)
## 步驟 1：定義應用程式研討會程序
研討會程序是應用程式深入探索最有效率的方法之一。使用此程序，您可以與利益相關者、應用程式擁有者和產品組合團隊合作，以評估和分析應用程式。目標是清楚地了解應用程式的目前狀態，包括其架構、業務目的、相依性和環境。然後，您可以使用有關應用程式大小和複雜性的詳細資訊來設計應用程式的目標狀態。
每個研討會通常持續 1-8 小時，雖然您可能會發現高複雜度的應用程式需要額外的時間。您也可以根據資源的可用性、您的偏好，以及應用程式的大小和複雜性，將研討會分成多個會議。
### 識別預期結果
在進行應用程式研討會之前，您應該設定議程並定義研討會的預期成果，或需要在研討會中收集的資訊。這可讓研討會參與者為研討會做好準備，協助將會議保持在目標上，並確保研討會結束時，您擁有排定優先順序、動盪計畫和遷移應用程式所需的所有必要資訊。
我們建議您定義一組標準預期結果，並將其記錄在應用程式的優先順序 Runbook 中。準備研討會時，您可以使用標準預期成果，並為特定應用程式新增成果。
定義應用程式研討會的標準預期結果集，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*應用程式研討會預期成果*區段中，為應用程式研討會建立一組標準預期成果。準備研討會時，您可以針對應用程式的特定需求自訂這些項目。
1. 儲存應用程式優先順序 Runbook。
1. 維護應用程式優先順序 Runbook 中的預期結果。當您進行應用程式研討會並繼續產品組合評估和波動規劃時，您可以識別新的預期成果或精簡現有的成果。
以下是應用程式研討會預期成果的範例。
****
| Priority | 應用程式研討會的預期成果 |
| --- | --- |
| 1 | 清楚了解應用程式目前的架構，包括相關聯的伺服器、相依性、環境和應用程式層。 |
| 2 | 團隊已收集中繼資料以支援目標架構的設計。需要下列中繼資料：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 3 | 應用程式擁有者問卷已完成，並回答所有關鍵問題。 |
| 4 | 團隊已收集所有應用程式文件，例如使用者指南、應用程式架構文件、測試文件、設計文件和應用程式設計界面 (API) 文件。 |
### 定義應用程式研討會規則
在進行應用程式研討會之前，您應該定義管理研討會的規則。常見規則包括研討會長度、研討會中可能需要的工具，以及任何需要考慮的排程考量或截止日期。這有助於讓會議保持在目標上，並確保研討會中所做的決策符合遷移排程。
我們建議您在應用程式優先順序 Runbook 中記錄應用程式研討會規則。
定義您的應用程式研討會規則，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*應用程式研討會規則*區段中，定義管理研討會的規則。
1. 儲存應用程式優先順序 Runbook。
1. 維護應用程式優先順序 Runbook 中的規則。當您進行應用程式研討會並繼續產品組合評估和波動規劃時，您可以識別新的規則或精簡現有的規則。
以下是應用程式研討會的規則範例。
****
| Priority | 研討會規則 |
| --- | --- |
| 1 | 每週二和週四的每個工作階段應排程最多 2 小時的研討會。 |
| 2 | 12 月 1 日至 1 月 15 日已排程凍結基礎設施。 |
| 3 | 遷移工具有一個實作研討會。 |
| 4 | 資料中心合約將於 3 月 31 日到期。工作負載必須在 3 月 31 日之前疏散，以避免處罰和昂貴的合約延長。 |
| 5 | 生物識別應用程式和時間和出席者應用程式將會保留。 |
### 定義應用程式研討會程序
請務必定義執行應用程式研討會的標準程序。這可確保一致的體驗，並為研討會參與者設定期望，這可以提高研討會的效率。
應用程式研討會程序有三個階段：
+ **準備研討會** – 準備研討會有助於確保工作階段順利進行，並確保參與者知道預期的內容。若要準備研討會，您可以建立議程並定義預期成果、識別研討會中所需的參與者、工具和資訊，以及安排研討會。至少提前一週排程研討會，可讓團隊有時間封鎖行事曆、準備研討會，以及收集任何有用的資訊。
+ **進行研討會** – 進行研討會時，請將討論限制在議程上的項目，並確保您符合預期的成果。請注意您認為有用的主題，但不包含在您的議程中。記錄研討會會很有幫助。
+ **完成研討會成果** - 在研討會之後，您的團隊應該清楚地了解應用程式的目前狀態，以及可能影響優先順序和遷移的潛在困擾點、風險、挑戰和阻礙因素。研討會之後的常見任務包括：重新排定應用程式的優先順序、草擬應用程式的未來狀態，以及使用在下一個研討會中可能有幫助的任何預期結果、規則或程序變更來更新 Runbook。
應用程式*優先順序的 Runbook 範本*包含準備、執行和完成應用程式研討會的標準step-by-step程序。定義您的應用程式研討會程序，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*應用程式研討會程序*區段中，修改標準程序以符合您的使用案例需求。
1. 儲存應用程式優先順序 Runbook。
1. 維護應用程式優先順序 Runbook 中的程序。當您進行應用程式研討會時，您可以識別要對此程序進行的變更。
### 步驟退出條件
+ 您已定義研討會議程，以及支援研討會所需的資源和成品。
+ 您已定義研討會的預期成果，並識別您需要在研討會中收集的資訊。
+ 您已試用研討會程序，並擁有支援應用程式映射和設計目標狀態所需的資訊。
+ 您已在應用程式優先順序 Runbook 中記錄下列項目：
+ 應用程式研討會預期成果
+ 應用程式研討會規則
+ 應用程式研討會程序
## 步驟 2：定義應用程式映射程序
*應用程式映射*是將每個應用程式指派給您在 中識別和驗證的遷移模式的程序[步驟 4：驗證遷移模式](discovery.md#discovery-4)。在此步驟中，您會定義用來評估應用程式的規則。然後，定義您將用來評估每個應用程式的程序。將每個應用程式映射到遷移模式的使用案例，可協助您識別遷移工具、完成遷移所需的任何技能，以及遷移模式的複雜性。
您不一定會將應用程式遷移至單一模式。如需有關何時可能需要相同應用程式多個模式的詳細資訊，請參閱本節[定義應用程式映射程序](#deep-dive-2-process)稍後的 。
### 應用程式映射規則
應用程式映射規則可協助您評估應用程式，並識別適當的遷移模式。每個規則都包含任何您應該用來評估應用程式的資訊，以及模式的比對條件。
在[產品組合手冊範本](samples/portfolio-playbook-templates.zip)中，*應用程式優先順序的 Runbook 範本*包含用於記錄應用程式映射規則的區段。定義您的程序，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*應用程式映射規則*區段中，定義您的應用程式映射規則。
1. 儲存應用程式優先順序 Runbook。
1. 維護應用程式優先順序 Runbook 中的規則。
下表提供應用程式映射規則的範例。
**注意**
此資料表中的模式 IDs和名稱對應至 中的範例模式[步驟 4：驗證遷移模式](discovery.md#discovery-4)。使用您在應用程式優先順序 Runbook 中定義的模式 IDs 和名稱。
****
| Priority | 映射規則 |
| --- | --- |
| 1 | 使用使用率資料或監控工具，識別應用程式是殭屍或閒置應用程式。如果應用程式是殭屍或閒置的應用程式，請選擇*模式 8：淘汰應用程式*，然後關閉應用程式堆疊中的伺服器。 |
| 2 | 識別將此應用程式遷移至雲端是否提供商業價值。僅在內部部署使用且未跨分支或地理位置共用的應用程式，例如時間和出席者應用程式，通常不需要遷移至雲端。如果遷移此應用程式不提供商業價值，請選擇*模式 9：保留在內部部署*。 |
| 3 | 識別 AWS 遷移服務 AWS、廠商或重新託管遷移工具是否支援應用程式的作業系統 (OS)，然後執行下列動作：[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 4 | 識別應用程式是否有軟體即服務 (SaaS) 版本或同等版本，然後評估移至此新平台的好處和成本。如果符合這些條件，請選擇*模式 10：重新購買並升級至 SaaS*。 |
| 5 | 識別應用程式的現場部署資料庫是否可以遷移至雲端中的同質服務，例如將現場部署 Oracle 資料庫遷移至 Amazon RDS for Oracle 或將現場部署 MySQL 資料庫遷移至 Amazon Aurora MySQL 相容版本資料庫。如果符合這些條件，請使用*模式 2：使用 AWS DMS 和 將格式複寫至 Amazon RDS AWS SCT*。 |
| 6 | 識別應用程式是否使用 Microsoft .NET Core (.NET 5 或 .NET 6)、Java、PHP 或其他開放原始碼程式設計語言，以及應用程式是否託管在 Microsoft Windows Server 中。評估轉換成本是否合理。如果符合這些條件，請選擇*模式 7：在 Amazon EC2 上從 Windows 到 Linux 的 Replatform*。 |
| 7 | 識別應用程式所依賴的內部部署本機和共用檔案儲存體，然後判斷它是否必須包含在遷移中。如果必須遷移本機和共用檔案儲存，請選擇*模式 4：使用 AWS DataSync 或 將格式轉換為 Amazon EFS AWS Transfer Family*。 |
| 8 | 識別應用程式的伺服器是大型主機還是中階伺服器，例如 IBM AS/400 或 Apache Spark，並確認應用程式與模擬器相容。如果符合這些條件，請使用*模式 6：使用模擬器將大型主機或中階伺服器轉換為 Amazon EC2*。 |
| 9 | 識別這是舊版、單體或大型主機型應用程式，因為其限制而無法再滿足業務需求。例如，識別應用程式是否可以擴展、與相關應用程式整合，還是昂貴且難以維護。如果應用程式符合任何這些條件，請選擇*模式 11：重新架構應用程式*。 |
### 定義應用程式映射程序
當您將應用程式映射至遷移模式時，向探索團隊請求應用程式的探索資料會很有幫助。此資料通常包含建議遷移模式 （有時稱為 *R 模式*或 *R 分數*)、使用率資訊、應用程式相依性，以及您可以在評估中使用的其他資訊等資訊。當您詳細探索此應用程式時，可能會決定變更先前識別的遷移模式。
當您擁有資料時，您可以將應用程式與您在 中識別的業務和技術條件進行比較[步驟 2：識別業務和技術驅動因素](discovery.md#discovery-2)。您在應用程式優先順序 Runbook 中記錄驅動程式。根據條件評估應用程式可能會導致您為應用程式選取多個遷移模式，或者可能會導致您根據成本、排程或其他限制來消除模式。
以下是商業驅動程式的範例，需要您在單一應用程式上使用多個遷移模式。您想要將現場部署 SQL Server 資料庫遷移至 Amazon DynamoDB，但由於資料中心的合約即將到期，因此企業想要比提議的排程更快地遷移該資料庫，以便進行複寫。為了解決此業務驅動因素，您將應用程式的遷移計劃修訂為兩模式方法。首先，您將應用程式重新託管到雲端，以便從資料中心將其移除。稍後，應用程式在雲端後，您可以根據提議的排程進行複寫。
您也應該考慮應用程式是否為 n 層應用程式，這是由多個層組成的應用程式。*應用程式層*是一組實體伺服器，可託管應用程式的水平層。N 層應用程式更為複雜，因為每個層可能需要不同的策略，而且您可以選擇在不同波浪中遷移應用程式層。例如，如果您的應用程式由簡報、商業服務和資料庫層組成，則您可能可以對應每個層的不同模式。
然後，您可以根據應用程式映射規則來評估應用程式，這是您在應用程式優先順序 Runbook 中定義的規則。如需詳細資訊，請參閱本節先前所述的[應用程式映射規則](#deep-dive-2-rules)。
將應用程式映射至一或多個模式後，請與應用程式擁有者檢閱並驗證此決策。應用程式擁有者應確認選取的模式，且應協助您規劃和執行遷移。目前，應用程式擁有者也可能根據他們的經驗提供洞見，或分享他們預期遷移的任何問題。
當您已將應用程式映射至一或多個遷移模式，並與應用程式擁有者確認模式時，您可以在應用程式優先順序 Runbook 中的應用程式映射資料表中記錄應用程式、模式 ID、模式名稱和相關驅動程式。
在[產品組合手冊範本](samples/portfolio-playbook-templates.zip)中，*應用程式優先順序的 Runbook 範本*包含應用程式映射的標準step-by-step程序。定義您的程序，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*應用程式研討會程序*區段中，修改標準程序以符合您的使用案例需求。
1. 儲存應用程式優先順序 Runbook。
1. 維護應用程式優先順序 Runbook 中的程序。
下表是範例應用程式映射表。*提供的應用程式優先順序 Runbook 範本*包含空白資料表，您可以在其中記錄應用程式映射程序的結果。
**注意**
此資料表中的模式 IDs 和名稱對應至 中的範例模式[步驟 4：驗證遷移模式](discovery.md#discovery-4)。使用您在應用程式優先順序 Runbook 中定義的模式 IDs 和名稱。
****
| Application name (應用程式名稱) | 模式 ID | 模式名稱 | 已解決的業務和技術驅動程式 |
| --- | --- | --- | --- |
| 公司網站 | 1 | 使用 Application Migration Service 或 Cloud Migration Factory 重新託管至 Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| HR 系統 | 8 | 淘汰應用程式 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 時間和出席者應用程式 | 9 | 保留現場部署 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| PO 系統 | 3 | 使用 將格式轉換為 Amazon EC2 CloudFormation | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| CRM 系統 | 10 | 重新購買和升級至 SaaS | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 固定資產系統 | 7 | Amazon EC2 上的從 Windows 到 Linux 的 Replatform | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| ERP 檔案儲存 | 4 | 使用 AWS DataSync 或 將格式轉換為 Amazon EFS AWS Transfer Family | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| Ledger 系統 | 6 | 使用模擬器將大型主機或中階伺服器重新託管至 Amazon EC2 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
| 一般總帳 | 11 | 重新建構應用程式 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/deep-dive.html) |
### 步驟退出條件
+ 您已在應用程式優先順序 Runbook 中記錄下列項目：
+ 應用程式映射規則
+ 應用程式映射程序
+ 您已使用一或多個proof-of-concept(POC) 應用程式來驗證映射規則和程序。
## 步驟 3：（選用） 定義應用程式目標狀態
在此步驟中，您會定義用於記錄應用程式目標狀態或*待定狀態*的屬性和程序。目標狀態是應用程式在遷移後在目標雲端環境中的運作方式。目標環境會根據您的目標平台或服務與業務需求而有所不同。目標環境可以是 AWS 雲端 或 AWS Managed Services (AMS)。
定義目標狀態有助於專案經理、遷移顧問、架構師、應用程式擁有者和利益相關者有效地協作。透過使用此程序，團隊可以事先識別和解決問題，並更有效率地實作目標狀態環境。
對於某些應用程式，此步驟是選用的。如果您要遷移的應用程式是獨立或低複雜度的應用程式，您可以略過此步驟。不修改應用程式的遷移策略，例如 Rehost，可能不需要此步驟。不過，對於更複雜的遷移策略，例如 replatform 和 re-architect，您應該在開始遷移之前定義目標狀態。
研討會可讓您深入了解應用程式的目前狀態，因此最好在完成研討會後草擬目標狀態。此外，將應用程式映射至其遷移模式提供額外的洞見，並協助您識別是否需要定義目標狀態。例如，如果您*使用 Application Migration Service 或 Cloud Migration Factory 將應用程式映射到模式 Rehost 到 Amazon EC2*，則表示策略是 Rehost，您可能不需要定義此應用程式的目標狀態。
### 目標狀態屬性
定義目標狀態並對應用程式做出決策時，建議您考慮下列目標狀態屬性：
+ **AWS Well-Architected Tool** – 根據 AWS Well-Architected Framework 檢閱應用程式目標狀態，以協助改善雲端中應用程式的安全性、效能和彈性。
+ **目標登陸區域** – 一般而言，[在調動階段](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/mobilize-phase.html)結束時，您應該已建置完整的登陸區域，準備好執行試驗應用程式。登陸區域應已設定多帳戶架構、身分和存取管理、控管、資料安全、網路設計和記錄。您可以使用試行應用程式來驗證登陸區域是否已完成。確認您可以在現有的目標登陸區域中啟動和執行試驗應用程式。如果您需要修改應用程式的登陸區域，請通知登陸區域團隊您的需求。例如，您的應用程式可能需要存取在個別帳戶中託管的服務，或者您的應用程式可能需要特殊路由到虛擬私有雲端 (VPC)。
+ **相依性** – 識別您的應用程式所依賴的任何應用程式，以正常運作。例如，您的應用程式可能依賴資料庫、儲存體或第三方服務，例如付款閘道或外部 Web 服務，或者您的應用程式可能依賴於您環境中的其他應用程式。為了存取這些相依性，您可能需要特殊的路由或組態，例如連線至目錄服務以進行身分驗證。
+ **相依的應用程式** – 識別任何依賴您應用程式的應用程式，以便正常運作。您可能需要重新設定和更新這些應用程式，以防止遷移期間停機。
+ **安全與合規** – 與安全與合規團隊一起檢閱目標環境，並找出任何差距。應用程式可能由數個元件、邏輯層或多個層組成。根據您的合規要求，您可能無法將這些元件遷移到目標環境，或在遷移工作負載時可能需要額外的安全措施。常見的安全與合規要求包括資料落地、傳輸中加密和靜態加密。這些需要目標環境中的其他組態。例如，您可能需要設定憑證以保護通訊安全，或者您可能需要加密金鑰來保護靜態資料。您可能還需要為應用程式選取多個遷移模式，以便某些應用程式層保留在內部部署，而其他層會遷移到雲端。
+ **儲存相依性** – 檢閱您的應用程式儲存相依性，並判斷將應用程式遷移至目標環境將如何影響這些相依性。例如，如果應用程式依賴網路儲存，例如網路連接儲存 (NAS) 或儲存區域網路 (SAN)，您需要規劃雲端中的儲存服務，例如 Amazon Simple Storage Service (Amazon S3) 或 Amazon FSx。您也需要規劃如何將資料遷移至目標雲端環境，以讓應用程式保持執行狀態。
+ **資料庫** – 檢閱應用程式使用之任何資料庫的遷移策略。您要轉換到新的資料庫服務，例如 Amazon Relational Database Service (Amazon RDS)、Amazon Aurora 或 Amazon DynamoDB？ 您要在目標環境中重新託管資料庫嗎？ 在某些情況下，特別是對於單體資料庫，您需要重構資料庫，以解決技術需求，例如低於一秒的延遲，或利用特定資料庫類型的功能 AWS 。如同資料駐留合規要求，您需要識別哪些資料應保留在內部部署，以及哪些應遷移至雲端。例如，您可能需要保留內部部署資料庫資料表以取得客戶資訊，而且您可以將其餘的資料庫遷移至雲端。
+ **應用程式元件** – 檢閱應用程式依賴的元件。判斷您的應用程式是否取決於目標環境不支援的元件。如果目標環境不支援所有應用程式元件，您需要重構應用程式以減輕問題。例如，如果您有依賴僅限 Windows 元件的 .NET Framework 應用程式，例如元件物件模型 (COM) Interop、COM\+ 或 Windows 登錄檔，若要在 Linux 作業系統上將應用程式重新格式化，您必須將應用程式重構為 .NET Core。
+ **應用程式層** – 識別應用程式中的層數。應用程式是 n 層、2 層還是獨立？ 確認您了解每個層的遷移模式。例如，您的應用程式可能有託管使用者介面的簡報 （或 *Web*) 層、託管商業服務的應用程式層，以及託管資料庫的資料庫層，而且每個層可能需要不同的遷移模式。
+ **災難復原** – 識別應用程式的目前和未來狀態災難復原 (DR) 計畫，包括復原點目標 (RPO) 和復原時間目標 (RTO)。決定要使用現有的現場部署 DR 計劃，還是在雲端探索新的 DR 策略。如需詳細資訊，請參閱[雲端中的災難復原選項](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)和雲端白皮書中*工作負載的災難復原 AWS：復原中的*[復原目標 (RTO 和 RPO)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html#recovery-objectives-rto-and-rpo)。
### 定義目標狀態程序
若要定義應用程式目標狀態，建議您使用提供的範本*應用程式目標狀態工作表* (Excel 格式），其可在[產品組合手冊範本](samples/portfolio-playbook-templates.zip)中使用。範本包含您可以使用或修改的標準屬性。定義記錄應用程式目標狀態的程序，如下所示：
1. 開啟*應用程式目標狀態工作表*。
1. 檢閱預設屬性，並針對您的使用案例進行任何變更。
1. 儲存工作表。
1. 開啟您的應用程式優先順序 Runbook。
1. 在*目標應用程式狀態*區段中，執行下列動作：
1. 在*何時完成此程序*區段中，建立條件，讓產品組合團隊判斷他們是否需要定義應用程式的目標狀態。
1. 視需要更新屬性區段。
1. 視需要更新使用案例的程序區段。
1. 儲存應用程式優先順序 Runbook。
#### 應用程式目標狀態的範例
下表顯示如何使用*應用程式目標狀態*工作表來記錄應用程式目標狀態的範例。
****
| 應用程式 | 範例 |
| --- | --- |
| **目標平台** | AWS 雲端 |
| **登陸區域** | 需要存取內部部署目錄服務
AWS Control Tower 需要集中管理整個組織的多個帳戶和服務 |
| **相依性** | Active Directory、付款閘道、清查系統 |
| **相依的應用程式** | 無 |
| **安全性** | 靜態和傳輸中加密 |
| **合規** | PCI、SOC |
| **儲存相依性** | 已連接的開機磁碟機、NAS、網路共享 |
| **資料庫** | 目前：Oracle 資料庫
雲端：Amazon RDS for Oracle |
| **應用程式元件** | .NET Framework 4.5 |
| **應用程式層** | N 層
前端、商業服務、資料服務和客服人員、資料庫 |
| **災難復原** | RPO：1 分鐘，RTO：5 分鐘
目前的 DR 策略為暖待命
任何美國區域的 DR |
### 步驟退出條件
+ 在*應用程式目標狀態工作表*中，您已定義要包含在目標狀態程序中的屬性。
+ 在您的應用程式優先順序 Runbook 中，您已完成下列動作：
+ 您已為預期產品組合團隊何時定義應用程式的目標狀態建立條件。
+ 您已根據使用案例更新定義目標狀態的程序。
## 步驟 4：完成應用程式深入探索程序
現在，您可以定義產品組合工作流程如何使用您在此任務中建立的研討會、規則和程序，以深入了解應用程式。這是產品組合工作流程在遷移實作階段參考的程序。
在應用程式優先順序 Runbook 中自訂此程序，如下所示：
1. 開啟您的應用程式優先順序 Runbook。
1. 在*階段 2：執行應用程式深入探討*區段中，根據您的使用案例和環境適當修改程序。
1. 儲存應用程式優先順序 Runbook。
1. 與 團隊分享您的應用程式優先順序 Runbook 以供檢閱。