导读：架构变更管理（Phase F）是TOGAF中持续运行的治理流程，负责系统化地评估和审批架构变更，以确保其与战略一致并控制风险，是连接架构设计与项目落地的关键桥梁。
目录
[4.1 架构参考资料](#4.1 架构参考资料)
[4.2 非架构性输入](#4.2 非架构性输入)
[4.3 架构性输入](#4.3 架构性输入)
[6. 阶段输出](#6. 阶段输出)
[7. 架构方法](#7. 架构方法)
1、架构变更管理概述
架构变更管理是TOGAF架构开发方法（ADM）的F阶段。它不是一个一次性的项目活动，而是一个持续性的、与ADM其他所有阶段并行运行的架构治理流程。本阶段充当了架构治理与具体项目实施（Phase G）之间的核心桥梁。
其核心目的是建立一个有纪律的、系统化的机制，用于评估、审批和管理所有对架构基线提出的变更请求。通过这一过程，确保架构在实施和演进过程中始终保持其完整性、一致性，并与企业的战略目标对齐，最终实现架构的预期价值。
2、重要性与价值
有效的架构变更管理是企业架构成功的关键，其重要性与价值体现在：
-
维持架构合规性与一致性： 防止未经控制的"架构漂移"，确保实际建成的系统与已定义的目标架构保持一致。
-
实现战略对齐： 确保每一个架构变更都经过审查，能够支持并推动企业战略目标的实现。
-
主动管理风险： 通过系统化的影响分析，提前识别变更可能带来的技术、业务和运营风险，并制定缓解措施。
-
保护投资回报： 避免因随意、重复或冲突的变更造成的资源浪费，保障企业对架构的投资能够产生预期收益。
-
建立单一可信源： 通过及时更新架构库，确保其始终准确反映企业现状，为决策提供可靠依据。
3、阶段目标
主要目标包括：
-
建立一个系统化的流程来识别、评估和管理架构变更请求。
-
评估变更对基线架构、目标架构以及现有业务运营的影响。
-
根据既定的架构原则、标准和业务目标，对变更请求做出治理决策（批准、拒绝、修改等）。
-
维护和更新架构库中的架构资产，使其与批准的变更保持一致。
-
为已批准的变更提供更新的架构路线图和工作包指导。
-
确保架构治理框架得到有效执行。
4、阶段输入
4.1 架构参考资料
这些是来自架构库的通用参考资料和标准。
-
架构库： 核心输入，是所有已批准资产的知识库。
-
架构治理框架： 定义了决策权、流程、角色和职责。
-
企业连续体： 提供分类法和参考模型，帮助理解变更的影响范围。
-
架构能力标准： 包括已定义的原则、标准和合规性要求。
4.2 非架构性输入
这些输入主要来自企业内的非架构流程。
| 类别 | 序号 | 要求/评估内容 | 说明 |
|---|---|---|---|
| 架构工作或工作组的要求 | 1 | 企业组织赞助者 | 拥有足够权力和资源，并支持该架构工作的高级管理层发起人。 |
| 2 | 企业组织使命声明 | 阐述组织存在的根本目的和核心价值，为架构工作提供根本导向。 | |
| 3 | 业务目标或变化 | 架构工作旨在支持的具体、可衡量的业务目标或需要应对的业务变化。 | |
| 4 | 业务策略/计划 | 实现业务目标的详细路线图，架构设计需要与之对齐。 | |
| 5 | 时间限制 | 项目必须完成的硬性时间要求或关键里程碑。 | |
| 6 | 业务环境变化 | 来自市场、竞争、法规等外部的驱动因素。 | |
| 7 | 企业组织约束 | 内部限制因素，如组织结构、企业文化等。 | |
| 8 | 预算信息或金融约束 | 为架构工作分配的财务预算以及相关的资金限制。 | |
| 9 | 外部约束或业务约束 | 来自外部的限制，如法律法规、合规性要求。 | |
| 10 | 已有业务系统描述 | 对当前业务流程、服务和组织结构的详细记录。 | |
| 11 | 已有架构或IT系统描述 | 对当前IT环境、应用系统、数据和技术基础设施的详细盘点。 | |
| 12 | 开发组织描述 | 负责实施架构的团队或部门的结构、能力和流程。 | |
| 13 | 开发组织可用资源描述 | 具体可用的资源情况，包括人员技能、时间投入和工具。 | |
| 企业总体能力评估 | 1 | 业务能力评估 | 评估组织核心业务流程的执行效率、成熟度及其支持战略目标的能力。 |
| 2 | IT能力评估 | 评估当前IT部门的技术实力、服务交付水平、运维效率及对业务需求的响应能力。 | |
| 3 | 架构能力成熟度评估 | 使用成熟度模型评估企业架构职能本身的管理、流程和效能水平。 | |
| 4 | 业务转型准备度评估 | 评估组织文化、员工心态、领导力支持等是否准备好接受重大业务转型。 |
4.3 架构性输入
| 大类别 | 输入项名称 | 主要内容与构成 |
|---|---|---|
| 组织与框架 | 企业架构组织模型 | 企业受影响范围、成熟度评估、差距分析、解决方案方法、架构团队的角色与责任、架构工作的约束、预算需求、治理与支持策略 |
| 治理模型与框架 | 用于业务计划、企业架构、产品集合、程序设计、项目计划、系统开发、系统工程、服务运作的治理体系 | |
| 已剪裁的架构框架 | 已剪裁的架构方法、架构内容（交付件与人工产品）、配置与部署工具 | |
| 项目章程 | 架构工作声明 | 定义工作范围与方法，主要包括：声明主题、项目要求与背景、项目描述与范围、架构愿景总体描述、范围过程的特殊变化、角色责任交付、验收条件与过程、项目计划与时间表、声明批准 |
| 核心架构资产 | 架构愿景 | 规划架构阶段，主要包括：利益相关者的问题描述、有待解决的问题或场景描述、架构工作声明的目标、架构工作要求的总体描述、需求映射关系、引用架构定义文档初始版本 |
| 架构仓库 | 架构标准、可重用模块、公开可用的参考模型、特定企业组织的参考模型、企业组织标准 | |
| 架构定义文档 | 详细的基线业务架构v1.0、详细的目标业务架构v1.0、 详细的基线数据架构v1.0、详细的目标数据架构v1.0、 详细的基线应用架构v1.0、详细的目标应用架构v1.0、 详细的基线技术架构v1.0、详细的目标技术架构v1.0 | |
| 架构需求规格说明书 | 描述实现项目需要的架构内容，主要包括：成功的方法措施、架构需求、业务/应用服务约定、实现指导、实现规格说明书、实现标准、互操作性标准、IT服务管理需求、约束、假设条件、所有架构阶段的差距分析 | |
| 计划与路线图 | 架构路线图 | 列举工作项，主要包括：工作分组描述、功能需求、工作项依赖、业务价值、风险分析、架构域、解决方案、业务转型、关键措施 |
| 实现与迁移计划 | 包括高阶的实现及迁移策略 | |
| 变更与需求 | 业务变化需求 | 业务开发、业务异常、业务创新、业务技术创新、业务策略变化 |
| 技术变化需求 | 新技术报告、资产管理成本、技术更新报告、标准规范 | |
| 架构需求变更 | 架构方法、业务策略、技术栈、需求规格、利益相关者的需求、架构仓库的引用 | |
| 治理与评估 | 实现治理模型 | 治理流程、治理组织结构、治理角色与责任、治理检查点与关键条件 |
| 能力评估 | 业务能力评估以及IT能力评估 | |
| 合规性评估 | 项目进度与状态、项目架构或设计、硬件或操作系统、软件服务与中间件、应用、信息管理、安全、系统管理、系统工程、方法与工具 |
5、流程步骤
Phase F的流程是一个持续的循环，典型步骤包括：
| 步骤 | 关键活动 | 核心任务与输出描述 |
|---|---|---|
| 1. 识别变更触发事件 | 持续监控 | 主动监控内外部环境，识别引发变更的事件，例如：新业务战略、技术迭代、项目实施中的问题、法规更新等。 |
| 2. 接收与记录 | 正式登记 | 通过正式渠道（如IT服务管理工具）接收变更请求（RFC），并记录所有详细信息，确保可追溯。 |
| 3. 初步筛选与分类 | 初步评估 | 对变更请求进行快速筛选，根据预定义标准确定其优先级、紧急性、影响范围以及所需进行的分析级别（如标准流程或快速通道）。 |
| 4. 详细影响分析 | 全面评估 | 对通过筛选的变更进行多维度深入分析： - 业务影响 ： 对业务流程、战略目标和业务价值的影响。 - 架构影响 ： 对数据、应用、技术各领域组件、标准和合同的影响。 - 项目与成本影响 ： 对项目时间表、预算和资源需求的影响。 - 风险分析： 识别新风险并重新评估现有风险。 |
| 5. 治理评审与决策 | 权威决策 | 将详细的影响分析报告提交给架构委员会 （或相关治理机构）进行评审，并做出决策：批准、拒绝、有条件批准或推迟。 |
| 6. 沟通决策 | 传达结果 | 将治理决策及其理由正式、清晰地传达给所有相关方，包括变更申请人、实施团队和受影响的业务部门。 |
| 7. 更新架构资产 | 维护基线 | 如果变更被批准，则更新架构库 中所有受影响的资产，如架构定义文档、路线图等，以建立新的架构基线。 |
| 8. 监控与闭环 | 确保落实 | 与Phase G（迁移规划）紧密协作，监控 已批准变更的实施情况，确保其符合决策要求，并收集反馈以开启新的变更管理循环。 |
6. 阶段输出
| 输出项类别 | 具体输出内容 | 说明 |
|---|---|---|
| 架构资产更新 | 架构阶段的更新 | 根据变更调整架构开发方法各阶段（如B、C、D阶段）的输出文档和模型。 |
| 架构框架以及原则的更新 | 根据实践经验或新需求，对架构框架本身、架构原则进行修订和优化。 | |
| 架构标准的更新 | 更新技术标准、数据标准、安全标准等企业架构标准。 | |
| 项目章程与组织更新 | 架构工作组的声明更新 | 更新架构工作说明书，以反映变更批准后的新范围、目标或计划。 |
| 架构工作组的新要求 | 为适应变更，向架构工作组本身提出的新技能、资源或流程要求。 | |
| 合规与评估更新 | 合规性评估的更新 | 更新合规性报告，以反映架构变更后对内部标准和外部法规的遵循状况。 |
7. 架构方法
| 方法类别 | 关键要素 | 描述与示例 |
|---|---|---|
| **变化驱动方法 （按变更来源与动机）** | 业务价值驱动 | 业务开发/创新/技术革新：为开拓市场、提升竞争力而主动寻求的新能力。 策略变化：企业战略调整直接驱动的架构变革。 降本增效：以优化流程、节约成本为核心的改进。 |
| 运营与技术驱动 | 运营管理需求：为支撑日常运维而进行的基础设施更正或能力增强。 技术更新/新技术报告：采用更优、更稳定或更具成本效益的技术。 新标准规范：为满足行业、安全或合规性新要求而做出的调整。 | |
| 问题与异常驱动 | 业务异常：为解决现有业务流程中的故障、瓶颈或缺陷。 | |
| **企业架构变化管理过程 （按变更规模与处理方式）** | 简单变化 | 影响范围极小、风险低的变更。通常走快速通道，简化审批流程，快速实施。 |
| 增量变化 | 在现有架构基础上进行增加或改进。这是最常见的类型，需要通过标准变更管理流程进行评审和批准。 | |
| 重构变化 | 对架构组件进行重组或优化，但不改变其外部行为或功能。旨在提升性能、可维护性等。 | |
| 重新设计/开发架构阶段 | 涉及根本性改变的重大变更。这可能导致需要重新执行ADM的某个或多个阶段，对基线或目标架构进行重大修订。 |