企业架构 on 文艺技术笔记

TOGAF 敏捷化实践：如何用 Sprint 模式驱动 ADM 架构迭代

Wed, 24 Jun 2026 22:30:00 +0800

当企业架构遇上"瀑布困境"

长期以来，企业架构（Enterprise Architecture, EA）在许多组织中扮演的角色更像是一位"远景规划师"——花几个月甚至一年的时间，产出一份厚达数百页的架构蓝图，然后把它交给项目团队去执行。这种模式有一个隐含的假设：需求是稳定的，环境是可预测的，架构师可以在项目启动之前就把所有的事情想清楚。

然而，今天的商业环境充满了波动性、不确定性、复杂性和模糊性（VUCA）。市场窗口稍纵即逝，技术栈半年一换，竞争对手随时可能用一种全新的商业模式改写行业规则。在这样的背景下，“先做完所有设计再开始实施"的瀑布式路径，已经越来越难以跟上节奏。

以瀑布方式交付单体式的企业架构、流程和应用，早在上世纪八十年代就被证明是一种反模式。松耦合的架构、由小型团队快速交付的独立构建块，才是成功组织的共同选择。

那么问题来了：TOGAF 这套被广泛采用的企业架构框架，能否真正融入敏捷？

答案是肯定的。TOGAF 标准本身就支持 ADM（Architecture Development Method，架构开发方法）的迭代式运用。而 TOGAF Series Guide G210e 更进一步，系统性地阐述了如何将 Sprint（冲刺）机制引入 ADM 的各个阶段，让企业架构团队也能像敏捷开发团队一样，在短周期内交付可验证的增量价值。

本文将围绕这份指南的核心理念，从协作模式、节奏管理、Sprint 零号、ADM 阶段适配到架构治理，逐步展开一套可落地的 TOGAF 敏捷化实践路径。

Sprint 如何重塑 ADM 流程

什么是"架构 Sprint”？

在敏捷开发中，Sprint 是一段固定长度的时间窗口（通常 1-4 周），团队在此期间集中完成一组预先约定的工作，并在结束时交付一个可演示的增量。将这个概念移植到企业架构领域，意味着：

架构工作不再是"一口气做完"，而是被切分成若干个有时间边界的迭代周期；
每个 Sprint 都产出可验证的交付物——可以是一个最小可行架构（Minimum Viable Architecture, MVA）、一份架构切片、一个概念验证原型，甚至是一段可运行的解决方案；
反馈环路被大幅压缩——利益相关方在每个 Sprint 结束时就能看到成果并给出意见，而不是等到整个架构项目结束。

为什么架构工作也需要 Sprint？

理由其实和软件开发引入敏捷的逻辑如出一辙：

传统痛点	Sprint 带来的改变
架构蓝图交付周期过长，等到落地时需求已经变了	短周期迭代，快速响应变化
架构师与开发团队脱节，设计与实施两张皮	通过协作 Sprint 拉齐认知
合规审查集中在项目末端，发现问题为时已晚	持续审查，问题在 Sprint 内即暴露
利益相关方参与度低，评审会流于形式	每个 Sprint 都有演示和回顾，参与感强
架构决策缺乏实验验证，靠"拍脑袋"	通过概念验证（PoC）和 MVP 快速试错

将工作拆分为 Sprint，不仅仅是把大任务切小，更重要的是在短周期内"做中学"，并根据 Sprint 评审和回顾来持续调整工作方式。

四种协作模式：从架构团队的敏捷到跨职能一体化

TOGAF G210e 提出了四种递进的协作模式，它们代表了企业架构与敏捷融合的不同成熟度阶段。组织可以根据自身的敏捷水平和业务需求，选择合适的起点，逐步演进。

模式一：EA Development Agility（架构开发敏捷）

这是最基础的切入点。企业架构团队自身采用 Sprint 方式来执行 ADM 的 A 到 F 阶段，将架构工作划分为一系列迭代，每个 Sprint 产出一个 MVA（最小可行架构）。

典型特征：

架构团队独立运作 Sprint，不要求解决方案团队同步敏捷化；
每个 Sprint 通常包含 ADM A-F 中的一个"切片"（Partition），而非完整走完所有阶段；
治理仍沿用 TOGAF 治理框架，但可适度敏捷化；
架构完成后，解决方案的实施可以用敏捷方法，也可以用传统方法。

适用场景： 组织刚开始探索敏捷，解决方案团队尚未转型，但架构团队希望率先提速。

模式二：Solution Collaboration（解决方案协作）

在架构团队已经跑通 Sprint 的基础上，解决方案开发团队也加入协作。架构团队为即将到来的开发 Sprint 创建"刚好够用"的 MVA，解决方案团队则基于 MVA 进行实施。双方通过 Demo 互相反馈。

典型特征：

架构团队和解决方案团队各自维护 Sprint，但节奏上互相协调；
解决方案架构师参与架构 Sprint 的设计过程，企业架构师参与解决方案 Sprint 的支持工作；
业务利益相关方在 Demo 中同时看到架构增量和解决方案增量。

适用场景： 解决方案团队已经具备敏捷能力，需要与架构团队建立更紧密的协作。

模式三：Cross-Development Collaboration（跨开发协作）

再进一步，业务开发团队也以敏捷方式参与进来。三个角色——业务开发、企业架构、解决方案开发——各自运行 Sprint，但形成了一条"流水线"式的协作链：

业务开发团队在 Sprint 1 产出最小可行业务开发（MVBD） → 架构团队在 Sprint 2 将其转化为 MVA → 解决方案团队在 Sprint 3 基于 MVA 交付 MVP。

典型特征：

三个角色有各自的 Sprint，但通过 Backlog 和 Demo 紧密串联；
每个角色都在为下一个角色的 Sprint “备料”；
业务开发团队不再只是"提需求"，而是持续参与价值验证。

适用场景： 组织在业务层面也在推动敏捷转型，需要打通从业务变更到技术交付的全链路。

模式四：Cross-Functional Agility（跨职能敏捷）

这是成熟度最高的模式。不再有独立的架构团队、业务团队和开发团队，取而代之的是混合型的跨职能 Sprint 团队。每个团队内部同时具备业务开发、企业架构和解决方案开发的能力，所有改进工作统一通过业务变更 Backlog 和 Sprint Backlog 管理。

典型特征：

打破组织筒仓（Silo），架构师嵌入交付团队；
每个 Sprint 内同时产出业务变更、架构定义和解决方案增量；
团队之间在 Sprint 结束时进行跨团队协调。

适用场景： 组织敏捷成熟度高，追求端到端的快速响应和持续交付。

协作模式	参与角色	Sprint 结构	典型产出	成熟度
EA Development Agility	架构团队	架构 Sprint 独立运行	MVA	★☆☆☆
Solution Collaboration	架构 + 解决方案	各自 Sprint，协调节奏	MVA + MVP	★★☆☆
Cross-Development Collaboration	业务 + 架构 + 解决方案	三组 Sprint，流水线串联	MVBD → MVA → MVP	★★★☆
Cross-Functional Agility	跨职能混合团队	统一 Sprint，跨职能协作	端到端增量	★★★★

这四种模式并非互斥的选项，而是一条渐进的演化路径。组织可以从模式一起步，随着敏捷能力的提升逐步向模式四靠拢。

DORP 节奏：每个 Sprint 的四拍循环

在 TOGAF 的敏捷化实践中，每个 Sprint 结束时都要执行一套标准化的四步活动，缩写为 DORP：

D — Demo（演示）

Sprint 团队向利益相关方和其他 Sprint 团队展示本轮迭代的成果。演示的重点不是"PPT 汇报"，而是可验证的交付物：一份架构模型、一个原型、一段可运行的代码、一项业务流程变更方案——越具体越好。

演示的目的有三层：

确保利益相关方理解他们即将得到什么；
检验 Sprint 增量是否满足业务和质量目标；
了解其他团队的进展，发现跨团队的依赖和冲突。

O — Outcome Review（成果审视）

在演示的基础上，团队进一步审视本轮 Sprint 产出的业务价值是否达标。审视的结论会直接影响下一轮 Backlog 的优先级排序：

业务开发的成果（如 MVBD）进入架构团队的 Backlog；
架构成果（如 MVA）进入解决方案团队的 Backlog；
解决方案成果可以通过 DevOps 流程部署上线。

R — Retrospective（回顾）

Sprint 团队内部复盘：哪些做法效果好？哪些地方可以改进？回顾是敏捷团队"检视与适应"（Inspect & Adapt）的核心机制，目标是从 Sprint 到 Sprint 持续提升团队效能（Velocity）。

回顾可以关注的维度包括：

需求拆解是否合理？
工作量估算是否准确？
跨团队协作是否顺畅？
架构决策是否及时传递给了开发团队？

P — Planning（规划）

基于业务变更 Backlog 的优先级和上一轮 Sprint 的反馈，规划下一轮 Sprint 的目标和内容。每个 Sprint 都必须有一个Sprint 目标（Sprint Goal）——它是本轮迭代的"必达项"，也是规划过程的起点。

DORP 的节奏感至关重要。它让架构工作不再是一团模糊的"进行中"状态，而是有清晰的节点、可衡量的产出和持续的改进动力。

双 Backlog 管理：业务变更与 Sprint 任务的上下联动

在 TOGAF 的 Sprint 体系中，存在两层 Backlog，它们的关系类似于"战略清单"与"战术清单"：

Business Change Backlog（业务变更待办）

这是一个覆盖整个业务变更范围的顶层待办清单，其内容来源于企业架构愿景、目标和战略。它回答的是"我们要做什么"的问题，通常包含：

需要做出的重大架构决策；
为支撑这些决策必须完成的分析和论证工作；
最具业务价值的利益相关方需求。

业务变更 Backlog 的优先级排序可以采取多种策略：

价值优先：优先处理最能产生业务价值的部分；
风险优先：优先处理最具不确定性和风险的部分；
全栈切片：优先选择一条贯穿多个 ADM 阶段的完整切片，验证端到端的可行性；
易实施优先：优先选择容易定义和实施的部分，快速建立信心。

Sprint Backlog（Sprint 内任务）

每个 Sprint 团队基于业务变更 Backlog 和 Sprint 目标，拆解出本轮迭代的具体任务。Sprint Backlog 回答的是"这个 Sprint 我们做什么"的问题。

两层 Backlog 之间的联动机制如下：

Sprint 规划时，从业务变更 Backlog 中选取最高优先级的项目，拆分为 Sprint 任务；
Sprint 进行中，新的变更请求和反馈被添加到业务变更 Backlog 中待评估；
Sprint 结束时，未完成的工作回到业务变更 Backlog，参与下一轮的优先级排序。

企业架构师在 Sprint 规划中扮演关键角色——他们需要帮助团队理解不同 Sprint 之间的互操作性和依赖关系，这对于工作量估算和优先级定义都至关重要。

Sprint Zero：为后续迭代奠定基础

为什么需要"零号 Sprint"？

在敏捷社区中，“Sprint Zero"是一个有争议的概念——部分敏捷实践者认为不应该存在一个"不做交付"的准备阶段。但在企业架构的语境下，TOGAF G210e 明确建议在正式开始迭代之前，先进行一次准备性 Sprint，通常称为 Sprint Zero 或 Strategic Sprint（战略冲刺）。

原因在于：企业架构工作有其特殊性。如果在没有任何方向性共识的情况下直接进入开发 Sprint，团队可能会在架构选型、技术路线、业务优先级等根本性问题上反复摇摆，造成巨大的浪费。

Sprint Zero 遵循的是 Enough Design Upfront（EDUF，足够的前期设计） 原则——不是要做到"完美设计”，而是要做到"足够让后续 Sprint 有序启动"的设计。

Sprint Zero 做什么？

Sprint Zero 的核心交付物包括：

业务变更愿景定义：明确业务改进的初始方向、主要价值流和关键能力；
高层级路线图：勾画业务转型的大致路径和阶段划分；
业务变更 Backlog 初版：基于愿景和路线图，列出需要后续 Sprint 处理的工作项；
无遗憾决策（No-Regret Decisions）：识别那些在任何场景下都成立的决策，先锁定下来，为团队争取时间。

Sprint Zero 的输入包括业务改进需求、IT 改进需求以及现有的战略架构和段架构。

Sprint Zero 结束时同样执行 DORP 流程。值得注意的是，只有紧随其后的第一个 Sprint 会被详细规划，其余 Sprint 不做预先安排——这正是敏捷"只规划下一步"的精髓。

ADM 各阶段的 Sprint 实践要点

TOGAF ADM 包含 A 到 H 共八个阶段。在 Sprint 化的环境中，每个阶段需要做不同程度的适配。以下逐一展开。

Phase A：架构愿景——采用演化方法

Phase A 的目标是快速创建或确认架构愿景的高层蓝图，包括预期成果、关键能力和业务价值。

在 Sprint 模式下，这份愿景不是一成不变的——它会随着每个 MVA 的迭代、业务环境的变化和开发团队的反馈而不断演化。但演化不等于推倒重来，愿景应当被视为一个稳固的基座，允许在其上扩展和延伸，为所有团队提供方向性指引。

实践要点：

Sprint Zero 中产出初始愿景；
后续每个 Sprint 的 Planning 阶段审视愿景是否需要微调；
愿景文档保持轻量级，避免过度详细化。

Phase B / C / D / E：业务、信息系统、技术架构与机会解决方案——Sprint 化的主战场

这四个阶段是 Sprint 模式最自然的适配区域。常见的做法是创建跨阶段的架构切片——每个 MVA 不是只做 B 阶段或只做 D 阶段，而是从 B 到 E 横切一刀，确保架构的完整性。

实践要点：

每个 Sprint 产出一个 MVA 切片，涵盖 B/C/D/E 中与本轮目标相关的部分；
业务团队、架构团队和解决方案团队在创建 MVA 时充分协作，确保共同理解；
可以有多个团队并行创建 MVA 和解决方案，前提是依赖关系已经理清；
TOGAF 标准并不要求 B 到 E 必须按顺序执行——你可以根据项目需要自由迭代。

Phase E / F：路线图与迁移规划——按 Sprint 粒度适配

Phase E（路线图部分）和 Phase F 的步骤需要在 Sprint 环境中做裁剪。不是每个 Sprint 都需要执行这两个阶段的所有步骤，而是根据本轮 Sprint 的工作量来选择性地执行。

关键适配原则：

Phase E/F 步骤	Sprint 化适配方式
确认企业变革属性	首个 Sprint 中完成即可，后续按需更新
识别业务约束	每个 Sprint 中识别新的约束
协调互操作性需求	在 Sprint 范围内协调
验证依赖关系	每个 Sprint 中细化团队间依赖
确认就绪度和风险	每个 Sprint 确认 MVP 的就绪度
制定实施与迁移策略	为 Sprint 范围制定足够详细的策略
识别工作包	每个 Sprint 识别本轮所需工作
创建路线图	与产品负责人和敏捷团队协作定义 Backlog
更新架构定义文档	每个 Sprint 更新以反映当前架构状态

Phase G：实施治理——从"门禁审查"到"持续审查"

在传统模式下，Phase G 的核心是合规性审查——在项目的特定节点进行"门禁式"检查，判断实施是否符合目标架构。在 Sprint 模式下，这种做法被根本性地改变了：

合规审查变为持续过程：不再等到项目末端才检查，而是在每个 Sprint 中持续验证架构一致性；
短周期暴露偏差：Sprint 的长度决定了偏差最多积累一个迭代周期就会被发现；
Sprint Review 承担治理职能：每个 Sprint 的 Demo 本身就是一个轻量级的合规审查节点；
非正式引导取代正式审查：架构师在 Sprint 过程中持续引导开发团队，而非事后审计。

Phase H：架构变更管理——融入持续迭代

Phase H 的目标是确保交付的解决方案兑现了承诺的价值，并处理变更请求。在 Sprint 模式下：

价值实现过程与 Sprint 并行运行——每个 Sprint 结束后验证业务价值是否被实际接收；
变更请求不再走独立的变更管理流程，而是直接进入业务变更 Backlog，参与下一轮 Sprint 的优先级排序；
风险管理从 Demo 和 Retrospective 中收集，并转化为具体的缓解行动；
治理过程嵌入 Sprint 内部：业务团队治理架构团队，架构团队治理解决方案团队，反之亦然——形成一种相互问责的协作式治理。

Sprint 长度与节奏选择

多长合适？

TOGAF G210e 给出的建议范围是 1-4 周，通常推荐 2 周。具体选择取决于：

项目的预期周期；
利益相关方能提供反馈的频率；
团队的经验水平和技术能力（如自动化测试、持续部署的成熟度）；
工作分解的原子性——理想情况下，一个 Sprint 应该处理一个相对独立的原子主题。

关键原则：固定长度

Sprint 的长度应当保持固定，而不是忽长忽短。固定长度的好处在于：

团队对"有多少时间可用"有稳定预期；
短期和长期规划都有可靠的节奏基准；
团队效能（Velocity）的度量更加准确。

如果一个 Sprint 内无法完成足够的架构工作来为后续开发提供价值，可以考虑两种策略：

让架构工作跨越多个 Sprint，但仍然拆分为 Sprint 粒度的可交付块；
定义"过渡架构"（Transition Architecture），当架构达到一定成熟度后，解决方案团队开始基于该版本进行开发，而架构团队同时推进下一个版本——这与敏捷发布火车（Agile Release Train）的理念相近。

架构治理的敏捷转型

从正式合规到持续协作

传统的企业架构治理往往是一套正式的合规流程：架构评审委员会在固定节点开会，对照架构文档逐项检查实施的符合性。这种模式在 Sprint 环境下显得笨重且低效。

敏捷化的架构治理强调三个转变：

从"节点审查"到"持续审查"——治理活动嵌入每个 Sprint 的日常工作中；
从"单向审计"到"相互问责"——业务团队、架构团队和解决方案团队彼此治理、彼此负责；
从"集中决策"到"分布式决策"——决策权根据类型和可逆性进行分级授权。

决策分类：可逆与不可逆

在企业架构治理中，决策可以分为两类：

可逆决策（Type 2）：如果发现错了，可以回滚或调整。这类决策应当授权给单个团队自行做出，不需要层层审批。
不可逆决策（Type 1）：一旦执行就难以撤回，影响深远。这类决策需要更大范围的利益相关方共同参与，包括所有相关的敏捷团队。

这种分类方法有助于在"决策速度"和"决策质量"之间找到平衡——大部分日常架构决策快速下放，少数关键决策集中审慎。

授权层级：Management 3.0 的七级模型

在确定哪些决策可以下放、下放到什么程度时，可以参考 Management 3.0 框架中的七级授权模型：

级别	名称	含义
1	Tell（告知）	上级做出决策，通知团队执行
2	Sell（推销）	上级做出决策，但需要说服团队接受
3	Consult（咨询）	上级在决策前征询团队意见
4	Agree（协商）	上级与团队共同商议达成一致
5	Advise（建议）	团队做出决策，但会征询上级的建议
6	Inquire（问询）	团队做出决策，上级事后了解
7	Delegate（委托）	团队完全自主决策

这个模型是对称的——从 1 到 7 是逐步放权，从 7 到 1 是逐步收权。不同类型的架构决策可以映射到不同的授权级别，从而在治理严谨性和团队自主性之间取得平衡。

治理不再是"谁批准谁"的问题，而是"如何让正确的决策在正确的层级被做出"的问题。

落地建议：从哪里开始？

第一步：评估组织的敏捷成熟度

在四种协作模式中，选择与组织当前状态最匹配的那个作为起点。如果解决方案团队还没有采用 Sprint，那就从模式一（架构团队自己跑 Sprint）开始；如果已经有多个敏捷团队在运行，可以直接尝试模式三甚至模式四。

第二步：从一个 Sprint Zero 开始

不要跳过准备阶段。用一个 Sprint Zero 来建立愿景、梳理 Backlog、锁定无遗憾决策。这会让后续的 Sprint 有方向感，避免团队在迷雾中摸索。

第三步：建立 DORP 节奏

无论选择哪种协作模式，DORP 都是不可省略的骨架。确保每个 Sprint 结束时都有演示、成果审视、回顾和规划——这四步是让架构工作从"黑箱"走向"透明"的关键。

第四步：从小切片开始

不要试图在一个 Sprint 中覆盖 ADM 的所有阶段。选择一个端到端的架构切片（比如一条价值链从业务架构到技术架构的完整路径），验证 Sprint 化的可行性，再逐步扩展范围。

第五步：治理模型同步演进

架构治理不能停留在传统模式。从决策分类入手，区分哪些决策可以下放给团队、哪些需要集中讨论。借助授权层级模型，逐步建立起适配敏捷节奏的治理体系。

第六步：持续迭代，不要追求一步到位

Sprint 模式的精髓就是"做中学"。第一轮可能不完美，但通过每个 Sprint 的 Retrospective，团队会不断发现改进点。架构工作方式的敏捷化本身，就应该以敏捷的方式来推进。

小结

TOGAF ADM 与 Sprint 的结合，本质上是用敏捷的节奏感重新组织企业架构的开发和治理过程。四种协作模式提供了从入门到高阶的渐进路径，DORP 机制确保了每个迭代的闭环管理，双 Backlog 实现了战略与执行的上下对齐，Sprint Zero 为后续迭代奠定了"足够好"的基础，而架构治理的转型则保证了敏捷不等于失控。

对于正在探索企业架构敏捷化的组织而言，最重要的不是一次性把所有模式都搬过来，而是选准切入点，跑通第一个 Sprint，然后在实践中不断迭代。毕竟，架构方法的演进本身，也应当遵循它所倡导的原则——小步快跑，持续交付，检视适应。

TOGAF 第10版标准精读：与 9.2 版的五大关键变化与升级建议

Wed, 24 Jun 2026 22:00:00 +0800

从"一本厚书"到"模块化标准"：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 将标准拆分为两个层次：

层次	名称	定位	更新频率
第一层	Fundamental Content（基础内容）	稳定的核心概念、ADM 方法论、关键定义	长期稳定，极少变动
第二层	Series Guides（系列指南）	面向特定行业、架构风格、问题场景的实践指导	快速迭代，持续更新

官方文档原文如此描述：“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 体系：

语境	名称	核心关切	TOGAF 在此语境的角色
Context I	Individual / Founder	最小可行数字产品的交付	轻量级架构角色，按需赋能，关注风险识别
Context II	Team	团队协作与产品管理	建立共享理解，辅助流程可视化与沟通
Context III	Team of Teams	跨团队协调与产品组合管理	识别依赖关系，降低认知负载，支持组合决策
Context IV	Enduring Enterprise	治理、合规、信息管理与长期可持续	全面治理框架，投资组合管理，架构驱动运营

有人提出过一个形象的比喻：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"这个问题。核心内容包括：

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

EA Development Agility（架构开发敏捷）：架构团队自身用 Sprint 交付架构产出物，ADM 各阶段被拆分为多个 Sprint，每个 Sprint 产出一个 MVA（最小可行架构）。
Solution Collaboration（解决方案协作）：架构团队和敏捷开发团队并行工作。架构团队为后续 Sprint 创建 MVA，开发团队基于 MVA 交付 MVP。
Cross-Development Collaboration（跨领域协作）：业务开发、架构和开发三个角色各自用 Sprint 工作，形成 MVBD（最小可行业务发展）→ MVA → MVP 的接力链条。
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 的类比

概念	关注点	核心问题	时间维度
MVP	产品	“我们能交付的最小可用产品是什么？”	面向客户
MVA	架构	“支撑这个产品所需的最小架构定义是什么？”	面向内部
MVBD	业务	“驱动下一步架构工作的最小业务变更是什么？”	面向战略

在 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 服务的形态也不同：

语境	EA 服务形态	典型服务内容
Individual / Founder	按需咨询，创始人兼任架构角色	风险识别、技术选型建议、业务模型梳理
Team	轻量级服务嵌入	工作流建模、共享理解建立、架构模型辅助产品管理
Team of Teams	跨团队协调服务	依赖关系管理、组合视图、认知负载优化
Enduring Enterprise	完整 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 之间差距最大的领域。建议：

精读 “Applying the TOGAF ADM using Agile Sprints”（G210e），理解四种协作模式和 DORP 节奏
在实际项目中尝试"架构 Sprint”——将 ADM 各阶段的工作拆分为 2-4 周的 Sprint
练习 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 9.2	TOGAF 10
文档结构	单一巨型标准文档	Fundamental Content + 多个 Series Guides
更新机制	整体修订，周期长	核心稳定 + 指南独立快速更新
数字企业支持	无显式指导	通过 G217e 与 DPBoK 四语境显式整合
敏捷支持	“兼容"态度，缺少具体方法	Sprint 驱动 ADM（G210e），四种协作模式
DevOps/CI-CD	几乎未涉及	作为一等公民纳入，与架构治理融合
架构产出理念	完整架构文档	MVA（最小可行架构），just enough, just in time
EA 角色定位	审批门卫（gate-keeper）	按需服务提供者（EA as a Service）
组织规模适配	默认面向成熟大型企业	覆盖从个人/创始人到持久企业的四种语境
生态标准整合	与 DPBoK、O-AA 等无显式桥接	显式引用并整合 DPBoK、O-AA、IT4IT 等
技术债务管理	隐含在治理中	明确提出被动式和主动式技术债务管理策略
架构合规方式	阶段性关卡评审	嵌入 Sprint 的持续合规审查

不同场景下的选型建议

并非所有组织都需要立刻"全面升级"到 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 时代架构师最核心的竞争力。