本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
探索加速和初始規劃
產品組合評估的這個階段會在雲端之旅的早期進行。它通常在接近執行決策時執行,將現有的應用程式產品組合移至雲端或在探索階段期間。探索加速和初始規劃階段著重於下列項目:
-
了解業務驅動因素
-
識別現有的資料來源
-
評估自動化探索工具的需求
-
建立應用程式優先順序和遷移策略選擇的基礎模型
這些活動會導致下列情況:
-
產品組合的初步分析
-
識別初始遷移候選者
-
建立用於遷移的定向商業案例
-
初始計劃的概述。
關鍵在於了解此階段的利益相關者是誰,以及他們需要哪些資料要求才能繼續進行。利益相關者範圍從董事會成員和 CxOs,到業務單位主管、資深經理和應用程式擁有者。
提示
如需詳細資訊和指引,請參閱AWS 雲端 遷移應用程式產品組合評估指南中的相關章節。
高階目標和動作
-
確定利益相關者 – 誰會受到遷移的影響? 誰是決策者? 誰會從此遷移中受益? 誰負責執行遷移?
-
識別業務驅動因素 – 由於遷移 (例如,業務轉型、成本降低、敏捷性) 而追求的業務成果和目標為何? 此資訊將是遷移策略和優先順序的關鍵決定因素。
-
識別現有的資料來源 – 識別和記錄現有的資料來源,例如人員、工具、文件。為每個來源指派信任層級。例如,程式設計或自動化來源比機構知識或文件更受信任。隨著時間的推移,低信任的資料來源將被更高信任的資料來源取代。
-
建立應用程式和基礎設施的初始清查 – 識別應用程式名稱、主要函數、重要性、IT 環境、高階合規和法規要求,以及已知的相依性。哪些 IT 資產與應用程式相關聯? 識別產品名稱和版本、歷史效能資料、已知問題和風險。
-
識別資料差距和探索需求 – 分析資料差距並評估採購自動化探索工具的需求。探索工具投資決策應該有提高資料整體可信度的必要,以便進行準確分析。為了維持應用程式產品組合up-to-date檢視,我們建議為工作負載探索使用專門的工具。
-
部署探索工具 – 在適用的情況下,採購、安裝和設定探索工具,並建立推展計劃到目標系統。所有目標系統兩週的程式設計資料收集可提供足夠的資料,以達到此階段的結果。不過,若要精簡輸出,在稍後階段需要持續收集資料。
-
收集總體擁有成本 (TCO) 資料 – 使用收集的資料來產生和更新 TCO 報告,並建立具方向性的商業案例。如需詳細資訊,請參閱最佳實務一節。
-
使用應用程式合理化模型 – 建立或採用基礎應用程式合理化模型以進行遷移。根據 6 Rs 決策樹,包含關鍵應用程式屬性、優先順序權重和初始 R 類型 (重寫、轉換、重構 (重新建構)、重新購買、保留、淘汰) 的選擇。
-
識別初始遷移候選項目 – 現在可移動哪些應用程式來建立或擴展 AWS 基礎並取得經驗? 在此階段,模型應該優先考慮具有低層級相依性的簡單工作負載 (例如零三)。
-
規劃持續評估 – 規劃下一個產品組合評估活動,例如執行優先順序工作負載的詳細評估。
-
計劃通訊 – 為您的利益相關者建立通訊計劃或節奏,以及範圍控制機制。範圍隨著遷移計畫進行而變更是正常的。確保產品組合資料有單一的事實來源,並且會追蹤、評估和傳達範圍的變更。
結果
-
記錄的業務驅動因素、成果、目標和技術指導原則。
-
應用程式和基礎設施的初始清查,以及已識別的資料差距。這是產品組合的初始檢視,這些產品組合將在後續階段中反覆運算和微調。
-
有方向性的商業案例和要遷移的估計成本。
-
三五個初始遷移候選應用程式的清單。
-
產品組合相關活動、里程碑和範圍變更的通訊計劃。
最佳實務
-
專注於階段目標,並將分析保持在高層級。採用漸進式的資料收集方法,在繼續之前,請不要等待完整的資料集。
-
避免分析癱瘓。專注於識別資料差距和驅動動作來縮小這些差距。
-
採購專門的探索工具。通常透過自動化工具取得的程式設計資料具有更高層級的信任,在撰寫文件、靜態資料和機構知識之前應優先考慮。
-
使用已識別的利益相關者來移除封鎖程式。
-
將單執行緒領導者指派給應用程式產品組合評估工作流程。
-
請考慮將 Migration Evaluator
用於定向商業案例,或探索 AWS Partner Network 工具和 TCO 和 AWS 定價方案。