TOGAF ADM 方法精要：8个阶段串起企业架构全景

Thu, 18 Jun 2026 21:00:00 +0800

做企业架构绕不开一个方法——ADM（Architecture Development Method）。它是 TOGAF 框架里真正"能落地"的部分，也是全球使用最广泛的企业架构方法论。不管你是考 TOGAF 认证，还是在公司里推架构治理，ADM 都是绑在腰带上的基础工具。

很多人把 ADM 当成考试知识点背完就扔，这是最大的浪费。它的设计初衷是给架构师一套可重复、可裁剪的工作流——从愿景到变更，每个阶段该干什么、交付什么、怎么衔接，都有明确的锚点。

一张图看懂 ADM 全貌

ADM 的核心结构可以用一句话概括：一备、一中心、八步一方法。

组成部分	内容	定位
预备阶段（Preliminary）	定支持、定接受，搞定组织和治理前提	地基
需求管理（中心）	需求登记 + 能力验证，贯穿全程	心脏
A 愿景	定方向、定范围	起点
B 业务架构	看流程	骨架
C 信息系统架构	数据架构看统一 + 应用架构看交互	血管
D 技术架构	看共享	基础设施
E 机会与方案	紧迫性 × 方案成熟度	选项池
F 迁移规划	排序 + 发布节奏	路线图
G 实施治理	合规与偏差管控	护栏
H 架构变更	变更评估、触发新一轮	闭环

注意 A-D 阶段定义架构本身（“是什么”），E-H 阶段定义如何落地（“怎么做”）。前四个阶段产出基线架构和目标架构，后四个阶段把差距转化为可执行的项目。

四个架构域：各看什么？

架构域	核心关注	一句话
业务架构	流程	业务怎么跑
应用架构	交互	系统之间怎么对话
数据架构	统一	数据怎么一致
技术架构	共享	基础设施怎么复用

这四个域不是孤立的。业务架构驱动应用架构，应用架构依赖数据架构，数据架构跑在技术架构之上。自顶向下设计，自底向上验证。

逐阶段拆解

预备阶段（Preliminary）

核心任务：确认组织具备架构能力——人、流程、工具到位，治理层认可。

关键交付物：架构能力框架、架构原则、组织承诺。

❌ 跳过预备直接画架构图 ✅ 先拿到管理层签字和资源承诺，确定架构治理的边界和权责

需求管理（中心）

这不是某个阶段，而是贯穿始终的脉搏。需求为准做登记，能力导向做验证。每一轮 ADM 循环都从需求出发，以需求校验收尾。

❌ 把需求管理当成 A 阶段的子任务，做完就丢 ✅ 每个阶段都要回到需求中心做校准，确保架构演进不偏离业务诉求

阶段 A：架构愿景

核心任务：定范围、定利益相关方、拿批准。

关键交付物：架构工作请求、愿景文档、利益相关方地图、架构工作说明书。

❌ 范围太宽，想一次搞定整个集团数字化转型 ✅ 划定边界，明确"这次做什么、不做什么"，拿到关键干系人的正式签字

阶段 B：业务架构

核心任务：梳理业务流程，建立基线（当前状态）和目标（未来状态），做差距分析。

关键交付物：业务流程模型、基线/目标架构、差距分析。

差距分析 = 目标架构 − 基线架构。这是 B/C/D 三个阶段共同的输出逻辑。基线架构是现在架构的状态与内容总称，目标架构是未来架构的状态与内容总称。

❌ 只做目标架构，不画基线 ✅ 基线不清，差距就是空中楼阁；必须两条线都画清楚才能看到真实距离

阶段 C：信息系统架构

拆成两个子域：

数据架构：数据实体、数据组件、数据治理——核心是"统一"
应用架构：应用系统、交互关系——核心是"交互"

关键交付物：数据模型、应用组合目录、接口清单、数据-应用映射矩阵。

❌ 数据和应用混在一起画，分不清哪些是数据问题哪些是系统问题 ✅ 先定数据归属和数据标准，再定系统边界和集成方式

阶段 D：技术架构

核心任务：定义技术平台、共享服务、部署拓扑。

关键交付物：技术参考模型、平台服务目录、技术标准与规范。

❌ 技术选型脱离业务需求，追新不追对 ✅ 技术为业务服务，共享是关键指标；能复用的不重建，能标准化的不定制

阶段 E：机会与解决方案

核心任务：根据需求紧迫性 × 方案成熟度两个维度，筛选可行方案组合。

这是一个发散阶段。目的是产生足够多的选项，形成可比的解决方案包供后续排序。不是挑一个"最好的"，而是把牌摊开让决策者选。

❌ 只给一个"最佳方案"，没有 Plan B ✅ 至少给出 2-3 个可比的方案包，标注各自的约束和前置条件

阶段 F：迁移规划

核心任务：给定问题是排序，给定依据是发布。

优先级公式：VCR = 价值% / (成本% × Wc + 风险% × Wr)

VCR 越高，优先级越高。Wc 和 Wr 是成本和风险的权重，由组织战略决定。这个公式的价值不在于精确计算，而在于把"拍脑袋排优先级"变成"可讨论的量化框架"。

关键交付物：实施与迁移计划、优先级排序矩阵、里程碑与发布节奏。

❌ 所有项目都是"高优先级"，等于没有优先级 ✅ 用 VCR 公式量化排序，让数据说话，减少利益相关方之间的扯皮

阶段 G：实施治理

核心任务：确保实施不偏离架构设计，管控合规与偏差。

❌ 架构团队交付完文档就撤，实施团队自由发挥 ✅ 持续参与，做架构合规评审，发现偏差及时纠正或记录为架构变更

阶段 H：架构变更管理

核心任务：评估变更影响，决定是否触发新一轮 ADM。

❌ 任何变更都走完整 ADM，流程太重 ✅ 判断变更级别：小改走变更控制流程，大改才重新跑完整轮次

迭代的本质：找爹原则

ADM 不是瀑布。每个阶段的输出都可以触发回溯——发现目标架构不可行，回到 A 调整愿景；发现技术架构支撑不了业务需求，回到 B 重新审视流程。

这叫"找爹原则"：当前阶段解决不了的问题，往上游阶段去找根因。不是推倒重来，而是带着新信息回到能解决问题的层级。

场景	回溯方向	触发原因
技术方案落地不了	D → B 或 C	需求理解有误或架构过度设计
迁移成本超出预算	F → E	方案选型需要重新评估
利益相关方不买账	任意阶段 → A	愿景和范围需要重新对齐
数据标准打架	C → B	业务流程定义不清导致数据归属模糊

小组织怎么用 ADM？

不是每家公司都有百人架构团队。中小组织可以这样裁剪：

做法	说明
合并阶段	B/C/D 合为一个"解决方案架构"阶段
轻量化交付物	用一页纸架构视图替代 50 页文档
缩短轮次	一个 ADM 周期从 12 个月压缩到 3 个月甚至更短
聚焦痛点	不做全域，只针对当前最痛的问题跑一轮
重用优先	框架为通用，定制为应用，迭代为完善，重用为质保

企业架构（IT）的本质是 IT 战略减去 IT 项目之间的 gap。ADM 帮你把这个 gap 显性化、可管理。小团队不需要做全套，但需要理解这个 gap 在哪里、有多大。

ADM 是思维框架，不是流水线

把 ADM 当 checklist 逐条打勾，大概率会做出一堆没人看的文档。真正有用的做法是：用 ADM 的阶段逻辑来组织你的思考，用差距分析来对齐利益相关方的认知，用迭代机制来应对不确定性。

阶段顺序是建议，不是法律。交付物是手段，不是目的。能把架构意图传达清楚、让项目和战略对齐、让变更可控可追溯，就算把 ADM 用明白了。别迷信流程的完整性，关注架构决策的质量和沟通的有效性。

ADM on 文艺技术笔记