当企业架构遇上"瀑布困境"
长期以来，企业架构（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，然后在实践中不断迭代。毕竟，架构方法的演进本身，也应当遵循它所倡导的原则——小步快跑，持续交付，检视适应。
