架构开发方法（ADM）：把不确定性变成可治理的变化

一家零售企业准备建设统一订单中心。业务负责人期待半年上线，技术团队已经开始讨论微服务、消息队列和数据库拆分，但三个问题没有答案：门店 POS 是否在本轮替换，库存锁定究竟由订单还是库存系统负责，统一订单首先服务客户查单还是财务对账。

这时直接进入系统设计，团队只能把尚未解决的企业问题编码进新系统。ADM 的作用不是替团队选择技术，而是把“为什么改变、改变什么、如何到达、如何证明”组织成连续决策，让不确定性在投资和实现之前逐步暴露。

ADM 管理的不是文档顺序

ADM 包含 Preliminary、Phase A 到 H，以及贯穿全程的需求管理。阶段名称看起来像项目流程，但它真正管理的是四次收敛：

收敛范围	需要回答的问题	决策结果
架构授权	为什么现在必须改变，谁有权做决定	范围、原则、干系人承诺和架构工作说明
目标定义	业务、数据、应用和技术分别需要达到什么状态	Baseline、Target、Gap 和关键架构决策
迁移设计	哪些差距组合成工作包，依赖和收益如何排序	过渡架构、迁移路线和投资组合
实施反馈	项目是否遵循架构，运行结果是否支持原假设	一致性证据、例外、变更请求和下一轮输入

如果把 ADM 当成文档清单，每个阶段都会产出一份材料，项目仍然可能彼此矛盾。如果把它当成控制回路，每个阶段都必须减少某类不确定性，并为下一项决策提供证据。

Preliminary：先建立决策能力

Preliminary 阶段不是为某个项目画图，而是建立组织长期开展架构工作的条件。它通常要明确：

• 哪些决策由企业级架构委员会处理，哪些下放给领域或项目团队。
• 业务、数据、应用、技术和安全架构分别由谁负责。
• 架构原则如何定义、发布、检查和修订。
• 架构资产存放在哪里，如何维护版本与适用范围。
• 方案评审、例外处理和遗留退出如何进入交付流程。

零售案例中可以先确立四条可执行原则：核心业务事实只有一个权威修改方；渠道应用不复制企业级规则；迁移过程必须可观测、可对账、可回退；临时例外必须有负责人、到期日和退出条件。

原则不能停留在口号。以“一个事实一个权威修改方”为例，它的直接影响包括禁止多个服务写同一业务表、要求数据责任矩阵、要求迁移阶段声明写入权威方，并在上线前检查旧入口是否仍有新增流量。

Phase A：把方案要求还原成架构问题

“建设统一订单中心”已经预设了解法。Phase A 需要退一步，把它还原成业务驱动、预期结果、约束和范围。

类型	示例	需要验证的内容
业务驱动	客户需要跨渠道查单和售后	跨渠道订单可见率、售后处理时长
运营问题	库存不一致造成超卖和人工调账	超卖率、缺货取消率、调账工时
技术约束	POS 与 WMS 无法在本轮全部替换	需要保留的协议、数据和运行责任
合规约束	支付和订单状态必须可审计	审计字段、保存期限和访问控制
投资约束	十二个月内分阶段交付收益	每个阶段可独立验证的业务结果

Phase A 的关键产物不是精美愿景图，而是各方对以下内容达成承诺：本轮架构工作的边界是什么，哪些问题明确不处理，成功如何度量，哪些假设需要后续验证，以及谁能批准重大取舍。

Phase B：先决定企业需要具备什么能力

业务架构不从现有系统清单出发，而从业务结果、价值流和能力出发。对于全渠道零售，团队可能识别出客户识别、商品管理、库存可视、库存承诺、订单管理、履约编排和售后服务等能力。

这里最重要的决策不是给能力起名，而是判断：

• 哪些能力直接影响本轮业务结果。
• 哪些能力是其他变化的基础依赖。
• 当前能力缺口来自流程、组织、数据还是系统。
• 目标能力由哪个业务负责人承担结果责任。

如果商品身份和库存语义尚未统一，“统一订单”就依赖两个未解决的基础问题。Phase B 会改变项目顺序：先统一关键身份和库存视图，再迁移库存承诺，最后逐步统一订单状态。

Phase C：把能力落到事实和应用责任

Phase C 包含数据架构和应用架构。数据架构先回答企业的核心事实是什么、由谁定义和修改；应用架构再回答哪些系统承担这些责任，以及系统如何协作。

以库存为例，Phase C 需要区分实物库存、冻结库存、安全库存、锁定库存和可售库存。它还要明确：

• WMS 和 POS 分别对哪些地点的实物库存负责。
• 库存平台是否拥有预占、释放和确认的最终裁决权。
• 订单管理是否只记录库存预占结果，而不直接修改库存。
• 渠道看到的是实时权威数据，还是带有时效预算的读模型。
• 旧系统的库存标识如何映射到企业 SKU 和地点标识。

只有事实责任稳定后，系统边界才有依据。否则所谓的订单中心或库存中心只是新的代码容器。

Phase D：从业务损失推导技术要求

技术架构不是列出 Kubernetes、Kafka、Redis 和 MySQL。Phase D 应把业务场景翻译成可验证的质量属性。

业务场景	架构要求	技术决策方向	验证证据
大促每秒 2500 次下单	核心链路在目标时延内稳定完成	容量模型、入口保护、热点隔离	分层压测、容量拐点
同一库存单元并发预占	不得超额承诺	单一写入责任、原子条件更新或串行化	并发冲突测试、库存对账
支付回调重复或乱序	不能重复入账或逆向跳转	幂等键、状态机约束、持久化事件	重放与故障注入
依赖短时不可用	已确认交易不能丢失	超时、隔离、本地消息、补偿	断网和依赖中断演练
核心数据恢复	满足明确的 RPO 与 RTO	备份、日志归档、恢复顺序	定期恢复演练

技术方案必须能回到业务损失和架构要求。无法追溯到需求或约束的组件，可能只是团队偏好。

Phase E：把 Gap 组合成可交付变化

从 Baseline 到 Target 往往会得到几十个 Gap。Phase E 不是把每个 Gap 建成一个项目，而是把相互依赖的业务、数据、应用、技术和组织变化组合成工作包。

例如“统一库存承诺”工作包可能同时包含：

• 统一企业 SKU 与地点标识。
• 定义锁定、释放、确认和过期规则。
• 建设库存预占接口与事件。
• 改造商城和指定门店渠道。
• 建立库存差异对账和异常处理流程。
• 明确库存产品 Owner、值班和审计责任。

只交付一个库存服务，并不能证明能力已经形成。工作包的边界应围绕可验证的业务结果，而不是围绕代码仓库。

Phase F：路线图表达依赖与收益

迁移路线不是把项目按季度排成甘特图。它要表达能力增量、过渡架构、依赖、收益节点和风险。

一个可行顺序可能是：

1. 建立商品和地点映射，形成跨系统对账基础。
2. 建设只读库存视图，通过影子计算校准语义和规则。
3. 选择一个线上渠道，由库存平台接管预占和释放。
4. 扩大到更多渠道与门店，清退旧写入口。
5. 在库存责任稳定后统一订单状态和履约编排。

每一步都对应一个过渡架构，并且具备独立的进入条件、退出条件和回退方案。路线图因此能够回答“为什么不能先做后面的项目”，而不只是展示日期。

Phase G：用交付证据检查一致性

实施治理不是在上线前召开一次评审会。架构约束应转成项目全过程中的证据：

决策	项目证据
库存平台是预占权威方	调用链、数据库写入来源、旧入口流量
事件必须兼容演进	Schema 兼容检查、消费者契约测试
交易状态可审计	状态变更日志、业务凭证和访问审计
迁移必须可回退	切换清单、回退演练和数据追平方案
核心链路满足质量属性	压测、故障注入、恢复演练和 SLO

架构一致性不是“代码与蓝图长得一样”，而是关键责任、约束和质量目标在实现中仍然成立。

Phase H：运行结果可以推翻原假设

新架构上线后，运行证据可能表明原来的判断并不成立。例如库存平台能够处理预占，但 WMS 的批量更新导致可售库存长期过期；门店自提量低于预期，却增加了大量门店操作成本；订单统一后，客服瓶颈转移到退款和逆向履约。

Phase H 需要判断这些变化属于哪一类：

• 项目实现偏离了目标，需要纠正。
• 原有架构要求不完整，需要补充。
• 业务环境发生变化，需要启动新的架构工作。
• 某项能力已经稳定，可以降低治理强度。

这使 ADM 形成反馈，而不是在目标架构发布后结束。

需求管理：让一条要求贯穿全程

需求管理的重点是追踪，而不是维护一张不断增长的列表。以库存超卖为例，可以形成一条完整链路：

业务驱动 DRV-INV-01
  -> 业务能力 CAP-INVENTORY-COMMITMENT
  -> 数据责任 DATA-RESERVATION
  -> 应用责任 APP-INVENTORY
  -> 质量属性 NFR-NO-OVERSELL
  -> Gap GAP-INV-03
  -> 工作包 WP-INVENTORY-COMMITMENT
  -> 过渡架构 TA-INV-02
  -> 运行证据 EVD-OVERSELL-RATE

链路中的任何变化都能定位影响。如果业务接受特定商品有限度超卖，库存规则、应用状态、告警阈值和业务指标都要一起调整，而不是只修改一个接口参数。

如何裁剪 ADM

裁剪不等于删除阶段名称，而是根据风险决定需要保留多少证据。

变化类型	建议做法
单团队、低风险模块改造	轻量愿景、边界决策、质量属性和上线证据
跨两个领域的系统重构	完整能力、数据责任、应用边界和过渡方案
核心交易平台迁移	全域 Baseline/Target/Gap、迁移路线、治理与恢复演练
法规或并购驱动变化	强化干系人、数据、合规、组织和遗留退出分析

是否需要更多工件，取决于决策代价、参与方数量、不可逆性和运行风险。复杂项目压缩文档没有问题，但不能压缩关键推理。

常见失效方式

• 从 Phase C 或 D 开始，技术方案先于业务与数据责任。
• 每个阶段都完成了文档，但没有可追踪的决策与退出条件。
• Target 描述理想状态，Baseline 只列系统名称，二者无法比较。
• 工作包按系统或团队切分，不能独立产生业务结果。
• 把上线当成完成，没有清退旧责任和验证收益。
• 把例外当成口头同意，没有到期日和补偿措施。

能力验证

• 能把“建设某平台”的要求还原成驱动、结果、约束和范围。
• 能解释每个 ADM 阶段减少了哪类不确定性。
• 能让业务能力、数据责任、应用边界和质量属性相互追踪。
• 能把 Gap 组合成工作包与过渡架构，而不是服务开发清单。
• 能用交付和运行证据判断架构是否成立。
• 能依据风险裁剪 ADM，同时保留关键决策链。

总结

ADM 的核心不是依次走完 A 到 H，而是持续缩小“企业想改变什么”和“项目实际改变了什么”之间的偏差。它从架构授权开始，经过目标定义和迁移设计，把架构要求带入交付，再让运行证据回到下一轮决策。理解这条控制回路，才可能把 TOGAF 从方法名称变成实际工作方式。