企业架构框架，如TOGAF（开放组架构框架），传统上与详细规划、大量文档和长期愿景相关联。相反，敏捷方法论则优先考虑迭代交付、适应性和客户反馈。对于许多组织而言，整合这两种截然不同的方法会产生摩擦。这种感知到的冲突源于架构治理需求与快速迭代愿望之间的张力。
本指南探讨了组织如何在敏捷环境中成功应用TOGAF原则。我们将研究将架构开发方法（ADM）与迭代开发周期对齐的实用策略，确保结构支持灵活性而非阻碍它。通过理解两种框架的细微差别，领导者可以构建出既稳健又对变化具有响应能力的系统。
🧩 理解核心框架
为了有效整合，我们必须首先在不依赖流行术语的前提下，理解每种方法的基本本质。
🏛️ TOGAF架构开发方法
TOGAF提供了一种结构化的方法，用于设计、规划、实施和管理企业信息架构。该框架的核心是ADM循环，包含多个阶段：
- 阶段A：架构愿景 – 确定范围和利益相关者需求。
- 阶段B：业务架构 – 定义业务战略和流程。
- 阶段C：信息系统架构 – 涵盖数据架构和应用架构。
- 阶段D：技术架构 – 定义基础设施和技术标准。
- 阶段E：机遇与解决方案 – 规划实施路线图。
- 阶段F：迁移规划 – 顺序安排过渡步骤。
- 阶段G：实施治理 – 确保解决方案与设计一致。
- 阶段H：架构变更管理 – 管理架构的变更。
传统上，这一循环被视为线性或半线性，通常需要在实施开始前完成全部定义。这正是与敏捷方法产生摩擦的地方。
⚡ 敏捷思维
敏捷不仅仅是一套实践；它是一种以敏捷宣言为核心的思维模式。其核心原则包括：
- 个体与互动胜过流程与工具。
- 可工作的软件胜过详尽的文档。
- 客户协作胜过合同谈判。
- 响应变化胜过遵循计划。
敏捷团队通常以短周期（冲刺）工作，以交付可用的功能增量。他们依赖持续的反馈来调整产品方向。在这种背景下，过于僵化的架构计划会减缓价值交付。
🤝 集成挑战
将TOGAF与敏捷结合的主要挑战在于时间跨度和规划粒度的差异。TOGAF通常着眼于数年内的企业层面，而敏捷则在数周或数月内运作。如果架构过于僵化，会抑制团队的灵活调整能力；如果过于松散，组织则可能面临技术债务和技术碎片化风险。
以下是矛盾通常出现的方面：
| 方面 | TOGAF关注点 | 敏捷关注点 | 潜在冲突 |
|---|---|---|---|
| 规划 | 长期路线图 | 短期冲刺待办事项 | 需要多少未来的细节？ |
| 文档 | 全面的模型 | 可工作的软件 | 文档的开销是否合理？ |
| 决策 | 集中式治理 | 去中心化所有权 | 由谁批准变更？ |
| 变更 | 受控演进 | 拥抱适应 | 如何管理偏离？ |
认识到这些差异，使架构师能够设计出一种混合模型，尊重两者的优点。
🔄 为敏捷周期适配ADM
架构开发方法无需被抛弃，反而可以实现迭代化。‘迭代式ADM’的概念使得架构工作能够与开发工作并行开展，而非完全前置。
🌱 迭代式架构愿景
阶段A（愿景）不应是一次性事件。在敏捷环境中，愿景被视为一份动态文档。它提供方向指引，但可根据市场反馈进行调整。架构师与产品负责人协作，确保愿景与产品路线图保持一致。
关键行动包括：
- 定义保持不变的高层次原则。
- 识别不可妥协的约束条件（安全、合规）。
- 将愿景分解为可执行的架构史诗。
🏗️ 即时架构定义
在传统模式中，所有四个领域（业务、数据、应用、技术）在开发开始前都会被完全定义。敏捷方法建议仅定义推进所必需的内容。这通常被称为“即时”架构。
例如：
- 冲刺 1-3： 聚焦于业务架构和高层次的应用逻辑。
- 冲刺 4-6： 根据具体数据实体的需求，优化数据架构。
- 冲刺 7 及以后： 详细设计部署环境的技术架构。
这种方法减少了浪费。架构师不必花费时间去建模那些可能在迭代过程中被丢弃的组件。
🏗️ 架构跑道
这一整合中的一个关键概念是“架构跑道”。该术语指的是必须建立的技术基础设施和架构原则，以支持未来功能的开发。如果没有跑道，开发人员可能不得不在功能冲刺中途停下来构建基础组件，从而导致延迟。
为了保持健康的跑道：
- 识别使能者： 确定哪些技术工作是实现未来业务价值所必需的。
- 分配容量： 为架构使能者预留一部分冲刺容量（例如，20%）。
- 自动化标准： 使用基础设施即代码来强制执行技术标准，避免人工审查瓶颈。
这确保了敏捷团队能够获得所需的工具和框架，而无需等待大型架构项目完成。
🛡️ 轻量级治理
敏捷环境中的治理必须是轻量级的。过于严苛的审批流程会扼杀进展。目标是在不造成瓶颈的情况下确保合规性和质量。
📝 架构决策记录（ADRs）
与其使用庞大的架构文档，组织可以使用架构决策记录。ADR 会记录一个重要的架构决策及其背景和后果。这是一种轻量级文档，存储在代码仓库中。
ADRs 的优势包括：
- 可追溯性： 数月甚至数年后仍能知道当初做出该决策的原因。
- 协作：团队成员可以轻松地审查和评论决策。
- 透明度： 决策历史对所有人开放。
🔍 架构评审委员会
传统的架构评审委员会（ARB）可能成为瓶颈。在敏捷环境中，ARB 应作为咨询机构而非守门人运作。评审应在关键里程碑进行，而不是每个冲刺都进行。
考虑以下调整：
- 聚焦风险： 仅审查可能影响企业整体的高风险决策。
- 异步评审： 允许架构师异步提供反馈，以避免时间安排冲突。
- 同行评审： 鼓励开发人员在正式的 ARB 评审前相互审查架构合规性。
👥 角色与职责
成功的整合需要明确的角色定义。传统的“首席架构师”角色通常需要演变为更分散的模式。
🧑💼 企业架构师
企业架构师专注于长期愿景。他们定义指导组织的标准、原则和模式。他们确保不同团队不会构建出不兼容的孤岛。
🧑💻 系统架构师
系统架构师更贴近开发团队。他们将企业原则转化为特定解决方案的具体技术设计。他们充当高层战略与代码之间的桥梁。
🏃♂️ 敏捷架构师
一些组织将架构师直接嵌入敏捷团队。这些人员帮助团队做出与整体战略一致的决策，同时保持开发速度。他们参与冲刺计划和待办事项梳理。
🧭 产品负责人
产品负责人代表业务价值。他们与架构师合作，确保技术约束在业务目标背景下被充分理解。他们将架构使能项与用户故事一同优先排序。
🚧 常见陷阱，需避免
即使有完善的计划，如果忽视了某些陷阱，整合仍可能失败。意识到这些常见错误可以节省大量时间和资源。
- 过度设计： 试图为所有可能的未来场景设计会导致系统臃肿。应基于当前需求进行设计，并考虑可扩展性。
- 设计不足： 忽视架构约束会导致技术债务难以管理。务必确保非功能性需求（性能、安全等）得到解决。
- 沟通断层： 架构师和开发人员常常使用不同的语言。使用团队所有人都能理解的图表和模型。
- 忽视技术债务： 敏捷团队通常更重视功能而非重构。制定规则，确保每个冲刺中都有一定比例的工作用于解决技术债务。
- 工具过载： 不要依赖需要培训的复杂建模工具。保持文档简洁，并与开发流程紧密集成。
📊 衡量成功
你如何知道集成是否有效？你需要能够反映架构健康状况和交付速度的指标。
📈 架构健康指标
- 合规率： 遵循既定标准的解决方案所占比例。
- 技术债务比率： 重构工作量与新功能工作量之比。
- 可复用性： 在不同项目中被复用的共享组件数量。
🚀 交付指标
- 前置时间： 从想法到部署的时间。
- 部署频率： 代码发布的频率。
- 变更失败率： 导致失败的部署所占比例。
通过跟踪这些指标，管理层可以基于数据做出决策，明确在架构上投入资源的位置，或在哪些方面可以放宽约束。
🤔 常见问题
❓ TOGAF 能否与 Scrum 结合使用？
可以。ADM 阶段可以映射到冲刺周期中。例如，B 阶段和 C 阶段可以在一系列冲刺中进行探索。关键在于将 ADM 视为一个发现循环，而非线性的瀑布模型。
❓ 需要多少文档？
文档应足以支持系统维护，但不应过多。一张纸就能说清楚的图表，通常比50页的文档更有效。应聚焦于能为维护带来价值的文档。
❓ 如果业务需求在冲刺中途发生变化怎么办？
这是敏捷的核心原则。架构必须具备足够的灵活性以适应变化。使用抽象层和接口来解耦组件，使某一区域的变更不会导致整个系统崩溃。
❓ 我们是否需要像 SAFe 这样的独立敏捷框架？
不一定。尽管像SAFe（规模化敏捷框架）这样的框架为大型组织提供了结构，但TOGAF可以在不采用完整框架的情况下进行调整。选择取决于组织的规模和复杂性。
❓ 我们如何处理遗留系统？
遗留系统通常需要不同的处理方式。你可能需要创建一种“绞杀者藤蔓”模式，即在遗留系统周围逐步构建新功能，最终将其替换。TOGAF有助于描绘从遗留状态到目标状态的过渡过程。
🔍 关键要点
将TOGAF与敏捷结合，并非要在两者之间做出取舍。而是在结构与敏捷之间找到平衡。通过使架构开发方法具有迭代性，采用轻量级治理，并明确界定角色，组织可以同时实现稳定性和速度。
成功取决于沟通、灵活性以及对目标的共同理解。当架构团队与开发团队作为合作伙伴协同工作时，结果将是一个能够适应市场变化、同时不牺牲质量或合规性的韧性企业。
从小处着手。在一个团队中试点该方法。衡量结果。调整流程。重复。这种对架构本身的迭代方法，正是其试图支持的敏捷理念的体现。
