TOGAF 核心问题与应用辨析

TOGAF 的术语并不难记，困难的是把这些术语连接成一套可以解决实际问题的推理方式。只知道 ADM 有哪些阶段、四大架构域叫什么，仍然无法判断一个统一订单项目为什么失败，也无法说明库存责任应该如何迁移。

这篇文章用问题组织内容。每个回答先划清概念边界，再说明它在零售全渠道案例中的应用，并给出进一步阅读入口。问题之间不是孤立的，它们最终汇成四条主线：为什么改变、改变什么、如何到达、怎样证明。

定位与边界

1. TOGAF 到底解决什么问题？

TOGAF 解决的是企业级变化如何被描述、设计、迁移和治理。它关注的不只是一个系统是否设计合理，还关注多个业务能力、数据责任、应用、技术平台和组织是否共同到达一个目标状态。

例如统一订单项目可以在代码层面采用合理的微服务设计，但会员身份仍由三个系统维护、库存锁定仍由多个渠道修改、旧 POS 没有退出路径。系统架构可能成立，企业变化却没有完成。TOGAF 用架构愿景、4A 架构域、Gap、过渡架构和治理把这些问题放进同一条决策链。

进一步阅读：TOGAF 深度实践。

2. 企业架构与系统架构有什么区别？

系统架构在相对确定的边界内解决模块、数据、接口、性能和可靠性问题。企业架构要先决定边界本身：企业需要获得什么能力，核心事实由谁负责，哪些系统保留或退出，多个项目按什么顺序推进。

两者的关系不是高层与底层，而是问题范围不同。企业架构决定“为什么改、改哪些责任、怎样迁移”，系统架构决定“某个应用怎样实现并稳定运行”。企业架构不能替代代码和运行设计，系统架构也不能替代跨组织投资和迁移决策。

3. TOGAF 是框架、方法还是标准答案？

TOGAF 是企业架构框架，其中包含 ADM 方法、架构内容、架构仓库、参考分类和架构能力等内容。它提供一组稳定问题、概念关系和工作方式，不提供某个行业的唯一目标架构。

同样使用 TOGAF，两家零售企业可能得到不同方案：一家适合统一库存平台，另一家因为区域经营和门店自治，需要联邦式库存责任。TOGAF 要求两者都能说明驱动、原则、Target、Gap、过渡状态和治理证据，但不会规定必须使用相同系统。

4. TOGAF 会不会只适合大型组织？

跨部门、跨系统和跨年度变化越复杂，TOGAF 的价值越明显。但小型组织同样可以使用它的核心推理，只是需要裁剪工件和治理强度。

一个团队改造核心支付链路，不需要完整架构仓库和多层委员会，但仍应明确业务驱动、事实责任、质量属性、Baseline/Target/Gap、迁移与回退。裁剪的是表达规模，不是删除关键推理。

5. TOGAF 与项目管理有什么区别？

项目管理关注范围、资源、进度、成本和交付协调；企业架构关注目标状态、能力依赖、数据和应用责任、质量约束以及项目组合是否共同实现业务结果。

“库存平台三季度上线”属于项目计划；“在商品身份统一后，先用影子计算验证库存语义，再按渠道迁移唯一写入责任”属于架构迁移逻辑。两者需要衔接，但甘特图不能替代过渡架构。

ADM 与需求管理

6. ADM 为什么不是瀑布流程？

ADM 的阶段顺序表达依赖关系，不要求每个阶段只执行一次。Phase C 发现商品身份无法统一时，可能返回 Phase B 重新审视商品管理能力；Phase G 的运行证据也可能触发 Phase H，重新调整目标或原则。

更合适的理解是四次收敛：Preliminary 与 Phase A 收敛授权和范围；Phase B/C/D 收敛目标；Phase E/F 收敛迁移；Phase G/H 用实施和运行反馈校正。每次迭代都应减少某类不确定性。

进一步阅读：ADM 方法。

7. 需求管理为什么贯穿 ADM？

企业架构需求会在不同阶段被发现和修正。业务阶段形成能力要求，数据阶段发现语义和责任约束，技术阶段把业务损失转换为容量和恢复要求，实施阶段又通过真实证据检验这些要求是否合理。

需求管理的重点是追踪而不是收集。库存超卖问题应该能够追踪到库存承诺能力、锁定事实、库存应用责任、并发质量属性、Gap、工作包和超卖率指标。任何一层变化，都能找到受影响对象。

8. Preliminary 阶段有什么实际作用？

Preliminary 建立开展架构工作的组织能力，包括决策权、原则、角色、仓库、治理和例外机制。没有这些基础，每个项目都会重新讨论相同问题，并且无法要求项目提供一致证据。

零售案例中可以先确立“一个事实一个权威修改方”“渠道不复制企业级规则”“迁移必须可观测和可回退”等原则，再把它们转成数据责任矩阵、数据库权限、契约测试和旧入口退出检查。

9. Phase A 最重要的输出是什么？

Phase A 的重点不是画一张高层蓝图，而是让关键干系人对驱动、结果、范围、约束、假设和成功标准达成承诺。

“建设统一订单中心”已经预设了解法。更合格的架构问题是：“降低库存不一致和重复渠道接入成本，在不能替换全部 POS 的约束下实现跨渠道订单可见和可治理的责任迁移。”后者允许团队比较不同方案。

10. ADM 应该如何裁剪？

裁剪依据是风险、参与方数量、不可逆性和跨域影响。低风险模块改造可以只保留轻量愿景、边界决策、质量属性和上线证据；核心交易平台迁移则需要完整的业务、数据、应用、技术、过渡和恢复分析。

裁剪不是把 Phase B 或 D 从目录中删除，而是判断某类问题是否已经有可靠答案，以及需要多少证据支持决策。

四大架构域

11. 四大架构域为什么不能分别完成？

业务、数据、应用和技术架构描述同一次变化的不同视角，它们之间存在因果关系：业务结果要求能力变化，能力产生核心事实，事实责任影响应用边界，应用质量要求又推动技术机制。

如果业务架构要求统一库存承诺，数据架构必须定义实物、锁定和可售库存；应用架构必须指定库存平台为预占权威方；技术架构必须解决并发裁决、幂等、恢复和观测。四份互不关联的文档无法形成这个链路。

12. 业务能力与业务流程有什么区别？

业务能力描述企业能够做什么，例如客户识别、库存承诺和履约编排；业务流程描述不同角色如何完成一项工作。能力相对稳定，流程会随着渠道、组织和工具变化。

门店自提流程可以重新设计，POS 可以替换，但库存承诺和门店履约能力仍然存在。能力适合连接战略和投资，流程适合分析端到端执行与断点。

进一步阅读：业务架构。

13. 数据架构与数据库设计有什么区别？

数据库设计关注表、字段、索引和事务；数据架构关注企业事实的语义、身份、生命周期、Owner、权威修改方、流动、质量和安全。

同一个订单可以存在于交易库、客服读模型、搜索索引和数据仓库。数据架构不要求只存一份，但要求所有副本能追溯到权威事实，知道多久有效，并且不能绕过权威方修改核心状态。

进一步阅读：数据架构。

14. 应用架构等于微服务拆分吗？

应用架构定义应用组合、能力承载、数据责任、契约、交互和生命周期。微服务只是某些应用边界的部署实现方式。

边界尚不稳定、一个团队维护、强事务较多时，模块化单体可能更合理；业务责任稳定、需要独立扩缩容、团队和故障域明确时，独立服务才产生足够收益。TOGAF 不会直接推导服务数量。

进一步阅读：应用架构。

15. 技术架构为什么不是技术选型清单？

Redis、Kafka、Kubernetes 和数据库只是实现机制。技术架构要先回答业务场景、质量属性、容量假设、故障语义、恢复目标、安全边界和成本约束。

“每秒 2500 次下单”还要继续拆解商品浏览、库存预占、支付回调、履约创建和消息写放大。只有知道每类流量失败时允许什么结果，才能决定缓存、限流、队列、隔离和恢复机制。

进一步阅读：技术架构。

16. 如何判断应用边界是否合理？

可以同时检查六个信号：业务规则是否内聚、核心事实是否只有一个修改方、强一致范围是否清晰、变化节奏是否独立、团队责任是否匹配、故障是否能够隔离。

如果订单服务为了方便直接维护会员等级、商品主数据和库存锁定，它不是能力中心，而是责任混乱的集中点。边界合理不等于依赖少，而是依赖语义和失败责任清楚。

干系人、原则与内容资产

17. 干系人分析为什么不只是列参与人？

干系人分析需要记录关注点、影响、决策权和参与方式。门店运营关心断网经营，财务关心凭证和对账，平台团队关心容量和恢复，业务负责人关心收益与节奏。

架构师不应强迫所有人阅读同一张技术图，而要用能力图、数据责任、质量属性或迁移路线分别回答对应关注点。

进一步阅读：干系人与架构原则。

18. 什么样的架构原则才可执行？

可执行原则至少包含陈述、理由、影响、度量和例外机制。“安全优先”“高内聚低耦合”无法直接检查。

“一个事实只有一个权威修改方”会影响数据责任、应用边界、数据库权限、迁移写入范围和旧入口清退。它还能通过写入来源、重复事实和对账差异进行度量，因此可以进入项目交付。

19. Deliverable、Artifact 和 Building Block 有什么区别？

Deliverable 是正式提交和评审的工作成果，例如架构定义或迁移计划；Artifact 是目录、矩阵和图示等表达，例如能力热力图和应用-数据矩阵；Building Block 是满足一组需求、可组合复用的能力单元。

一份迁移计划可以包含多个工件，工件描述库存承诺、事件发布等构建块。三者混成一个“方案文档”后，架构资产很难追踪和复用。

20. ABB 与 SBB 为什么要区分？

Architecture Building Block 描述稳定的能力和约束，不绑定具体实现；Solution Building Block 描述用什么组件或产品实现。

“事实提交后可靠发布、可重放、可兼容演进”属于事件发布 ABB；具体消息集群、Schema Registry 和 Outbox 实现属于 SBB。区分二者后，替换产品不必改变稳定架构要求。

21. 架构仓库怎样避免变成文档仓库？

架构仓库要管理对象、关系、Owner、版本、状态、适用范围和最近验证时间，而不是只保存文件。项目需要能引用原则、标准、构建块和 ADR，运行指标也要能够更新架构状态。

“已批准”只表示决策通过，“采用中”表示项目正在使用，“已验证”表示有运行证据支持，“已弃用”则表示不再供新项目采用。没有生命周期的“最终版”很快会失效。

进一步阅读：架构内容与架构仓库。

Baseline、Target、Gap 与迁移

22. Baseline 为什么不能只看现有文档？

Baseline 描述企业实际如何运行，需要结合流程、应用目录、代码、数据库、调用链、权限、指标、对账和访谈。历史方案可能已经与现实偏离。

如果设计文档写着商城通过库存服务查询，实际调用链却显示商城仍直接读旧表，Baseline 应记录真实调用和偏差。现状不准确，Gap 和迁移风险都会被低估。

23. Target 怎样避免成为理想蓝图？

Target 要写成可验证条件，而不是“建设某中心”或“实现云原生”。例如“已迁移渠道的库存预占只由库存平台裁决，旧系统无新增锁定，超卖率和对账差异达到阈值”。

这种目标允许多个技术实现，也能明确何时真正达到目标。只有组件名称的目标图无法证明企业状态已经变化。

24. 什么样的 Gap 才能进入实施？

可执行 Gap 应包含 Baseline、Target、具体变化、Owner、依赖、风险、退出条件和证据。Gap 可以是新增、改变、保留、删除、合并或迁移期间临时存在的内容。

“建设库存平台”不是 Gap；“指定渠道库存预占改由库存平台裁决，迁移状态、收回旧写权限并停用旧任务”才是可以排序和关闭的变化对象。

进一步阅读：Baseline、Target 与 Gap。

25. Target Architecture 与 Transition Architecture 有什么区别？

Target 描述最终状态，Transition 描述到达目标之前某一阶段如何稳定运行。过渡状态仍然必须完整说明业务、数据、应用、技术和责任。

例如 T2 阶段可以规定商城由新库存平台负责预占，未迁移门店仍由 POS 负责。多个权威方可以暂时共存，但范围必须互斥，不能在同一渠道和商品上同时写入。

26. Work Package 与项目、服务有什么区别？

Work Package 围绕可验证业务结果组合跨域 Gap，可能包含流程、数据、应用、技术和组织变化。项目是资源和交付管理单元，服务是软件部署或责任单元。

“库存承诺工作包”不仅包括库存服务，还包括商品映射、业务规则、渠道改造、对账、异常处理、Owner 和旧入口退出。只有服务上线，能力并没有完整形成。

27. 迁移路线与项目排期有什么区别？

迁移路线先表达能力增量、过渡状态、依赖、收益和风险，再映射到日期和资源。项目排期主要表达任务何时由谁完成。

商品身份和地点映射是库存可视的前提，库存可视和差异解释又是库存承诺接管的前提。这种因果关系不能只用季度顺序替代。

进一步阅读：过渡架构与迁移规划。

治理与工程协同

28. 架构治理是否等于架构评审？

评审只是治理的一部分。架构治理还包括原则和标准、决策权、ADR、契约检查、例外、债务、运行指标、遗留退出和 Phase H 反馈。

真正有效的治理会把原则转成数据库权限、Schema 兼容检查、契约测试、迁移对账和 SLO，而不是只在上线前审核一张架构图。

进一步阅读：架构治理。

29. 临时例外应该怎样管理？

例外需要记录偏离的原则、业务理由、影响范围、风险、补偿、Owner、到期日和退出证据。它是一项受控风险决策，不是口头同意。

营销系统可以在特定活动期间读取会员等级快照，但应只读、定期对账、记录来源版本，并在活动结束后删除临时字段和任务。没有退出条件的临时方案，会成为新的长期架构。

30. TOGAF 如何与 DDD、敏捷和 DevOps 协同？

TOGAF 决定为什么变化、改变哪些能力和责任、如何迁移与治理；DDD 发现业务语言、模型和边界；敏捷把能力增量拆成可交付反馈；DevOps/SRE 用自动化交付、SLO、演练和运行数据验证架构。

这些方法工作在不同层次。TOGAF 不直接设计聚合根，DDD 不负责企业投资组合，DevOps 也不会自动确定数据 Owner。把它们串起来，才能从战略目标追踪到代码和运行指标。

应用检查

理解这些问题后，可以用一条业务驱动检查整套架构是否贯通：

降低库存不一致造成的超卖
  -> 库存承诺能力
  -> 锁定库存事实及其 Owner
  -> 库存平台应用责任
  -> 并发、幂等、恢复质量属性
  -> Baseline / Target / Gap
  -> 库存承诺工作包
  -> 影子、局部接管、扩大接管
  -> 超卖率、锁定超时、对账差异、旧入口流量

如果某个技术组件无法回到业务驱动或架构要求，它可能只是偏好；如果某个业务目标没有对应的 Gap、工作包和运行指标，它仍然只是口号；如果新系统上线后旧责任没有退出，企业还没有真正到达 Target。

达成标志

• 能区分企业架构、系统架构和项目管理解决的问题。
• 能把 ADM 解释为收敛和反馈，而不是阶段背诵。
• 能从业务能力推导数据责任、应用边界和质量属性。
• 能写出可验证的 Target 和可执行的 Gap。
• 能用 Transition Architecture 说明新旧系统共存时的责任。
• 能区分交付物、工件、ABB、SBB 和架构仓库资产。
• 能把原则转成设计、测试、发布和运行证据。
• 能从业务驱动一路追踪到迁移工作包和运行指标。

总结

TOGAF 的核心问题可以归结为四类：企业为什么改变，目标状态由哪些能力和责任构成，现状如何经过可运行的过渡状态到达目标，以及什么证据能够证明变化真正发生。术语只有进入这条推理链才有意义。掌握 TOGAF 不是记住更多名称，而是能够在复杂组织中持续建立可解释、可实施、可验证的架构决策。