导读：迁移计划是TOGAF架构开发方法（ADM）从"蓝图设计"到"实施治理"的核心桥梁。它主要对应于阶段F：迁移规划，但其基础源自阶段E：机会与解决方案的输出。本规范详细阐述了如何制定一个可行、有价值的迁移计划。
目录
[4.1 架构参考资料](#4.1 架构参考资料)
[4.2 非架构性输入](#4.2 非架构性输入)
[4.3 架构性输入](#4.3 架构性输入)
1、迁移计划概述
本阶段的核心任务是将目标架构转化为具体的实施行动。它不是一个单一的"大爆炸"式切换计划，而是一个识别并规划一系列结构化的"工作包"或"项目"的过程，这些项目将逐步、可控地实现从基线架构到目标架构的过渡。
阶段F（迁移规划）重点 ：规划怎么做（How）和何时做（When）。即基于阶段E的输出，制定详细的迁移计划，定义具体项目、优先级、依赖关系、资源需求和实施路线图。
2、重要性与价值
降低风险：通过分阶段实施，将复杂的转型分解为可管理的小步骤，降低了项目失败的风险和对业务运营的冲击。
优化投资：通过优先级排序，确保资源（资金、人力）优先投入到最具业务价值和最紧急的领域。
明确路径：为所有利益相关者（业务部门、IT团队、管理层）提供一份清晰、共识化的行动指南和时间表，统一期望，指导决策。
实现可控过渡：确保在架构迁移过程中，业务连续性得到保障，技术债务得到有效管理。
3、阶段目标
- 最终确定一套经过优先级排序的、用于实现目标架构的工作包或项目组合。
- 制定一份详细的、经批准的实施与迁移计划，该计划应包含具体的阶段划分、里程碑和交付物。
- 识别并管理项目之间的依赖关系、风险、假设和约束。
- 与组织的项目管理方法论（如PMI）进行对接，确保架构项目能够顺利启动和执行。
- 获得管理层对迁移计划和资源投入的正式批准。
4、阶段输入
4.1 架构参考资料
企业架构仓库主要存放企业所有架构相关的项目资料，其中，包括项目交付件、可重用资产、对架构工作组以及企业利益相关者的输出。
4.2 非架构性输入
| 类别 | 输入项名称 | 主要内容 / 构成要素 |
|---|---|---|
| 架构工作要求 | 业务背景与约束 | 企业组织的赞助者 企业组织使命的声明 业务目标或变化 业务策略计划 时间限制 业务环境的变化 企业组织的约束 预算信息或金融约束 外部约束或业务约束 |
| 现有环境与资源 | 已有业务系统描述 已有架构或IT系统描述 开发组织的描述 的可用资源描述 | |
| 能力评估 | 企业能力评估 | 业务能力评估 IT能力评估 架构能力成熟度评估 业务转型准备度评估 |
| 沟通计划 | 利益相关者沟通策略 | 识别确认利益相关者以及按照沟通需求分组 识别确认与架构愿景相关的关键信息 识别确认沟通机制 识别确认沟通时间 |
4.3 架构性输入
| 输入项名称 | 核心内容描述 |
|---|---|
| 企业架构组织模型 | 定义架构工作的组织环境，包括受影响范围、成熟度评估、团队角色职责、预算、约束及治理支持策略。 |
| 治理模型与框架 | 用于指导业务计划、项目开发、系统设计、服务运营等各领域活动的标准治理框架。 |
| 已剪裁的架构框架 | 根据项目具体情况定制的方法论、交付物清单（内容元模型）以及所使用的工具。 |
| 架构工作声明 | 项目的章程性文件，明确项目背景、目标、范围、愿景、计划、验收标准和各方职责。 |
| 架构愿景 | 项目初期的高层次描述，包括利益相关者关切、问题陈述、业务目标和高层次需求。 |
| 架构仓库 | 存储可重用架构资产的知识库，包括标准、参考模型和已有的架构构建块。 |
| 起草架构定义文档 | 包含基线架构与目标架构的详细描述，涵盖业务、数据、应用、技术四个架构域。 |
| 起草架构需求规格说明书 | 实现目标架构所需满足的详细需求、标准、约束、假设以及各阶段的差距分析结果。 |
| 架构路线图 | 实现目标架构的过渡计划，列出工作项、依赖关系、业务价值、风险和关键措施。 |
5、流程步骤
| 关键活动 | 描述与主要内容 |
|---|---|
| 1. 与企业治理框架协调 | 确保实施与迁移计划与组织的管理框架相协调，主要包括： • 业务计划 • 企业架构 • 项目组合管理 • 运营管理 |
| 2. 指派业务价值 | 为各工作包/项目集指派明确的业务价值，评估依据主要包括： • 绩效评估指标 • 投资回报率 (ROI) • 业务价值 • 关键成功因素 (CSF) • 效率测量 • 策略适配度 |
| 3. 估算资源与时间 | 估算项目所需的资源、时间线以及交付阶段，为项目的增量式实施提供支持。 |
| 4. 评估与确定优先级 | 通过评估收益、成本 和风险来对迁移项目进行优先级排序，确保决策者全面了解情况。 |
| 5. 确定架构路线图与更新文档 | 确定最终的架构路线图，并更新架构定义文档以反映所有相关的架构变更。 |
| 6. 完成实施与迁移计划 | 生成完整的实施与迁移计划文档，内容应包括： • 计划与管理技术 • 全部的架构变化 • 内外部依赖关系 |
| 7. 完成架构开发周期 | 完成当前的架构开发周期，为下一阶段（治理实施）做好准备，包括对架构变更的治理。 |
6、阶段输出
| 类别 | 组成部分 | 描述 |
|---|---|---|
| 1. 战略与概述 | 实现与迁移策略 | 指导整个迁移过程的高层战略、原则和方法。 |
| 与目标架构及变更架构的关系 | 阐明本计划如何实现目标架构，并描述关键的中间过渡状态。 | |
| 2. 项目分解 | 项目/产品实现的工作分解 | 将整体迁移工作分解为可管理、可执行的工作包或项目。 |
| 工作分解结构 | 以层级化形式详细展示所有任务和子任务。 | |
| 3. 评估与分析 | 业务价值 | 说明每个工作包或项目将带来的具体业务效益和投资回报。 |
| 风险分析 | 识别、评估迁移过程中的主要风险，并制定应对策略。 | |
| 资源需求与成本 | 详细列出所需的人力、技术、财务资源及总体预算。 | |
| 4. 核心架构交付物 | 已最终确定的架构定义文档 | 包含详尽的基线架构和目标架构描述的正式文档。 |
| 已最终确定的架构需求规格说明书 | 实现目标架构必须满足的功能、技术及合规性要求。 | |
| 已最终确定的架构路线图 | 显示迁移阶段、里程碑、依赖关系和时间表的可视化规划。 | |
| 5. 治理与支持 | 实现治理模型 | 在实施阶段用于监督项目、确保符合架构的治理流程和组织。 |
| 架构工作的要求 | 对执行迁移工作的团队和组织在能力、角色上的要求。 | |
| 架构能力的变化要求 | 为支持未来架构，组织需要在技能、流程上做出的变革。 | |
| 6. 资产与输入 | 可重用的架构模块 | 在迁移过程中可以被重复使用的标准解决方案或构建块。 |
| 利益迁移 | 描述如何管理过渡阶段，以平衡业务收益、成本和技术债务。 |
7、架构方法
- 增量迭代法：采用"小步快跑"的方式，通过多个迭代周期逐步实现目标架构，每个周期都交付可衡量的业务价值。
- 基于能力的规划：将迁移计划与业务能力的提升直接关联，确保技术投资直接支持业务发展。
- 差距驱动：迁移计划的核心驱动力是弥补基线架构与目标架构之间的差距。
- 协作式规划：架构师与项目经理、业务代表、运营团队紧密协作，确保计划的可行性和共识。
8、最佳实践建议
- 业务价值优先：始终将交付短期、可见的业务价值作为优先级排序的首要标准，这有助于维持项目动力和管理层支持。
- 保持灵活性和可调整性：迁移计划不是一成不变的，应将其视为"活文档"，能够根据业务环境变化、项目进展和新的发现进行调整。
- 尽早并持续沟通：路线图和计划的可视化呈现至关重要。使用清晰的图表（如甘特图、路线图）与所有利益相关者沟通，确保一致理解。
- 关注过渡架构：认识到目标架构不是一步到位的。明确规划必要的"过渡架构状态"，作为演进过程中的稳定中间形态，以管理技术债务和风险。
- 强调整治与合规：在计划中明确架构合规性检查点，确保实施项目不偏离架构蓝图，防止产生新的架构债务。