TOGAF® 标准如何支持敏捷性
作者：Mike Lambert，The Open Group 研究员兼The Open Group 架构论坛主席
The Open Group TOGAF® 标准–版本9.2 于2018 年4 月16 日发布。那时一些人普遍持有的一种错误观念是，企业架构和TOGAF 标准妨碍了企业敏捷性。本文通过引用该标准的具体章节对这种错误观念进行了反驳；本文不假设采用任何特定的敏捷方法。
敏捷性为何重要？
企业越来越需要更快地产生效益。企业必须能够快速地响应变更动因，并能够迅速、安全地改变方向。
企业架构扮演何种角色？
企业架构提供了一个变更框架，与战略方向和业务价值紧密联系。企业架构充分显示了组织如何管理复杂性、支持持续变更和管理意外影响的风险。
敏捷性并非新要求
1996 年美国克林杰- 科恩法案是推动企业架构采用的主要因素，因为它要求投资新IT 系统（在美国公共部门）以证明支持现有的系统。很快，人们认识到，“自上而下”开发一个完整的企业架构是不切实际的；我们需要根据企业在特定时间点的特定需求将这一任务分解为多个“部分”，并部署某种形式的“集成架构”以确保所有部分相互配合并与企业的战略方向保持一致。
TOGAF 标准从版本1 就支持敏捷性
TOGAF 标准从版本1 就支持架构分区的概念。[1] 总的来说，这表明每个架构计划都需要明确覆盖范围以满足待处理部分的特定需求。（TOGAF 标准第4.5 节）。
明确覆盖范围时的主要参考维度：
- 企业广度
- 深度；细节程度
- 时间范围
- 相关架构领域
TOGAF 标准版本9 于2009 年发布，最新版本在此基础上加入了一个可开发各种细节程度的架构分区的模型[2]：
|
Breadth |
广度 |
|
Level |
级别 |
|
Time |
时间 |
|
Enterprise Strategic Architecture |
企业战略架构 |
|
Segment Architecture |
细分架构 |
|
Capability Architecutre |
能力架构 |
具体来说，该模型引入了“能力架构”这一术语，表示通过“持续”交付（小）能力增量满足企业不断演进的需求。
然而，它强调必须充分理解企业的整体战略方向和能力增量需要适应的情境，以避免意外影响。
这与2018 年提高敏捷性的要求有何关系？
缩减架构分区大小和时段及能力增量的需求持续存在。这反过来会导致企业倾向于跳过战略和分区架构的开发，进而使得一些看似微不足道的变更的意外影响会造成一些严重的IT 故障。
实现卓越敏捷性的关键
有两大因素与实现卓越敏捷性相关：
- 管理覆盖范围，了解何时需要新能力，对企业的影响范围，以及企业的不同部分如何互动。
- 构建一个“全局视图”，清晰地呈现出企业的整体战略方向、关键业务能力和必须保护的重要关系。如果没有“全局视图”，对关键依赖关系的认识会存在不足，进而可能造成意外的影响，同时零碎开发和变更可能会影响企业的整体战略。“全局视图”支持对任何建议的变更进行影响评估。
架构级别有助于提升敏捷性
自上而下，企业战略架构为企业受变更影响的部分提供了一个高级视图；能力架构详细描述了待交付的能力（增量）。这些是敏捷环境中的迭代(sprint)。它们具有充分的细节，可交付给开发人员付诸实施。如图所示，迭代可以并行发生。
一个关键考虑事项是迭代有时间限制，并且旨在实现一系列有界目标。为了实现这些目标，能力架构应严格明确覆盖范围。
更高级架构显示了能力增量之间的关系和依赖性，并为管理意外影响的风险提供了框架。它们为评估建议变更的整体影响提供了所需信息。
自下而上，从能力增量实施中获得的反馈会影响更高级架构。得益于从每次能力增量部署中汲取的经验，企业战略架构得以演进。[3]
战略架构并非一成不变。当企业战略演进时，它也必须演进；在敏捷环境中，它可能比“传统”的长期战略计划演进得更频繁。
但至关重要的一点是要进行适当的治理以维护战略架构和企业业务需求之间的联系。
过渡架构管理风险
过渡架构提供了一种风险管理方法。[4] 过渡架构会记录每次迭代结束后的架构状态，将每个能力增量映射至期望的最终状态，并展示整个系统的稳定性。
TOGAF 架构开发方法
|
Preliminary |
预备 |
|
A. Architecture Vision |
A. 架构愿景 |
|
B. Business Architecture |
B. 业务架构 |
|
C. Information Systems Architectures |
C. 信息系统架构 |
|
D. Technology Architecture |
D. 技术架构 |
|
E. Opportunities and Solutions |
E. 机遇和解决方案 |
|
F. Migration Planning |
F. 迁移规划 |
|
G. Implementation Governance |
G. 实施治理 |
|
H. Architecture Change Management |
H. 架构变更管理 |
|
Requirements Management |
要求管理 |
TOGAF ADM 图示强化了企业架构是一个漫长的“瀑布”流程的印象。
然而，TOGAF 标准并不：
- 强制要求必须按照所示顺序执行步骤
- 强制要求使用“瀑布”方法
- 为任何架构开发阶段或周期规定持续时间
本标准的确建议调整ADM 以满足企业需求，包括敏捷性需求。[5]
本标准指出了如何迭代使用ADM 以开发全面的企业架构环境。[6]
敏捷环境中的企业架构
传统的企业架构视图显示多个阶段：
|
Define baseline |
定义基线 |
|
Define target |
定义目标 |
|
Deploy target |
部署目标 |
|
Manage Change |
管理变更 |
就TOGAF ADM 而言，
- 阶段B、C 和D 定义基线和目标
- 阶段E、F 和G 部署目标
- 阶段H 管理变更
在敏捷环境中，这些活动可以是一个持续的管理过程：
|
Define Baseline |
定义基线 |
|
Define Target |
定义目标 |
|
Deploy Target |
部署目标 |
|
Govern and Manage Change |
管理变更 |
TOGAF 标准中包含与该“架构风格”直接相关的指导：
结论
本文证明了TOGAF ADM 可通过调整支持企业敏捷性。事实上，在过去几年里，The Open Group成员季会已多次演示了TOGAF ADM 在敏捷环境中的成功应用。
[1] TOGAF 标准版本9.2 第36 章
[6] TOGAF 标准版本9.2 第18.1 和18.2 节
[7] TOGAF 标准版本9.2 第7.3.2、9.3.2、10.3.2 和11.3.2 节
[8] TOGAF 标准版本9.2 第7.3.3、9.3.3、10.3.3 和11.3.3 节