做企业架构绕不开一个方法——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 用明白了。别迷信流程的完整性，关注架构决策的质量和沟通的有效性。