从"一本厚书"到"模块化标准"：TOGAF 为何必须升级

有句话说，“唯一不变的就是变化本身。“这句话放在企业架构领域再合适不过。

TOGAF（The Open Group Architecture Framework）作为全球应用最广泛的企业架构方法论，自 2011 年发布 9.0 版以来，经历了 9.1、9.2 两个小版本迭代。但本质上，9.x 系列仍然是一个巨大的单体文档——从 ADM 方法论到内容框架、从治理到参考模型，全部塞进一部近千页的标准里。这种做法在技术变化较慢的年代尚能维持，但到了云原生、微服务、DevOps 和数字化转型全面铺开的今天，问题就变得尖锐起来：

• 更新周期过长：任何一处修改都要走漫长的共识审批流程，跟不上行业实践的演进速度。
• 适应性不足：面对数字企业、敏捷交付、初创公司等不同场景，9.2 版只能靠"裁剪指南"做有限适配。
• 生态融合欠缺：与同一组织旗下的 DPBoK（Digital Practitioner Body of Knowledge）、O-AA（Open Agile Architecture）等标准之间缺少显式桥接。

2022 年 4 月，The Open Group 正式发布了 TOGAF Standard 第10版（以下简称 TOGAF 10），以及配套的数十份 Series Guides。这不是一次简单的版本号升级，而是一次结构性重构。下面，我们从五个关键维度逐一对比 TOGAF 10 与 9.2 版的核心差异，并给出面向已认证架构师的升级建议。

变化一：模块化结构重构——从"单体巨著"到"核心+指南"双轨制

9.2 版的问题

在 9.2 版中，所有内容——ADM 方法论、内容框架、企业连续统、参考模型、治理框架——都封装在一部标准文档中。好处是"一站式查阅”，坏处是牵一发而动全身：想要更新某个实践指南，必须启动整个标准的修订流程。

TOGAF 10 的做法

TOGAF 10 将标准拆分为两个层次：

官方文档原文如此描述：“The TOGAF Series Guides are expected to be the most rapidly developing part of the TOGAF Standard and are positioned as the guidance part of the standard. While the TOGAF Fundamental Content is expected to be long-lived and stable, guidance on the use of the TOGAF Standard can be industry, architectural style, purpose, and problem-specific.”

这意味着什么？想象一下，你正在做一家传统制造业的云迁移架构。在 9.2 时代，你需要在标准文档中反复查找、裁剪、组合适用内容。而在 TOGAF 10 下，核心方法论不变，但你可以直接拿到一份专门讲"云环境下的 TOGAF 应用"的 Series Guide，它由领域专家编写，更新频率远高于核心标准。

对架构师的实际影响

• 学习成本降低：新手只需掌握 Fundamental Content 即可入门，不需要啃完全部文档。
• 实践指导更精准：不同行业、不同成熟度的组织，可以找到匹配的 Series Guide。
• 知识更新更及时：Series Guides 可以单独发布和修订，不再受核心标准的发版周期约束。

变化二：数字企业融合——与 DPBoK 标准的显式整合

9.2 版的盲区

TOGAF 9.2 诞生于"企业 IT 规划"为主流的年代，它默认的组织形态是有一定规模、有正式 IT 部门、有架构评审委员会的成熟企业。对于初创公司、数字原生团队、以及正在从单体走向平台化的组织，9.2 版几乎没有给出差异化的指导。

TOGAF 10 的突破

TOGAF 10 通过一份名为 “Using the TOGAF Standard in the Digital Enterprise” 的 Series Guide（编号 G217e），将 DPBoK Standard 的四个组织演化语境显式引入 TOGAF 体系：

有人提出过一个形象的比喻：9.2 版像一本为"大型交响乐团"写的乐谱，而 TOGAF 10 则同时考虑了"独奏者"“室内乐队"“多个乐队联合演出"和"交响乐团"四种场景，并为每种场景提供了量身定制的演奏指南。

“Peek-Ahead"策略

TOGAF 10 在数字企业语境下引入了一个重要的架构策略——“Peek-Ahead”（前瞻策略）。核心思想是：

在当前语境中提供"刚好够用"的架构支持，同时向前看，确保今天的决策不会阻碍组织顺利过渡到下一个更成熟的语境。

举个例子：一个三人创业团队（Context I）不需要完整的企业架构文档，但架构师（哪怕这个角色由创始人兼任）需要考虑：如果产品成功了，团队从 3 人增长到 30 人（Context II），当前的技术选型和数据结构是否还能支撑？这就是"Peek-Ahead"的价值——用最小的架构成本避免未来的致命返工。

变化三：敏捷原生支持——从"兼容态度"到"一等公民”

9.2 版的立场

TOGAF 9.2 对敏捷的态度可以概括为"不反对，但也不主动拥抱”。标准中提到 ADM 支持迭代，也给出了迭代指导，但具体如何将 ADM 与 Sprint、Scrum、Kanban 结合，基本留给实践者自行摸索。DevOps、CI/CD、DevSecOps 这些在 2011-2018 年间蓬勃发展的实践，在 9.2 版中几乎没有出现。

TOGAF 10 的革新

TOGAF 10 发布了一份专门的 Series Guide——“Applying the TOGAF ADM using Agile Sprints”（编号 G210e），系统性地回答了"如何在 Sprint 中跑 ADM"这个问题。核心内容包括：

四种协作模式（从低到高成熟度）：

1. EA Development Agility（架构开发敏捷）：架构团队自身用 Sprint 交付架构产出物，ADM 各阶段被拆分为多个 Sprint，每个 Sprint 产出一个 MVA（最小可行架构）。

2. Solution Collaboration（解决方案协作）：架构团队和敏捷开发团队并行工作。架构团队为后续 Sprint 创建 MVA，开发团队基于 MVA 交付 MVP。

3. Cross-Development Collaboration（跨领域协作）：业务开发、架构和开发三个角色各自用 Sprint 工作，形成 MVBD（最小可行业务发展）→ MVA → MVP 的接力链条。

4. Cross-Functional Agility（跨职能敏捷）：不再有独立的架构团队或开发团队，所有角色混编在同一个跨职能 Sprint 团队中，每个 Sprint 同时产出业务设计、架构和解决方案。

DORP 节奏机制：

每个 Sprint 结束时执行四个活动，缩写为 DORP：

• Demo（演示）：向利益相关者展示本 Sprint 的架构/解决方案增量
• Outcome Management（成果管理）：评估交付是否达到预期价值
• Retrospective（回顾）：反思协作方式，持续改进
• Planning（规划）：基于优先级选取下一个 Sprint 的工作项

DevOps / DevSecOps / CI-CD 的一等公民地位：

在 G210e 文档中，敏捷（Agile）、DevOps、DevSecOps 和 CI/CD 被明确定义为"四种独立但互补的实践”，当开发组织同时运用这四者时，“效果是变革性的”（the results are transformational）。架构师的合规审查不再是传统意义上的"关卡式评审”（gate review），而是嵌入 Sprint 的持续过程——“an ongoing process, as opposed to the traditional gate/review process at a specific point in time”。

变化四：MVA——最小可行架构

概念的诞生

在敏捷世界里，MVP（Minimum Viable Product，最小可行产品）早已是一个耳熟能详的概念。但架构师常常面临一个两难困境：

• 做太多架构设计 → 变成"过度前置设计"（too much architecture upfront），拖慢交付节奏
• 做太少架构设计 → 系统复杂且缺乏文档，变成技术债的温床

TOGAF 10 给出的答案是 MVA（Minimum Viable Architecture，最小可行架构）。

官方定义：“A Minimum Viable Architecture (MVA) defines the minimum (Enterprise) Architecture that is realizable and add business value.”

翻译过来就是：MVA 是能够被实现并产生业务价值的最小架构定义。

与 MVP 的类比

在 Sprint 驱动的工作流中，这三者形成一条清晰的价值链：

1
2

MVBD → MVA → MVP
（业务团队产出）→（架构团队产出）→（开发团队产出）

“Just Enough Architecture, Just in Time”

G217e 文档中有一段非常精辟的表述：

“The job of the architect is to do just enough architecture, just in time.”

这句话浓缩了 TOGAF 10 对架构师角色的重新定位。架构师不再是"先把所有东西都想清楚、写下来，然后交给别人去实现"的角色，而是在每个 Sprint 中，为下一个 Sprint 提供刚好够用的架构指导。

同时，文档也指出了两个需要警惕的极端：

• 架构不足：系统复杂但没有文档描述（insufficient architecture）
• 架构过度：在每个想法还没有验证可行性之前就要求"架构审批"（too much architecture）

MVA 的精髓在于找到这两者之间的平衡点，而且这个平衡点是随组织语境动态变化的——在 Individual/Founder 语境下，MVA 可能就是几张白板草图；在 Enduring Enterprise 语境下，MVA 可能需要正式的建模工具和合规审查。

变化五：EA 即服务——从"审批门卫"到"按需赋能"

9.2 版的典型形象

在很多组织中，企业架构团队被定位为"架构评审委员会"的执行者。项目走到某个节点，必须提交架构文档，等待架构团队审批通过后才能继续推进。这种模式下，架构师实际上扮演的是 gate-keeper（门卫） 的角色。

这种模式在稳态企业环境中有一定合理性，但在数字化转型时代，它的弊端显而易见：

• 审批流程成为瓶颈，拖慢交付速度
• 架构团队被动等待，不了解业务一线的真实需求
• 敏捷团队将架构视为"阻碍"而非"助力"，选择绕过而非协作

TOGAF 10 的服务化转型

G217e 文档明确提出了两个战略转型方向：

第一个战略——从"审批后放行"到"赋能中协作"：

“Move from a ‘do it if, and after, the architect says OK’ to a ‘do it with the architecture enablement’ approach.”

即从"架构师说 OK 之后才能做"转变为"在架构赋能下一起来做"。架构师不再是高高在上的审批者，而是嵌入团队、按需提供指导的赋能者。

第二个战略——EA 即服务交付模型：

“Moving from producing architectures, and gating progress, to developing just enough architecture on demand to support the operations tempo of the digital effort.”

即从"生产架构文档、把关项目进度"转变为"按需开发刚好够用的架构，以匹配数字化工作的节奏"。

G217e 进一步将 EA 服务分为两大类：

• Internal-centric（内部导向）：面向企业内部的架构决策支持、治理、合规
• Customer-centric（客户导向）：面向数字产品交付、客户旅程、服务组合

在不同组织语境下，EA 服务的形态也不同：

值得注意的是，即使在 Context I（个人/创始人阶段），文档也强调了架构工作的存在性——“Even in the Individual/Founder Context, the individual/founder provides the business analysis delivered by an Enterprise Architect, even if it is done in an ad hoc fashion.“也就是说，架构工作始终存在，只是形式和正式程度不同。

升级路径建议：面向已认证 TOGAF 9.2 架构师

如果你已经持有 TOGAF 9.2 认证，或者在组织中基于 9.2 建立了架构实践体系，以下是具体的升级路径建议：

第一步：理解结构变化，调整知识体系

TOGAF 10 的 Fundamental Content 与 9.2 的核心方法论高度兼容。ADM 的八个阶段（Preliminary、A-H）没有发生根本性变化。你的核心知识储备仍然有效。

需要新增的学习内容：

• 模块化结构的逻辑：哪些是 Fundamental Content，哪些属于 Series Guides
• 如何根据项目需求"选配"适用的 Series Guides
• 新版认证体系的考试范围变化

第二步：掌握敏捷-架构融合实践

这是 9.2 到 10 之间差距最大的领域。建议：

1. 精读 “Applying the TOGAF ADM using Agile Sprints”（G210e），理解四种协作模式和 DORP 节奏
2. 在实际项目中尝试"架构 Sprint”——将 ADM 各阶段的工作拆分为 2-4 周的 Sprint
3. 练习 MVA 的定义能力——为每个 Sprint 明确"最小可行架构"的边界

第三步：建立"EA 即服务"的运营思维

从"审批者"心态切换到"服务提供者"心态：

• 建立 EA 服务目录（Service Catalog），明确可以提供哪些服务
• 设定服务等级目标（SLA），例如"架构咨询请求 48 小时内响应”
• 收集"客户反馈"——向使用架构服务的团队定期做满意度调研
• 用数据说话——追踪架构服务对交付速度和质量的影响

第四步：了解 DPBoK 与数字企业语境

如果你服务的组织正在经历数字化转型，或者你自己正在从传统 IT 架构师向数字化架构师转型，建议：

• 了解 DPBoK 标准的四个语境（Individual → Team → Team of Teams → Enduring Enterprise）
• 评估你当前服务的组织处于哪个语境
• 使用"Peek-Ahead"策略，为组织向下一语境的过渡做好架构准备

第五步：认证升级

The Open Group 提供了从 TOGAF 9.2 到 TOGAF Enterprise Architecture Practitioner 的桥接认证路径。建议优先完成桥接考试，获取新版认证。

全景对比表：TOGAF 9.2 vs TOGAF 10

不同场景下的选型建议

并非所有组织都需要立刻"全面升级"到 TOGAF 10。以下是根据不同组织特征的选型建议：

场景一：稳定运营的传统大型企业

如果你的组织 IT 环境相对稳定，变更节奏不快，9.2 的方法论核心仍然适用。但建议尽早了解 TOGAF 10 的模块化结构，将日常使用的实践指南"迁移"到对应的 Series Guides 上，为未来升级做准备。

场景二：正在推进数字化转型的企业

强烈建议采用 TOGAF 10。特别是 G217e（数字企业指南）和 G210e（敏捷 Sprint 指南），它们直接解决了"如何在快速变化的数字环境中做架构"这个核心痛点。MVA 理念和 EA 即服务模式可以显著降低架构团队与敏捷团队之间的摩擦。

场景三：数字原生公司 / 创业公司

TOGAF 10 的 DPBoK 四语境模型特别适合你。从 Context I 开始，随着组织成长逐步引入更多架构实践——这正是"Peek-Ahead"策略的核心。不需要一上来就搭建完整的 EA 能力中心，但需要在每个阶段为下一个阶段做好准备。

场景四：咨询公司的架构顾问

TOGAF 10 的模块化结构和 Series Guides 体系为你提供了更灵活的"工具箱”。针对不同客户，可以选配不同的 Series Guides 组合，而不必每次都从那份近千页的标准文档中裁剪。

小结：五大变化的底层逻辑

回顾这五大变化——模块化重构、数字企业融合、敏捷原生支持、MVA 最小可行架构、EA 即服务模式——它们背后有一条统一的主线：

TOGAF 正在从"一套规定好的方法"进化为"一组可组合的能力"。

9.2 版像一套精密的瑞士钟表——所有零件严丝合缝，但也意味着只能按照设计者的意图运转。TOGAF 10 更像一组乐高积木——核心连接件（Fundamental Content）保证结构稳固，而各种功能模块（Series Guides）可以按需组合，适应从微型创业团队到跨国企业的各种场景。

有人提出过这样一个观点：标准的价值不在于你遵守了多少条规则，而在于它帮你做出了多少更好的决策。TOGAF 10 的这次升级，正是沿着这个方向迈出了重要一步——它不再试图告诉每个组织"你应该怎么做"，而是为每个组织提供"在你当前的情境下，可以怎么做"的选项和工具。

对于企业架构师来说，这既是机遇也是挑战。机遇在于方法论更加灵活、更加贴合实际；挑战在于你需要具备更强的判断力——知道什么时候该用 MVA、什么时候该做完整架构，什么时候该按需赋能、什么时候该正式评审。这种判断力，恰恰是 TOGAF 10 时代架构师最核心的竞争力。