高等院校智慧物流与供应链系列教材

TOGAF®标准第 10 版
口袋指南（中文版）

开梵标准（The Open Group） 著

机械工业出版社
 本书是 TOGAF®标准第 10 版口袋指南，旨在简明扼要地介
®
绍 TOGAF 标准的内容和目的。内容包括：第 1 章简介，第 2 章
通用指导信息，第 3 章组建企业架构团队，第 4 章特定域的指南，
第 5 章 TOGAF 基本内容，第 6 章 TOGAF 架构开发方法，第 7
章 ADM 交付物，附录 A 词汇表和首字母缩略词。
®
本书的受众包括：想要了解 TOGAF 标准的企业架构师、业
务架构师、IT 架构师、数据架构师、系统架构师、解决方案架构
®
师和高级管理人员；对 TOGAF 标准感兴趣的读者。

图书在版编目（CIP）数据
TOGAF®标准第 10 版口袋指南 / 开梵标准著．—北京：机械工
业出版社，2023.11
ISBN 978-7-111-73946-3
Ⅰ. ①T… Ⅱ. ①开… Ⅲ. ①企业管理-指南 Ⅳ. ①F272-62

中国国家版本馆 CIP 数据核字（2023）第 215099 号

机械工业出版社（北京市百万庄大街 22 号 邮政编码 100037）

策划编辑：王 斌 责任编辑：王 斌
责任校对：王乐廷 梁 静 责任印制：张 博
有限公司印刷
2023 年 3 月第 1 版第 1 次印刷
130mm×184mm·15.25 印张·214 插页·214 千字
标准书号：ISBN 978-7-111-73946-3
定价：89.00 元

电话服务 网络服务
客服电话：010-88361066 机 工 官 网：www.cmpbook.com
读者购书：010-88379833 机 工 官 博：weibo.com/cmp1952
读者购书：010-68326294 金 书 网：www.golden-book.com
封底无防伪标均为盗版 机工教育服务网：www.cmpedu.com
 商标

商标

ArchiMate, DirecNet, Making Standards Work, Open O

logo, Open O and Check Certification logo, Platform 3.0, The
Open Group, TOGAF, UNIX, UNIXWARE, FACE, Future
Airborne Capability Environment, 以及 the Open Brand X 标
识为 The Open Group 注册商标。Boundaryless Information
Flow, Build with Integrity Buy with Confidence, Commercial
Aviation Reference Architecture, Dependability Through
Assuredness, Digital Practitioner Body of Knowledge, DPBoK,
EMMM, the FACE logo, FHIM Profile Builder, the FHIM logo,
FPB, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA,
O-PAS, OTTPSTM, Open Agile Architecture, Open FAIR,
Open Footprint, Open Process Automation, Open Subsurface
Data Universe, Open Trusted Technology Provider, OSDU,
Sensor Integration Simplified, SOSA, 以及 the SOSA 标识为

III
TOGAF®标准第 10 版口袋指南（中文版）

The Open Group 商标。

Association of Enterprise Architects is a registered
trademark of the Association of Enterprise Architects.
Business Model Canvas is a trademark of Alexander
Osterwalder.
Gartner is a registered trademark of Gartner, Inc.
GitLab is a registered trademark of GitLab, Inc.
PMBOK is a registered trademark of the Project
Management Institute, Inc.which is registered in the United
States and other nations.
POSIX is a trademark of the IEEE.
PRINCE2 is a registered trademark of AXELOS Limited.
SABSA is a registered trademark of The SABSA
Institute.
SAFe is a registered trademark of Scaled Agile, Inc.
UML is a registered trademark and Unified Modeling
Language is atrademark of Object Management Group, Inc.
所有其他品牌、公司和产品名称仅做识别之用途，
可能是其各自所有者的唯一财产的商标。

IV
 前言

前言

本书是 TOGAF® 标准第 10 版口袋指南，简明扼要

地介绍 TOGAF 标准的内容和目的。因此，本书并未涵
盖 TOGAF 标准各方面的详细信息，只提供了重点内容
和关键参考信息。本书的组织结构如下：
• 第 1 章介绍了 TOGAF 标准、TOGAF 文档、
TOGAF 框架以及关于本标准的阅读指导。
• 第 2 章描述 了 TOGAF 标 准 提供的 通用 指导
信 息。
• 第 3 章描述了 TOGAF 标准中关于如何支持组建
企业架构团队的指南。
• 第 4 章描述了 TOGAF 标准针对特定主题域提供
的指南，其中包括安全架构、业务架构、数据/
信息架构、敏捷方法以及参考模型和方法。
• 第 5 章描述了 TOGAF 标准提供的 TOGAF 基本

V
TOGAF®标准第 10 版口袋指南（中文版）

内容文档。
• 第 6 章描述了 TOGAF 架构开发方法以及 ADM
阶段。
• 第 7 章描述了 ADM 交付物的典型基线。
• 附录 A 包含本书使用的词汇表和首字母缩略词。
本书的受众：
• 想要了解 TOGAF 标准的企业架构师、业务架构
师、IT 架构师、数据架构师、系统架构师、解决
方案架构师和高级管理人员。
本书适合对 TOGAF 标准感兴趣的读者。

VI
 目录

目录

前言
第 1 章 简介···················································· 1
1.1 TOGAF 标准简介 ····································· 1
1.2 TOGAF 文档集的结构 ······························ 2
1.3 TOGAF 标准概述 ····································· 4
1.3.1 TOGAF 基本内容 ···································· 5

1.3.2 TOGAF 系列指南····································· 6

1.3.3 文档集概述 ··········································· 7

1.4 TOGAF 库 ············································· 11

1.5 TOGAF 框架概述 ···································13
1.6 如何阅读 TOGAF 标准 ·····························14
1.6.1 企业架构师 ··········································15

1.6.2 企业架构团队领导者 ································16

1.6.3 企业架构团队发起人 ································17

第 2 章 通用指导信息·······································19

VII
TOGAF®标准第 10 版口袋指南（中文版）

2.1 文档 ·····················································19
2.2 什么是企业架构 ······································20
2.3 为什么要开发企业架构 ·····························21
2.4 企业架构的目的 ······································22
2.5 开发企业架构 ·········································23
2.6 阶段 A：起点 ·········································24
2.7 ADM 基本输出 ·······································26
2.8 数字化企业的战略 ···································28
2.9 支持数字化企业 ······································29
2.9.1 背景环境 I：个人/初创者 ··························30

2.9.2 背景环境 II：团队 ···································32

2.9.3 背景环境 III：复杂团队 ·····························33

2.9.4 背景环境 IV：长青企业 ····························35

2.9.5 根据背景环境应用 TOGAF 原则 ···················36

2.9.6 在数字化企业中应用企业架构服务 ················36

2.10 影响数字技术采用的因素 ························40

2.11 数字技术采用路线图·······························41
第 3 章 组建企业架构团队·································45
3.1 文档 ·····················································45
3.2 企业架构能力 ·········································46

VIII
 目录

3.3 组织模型 ···············································48

第 4 章 特定域的指南·······································51
4.1 安全架构 ···············································51
4.1.1 文档 ··················································51

4.1.2 集成风险与安全 ·····································52

4.1.3 风险的定义 ··········································53

4.1.4 安全是贯穿各个领域的关注点 ·····················54

4.1.5 企业风险管理········································55

4.1.6 信息安全管理········································56

4.2 业务架构 ···············································57

4.2.1 文档 ··················································57

4.2.2 业务模型 ·············································59

4.2.3 什么是业务能力 ·····································59

4.2.4 定义业务能力········································60

4.2.5 什么是业务能力模型 ································62

4.2.6 将能力映射到其他业务角度 ························64

4.2.7 什么是价值流········································64

4.2.8 价值流的优势········································65

4.2.9 定义价值流 ··········································66

4.2.10 分解价值流 ·········································67

IX
TOGAF®标准第 10 版口袋指南（中文版）

4.2.11 将价值流映射到能力 ·······························69

4.2.12 信息映射············································70

4.2.13 组织映射············································71

4.2.14 业务场景············································74

4.3 数据/信息架构 ········································75

4.3.1 文档 ··················································75

4.3.2 客户主数据管理（C-MDM） ·······················76

4.4 敏捷方法 ···············································76

4.4.1 文档 ··················································76

4.4.2 敏捷性是什么意思，为什么如此重要 ··············77

4.4.3 不同的细节级别激活敏捷性 ························78

4.4.4 构建敏捷企业架构的一种方法 ·····················80

4.4.5 映射到敏捷概念 ·····································83

4.4.6 敏捷产品管理········································84

4.4.7 如何在冲刺中使用 TOGAF ADM···················86

4.5 TOGAF 标准参考模型和方法 ·····················88

4.5.1 文档 ··················································88

4.5.2 数字化业务参考模型（DBRM） ···················89

4.5.3 政府参考模型········································92

4.5.4 架构成熟度模型 ·····································95

X
 目录

4.5.5 架构项目管理········································96

4.5.6 架构技能框架········································97

第 5 章 TOGAF 基本内容 ·································99

5.1 简介和核心概念 ······································99
5.2 架构开发方法（ADM）·························· 101
5.3 ADM 技术 ··········································· 101
5.3.1 利益相关者管理 ··································· 102

5.3.2 差距分析 ··········································· 104

5.3.3 迁移规划技术······································ 105

5.3.4 风险管理 ··········································· 110

5.3.5 架构替代方案与权衡 ·······························111

5.4 应用 ADM ··········································· 112

5.4.1 架构风格 ··········································· 112

5.4.2 迭代和 ADM ······································· 114

5.4.3 在架构景观中应用 ADM ·························· 119

5.4.4 架构分区 ··········································· 120

5.5 架构内容 ············································· 121

5.5.1 内容框架概述······································ 123

5.5.2 架构工作产物······································ 124

5.5.3 企业连续序列······································ 125

XI
TOGAF®标准第 10 版口袋指南（中文版）

5.5.4 架构存储库 ········································ 126

5.6 企业架构能力和治理 ······························ 127

5.6.1 架构能力 ··········································· 128

5.6.2 架构治理 ··········································· 129

5.6.3 架构委员会 ········································ 130

第 6 章 TOGAF 架构开发方法 ························· 132

6.1 什么是 ADM ········································ 132
6.2 ADM 包括哪些阶段 ······························· 134
6.3 ADM 详细介绍 ···································· 135
6.3.1 预备阶段 ··········································· 136

6.3.2 阶段 A：架构愿景································· 137

6.3.3 阶段 B：业务架构 ································· 139

6.3.4 阶段 C：信息系统架构 ··························· 141

6.3.5 阶段 D：技术架构 ································ 144

6.3.6 阶段 E：机会和解决方案 ························ 145

6.3.7 阶段 F：迁移规划 ································· 147

6.3.8 阶段 G：实施治理································· 149

6.3.9 阶段 H：架构变更管理 ··························· 151

6.3.10 需求管理·········································· 152

第 7 章 ADM 交付物······································ 155

XII
 目录

7.1 裁剪的架构框架 ···································· 157

7.2 企业架构的组织模型 ······························ 158
7.3 架构原则 ············································· 159
7.3.1 架构原则的概念 ··································· 159

7.3.1 定义架构原则······································ 161

7.4 业务原则、目的和驱动因素····················· 163

7.5 架构工作要求书 ···································· 163
7.6 架构工作说明书 ···································· 165
7.7 架构愿景 ············································· 166
7.8 沟通计划 ············································· 167
7.9 能力评估 ············································· 168
7.10 架构定义文档 ····································· 170
7.10.1 业务架构·········································· 172

7.10.2 信息系统架构 ···································· 173

7.10.3 技术架构·········································· 174

7.11 架构需求规范······································ 175

7.11.1 业务架构需求 ···································· 176

7.11.2 信息系统架构需求 ······························· 177

7.11.3 技术架构需求 ···································· 178

7.11.4 互操作性需求 ···································· 178

XIII
TOGAF®标准第 10 版口袋指南（中文版）

7.12 架构路线图········································· 178

7.13 架构构建块········································· 180
7.14 解决方案构建块 ·································· 181
7.15 实施和迁移计划 ·································· 182
7.16 过渡架构············································ 184
7.17 实施治理模型 ····································· 185
7.18 架构合同············································ 186
7.19 变更要求············································ 188
7.20 合规性评估········································· 189
7.21 需求影响评估 ····································· 190
附录 A 词汇表和首字母缩略词 ························· 192

XIV
 第1章 简介

第 1 章 简介

本章介绍了 TOGAF®标准，一个凝聚行业共识的开
放企业架构框架。
本章内容包括：
• TOGAF 标准简介
• TOGAF 文档集的结构
• TOGAF 标准概述
• TOGAF 库
• TOGAF 框架概述
• 如何阅读 TOGAF 标准

1.1 TOGAF 标准简介

TOGAF 标准是一个企业架构框架。简单来说，它

1
TOGAF®标准第 10 版口袋指南（中文版）

是一种用于开发、认证、使用和维护企业架构的标准方
法，适用于所有企业架构实践。它以最佳实践支持的迭
代流程模型以及一套可复用的现有架构资产为基础。
TOGAF 标准由 The Open Group 架构论坛的成员开
发和维护。1995 年，第一版 TOGAF 标准在美国国防部
信息管理技术架构框架（TAFIM）的基础上诞生。在此
基础上，The Open Group 架构论坛又连续定期开发了
TOGAF 标准的后续版本，并将每个版本发布在 The
Open Group 的公共网站上。接连发布的版本反映了最佳
实践的当时状态是稳定的、可扩展的。
本版本以此前几个版本的 TOGAF 标准为基础，扩
展并更新了可供架构从业者使用的资料，以帮助其创建
可持续的企业架构。

1.2 TOGAF 文档集的结构

TOGAF 文档集的结构旨在实现从常见通用概念到
组织内个性化配置的过渡。它包括正式的 TOGAF 标准

2
 第1章 简介

和 TOGAF 库中更广泛的知识体系，如图 1-1 所示。

图 1-1 TOGAF 文档集

TOGAF 标准代表了当今稳定、可扩展的最佳实践，
其概念和指南适用于各个行业内具有不同规模和变革速
度的各个组织。这正是作为标准的作用和意义，即提供
经过验证的实践、稳定的概念和可操作性。TOGAF 标
准提供了一套经过验证的实践体系，以应对其广泛的用
途。TOGAF 基本内容介绍了企业架构的通用概念。

3
TOGAF®标准第 10 版口袋指南（中文版）

TOGAF 系列指南采用了这些概念并使其具有可操作
性。TOGAF 基本内容和 TOGAF 系列指南共同构成
了 TOGAF 标准。
之所以将 TOGAF 标准划分成多个独立文档，是为
了对不同专业领域进行详细考量，并在可能的情况下单
独处理。虽然所有组成文档作为一个整体发挥作用，但
也可以在实际应用中单独使用某些文档。
TOGAF 文档集采用了模块化结构。从 TOGAF 基本
内容中的通用概念到 TOGAF 系列指南中稳定的最佳实
践，再到 TOGAF 库中的新兴想法，它的层次结构非常
清晰。TOGAF 文档集的结构使得用户采用最佳方法更为
容易。

1.3 TOGAF 标准概述

TOGAF 标准适用于全部企业架构实践。无论您的
架构是否用于支持战略、项目组合、项目或解决方案交
付，或者用于开始数字化转型或简化遗留问题。TOGAF

4
 第1章 简介

基本内容和 TOGAF 系列指南提供了持久、稳定的通用

概念和业经验证的最佳实践。

1.3.1 TOGAF 基本内容

TOGAF 基本内容由六个文档组成，如表 1-1 所示。

TOGAF 基 本 内 容 的 核 心 是 TOGAF 架 构 开 发 方 法
（ADM）
，它为架构开发提供了一个经过测试并且可重复
使用的流程。

表 1-1 TOGAF 基本内容文档

文 档 概 述

该文档介绍了 TOGAF 标准，综合介绍了企

TOGAF 标准：简介和核心 业架构和 TOGAF 标准；描述了 TOGAF 文
概念（见第 5.1 节） 档集的结构和框架的核心概念以及适用于基
本内容的术语和定义

TOGAF 标准：架构开发方 该 文 档 描 述 了 TOGAF 架 构 开 发 方 法

法（见第 6 章） （ADM）—一种迭代式的企业架构开发方法

TOGAF 标准：ADM 技术 该文档包含一系列有助于应用 TOGAF 方

（见第 5.3 节） 法和 TOGAF ADM 的技术

TOGAF 标准：应用 ADM 该文档提供了根据实际背景环境中所需

（见第 5.4 节） 的特定架构风格调整 TOGAF ADM 的指南

5
TOGAF®标准第 10 版口袋指南（中文版）

（续）
文 档 概 述

TOGAF 标准：架构内容 该文档描述了 TOGAF 内容框架（架构制品

（见第 5.5 节） 的结构化元模型）以及典型架构交付物的概况

该文档论述了在企业内建立和运行架构职
TOGAF 标准：企业架构能
能所需的组织、流程、技能、角色和职责，并
力和治理（见第 5.6 节）
介绍了企业架构治理框架

TOGAF 基本内容的作用是提供基本概念以及稳定、
持久且成熟的最佳实践。TOGAF 基本内容中的概念普遍
适用于 TOGAF 框架。

1.3.2 TOGAF 系列指南

TOGAF 系列指南由一系列最佳实践文档组成，它
将有望随着构成 TOGAF 标准的专业知识体系引入更
多稳定的最佳实践而逐渐扩展。
TOGAF 系列指南的作用是在 TOGAF 基本内容
的基础上，为特定主题、关注点和用例提供扩展的指南。
本指南材料涵盖的主题领域如图 1-2 所示。

6
 第1章 简介

图 1-2 TOGAF 标准

1.3.3 文档集概述

TOGAF 标准文档集概述如表 1-2 所示。文档类型

大体分类如下：
• 通用操作指南（见第 2 章）
。
• 组建企业架构团队（见第 3 章）
。
• 特定域的指南（见第 4 章）
。
• TOGAF 基本内容（见第 5 章）
。
此分类法也用于组织本书的章节内容。

7
TOGAF®标准第 10 版口袋指南（中文版）

表 1-2 对特定域的指南进行了分类，并在表 1-3 中

进行了总结。

表 1-2 TOGAF 标准文档集概述

通用
组建 EA TOGAF
文 档 操作 SA BA IA AM RM
团队 基本内容
指南
TOGAF 系 列 指
南：遵循 TOGAF®
X
ADM 开发企业架
构的从业者方法

TOGAF 系 列 指
南：在数字化企业中 X
应用 TOGAF 标准

TOGAF 系 列 指
南：数字技术采用：
X
就绪度评估和路线
图开发指南

TOGAF 系 列 指
南：建立并演进企业
X
架构能力的 TOGAF®
领导者指南

TOGAF 系列指南：
在 TOGAF 企业架构 X
中集成风险和安全

8
 第1章 简介

（续）
通用
组建 EA TOGAF
文 档 操作 SA BA IA AM RM
团队 基本内容
指南
TOGAF 系 列 指
X
南：业务模型

TOGAF 系列指南：
X
业务能力，第 2 版

TOGAF 系 列 指
X
南：价值流

TOGAF 系 列 指
X
南：信息映射

TOGAF 系 列 指
X
南：组织映射

TOGAF 系 列 指
X
南：业务场景

TOGAF 系列指南：
信息架构：
客户主数据 X
管理（C-MDM）

TOGAF 系 列 指
X
南：
实现企业敏捷性

TOGAF 系 列 指
南：使用敏捷 Sprint X
应用 TOGAF ADM

9
TOGAF®标准第 10 版口袋指南（中文版）

（续）
通用
组建 EA TOGAF
文 档 操作 SA BA IA AM RM
团队 基本内容
指南
TOGAF 系列指
南：TOGAF 数字
X X
化业务参考模型
（DBRM）

TOGAF 系 列 指
X X
南：政府参考模型

TOGAF 系 列 指
X
南：
架构成熟度模型

TOGAF 系 列 指
X
南：架构项目管理

TOGAF 系 列 指
X
南：架构技能框架

TOGAF 标准：简
X
介和核心概念

TOGAF 标准：架
X
构开发方法

TOGAF 标 准 ：
X
ADM 技术

TOGAF 标准：应
X
用 ADM

10
 第1章 简介

（续）
通用
组建 EA TOGAF
文 档 操作 SA BA IA AM RM
团队 基本内容
指南
TOGAF 标准：架
X
构内容

TOGAF 标准：企
X
业架构能力和治理

表 1-3 表 1-2 中有关特定域指南的纵列术语解释

特定域的指南
SA = 安全架构 BA = 业务架构
IA = 数据/信息架构 AM = 敏捷方法
RM = 参考模型和方法

1.4 TOGAF 库

TOGAF 库 为 标 准 提 供 了 其 他 配 套 资 源 。 尽 管
TOGAF 系列指南是经过验证的、稳定的最佳实践，但
TOGAF 库还提供了新的想法、指南、模板、模式和其他
形式的参考材料，以加快新架构在企业中的创建。

11
TOGAF®标准第 10 版口袋指南（中文版）

TOGAF 库遵循基于能力和特性的分类模型，如
图 1-3 所示。

图 1-3 TOGAF 库分类

TOGAF 库还包含在 The Open Group 开发的其他材

《The Open Group IT4IT™ 参考架构》
料中；例如， 《The
Open Group 商用航空参考架构》
《O-PAS™ 标准》
。这些
参考架构由各行各业的专家开发，可供直接采用或用作
参考示例。
TOGAF 库中的新的想法通常以白皮书的形式呈
现。此类材料要么未经时间考验，要么是有些成员将
想法开发到可用的程度、又将创新思维转移到了新想
法上。
TOGAF 库中的所有文档都可以按原样使用，也可
以作为开发组织企业架构的切入点。

12
 第1章 简介

1.5 TOGAF 框架概述

TOGAF 框架反映了企业架构能力的结构和内容，
如图 1-4 所示。

图 1-4 TOGAF 框架概述

该框架的核心是 ADM（见第 6 章）
。企业架构能力
和治理（见第 5.6 节）负责运行该方法。该方法由 ADM

13
TOGAF®标准第 10 版口袋指南（中文版）

技术（见第 5.3 节）
、应用 ADM 指南（见第 5.4 节）
、
TOGAF 系列指南（见第 1.3.2 节）和 TOGAF 库（见第
1.4 节）提供支持。以这种方式生成的内容会被存储为架
构内容（见第 5.5 节）
。

1.6 如何阅读 TOGAF 标准

本节为接触此版本 TOGAF 标准的读者提供了简

要指南。
建议第一次接触企业架构主题的读者阅读白皮书
，可从 TOGAF 库获取，网址
《为什么企业架构很重要》
为 https://www. opengroup.org/library/w076。
建议第一次接触 TOGAF 标准的读者结合《TOGAF
标准—简介和核心概念》（基本内容的一部分）阅读
本书。
建议所有读者（包括熟悉 TOGAF 标准早期版本的
读者）阅读《TOGAF 标准第 10 版简介》白皮书，可
从 TOGAF 库 获 取 ， 网 址 为 https://www.opengroup.

14
 第1章 简介

org/library/ w212。

接下来，我们提供了面向企业架构师、企业架构团
队领导者和企业架构团队发起人的指南：

1.6.1 企业架构师

TOGAF 标准的目标受众是关心为其所在组织开发
企业架构的企业架构师。它可以帮助读者直观地了解如
何开发、批准和使用企业架构。
首 先 最 好 获 取 一 份 《 TOGAF 系 列 指 南 ： 遵 循
TOGAF®ADM 开发企业架构的从业者方法》
，其第 3 章
和第 6 章为 TOGAF 标准、TOGAF 基本内容、其他
TOGAF 系列指南和 TOGAF 库中的所有内容的应用奠
定了基础。
接下来阅读《TOGAF 系列指南：在 TOGAF 企业
架构中集成风险和安全》
。风险和安全是每位企业架构从
业者都应关注的重点。每位从业者都有责任提高其组织
的绩效。从业者有责任降低组织目标实现过程中的不确
定性并提高安全性。

15
TOGAF®标准第 10 版口袋指南（中文版）

然后获取适用于您工作的指南，这些指南适用于各
自专攻的问题或领域。如果您的组织具有数字化举措，
请参考特定的数字化指南。如果您需要支持敏捷开发，
请参考敏捷指南。如果您是业务架构师，请参考业务架
构指南。如果您是数据架构师，那么《TOGAF 系列指
南：信息架构：客户主数据管理（C-MDM）
》可能会有
所帮助。
最后，探索 TOGAF 库。您可以查找那些能够直接
帮助其完成工作或展示有效方法的文档。二者都能让您成
为更好的企业架构师。在任何时候，TOGAF 基本内容都
能提供一致的框架。

1.6.2 企业架构团队领导者

领导者面临着优化企业架构能力和培养从业者的
挑战。
本小节为企业架构团队领导者提供了有关如何上手
使用此版 TOGAF 标准的简明指南。
《TOGAF 系列指南：建立并演进企业架构能力的

16
 第1章 简介

TOGAF® 领导者指南》能够确保您清楚地了解企业架
构团队的目的（第 3.3 节）以及企业的边界（第 4.1 和
4.2 节）
。
确定您在交付组织期望的企业架构方面存在的任何
能力差距，并思考如何填补这个差距。您可能会发现以
《在 TOGAF® 企业架构中
下 TOGAF 系列指南很有用：
集成风险和安全》和《在数字化企业中使用 TOGAF 标
准》
。高效的企业架构团队总能降低组织目标实现过程中
的不确定性并提高安全性。如果您的组织还没开启数字
化转型之旅，那么您应期待它很快会开始。
下一步是获取适用于您的团队的指南，熟悉其中的
内容并将它们分发给您的团队。

1.6.3 企业架构团队发起人

企业架构团队发起人深知，他们可以通过企业架构
提高组织制定变革决策和执行变更的能力，因此他们是
企业架构团队的拥护者。大多数发起人自身不是企业架
构从业者或企业架构团队领导者，因此面临更多挑战：

17
TOGAF®标准第 10 版口袋指南（中文版）

因为大多数人只想要结果，而不清楚具体工作过程。
阅读《TOGAF 系列指南：建立并演进企业架构能
力的 TOGAF®领导者指南》
。您应该明确企业架构团队的
目的（第 3.3 和 8.2 节）
、企业的边界（第 4.1 和 4.2 节）
以及如何衡量成功（第 5.4 节）
。此外，您需要协助改善
治理结构（第 6 章）
。

18
 第2章 通用指导信息

第 2 章 通用指导信息

本章介绍了 TOGAF 标准提供的通用指导信息，这

些内容如表 2-1 所示。

2.1 文档

表 2-1 TOGAF 通用指导文档

文 档 概 述
本文档专门面向负责开发、维护和使用企
业架构的从业者。
“从业者”一词是经过深思
熟虑的选择，反映了一个人的角色，而不是
从业者可能在企业中担任的某个职位
TOGAF 系列指南：遵循 该文档提供了有关使用 TOGAF 框架开
TOGAF®ADM 开发企业架 发、维护和使用企业架构的指南。它是
构的从业者方法 TOGAF 框架的配套材料，旨在更加生动地
解释 TOGAF 框架中的概念和通用结构。它
提出了一种开发、维护和使用企业架构的方
法，这种方法可以帮助满足利益相关者的一
系列需求和期望，并支持创造可预测的价值

19
TOGAF®标准第 10 版口袋指南（中文版）

（续）
文 档 概 述
该文档专门面向企业架构师和数字从业者
它阐述了哪些架构实践有助于发展数字
TOGAF 系列指南：在数
化企业，以及企业架构师角色如何支持数字
字 化 企 业 中 应 用 TOGAF
化企业。它可以指导用户协调使用 TOGAF
标准
标准与数字从业者知识体系™ 标准（也称
为 DPBoK™ 标准）
该文档为企业架构师提供了一种领导和
指导数字化转型评估流程的技术
TOGAF 系列指南：数字 该文档涵盖了任何组织采用数字技术的
技术采用：就绪度评估和路 关键原则。该文档的应用在设计上保持技术
线图开发指南 中立。该文档的读者将获得一个支持数字技
术采用的明确路线图。该文档的目的是方便
读者使用就绪度评估作为工具包

2.2 什么是企业架构

简而言之，企业架构描述了企业的未来状态，以指导
达到该未来状态需要做出哪些调整。这种描述使关键人员
能够了解企业必须具备哪些条件才能在企业运营环境中
实现企业的目的、目标、使命和愿景。企业当前状态和未

20
 第2章 通用指导信息

来状态之间的差距指导着企业必须在内部做出哪些转变。

2.3 为什么要开发企业架构

开发企业架构的原因非常简单：指导有效的变革。
所有企业都在寻求改进。无论是上市企业、私营企
业还是社会组织，都需要通过深思熟虑的有效变革来实
现改进。这种改进可能体现在私营企业的股东价值或敏
捷性上，或者上市企业的价值主张或效率上，也可能只
是社会组织在使命上的改进。
有效的变革指导与经批准的企业架构活动是同步进
行的。在实施过程中，利益相关者会使用企业架构来治
理变革。治理的第一步是指导变革活动—使变革路线
与实现预期价值的最佳路径保持一致。治理的第二步是
控制变革活动—确保变革不偏离最佳路径。
改进工作的范围为一切任务的完成提供了驱动力。
如果一种方法可以验证企业的目标和变革，确保两者的
可行性，那么它自然也会经济高效地交付期望的价值。

21
TOGAF®标准第 10 版口袋指南（中文版）

架构化方法提供了严格的规划和变革治理方法。

2.4 企业架构的目的

企业架构具有以下四大用途：
• 企业架构支撑战略：交付企业架构提供端到端的
目标架构，并形成更长时间内的变革路线图，
比如，三年或更长。此类架构通常会涵盖多项变
革计划或项目组合。从这个角度来说，该架构可
用于确定变革举措、支持性项目组合和项目群、
职责范围以及协同工作，并通过项目组合和项目
群治理战略的执行。
• 企业架构支撑项目组合：交付企业架构支持跨职
能、跨阶段和跨项目的变革举措。此类架构通常
涵盖多个项目组合。从这个角度来说，该架构可
用于确定项目、设置职责范围、统一方法、确定
协同工作以及治理项目的执行。
• 企业架构支撑项目：交付企业架构支持企业的项

22
 第2章 通用指导信息

目交付方法。此类架构通常涵盖多个项目。从这
个角度来说，该架构可用于阐明项目的目的和价
值，确定解决协同工作和未来依赖关系的要求，
保障在架构治理方面的合规性，并支持项目之间
的集成和一致性。
• 企业架构支撑解决方案交付：交付企业架构用于支
持解决方案的部署。此类架构通常是单个项目或该
项目的重要组成部分。从这个角度来说，该架构可
用于定义变革的设计和交付方式，确定对设计的约
束、控制和架构需求，最后充当变革的治理框架。

2.5 开发企业架构

企业架构开发工作是一个迭代的过程。企业架构的
各部分是在不同架构项目㊀下单独开发的。每个架构项目

㊀ 不要拘泥于“项目”一词的定义或项目是什么。这只是为实现可理解
的结果而开展的组织工作。不同组织对项目的内部定义以及使用的标
签可能并不一样。

23
TOGAF®标准第 10 版口袋指南（中文版）

都对企业架构进行了扩展或更新，以实现有效的变革。因
此，架构开发方法的核心就是创建有用的信息，包括架构
描述、约束因素或可用的指导。最佳实践可以将信息的收
集和分析限制在解决手头问题所需的最低限度。架构师应
采用增量法，当使用综合企业架构生成的结果指导改进组
织的变革时，所付出的努力会收获最高的价值回报。
架构开发方法专门用于确定开发部分企业架构所需
的信息，以及创建一致的输入和输出信息的步骤。
TOGAF 标准对架构开发方法的每个阶段分别进行了描
述，以明确它们的输入、步骤和输出，而不是为了机械
地描述一连串的工作。

2.6 阶段 A：起点

根据 ADM（见第 6 章）进行的所有架构开发都需
要从 TOGAF ADM 的阶段 A（见第 6.3.2 节）开始。
如果没有阶段 A 的固有设置，从业者可能会偏离正轨，
无法交付有用的架构。

24
 第2章 通用指导信息

阶段 A 的设置要领如下：
• 定义架构项目的范围。您要解决哪些问题？要
从企业架构景观（广度和规划周期）以及目的
的角度来定义这个问题，注意要确认必要的信
息详细程度。要完全清楚该架构将在业务周期
中的哪个阶段使用。
• 识别利益相关者、关注点和业务需求。探索企业
架构存储库，了解来自上级架构的约束和指导。
制定利益相关者映射图，了解必须为哪些利益相
关者提供服务及其关注点是什么。
• 评估企业架构团队的能力。严格审核企业架构团
队，确认团队在交付此架构开发项目方面的能力
水平。一个优秀的企业架构团队可以弥补经验和
技能方面的差距，消除偏见，克服团队中少数成
员的弱点，从而交付有用的架构。
阶段 A 的目标达成要素：主要利益相关者就目标摘
要和实现目标所需完成的工作达成共识。
在所有领域充分开展架构开发工作，与关键利益相
关者沟通如何解决分配给您的问题，并确认符合其偏好

25
TOGAF®标准第 10 版口袋指南（中文版）

的变革范围。明确目标、目标的价值以及促进变革所需
完成的工作。

2.7 ADM 基本输出

表 2-2 对基本成果和输出进行了总结。这些成果源
自 ADM 阶段的目标（见 6.3 节）
。

表 2-2 基本的 ADM 输出、成果和知识

阶 段 输出与成果 基本知识
正在解决的问题的范围
与正在解决的问题有根本
允 许 继 续 进行 工作 的
利益关系的人（利益相关者和
充分文档凭证
关注点）
继续开发目标架构（以
利益相关者在该问题上可
阶段 A：架构愿 证明摘要目标）的许可
以接受哪些总结性答案（架构
景（见第 6.3.2 节） 允 许 继 续 进行 工作 的
愿景）
充分文档凭证
利益相关者的优先级和
继续开发目标架构（以
偏好
证明摘要目标）的许可
该总 结 性 答 案 能 带 来 哪
些价值

26
 第2章 通用指导信息

（续）
阶 段 输出与成果 基本知识
当前的企业为什么未能满
足利益相关者的偏好
为了使企业能够满足利益相
利 益 相 关 者为 正在 解 关者的偏好，必须做出哪些变
阶段 B、阶段 C 决的问题批准的一组域 更（差距）
和阶段 D（见 6.3.3 架构，其中包括一系列的 必须做哪些工作才能实现
节、6.3.4 节、6.3.5 差距以及消除利益相关 这些变更，并与所创造的附加
节） 者眼中的差距需要完成 价值相符（工作包）
哪些工作 利益相关者的优先级和偏
好如何随着价值、努力和变
更风险而调整（利益相关者
的需求）
一系列变更之间的依赖关系
用于弥补差距的一系
（工作包和差距的依赖关系）
列工作包，指明了达到
阶段 E：机会和 与每项变更和每个工作包
调整后的目标后创造的
解决方案（见第 相关的价值、努力和风险
价值和所需做出的努
6.3.6 节） 利益相关者的优先级和偏
力，以及工作包之间的
好如何随着价值、努力和变更
依赖关系
风险而调整
可用于实施变更的资源
一组经批准的项目，其
阶段 F：实施和 利益相关者的优先级和偏
中包含目标和任何必要
迁移计划（见第 好如何随着价值、努力和变
的限制、所需的资源以及
6.3.7 节） 更风险而调整（利益相关者
开始和结束日期
的需求）
实施团队的目的和面临的约
成功结项：只有完成这 束（差距、架构需求规范、控制）
阶段 G：实施治
些项目，才能实施达到目 利益相关者的优先级和偏好如
理（见第 6.3.8 节）
标状态所需的变更 何随着成功、价值、努力和变更
风险而调整（利益相关者的需求）

27
TOGAF®标准第 10 版口袋指南（中文版）

（续）
阶 段 输出与成果 基本知识
继 续 开 发 目标 架构 的 获批的目标（或偏好）与先
方向，目的是解决企业中 前工作实现的价值之间的差
阶段 H：架构变更
与利益相关者偏好相对 距（价值实现）
管理（见第6.3.9 节）
应的可能存在、真实存在 偏好或优先级的变化（利益
或预期存在的短板 相关者的需求）

2.8 数字化企业的战略

任何组织都可以通过制定以下两个战略来提高数字
化企业的成功率。
1．前瞻战略
第一个战略是“架构赋能”法。赋能的形式是，使
用有关风险、标准和最佳实践的指南，根据背景环境交
付最简单可行的数字产品，同时展望未来，以确保支持
顺利过渡到下一种背景环境。这并非阻止进展，而是要
确保当前能够在适当了解潜在问题和困难的情况下制定
决策。这个战略可以由担任架构师角色的人来落实。即
使在 DPBoK 标准的“个人/初创者”背景中，个人/初创

28
 第2章 通用指导信息

者也可以临时提供企业架构师交付的业务分析。
2．企业架构即服务战略
第二个战略是对第一个战略的强化，通过按需开发
足够的架构来支持数字化工作的运营节奏。通过承担企
业架构师角色的人员提供的企业架构服务交付模型可以
实现这点。它可以通过支持咨询的方式完成。这一点在
以下两个层面尤其重要：
• 在“复杂团队”层面，架构师可以提供服务，增
强跨团队沟通并减少团队合作的认知负担。
• 在大型组织中，作为创新/孵化战略的一部分，为
初创者/团队提供咨询服务。

2.9 支持数字化企业

本节提供了有关使用 TOGAF 标准支持数字化企业

的见解，它参考了《TOGAF 系列指南：在数字化企业
中使用 TOGAF 标准》并与 DPBoK 标准保持一致。
DPBoK 标准确定了组织向数字化企业发展的四种

29
TOGAF®标准第 10 版口袋指南（中文版）

背景环境：
• 背景环境 I：个人/初创者。
• 背景环境 II：团队。
• 背景环境 III：复杂团队。
• 背景环境 IV：长青企业。
这些背景环境层层递进，企业从早期背景环境逐步
进入下一个成功层级。DPBoK 标准称其为扩展模型。企
业架构可以通过前瞻战略（在 2.8 节中定义）来支持这
种扩展模型。企业架构师不仅要支持特定背景环境，还
要考虑下一层级，并让数字从业者充分了解如何定位才
能实现自身发展。在扩展模型的较高层级，企业架构师
可以在支持跨团队沟通方面发挥至关重要的作用，并且
不会增加各个团队的认知负担。此外，企业架构师可以
确保清楚地识别和传达风险，以便在适当了解潜在问题
和困难的情况下制定决策。

2.9.1 背景环境 I：个人/初创者

“个人/初创者”背景环境解决了“开发和维持基础

30
 第2章 通用指导信息

数字产品所必须解决的最基本问题”
。这种背景环境代表
了交付数字价值的最低要求。
这种背景环境的关键主题是：
• 数字化价值的概念。架构经常用作一种交流媒
介。架构模型可以很好地沟通和传达。此外，企
业架构师是一名沟通者，是重要的企业联络员。
• 数字基础设施和相关实践（快速向市场交付价值的
基本基础设施和流程选择）
。企业架构提供了必要
的描述来传达可用的基础架构及其在开发和交付
过程中的适当用途。企业架构师还可以帮助识别可
嵌入至大型组织中的个人/初创者的现有基础设施
方法，并将经过审查的技术要求传达给基础设施组
织，以确保为运行新的工作负载做好准备。
• 敏捷开发和持续交付实践。企业架构通常用于支
持和回答有关敏捷开发和持续交付的问题。企业
架构师（如果适用于个人/初创者）通常会根据其
实践经验，在这些领域按需提供指导。
在这种背景环境下，企业架构工作必须能够支持项
目有效、高效地交付数字产品/解决方案。为了支持这种

31
TOGAF®标准第 10 版口袋指南（中文版）

背景环境，担任企业架构师的人员有责任确保风险被理
解并且决策是在理解风险的情况下做出的。
有关 TOGAF 标准如何支持企业敏捷性的更多详细
信息，请参阅《TOGAF®系列指南：实现企业敏捷性》
和《TOGAF®系列指南：使用敏捷 Sprint 应用 TOGAF®
ADM》
。另请参考 4.4 节。

2.9.2 背景环境 II：团队

团队的任务单一、凝聚度高，完成工作并不需要大
量开销。
“团队”背景环境涵盖了协作式产品团队在保持
可管理的人力规模的同时取得成功所必需的基本要素。
“团队”背景环境关注的关键主题是：
• 产品管理。
产品架构一直是协助制定产品管理决策
的主要内容。企业架构可以提供架构模型，映射至
给定数字产品配置文件。此外，企业架构明确了相
互依赖关系，确保形成数字产品的整体视图。
• 工作执行管理。企业架构通常用于描述流程和工
作流，信息详细程度从非常简单到非常复杂不

32
 第2章 通用指导信息

等。在“团队”背景环境下，人们可以构建非常
简单的模型来帮助沟通工作流和流程；虽然这不
是最佳工作管理形式，但在小团队中也不失为一
种有效的沟通方式。
• 运营管理。企业架构师一直是管理运营的重要贡
献者。在“团队”背景环境下，企业架构工作必
须能够支持项目在多人参与的环境中有效且高
效地交付数字产品/解决方案—沟通是必不可
少的。在这种背景环境下，企业架构师发挥的作
用更大，能确保团队成员了解风险并在了解风险
的情况下做出决策。而且，鉴于“团队”背景环
境涉及更多人员，企业架构师还会多添一份确保
沟通和协作有效性的责任。因此，在建模和编档
方面达成理解上的共识对于支持产品管理、工作
执行和运营理解变得尤为重要。

2.9.3 背景环境 III：复杂团队

跨“复杂团队”进行协调是担任企业架构师角色的

33
TOGAF®标准第 10 版口袋指南（中文版）

人员使用企业架构和 TOGAF 标准解决的主要问题。很

多时候，协调机制（例如过度以流程为中心的运营模式）
会降低团队凝聚力和绩效。在过度复杂的协调与确保数
字产品系列成功开发之间进行平衡是非常重要的。
这种背景环境的关键主题是：
• 组织和文化因素。组织因素尤其是文化问题通常是
影响流程设计的重要驱动因素，在跨国或跨区企业
中尤其如此。在某些情况下，可能需要通过不同的
方式尊重文化差异。包括改变基本流程、采用不同
的利益相关者交互和管理方法，或者改变设计。如
果一个组织加强在价值生成方面的共识，那么只要
予以各个组成部分充分的尊重，许多文化问题就会
迎刃而解。企业架构有助于解决所有这些问题。
• 协调与处理机制。企业架构用于描述流程和控制
机制，可以帮助识别和消除瓶颈，并支持持续的
流程改进。
• 多团队结构的投资和项目组合带来的影响。描述产
品组合的企业架构是项目组合管理中的关键资源。

34
 第2章 通用指导信息

这种对相互依赖关系（价值生成和成本等）的全面
描述能够为项目组合管理决策提供有效支持。
在“复杂团队”背景环境下，企业架构和担任企业
架构师角色的人员将继续确保所有团队了解风险并进行
有效的沟通。

2.9.4 背景环境 IV：长青企业

“长青企业”背景环境的核心在于如何管理一家已获
得成功、但又努力尝试在比下一个产品周期更长的时间
内运营可持续业务的企业。
此背景环境关注的关键主题领域是：
• 治理、风险、安全和合规。风险（包括安全风险）
管理常常通过治理和合规性来完成。合规标准可
以来源于（公司）内部，也可以来源于公司外部
（如法律法规）
。一个优秀的企业架构会提供必要
的合规标准评估业务流程、信息技术和人力资源
合规性。
• 信息管理。信息系统在任何企业架构中都是一个

35
TOGAF®标准第 10 版口袋指南（中文版）

至关重要的领域，它涵盖了数据和应用架构；此
域用于指导解决信息管理问题。
• 架构和项目组合管理。描述产品项目组合的企业
架构是项目组合管理中的关键资源。这种对相互
依赖关系（价值生成和成本等）的全面描述能够
为项目组合管理决策提供有效支持。考虑到企业
架构的成本，这项活动本身代表了项目组合中一
些应在“长青企业”背景环境中管理的东西。
为了支持长青企业，企业架构将其作用扩展到整体
战略和治理中。它必须支持上述内容以及其他企业问题，
例如处理第三方、对合并和收购的影响分析等。

2.9.5 根据背景环境应用 TOGAF 原则

图 2-1 确定了哪些 TOGAF 原则最适用于 DPBoK 标

准的每种背景环境。

2.9.6 在数字化企业中应用企业架构服务

企业架构服务是企业架构能力的交付机制。在本节

36
 第2章 通用指导信息

中，我们列出了 TOGAF 标准支持的、可用于 DPBoK 标

准中各种背景环境的企业架构能力。

图 2-1 TOGAF 原则与 DPBoK 标准背景环境的对应关系

图 2-2 总结了在交付企业架构能力时应根据背景环
境考虑的企业架构服务。

37
TOGAF®标准第 10 版口袋指南（中文版）

图 2-2 DPBOK 标准涌现模型的企业架构服务

38
 第2章 通用指导信息

图 2-3 总结了每个背景环境下的企业架构服务，并
搭建了企业架构服务涌现模型。

图 2-3 企业架构服务涌现模型

39
TOGAF®标准第 10 版口袋指南（中文版）

2.10 影响数字技术采用的因素

《TOGAF 系列指南：数字技术采用：就绪度评估和
路线图开发指南》提供了一种叫作“数字化转型就绪度
评估（DTRA）
”的技术，企业架构师可以使用该技术来
领导和指导数字化转型的评估过程。它可以帮助企业审
视自身在多大程度上准备好了迎接采用数字技术带来的
变化。这为组织开展大规模转型的就绪度提供了一个可
量化的度量，并明确了需要消除的差距。组织在不了解
是否有适当的资源和条件来有效完成转型并持续获得全
部优势的情况下，可能不会想去启动大规模转型计划。
DTRA 中定义的用于评估企业数字技术就绪度的因
素可分为以下几类：
• 基本因素：在数字技术采用过程中，确保组织达
到最低可接受就绪度的必备因素。
• 影响因素：通过提供支持条件来增强或扩大主要
因素效能的因素。

40
 第2章 通用指导信息

• 支持因素：将采用数字技术制度化，以实现可持
续的长远利益的因素。
在表 2-3 中，各种因素按类别进行了排列。图 2-4
展示了这些因素之间的关系和依存状态。
表 2-3 因素分类
基本因素 影响因素 支持因素
愿景 业务模型适应性 价值实现
发起和指导 技能和胜任力 政策与法规
IT 能力 技术成熟度 资金与资源
文化 生态系统
范围和规模 治理与合规性
业务原则
实施方法

2.11 数字技术采用路线图

第 1 步：选择采用方法
组织必须选择一种采用方法，以帮助其采用所需的
“ABCD”框架（如图 2-5 所示）适用于具有
数字技术。
不同数字技术采用战略的各种类型的组织。

41
TOGAF®标准第 10 版口袋指南（中文版）

图 2-4 DTRA 因素依赖关系图

42
 第2章 通用指导信息

图 2-5 “ABCD”数字技术采用框架

第 2 步：执行 DTRA
DTRA（包括所有已经确定的因素）可以被看作是
一种工具套件，能够对照评估中定义的所有关键因素检
查组织的就绪度。
《TOGAF 系列指南：数字技术采用：
就绪度评估和路线图开发指南》的附录 A 中提供了一
份相关的调查问卷。
第 3 步：确定需要管理层注意的因素
该流程的下一步是分析就绪度评估的输出。可能某
些因素没有达到预期，组织的某些参数不符合标准。了
解缺失因素的影响至关重要。例如，如果就绪度评估结
果表明一个组织的“实施方法”落后，则意味着试错验

43
TOGAF®标准第 10 版口袋指南（中文版）

法有可能导致错失机遇。组织可能存在多个缺失因素，
因此，需要将所有因素的主要后果作为一个整体来看待，
不能带有任何偏见。
第 4 步：阐明缺陷，启动数字技术采用
在数字技术采用的旅程中，该步骤将根据在上一步
中确定的主要后果，准备好解决缺失因素（填补空缺）
。
根据评估结果，组织可以划分为三种类型。
类型 1：仅实现基本因素的企业。
类型 2：实现基本和影响因素的企业。
类型 3：实现基本、影响和支持因素的企业。
如果组织没有满足基本因素的要求，则评估影响和
支持因素毫无意义。因此，企业必须采用循序渐进（逐
步）的敏捷方法来降低缺失因素的影响。
如果企业被评估为类型 3；即在 3 个因素层面上均已
准备就绪，那么相比被评估为类型 2 或类型 1 的企业，该
企业的就绪度更高，更有利于开始数字技术采用。建议类
型 1 或类型 2 的组织采用渐进式和敏捷方法；先解决基本
因素，其次是影响因素，最后是支持因素。

44
 第3章 组建企业架构团队

第 3 章 组建企业架构团队
本章描述了 TOGAF 标准中关于如何支持组建企
业架构团队的指南。

3.1 文档

有关 TOGAF 组建企业架构团队的文档为《TOGAF
系列指南：建立并演进企业架构能力的 TOGAF®领导者
，该文档的概述如表 3-1 所示。
指南》

表 3-1 有关 TOGAF 组建企业架构团队的文档

文 档 概 述
本文档的目标受众是 EA 能力领导者，
其负责领导 EA 能力的建立或发展。它针
TOGAF 系列指南：建立并演 对如何建立符合每个企业特定要求和期望
进企业架构能力的 TOGAF®领 的 EA 能力给出了建议，并提出了一种基
导者指南 于既有最佳实践来建立和增强企业 EA 能
力的方法。此方法遵循通过 TOGAF ADM
配置的路径

45
TOGAF®标准第 10 版口袋指南（中文版）

3.2 企业架构能力

企业架构能力是开发、使用和维护特定企业的架构
并使用该架构来治理变革的能力。
不同的从业者对“能力”一词的定义不同，最常见的
情况是用作正式分析技术的一部分，此时其定义必须精确
且受到约束。EA 能力可以被看作是一个管理概念，有助
于规划改进做某事的能力，从而强化该能力所带来的结果。
虽然每个组织都可以从 EA 能力中受益，但每个组
织所需的 EA 能力不同。
结合图 3-1 所示和 2.4 节所述，EA 能力通常有四个
广泛的用途。
EA 能力必须能够高效地运行，并与不断变化的运营和
财务实践保持一致。它在概念上类似于组织中任何职能的运
作。它由特定的企业架构活动和任何业务的一般活动组成。
如图 3-2 所示的 EA 能力模型分解图所示，特定的
企业架构活动要么是基本活动，要么有着特定的目的。

46
 第3章 组建企业架构团队

负责提供 EA 能力的团队所做工作的性质决定了这些活
动是共享功能。该团队需要受影响的团队能够在相关性、
效率、有效性和增长方面进行持续的投入—建立 EA
能力的共同基本元素十分重要。

图 3-1 企业架构能力模型

图 3-2 企业架构能力模型分解图

47
TOGAF®标准第 10 版口袋指南（中文版）

3.3 组织模型

图 3-3～图 3-5 显示了提供 EA 能力的团队在组织

一致性方面的不同形式。这些图只是用来说明观点的，
并未考虑企业可能存在的差异，如行业、客户群、产品
线、国家和地理位置等。
在以功能为中心的模型中（见图 3-3）
，企业架构可
能是每个垂直职能部门的组成部分，选取其中一个团队
整合所有企业架构活动（如图 3-3 上部所示）
；企业架构
也有可能是企业的主导或关键职能部门之一（如图 3-3
的下部所示）
。在第二种形式中，谨慎的做法是从各个职
能部门抽调具备 EA 能力的成员组成团队，他们对共同
的 EA 目标负有扩展的责任。从人力资源管理的角度来
看，他们向各自的职能或区域业务领导汇报。
在以 IT 为中心的模型中（见图 3-4），无论如何
命名，企业架构通常都与 IT 组织保持一致。团队章
程可能因组织内的 IT 结构而异。当 IT 与 CFO 目标

48
 第3章 组建企业架构团队

一致时，企业架构团队的章程可能是改善运营效率和
成本控制。当 IT 与交付或营销保持一致时，其章程
更有可能关注敏捷性和效率。重点是要了解背景，吸
引具有流程分析和成本管理专业技能或深厚运营职
能知识的成员。

图 3-3 以功能为中心的企业架构

在以战略为中心的模型中（见图 3-5）
，企业架构可
能与公司战略、整体运营或财务保持目标一致。提供 EA
能力的团队根据章程（持续增长、运营效率、成本和风
险降低）将其服务扩展到企业的其他部门。

49
TOGAF®标准第 10 版口袋指南（中文版）

图 3-4 以 IT 为中心的企业架构

图 3-5 以战略为中心的企业架构

50
 第4章 特定域的指南

第 4 章 特定域的指南

本章描述了 TOGAF 标准中针对特定主题域提供的

指南。

4.1 安全架构

4.1.1 文档

有关 TOGAF 标准安全架构的文档为《TOGAF 系列
指南：在 TOGAF 企业架构中集成风险和安全》
，该文档
的概述如表 4-1 所示。

51
TOGAF®标准第 10 版口袋指南（中文版）

表 4-1 TOGAF 标准安全架构

文档 概述

本文档为安全从业者和企业架构师提供了开发全面
TOGAF 系列指南：
解决风险和安全的企业架构指南。它描述了如何将风
在 TOGAF 企业架构
险和安全集成到企业架构中，并为安全架构师和企业
中集成风险和安全
架构师引入了一种通用语言

4.1.2 集成风险与安全

安全架构是一个由组织、概念、逻辑和物理组件组
成的结构，这些组件以有机统一的方式进行交互，以实
现和维护受管理的风险和安全（或信息安全）状态。在
实现安全可靠、有保障、有韧性的行为的过程中，安全
架构既是推动者、又是支持者，在处理整个企业中的风
险区域时也不例外。
然而，企业安全架构并不是孤立存在的。作为企
业的一部分，它建立在企业架构中已有的企业信息之
上，并生成影响企业架构的信息。正是出于这个原因，
在企业架构中紧密集成安全架构才大有裨益。最后，

52
 第4章 特定域的指南

与其亡羊补牢，不如一开始就行之有道，这可以节省
成本并提高效率。为了实现这一点，安全架构师和企
业架构师需要一种通用语言。《TOGAF 系列指南：在
TOGAF 企业架构中集成风险和安全》就介绍了这一
语言。

4.1.3 风险的定义

风险是“不确定性对目标的影响”（ISO 31000:
2009）
。
不确定性可能会造成与预期的任何偏差—有正面
影响也有负面影响。鉴于做决策时可用的信息量有限，
预测未来结果时就会产生不确定性。虽然我们期望通过
更高质的信息做出更明智的决策，但这种信息永远不会
是完美的。每个决策都是有一定的前提的，包括评估潜
在机会和威胁之间的平衡、出现有益结果与破坏性结果
的可能性、这些潜在事件的积极或消极程度以及出现每
个已确定结果的可能性。识别和评估这些因素即为“风

53
TOGAF®标准第 10 版口袋指南（中文版）

险评估”或“风险分析”
。“风险管理”是在决策过程中
应用这些概念的一门艺术和科学。

4.1.4 安全是贯穿各个领域的关注点

安全架构是贯穿整个企业架构中各个领域的关注
点。我们可以将其描述为一个由视图、视角和制品组成
的连贯集合，其中包括安全、隐私和运营风险观点以及
安全目标和安全服务等相关主题。安全架构不仅仅是一
个数据集，而且还以强大的信息安全管理（ISM）和企
业风险管理（ERM）流程为基础。
TOGAF ADM 涵盖了业务、数据、应用及技术这
四个架构域的开发，它们是公认的企业架构的子集。
作为一个贯穿各个领域的关注点，安全架构影响和指
导着业务架构、数据架构、应用架构和技术架构的开
发（参见图 4-1）。安全架构的组织工作可能通常在架
构范围之外进行，但它的部分内容需要以集成架构的
方式开发。

54
 第4章 特定域的指南

图 4-1 安全是贯穿架构中各个领域的关注点

4.1.5 企业风险管理

企业风险管理（ERM）可以通过考虑不确定性和

未来事件或情况（有意或无意）的可能性及其对商定

目标的影响来帮助决策。风险管理应深深扎根于所有

业务活动中。它是一个连续的生命周期，不是一个孤

立的活动。

以下概念对 ERM 很重要：

• 关键风险领域。

55
TOGAF®标准第 10 版口袋指南（中文版）

• 业务影响分析。

• 风险评估。

• 业务风险模型/风险登记表。

• 风险偏好。

• 风险缓解计划/风险处理计划。

ISO 31000:2009 风险管理流程模型如图 4-2 所示。

图 4-2 ISO 31000:2009 风险管理模型

4.1.6 信息安全管理

信息安全管理（ISM）是一个定义安全目标、分配

56
 第4章 特定域的指南

信息安全风险所有权并支持安全措施实施的流程。安全
管理流程包括风险评估、安全措施的定义和正确实施、
安全状态报告（已经定义的、部署的和起效的措施）以
及安全事件的处理。

4.2 业务架构

TOGAF 标准可指导业务架构师和企业架构师根据
组织已有的和需要的业务模型、生态系统、价值和组织
设计开发业务架构。相关文档如表 4-2 所示。

4.2.1 文档

表 4-2 TOGAF 标准业务架构

文档 概述

本文档为企业架构师理解和利用业务模型奠定了
TOGAF 系列指南： 基础，这些模型描述了组织创造、交付和获取价值的
业务模型 基本原理。它涵盖了业务模型的概念和用途，重点介
绍了业务模型画布™技术

57
TOGAF®标准第 10 版口袋指南（中文版）

（续）

文档 概述

本文档回答了什么是业务能力以及如何使用业务
TOGAF 系列指南： 能力增强业务分析和规划等几个重要问题。它论述了
业务能力，第 2 版 架构师如何创建能力映射图，并将其与其他业务架构
视角保持一致，从而支持业务规划流程

价值流是业务架构的核心元素之一。本文档提供了
TOGAF 系列指南： 一种开发业务价值模型的架构方法。它阐述了价值流
价值流 的识别、定义和建模，以及如何将价值流映射到企业
业务架构的其他关键组件

本文档描述了如何开发信息映射图，以便清晰地阐
TOGAF 系列指南： 述、表征和直观地表示对业务至关重要的信息。它为
信息映射 架构师提供了一个框架，能够帮助他们在开发或提出
解决方案之前了解哪些信息对企业最重要

本文档展示了组织映射如何为企业架构提供组织
的背景环境。能力映射可显示业务单元所负责的内
TOGAF 系列指南：
容，价值流映射可显示如何向特定利益相关者交付
组织映射
价值，组织映射则可识别拥有或使用这些能力或者
参与价值流的业务单元或第三方

本文档描述了业务场景技术，它提供了一种机制
帮助充分理解信息技术需求，并将其与业务需求保
TOGAF 系列指南：
持一致。它展示了业务场景如何帮助开发引起共鸣
业务场景
的业务需求，以及它们如何支持和赋能企业实现其
业务目标

58
 第4章 特定域的指南

4.2.2 业务模型

业务模型是对组织如何创建、交付和获取价值的逻
辑依据的描述。
在如何描述和操作业务以寻求新的战略选择这一问
题上，业务模型为建立共同理解奠定了基础。从这个意
义上说，要想探讨业务创新和资源分配的战略规划，架
构师可以从业务模型入手。业务模型可以用许多不同的
方式来表示，相关示例请参见《TOGAF 系列指南：业务
模型》
。
使用业务模型带来的收益包括：
• 改善沟通。
• 提供一个共同的视角。

4.2.3 什么是业务能力

业务能力是企业为实现特定目的或成效而可能拥有
或置换的一种特殊能力或产能。
业务能力和业务流程的关键区别在于，业务能力描

59
TOGAF®标准第 10 版口袋指南（中文版）

述了业务所做的事情，而不试图解释业务如何、为何或
在何处使用该能力。
业务能力可以是当前存在的东西，也可以是支持新
方向或战略所需的东西。当集成到业务能力映射图时，
业务能力表示企业所具有的可用于开展业务的所有能
力。需要特别注意的是，业务能力的组成要素（实现方
式）会定期更改，但业务能力会在较长的规划周期内持
续存在。

4.2.4 定义业务能力

定义业务能力的第一步是命名业务能力。它明确了
对业务能力存在的需求，并有助于确保清楚地将其与其
他业务能力区分开来。
简短的描述有助于阐明业务能力的范围和目的，并
将其与其他业务能力区分开来。与为业务能力命名一样，
使用与业务利益相关者相关且适合的语言有助于描述所
有业务能力。谨记以下两点：
• 简明扼要：用一两句话提供足够的细节，让人们

60
 第4章 特定域的指南

获得比仅从业务能力名称中更深入的理解。
• 准确无误：不要简单地在描述中重复业务能力的
名称，例如将“项目管理”描述为“管理项目的
能力”
。
表 4-3 中显示的模板可用于定义各项业务能力。

表 4-3 业务能力模板

名称应该是名词（
“做什么”
）而不是动词（
“如何做”
）。
名 称 业务能力通常会写成复合名词，例如“项目管理”或“战
略规划”

一个简短的描述，用于阐明业务能力的范围和目的，
描 述 并将其与其他业务能力区分开来。采用“……的能力[或
产能]”的句式来描述每个业务能力是一个不错的办法

角色是指参与交付业务能力的各个施动者、利益相关者、
角色
业务部门或合作伙伴。角色的描述不得具有组织针对性

仅识别业务能力中的核心业务流程。梳理和分析核心
流程
流程的效率有助于优化业务能力的有效性

（与 IT 相关
业务能力所需或所使用的业务信息和知识
组成要素 数据实体不同），这可能还包括业务能力与其他能力交
信息
换的信息。例如，有关客户和潜在客户、产品和服务、
业务政策和规则、销售报告及绩效指标的信息

成功执行业务能力所依赖的工具、资源或资产。例如
资源 IT 系统和应用、有形的物质资产（建筑物、机械、车辆
等）和金钱、知识产权等无形资产

61
TOGAF®标准第 10 版口袋指南（中文版）

表 4-4 提供了一个业务能力示例—招聘管理。

表 4-4 业务能力示例—招聘管理

名 称 招聘管理

描 述 为组织招聘新员工而进行招揽、培训和提供支持的能力
用户：
• 招聘人员
角色 利益相关者：
• 经理
• 应聘员工
评估新的招聘申请
招聘/寻求应聘者
流程
组成 筛选应聘者
要素 雇佣应聘者
应聘/申请详情
职位描述
信息
招聘机构数据
行业标准角色定义
招聘管理应用
资源 HR 应用
社交媒体应用

4.2.5 什么是业务能力模型

业务能力模型反映了当前有效的、稳定的业务能力

62
 第4章 特定域的指南

集合（以及它们所有的定义特征）
，涵盖了相关的业务、
企业或组织单位。
业务能力建模的首要任务是捕获和记录所有业务能
力，这些业务能力代表业务目前所做的全部事情（无论
结果如何）
，或者希望将来能够做什么事情。接下来是有
逻辑地组织这些信息。
建模过程的最终产物通常是一个业务能力映射图，
它在适当的分解级别提供所有业务能力的可视化描述
（或蓝图）
，并按逻辑划分为不同的类别或角度，以支持
有效的分析和规划。
表 4-5 为业务能力模型示例。

表 4-5 ABC 公司的 1 级业务能力模型示例

业务规划 市场规划 合作伙伴管理

战略
资本管理 策略管理 政府关系管理

销售管理 产品管理 分销管理

核心
客户关系管理 渠道管理 代理管理

财务管理 人力资源管理 采购管理

支持
信息管理 培训管理 运营管理

63
TOGAF®标准第 10 版口袋指南（中文版）

4.2.6 将能力映射到其他业务角度

在梳理出业务能力并将其整理到业务能力模型后，
我们就可以开始在业务分析和规划中使用这些信息了。
我们需要考虑两个方面：
1）将热映射图添加到业务能力模型。
2）使用能力/组织映射和能力/价值流映射（见 4.2.11
节）等交叉映射技术，映射业务能力与其他业务和 IT 架
构域之间的关系。
相关信息详见《TOGAF 系列指南：业务能力第 2 版》
。

4.2.7 什么是价值流

价值流（简单示例见图 4-3）表现为一系列端到端
的增值活动，能够为客户、利益相关者或最终用户创造
整体效益。在建模术语中，这些增值活动被称为价值流
阶段，价值流每步入一个新的阶段就会为利益相关者创
造并增加增量价值。
价值流可能是由外部触发的，例如零售客户购买一

64
 第4章 特定域的指南

些商品；价值流也可能是内部触发的，例如经理招揽了
一名新员工。价值流可以在企业层面或业务部门层面进
行定义。无论采用哪种定义方式，完整的价值流集（如
价值流图或地图所示）都只是对代表组织主要业务活
动集的所有价值流的一种直观表示。它融合了企业为
各方利益相关者创造价值的多种方式。

图 4-3 价值流示例

4.2.8 价值流的优势

在更广泛的业务架构举措下映射价值流是获取整个
业务快照的一种快捷方法，因为这些价值流代表了该业
务需要执行的所有工作—至少从价值交付的角度来看
是这样。
这样做有助于企业领导者评估其组织为不同利益相
关者创造、获取和交付价值的有效性。

65
TOGAF®标准第 10 版口袋指南（中文版）

4.2.9 定义价值流

表 4-6 为定义价值流的模板。

表 4-6 价值流模板

价值流名称在发起方的利益相关者看来必须清晰易懂

与业务能力的命名方式相反，价值流使用主动句，不用
名 称
被动句。这通常意味着动词加名词的结构，例如“购买零
售产品”和“招聘员工”

虽然价值流名称应该是不言自明的，但简短而准确的描
描 述
述可以使价值流所涉及的活动范围更加清晰

利益相关者 启动或触发价值流的人或角色

利益相关者期望在成功完成价值流后获得的价值（从利
价 值 益相关者的角度来表述）
。该价值是每个价值流阶段交付
的增量价值项目汇总

仍旧以前面图 4-2 中的示例为例，我们可以定义

如表 4-7 所示的价值流。

表 4-7 价值流定义示例

名 称 购买零售产品

描 述 寻找、选择和获取所需零售产品的活动

利益相关者 希望购买产品的零售客户

价 值 客户能够找到并及时获取想要的产品

66
 第4章 特定域的指南

4.2.10 分解价值流

如价值流所示，价值是通过一系列连续进行和/或并
行发生的行动（价值流阶段）实现的，每步入一个新阶
段都会为利益相关者创造和增加价值。
我们可以通过定义价值流阶段来分解价值流，如
表 4-8 所示。

表 4-8 价值流阶段模板

用两三个词说明这个阶段实现了什么（或将要实现
名 称
什么）
描 述 用几句话解释该价值流阶段的目的和执行的活动
从价值流阶段获得可衡量价值的施动者，或为创造
利益相关者
或交付该价值做出贡献的施动者

触发价值流阶段或致使其被激活的起始条件或状态
准入条件
变更
表明价值流阶段已经完成的最终状态条件；即已为
结束条件 利益相关者创造或交付所需的价值。这些信息将会成
为下一个价值流阶段的准入条件

价值流阶段为参与的利益相关者创造或交付的增量
价值项
价值

表 4-9 对前面示例进行了进一步剖析，列出了每个

67
TOGAF®标准第 10 版口袋指南（中文版）

价值流阶段的元素，包括描述、参与的利益相关者、准
入条件、结束条件以及每个阶段交付的价值。这个零售
示例涉及实体店和网店，因此所使用的术语应该适用于
这两种客户交互渠道或类型。

表 4-9 “购买零售产品”价值流阶段

价值流 参与的利益相 准入 结束
描 述 价值项
阶段 关者 条件 条件

商店或网站 客户 客户可
广告 使客户关注公 客户选
所有者、营销部 搜索 用的零售
渠道 司产品的行为 择渠道
门 产品 渠道

以实物形式或
商店员工、库 客户 提供给
展示 以可搜索的数字 客户浏
存经理、网站设 选择 客户的产
商品 形式展示产品的 览产品
计者 渠道 品选项
行为

支持筛选和评
商店员工、网 客户
支持 估符合客户需求 客户选 锁定所
页设计者、零售 浏览
选择 的最佳产品的行 择产品 需产品
客户 产品
为
客户
处理 收取和处理客 收银员、金融 完成 交货承
选择
付款 户付款的行为 实体、零售客户 付款 诺
产品

交付 将产品送到客 仓储、运输、 完成 产品 用户拥

商品 户手中的行为 零售客户 付款 送达 有的产品

68
 第4章 特定域的指南

4.2.11 将价值流映射到能力

图 4-4 使用《TOGAF 系列指南：价值流》中的“招

聘员工”价值流展示了如何将价值流映射到业务能力以
及如何使用热图。此示例分析了每种业务能力对价值流
阶段交付所需价值的支持程度，绿色表示匹配良好，黄
色表示需要进行一些更改，红色表示当前与需求之间存
在明显差距。

图 4-4 价值流/能力热图示例

69
TOGAF®标准第 10 版口袋指南（中文版）

4.2.12 信息映射

信息映射可以帮助架构师清晰地阐述、表征和直观
地表示对业务至关重要的信息，并且这些信息的表达方
式允许进一步详细分析当前的业务运营方式或未来某个
时期应该采用的运营方式。
信息映射图包含一系列信息概念以及信息之间的相
互关系。
业务架构中的信息映射首先列出那些对业务最重要
的元素，以及如何用业务术语描述它们。辨别信息概念
的一个有用方法是倾听人们谈论业务时使用的名词。每
个名词都可能是一个信息概念。我们可以通过考察每个
名词来确定它是否代表企业关心的一则信息。换句话说，
企业中是否有人需要了解、存储或操纵该名词所代表的
对象？
图 4-5 展示了一个简单的概括性信息映射图示例。
这显示了可能在金融公司中发现的一些关键信息概念和
相互关系。

70
 第4章 特定域的指南

图 4-5 金融机构的简单信息映射图

架构师也可以为信息映射图正式建模；例如，建立
ArchiMate 模型、统一建模语言™（UML®）类图和实体
关系图（ERD）
。
信息映射图可以映射到业务能力、价值流以及组织
映射图。有关更多详细信息，请参阅《TOGAF 系列指南：
信息映射》
。

4.2.13 组织映射

组织映射图是一个业务架构蓝图，能够展示：
1）构成企业生态系统的主要组织单位、合作伙伴和
利益相关者群体。
2）每个实体之间的工作关系（非正式和正式）
。
这两个主要特征反映了组织映射图与传统组织结构

71
TOGAF®标准第 10 版口袋指南（中文版）

图的区别，传统组织结构图更倾向于描述负责每个部门
的指定个人之间存在的统属关系。相比以人员或职务为
中心，按照自上而下的层级结构来描述业务，组织映射
图以更流畅的语言描述了业务实体之间的关系网和交互
网，这一网络可能还会超出企业的法律边界。
组织映射的优势包括：
• 提高对组织的认识。
• 改进战略规划。
• 为部署提供组织背景环境。
• 改善沟通和协作。
• 提高组织变革管理的有效性。
如图 4-6 所示，组织映射图描绘了内部和外部关
系以及整个企业内外的协作，包括其业务合作伙伴和
利益相关者生态系统。中间的椭圆形（企业）表示要
在映射图中展现的总范围，而不仅仅是法人实体的名
称。另请注意，所有这些实体都是组织单元，而业务
部门一词用于表示企业以下的一个层级（在本例中表
示业务职能部门）。

72
 第4章 特定域的指南

图 4-6 通用组织映射图

如图 4-7 所示，组织映射图可以进行扩展，以显
示组织单元与其他业务架构域（例如业务能力）之间
的关系。

图 4-7 “招聘员工”价值流与业务能力的组织映射图

73
TOGAF®标准第 10 版口袋指南（中文版）

4.2.14 业务场景

业务场景法是一种帮助识别和理解架构必须解决哪
些业务需求的技术。一个好的业务场景代表着一个重要
的业务需求或问题，使供应商能够了解一个解决方案对
客户的价值。
业务场景描述了：
• 一个业务流程、一款应用或一组应用。
• 业务和技术环境。
• 执行该场景的人员和计算组件（
“施动者”
）。
• 正确执行的预期结果。
该方法可用于任何 ADM 阶段。最值得注意的是，
它可以用于预备阶段（用于定义建立企业架构能力的需
求）、ADM 周期的初始阶段、阶段 A（用于定义相关业
务需求并与利益相关者达成共识）以及业务架构阶段
（直接从高级业务需求中推导出架构特征）。该技术可以
迭代，并在业务架构的层级分解过程中采用不同的信息
粒度。

74
 第4章 特定域的指南

具体方法如下：
• 识别、记录和排序驱动场景的问题。
• 记录出现问题的业务和技术环境，并将其作为高
级架构模型。
• 确定并记录期望的目标；成功处理问题的结果（确
保目标具体明确、可衡量、可达成、切合实际且有
时限（SMART）
）。
• 确定人员施动者（参与者）及其在业务模型中的
位置。
• 确定计算机施动者（计算元素）及其在技术模型中
的位置。
• 检查适用性，仅在必要时进行改进。

4.3 数据/信息架构

4.3.1 文档

有关 TOGAF 标准数据/信息架构的文档为《TOGAF
系列指南：信息架构：客户主数据管理（C-MDM）
》，其

75
TOGAF®标准第 10 版口袋指南（中文版）

概述如表 4-10 所示。

表 4-10 TOGAF 标准数据/信息架构

文 档 概 述

TOGAF 系列指南： 本文档描述了一种在组织中实现客户主数据管理

信息架构：客户主数 （C-MDM）的方法。它使相关人员、流程、组织和系
据管理（C-MDM） 统将客户主数据作为资产来共同管理

4.3.2 客户主数据管理（C-MDM）

组织实施 C-MDM 的目的是增加整个组织共享的客

户信息的价值。它是大多数组织的数据基础。
《TOGAF 系列指南：信息架构：客户主数据管理
》第 4 章介绍了如何调整 TOGAF ADM 以支
（C-MDM）
持 C-MDM 转型计划的执行。

4.4 敏捷方法

4.4.1 文档

TOGAF 标准敏捷方法的相关文档如表 4-11 所示。

76
 第4章 特定域的指南

表 4-11 TOGAF 标准敏捷方法

文 档 概 述

本文档概述了如何调整 TOGAF® 标准以支持“敏捷

TOGAF 系 列 指
企业”
。本文适用于采用公认敏捷方法（即通过一系列冲
南：实现企业敏捷性
刺进行迭代开发）的任何敏捷交付方法

本文档描述了如何在多种场景中应用 Sprint：
• 遵循敏捷方法，协同应用企业架构和 TOGAF ADM
TOGAF 系列指 • 创建专为搭配使用敏捷实践而进行调整的企业架构
南：使用敏捷 Sprint • 支持敏捷团队并与其展开密切协作，以满足特定的
应用 TOGAF ADM 业务需求
• 支持企业架构师利用敏捷实践确保解决方案的敏捷
交付符合战略目标

4.4.2 敏捷性是什么意思，为什么如此重要

企业敏捷性是一个比较常用的术语，但在不同从业者
口中的具体定义并不完全相同。达成普遍共识的特征包括：
• 对变化做出响应：预测变化并制定明确计划的灵
活方法，通常包括短周期迭代，以及频繁重新调
整活动的优先级。
• 价值驱动：活动受交付价值驱动；不断重新评估
优先级，第一时间交付高价值事项，最大限度地
减少中间产品和文档方面的工作。

77
TOGAF®标准第 10 版口袋指南（中文版）

• 真实实验：相比大量理论分析，更倾向于开展实
验，从经验中获取知识，有时被称为“快速失败”
。
• 自治且自主的团队：由熟练技术人员组成的跨专
业团队密切协作，对本团队的决策和产物负责。
• 客户沟通与协作：与客户密切协作，满足其需求，
视协作和反馈的价值高于正式的文档和合同。
• 持续改进：改进组织绩效的内驱力。
• 尊重他人：以人为本，流程和工具不能凌驾于人
之上—尊重他人；灵活性、知识传递和个人发
展是最重要的。
敏捷性十分重要，因为它能支持企业在以客户和产
品为中心、更高效、以及更好地确保合规性等方面做得
更好，更加从容地应对各种变化。

4.4.3 不同的细节级别激活敏捷性

TOGAF 框架提供了一个模型，以确定用于架构开
发分区的 3 个细节级别：
• 企业战略架构。

78
 第4章 特定域的指南

• 分段架构。
• 能力架构。
这些级别如图 4-8 所示。

图 4-8 架构景观分类模型总结

我们从上往下来讲解：
企业战略架构提供了高阶视图。显示了企业受变更
影响的部分。它支持人们概括性地理解企业的总体战略方
向，其范围必须足够广泛，才能建立适合分段和能力的背
景环境。必须计划与设计整个工作，并避免意外后果。
中间的一层是分段架构，通常提供项目组合、项目

79
TOGAF®标准第 10 版口袋指南（中文版）

群或产品级别的方向。这些大规模分段的分界线通常与
职能的天然边界一致。
底层是能力架构，该架构详细描述了业务能力（的
增量）
。能力架构可能与交付冲刺一致，也有可能需要多
个冲刺来交付一项能力。它们具有充分的细节，可交付
给开发人员付诸实施。冲刺可发生在任何层级，但最常
与能力或能力增量交付相关联。冲刺可并行开展。
在企业层面成功实现敏捷性的两个主要因素为：
1）管理范围，了解何时需要新的能力，对企业的影
响有多大，以及企业的不同部分如何交互。
2）充分了解企业的整体战略方向、关键业务能力及
其相互关系，从而最大程度降低意外后果和零散开发的
风险，并识别任何损害企业整体战略的变革。这有助于
对变革提案的影响进行评估。

4.4.4 构建敏捷企业架构的一种方法

应用敏捷企业架构的一种方法是利用 ADM 周期的

层次结构，如图 4-9 所示。

80
 第4章 特定域的指南

图 4-9 ADM 流程的层次结构示例

81
TOGAF®标准第 10 版口袋指南（中文版）

一旦在战略架构中确定了相关领域，便可立即开展
定义分段架构相关的活动。即使有些分段尚未定义，也
可以从已经确定的部分开始架构工作。同理，定义能力
架构的工作不必等到所有分段架构都被定义之后才开
始。不同分段和能力的工作可以并行执行。
在开发能力架构时收获的经验会影响更高级别的分
段架构。在开发分段架构时收获的经验会影响更高级别
的战略架构。
敏捷交付团队应与架构师密切合作，以确保冲刺
团队理解并遵守架构规范（可能称为护栏（guardrail）
或跑道（runway）），并且向未来的架构迭代快速提供
反馈。
重要的是牢记以全局为重，以确保实施团队符合整
体战略。因此，既要在每个层级提供足够的细节，力求
清晰度与一致性；又要避免陷入过早探索太多细节，失
去交付冲刺的反馈带来的收益的“大设计先行”
（BDUF）。总之，要实现两者的平衡。这通常被称为最
小可行架构（MVA）
。

82
 第4章 特定域的指南

4.4.5 映射到敏捷概念

架构师也可以使用 SAFe ® 和 Scrum 等技术实施

ADM 流程法的层次结构。敏捷技术认为开发和交
付工作可交由跨所有层级（业务、技术、解决方案、
构建和交付）的综合团队来处理，处理的形式为一
组首尾相连的冲刺或者跨不同类型的边界，如图
4-10 所示。

图 4-10 映射至敏捷交付概念的 ADM 层级

83
TOGAF®标准第 10 版口袋指南（中文版）

4.4.6 敏捷产品管理

敏捷架构要求更密切地关注成果，包括从以项目为

中心到以产品为中心的方法转变。虽然大多数敏捷工作

发生在解决方案方面，但是旨在解决问题方面的技术（例

如设计思维㊀和业务模型画布）有助于指明架构方向、

将解决方案变为现实。需求通常都是即时制出现的，需

要通过迭代评估来再次确定问题定义（TOGAF ADM 阶

段 A）以及架构方法来实现所需的解决方案（TOGAF

ADM 阶段 B、C 和 D）
。

更少地单独关注架构的公共域，更多地强调围绕所

需产品、跨所有领域开展协作，这样的整体架构方法由

此而生。

敏捷架构中的一个重要概念是意向架构，该架构指

定了一整套有目的、有计划的架构策略和举措，可增强

㊀ 关于设计思维的描述，请参见开放敏捷架构™标准。

84
 第4章 特定域的指南

解决方案的设计、性能和可用性，并为团队间的设计和

实施同步提供指导。

在图 4-11 中，意向架构作为能力架构规范的一部分
而交付，旨在提供支持实施的护栏。战略架构的输出将
用于定义产品待办事项列表，后者将在分段架构中进一
步详细定义。在能力架构层级定义冲刺待办事项列表和
意图架构，意向架构将为实施（部署目标）提供指导。
变更管理将处理新的需求，并且支持对产品待办事项列
表进行梳理和优先级排序。

图 4-11 敏捷架构和产品开发

85
TOGAF®标准第 10 版口袋指南（中文版）

4.4.7 如何在冲刺中使用 TOGAF ADM

在企业架构开发中引入冲刺的方法有很多。本节简
要介绍四种不同的敏捷企业架构方法，如图 4-12 所示。
选择应用哪一种方法取决于组织对敏捷实践的需求。

图 4-12 敏捷企业架构协作方法

表 4-12 描述了四种协作方法。

表 4-12 敏捷企业架构协作方法

协作方法 概 述

使用冲刺为业务变革交付企业架构
交付企业架构所需的 ADM 阶段（A 到 F）被分为一
企业架构开发敏
组冲刺，通常每个冲刺中都有一个 ADM（A 到 F）切
捷性
。治理将遵循 TOGAF 治理框架，也可调整
片（分区）
为以敏捷方式应用

86
 第4章 特定域的指南

（续）
协作方法 概 述

通过协同配合企业架构和敏捷解决方案团队冲刺
交付解决方案，每个冲刺都包含企业架构和敏捷解
解决方案协作
决方案开发。企业架构团队将为后续开发冲刺创建
MVA

通过协作敏捷业务开发、敏捷企业架构和敏捷解决
方案开发冲刺来交付解决方案
每个冲刺都包含敏捷业务开发、敏捷企业架构和敏
捷解决方案开发。业务开发团队将为后续企业架构冲
跨开发协作
刺创建最小可行业务开发（MVBD）
，而企业架构团队
则为后续开发冲刺创建 MVA。企业架构交付有着不同
的背景环境。在每种背景环境中，冲刺、成果和成员
的含义均会有所不同

与混合的跨职能冲刺团队（均具备敏捷业务开发、
敏捷企业架构及敏捷解决方案开发能力）一同交付解
决方案
跨职能敏捷性
每个冲刺团队都具备业务开发、企业架构和敏捷解
决方案开发能力，可打破孤岛并确保持续创新。这些
能力在同一个团队中协同配合

有关更多信息，请参阅《TOGAF 系列指南：使用
敏捷 Sprint 应用 TOGAF ADM》
。

87
TOGAF®标准第 10 版口袋指南（中文版）

4.5 TOGAF 标准参考模型和方法

4.5.1 文档

TOGAF 标准参考模型和方法如表 4-13 所示。

表 4-13 TOGAF 标准参考模型和方法

文 档 概 述
本文档概要介绍了不受行业限制的通用核心组件，这
TOGAF 系列指南：
些组件是现代数字化企业必不可少的构建块。它使组织
TOGAF 数字化业务
能够根据不断变化的战略、业务模型、运营模型和运营
参考模型（DBRM）
情况，制定适当的数字化架构蓝图

本文档提供了一个标准参考模型模板，可用于描述公
TOGAF 系列指南： 共部门的任何业务，并支持使用不同的架构方法和分析
政府参考模型 技术。它为公共部门组织提供了一种自我审视的通用方
式，以便规划和执行有效的转型变革

本文档介绍了架构能力成熟度模型的概念、用于评估
TOGAF 系列指南： 和量化组织在企业架构成熟度的技术，包括用作示例的
架构成熟度模型 公开可用的框架，任何企业都可以使用该框架来开发本
组织专用的成熟度模型

本文档为 TOGAF 架构师提供了一份架构项目管理指

TOGAF 系列指南： 南，架构师可以通过用选定的项目管理技术补充 TOGAF
架构项目管理 ADM 方法管理架构项目。这种方法的目标是通过更好的
规划、监控和沟通来提高架构项目的成功几率

88
 第4章 特定域的指南

（续）
文档 概述
本文档为从事企业架构工作的人员提供了一套角色、
TOGAF 系列指南： 技能和经验规范。它介绍了企业架构团队中具体角色的
架构技能框架 能力水平，定义了具体角色、该角色所需的技能以及胜
任每个角色所需的知识深度

4.5.2 数字化业务参考模型（DBRM）

数字化业务参考模型（DBRM）是一种通用参考模
型，组织可以对其进行调整和使用，以实现可持续的企
业设计、组织敏捷性和互操作性，从而响应不断变化的
客户需求和业务生态系统。
DBRM 的简要视图如图 4-13 所示。
DBRM 为采用 The Open Group TOGAF 标准和其他
相关标准提供了指导，特别是 The Open Group DPBoK
和《开放敏捷架构标准》
。
DBRM 由十个核心元素组成，分为以下四个域：
• 数字域：
◦ 客户至上。

89
TOGAF®标准第 10 版口袋指南（中文版）

◦ 数字化企业。

图 4-13 DBRM 元素 — 简要视图

• 战略域：
◦ 战略背景。
◦ 业务动机。
◦ 业务服务和产品。
• 结构域：
◦ 生态系统和业务模型。
◦ 运营模型。

90
 第4章 特定域的指南

◦ 业务能力模型。
• 运营域：
◦ 业务运营环境。
◦ 数字化赋能。
四个域（数字、战略、结构和运营）使 DBRM 能够
解决特定的利益相关者关注点并实现一致的利益相关者
管理。
数字域对于采用由外而内的方法来使用不断增长的
数字化组件创建并管理数字产品和服务，或带领组织完
成数字化业务的转型之旅，至关重要。
战略域涉及“战略背景”
“业务动机”以及“业务服
务和产品”元素，这些元素决定了“为什么”开展业务。
支撑核心“业务服务和产品”元素的是聚焦于业务
要“做什么”的 DBRM 元素—生态系统和业务模型、
运营模型和业务能力模型，三者相互关联。它们共同定
义了企业建立和交付确定的核心业务服务，以实现“业
务动机”元素中定义的预期业务目标的方法。它们构成
了 DBRM 的结构域。

91
TOGAF®标准第 10 版口袋指南（中文版）

运营域涉及“业务运营环境”和“数字化赋能”
元素（业务“如何做”）。它们使企业能够有意识地
确定业务运营环境的需求和影响，以响应预期的业
务战略。

4.5.3 政府参考模型

政府参考模型（GRM）为公共部门组织提供了一
种通用的自我审视方式，以便规划和执行有效的转型变
革。它提供了一个标准参考模型模板，可用于描述公共
部门的任何业务，并支持使用不同架构方法和分析技
术。GRM 的目标受众包括公共部门变革的决策者和设
计者。
表 4-14 显示了 GRM 中各类部门的名称和描述。

表 4-14 GRM 部门和描述

部 门 定 义
政府为促进财政支持和国际经济贸易而开展的活动，
国际事务与贸易 以及与政策实施、援助计划、条约签订和建立外交关系
有关的活动

92
 第4章 特定域的指南

（续）
部 门 定 义
负责部队、武器和相关实体的研究、维护、装备、采
国防和安全 购和开发工作。其中还包括支付给所有服役和退役平民
及人员的薪酬和福利

一般政府部门 提供一般客户服务和运营活动，包括注册、许可、
（客户服务、客户运 申请、劳动力规划、社会服务、劳动者权利管理和本
营）和本地服务 地服务

与早期教育、小学、中学、高等教育及专业学校教育相对
青少年与教育 应的教育计划；儿童社会服务、保护及相关儿童和青少年服
务；以及政府为促进教育而开展的技能培训活动
包括医疗护理治理、向个人和家庭提供的策略与护理
健康与社区福祉 服务、研究工作，以及为保障身心健康而提供的医院和
社区服务
涵盖司法总成本、诉讼、资金保护相关费用、执法服务
司法与民政事务
及刑事司法（包括囚犯监禁、监管、假释和改造）费用
保持对公共支出、收入、财务报告和审计的控制，并
财政
为未来投资决策和财政规划提供方向

发展、住房及环 确保自然和城市环境责任、提供核心基础设施及通过
境 许可和执法保护公民生活水平和安全的活动

涉及整个政府的政策制定，根据基准提供人口和绩效
政策、绩效、人
统计数据以确保持续改进，并整合战略和长期规划，从
口及创新
而确定未来风险、机遇和解决方案
代表公众协调和管理人员、通信、金融及转型服务，
共享服务 以加快信息传输并促进对人员、流程及技术的监督，从
而支持采购流程并根据组织战略进行调整
支持在陆地、空中、海上及太空开展一般运营业务，
运输和运营
并保证人员和货物的安全转运和可用性的活动

93
TOGAF®标准第 10 版口袋指南（中文版）

该参考模型为政府提供的每项服务提供了一个分类
法，制定了一种通用语言来简化复杂的信息组件，确保
跨政府部门服务和通用能力的一致性，并针对常规需要
的运营服务提供了一致视图。
图 4-14 显示了从该模型中提取的一个示例。

图 4-14 司法与民政事务的要素

94
 第4章 特定域的指南

4.5.4 架构成熟度模型

能够有效管理变革的组织通常比那些不能有效管理
变革的组织更成功。许多组织都知道只有改进流程
才能成功管理变革，但却不得其法。此类组织通常要么
在流程改进上投入很少（因为不确定如何展开）
；要么在
许多并行的、分散的工作上投入过多，但收效甚微或无
济于事。
架构成熟度模型（更正式的名称是能力成熟度模型
（CMM）
）通过为组织提供一种经过验证的有效方法来解
决这个问题，帮助组织逐步控制和改进变革过程。该模
型提供以下收益：
• 描述了任何组织为改进其流程而必须执行的
实践。
• 提供了一个定期衡量改进的标准。
• 提供了一个支持管理改进工作的可靠框架。
• 将各种实践划分为多个级别，每个级别都代表了
控制和管理开发环境的更高能力。

95
TOGAF®标准第 10 版口袋指南（中文版）

根据模型对组织的实践进行评估，即“测评”
，确定
组织当前处于哪个级别。它表明了组织在相关领域的执
行能力，以及组织为了实现最大改进和最高投资回报而
需要关注的实践。CMM 在有效指导工作方面的收效是
有据可查的。
《TOGAF 系列指南：架构成熟度模型》将美国商务
部架构能力成熟度模型视为辅助的测评工具。

4.5.5 架构项目管理

一般来说，架构项目本质上是复杂的，它们需要通
过恰当的项目管理来保持正轨以及兑现承诺。《TOGAF
系列指南：架构项目管理》为架构项目团队提供了一套
整体观点和详细指导，说明了 PRINCE2®或项目管理知
识体系（PMBOK® ）的哪些流程、工具和技术可以与
TOGAF ADM 一起应用于项目规划、监测及控制。它还
提 供 了 TOGAF 框 架 流 程 和 交 付 物 到 PRINCE2 和
PMBOK 的详细映射关系。

96
 第4章 特定域的指南

4.5.6 架构技能框架

架构技能框架为从事企业架构工作的人员提供了一
套角色、技能和经验规范。
“企业架构”和“企业架构师”是被广泛使用但定义
不明确的两个词语。它们代表着在各种架构域中使用的
各种实践和技能。我们需要对其进行更好的分类，才能
对描述的架构师/架构类型形成更清晰的认识。
定义上的不一致性给试图通过招聘或指派/提拔员
工来填补架构领域职位空缺的组织带来了困难。由于术
语的用法不同，各类架构领域的招聘者和应聘者之间通
常会出现理解错位和沟通不畅的问题。
为了解决这些问题，TOGAF 架构技能框架针对希
望担任 TOGAF 框架中界定的各种架构角色的内外部人
员，定义了架构技能及其熟练程度。
技能类包括：
• 通用技能，通常包括领导力、团队合作、人际
关系技能等。

97
TOGAF®标准第 10 版口袋指南（中文版）

• 业务技能和方法，通常包括业务案例、业务流程、
战略规划等。
• 企业架构技能，通常包括建模、构建块设计、应
用和角色设计、系统集成等。
• 项目群/项目管理技能，通常包括业务变革管理、
项目管理方法和工具等。
• 通用 IT 知识和技能，通常包括应用代理、资产管
理、迁移规划、SLA 等。
• 技术类 IT 技能，通常包括软件工程设计、安全、
数据交换、数据管理等。
• 法律环境，通常包括数据保护法、合同法、采购
法、反欺诈等。

98
 第5章 TOGAF 基本内容

第 5 章 TOGAF 基本内容

本章描述了构成 TOGAF 标准的基本内容的文档。

5.1 简介和核心概念

本节综述了企业架构和 TOGAF 标准；描述了

TOGAF 文档集的结构和框架的核心概念以及适用于基
本内容的术语和定义。TOGAF 标准的简介和核心概念部
分由表 5-1 中所示的章节组成。

表 5-1 简介和核心概念总结

章 节 描 述

企业架构和 TOGAF 标准的一般介绍，包括要点

简介
综述

99
TOGAF®标准第 10 版口袋指南（中文版）

（续）
章节 描述

描述了构成 TOGAF 标准的材料的范围和结构，以

TOGAF 文档集
及 TOGAF 库的范围和结构

核心概念 介绍了 TOGAF 标准中各组成部分使用的核心概念

定义 介绍了 TOGAF 标准中各组成部分使用的术语定义

列出了 TOGAF 标准中参考的文档，补充了术语定

附录
义和常用缩写列表

本节中的核心概念包括对以下概念的简要描述：
• 架构开发方法。
• 企业架构服务。
• 交付物、制品和构建块。
• 架构抽象。
• 架构原则。
• 互操作性。
• 企业连续序列。
• 架构存储库。
• TOGAF 内容框架和企业元模型。
• 建立和维护企业架构能力。
• 以运营实体的形式建立架构能力。

100
 第5章 TOGAF 基本内容

• 使用 TOGAF 标准和其他框架。
• 配合不同的架构风格使用 TOGAF。
• 架构视图和视角。
• 企业敏捷性。
• 风险管理。

5.2 架构开发方法（ADM）

本节描述了 TOGAF 架构开发方法（ADM）—一

种迭代式的企业架构开发方法。本节详细内容请参见第
6 章。

5.3 ADM 技术

本节总结了一系列有助于应用 TOGAF 方法和

TOGAF ADM 的技术，如表 5-2 所示。

101
TOGAF®标准第 10 版口袋指南（中文版）

表 5-2 ADM 技术总结

章 节 描 述

描述了在整个企业中使用和部署资源的原则，以
架构原则 及如何为正在开发的架构制定一套通用规则和指
南。详见第 7.3 节

描述了如何进行利益相关者管理，成功的架构从
利益相关者管理
业者可使用这一重要原则来赢得项目支持

架构模式 提供了有关如何使用架构模式的指导

描述了 TOGAF ADM 中验证正在开发的架构所使

差距分析
用的技术

描述了在阶段 E 和阶段 F 支持迁移规划的一系列

迁移规划技术
技术。详见第 5.3.3 节

互操作性需求 描述了用于确定互操作性需求的技术

业务转型就绪度评估 描述了用于识别业务转型问题的技术

风险管理 描述了在架构/业务转型项目㊀期间管理风险的技术

介绍了一种用于确定替代目标架构并权衡不同替
架构替代方案与权衡
代方案的技术

5.3.1 利益相关者管理

利益相关者管理是一门重要的学问，它不仅可帮助

㊀ 有关风险管理的更多指导原则，请参阅《TOGAF 系列指南：在
TOGAF®企业架构中集成风险和安全》
。

102
 第5章 TOGAF 基本内容

架构师成功赢得他人的支持，还可确保其项目在别人失
败过的地方取得成功。该技术可在阶段 A 帮助识别架构
工作的关键参与者，并随着每个阶段的推进而更新。该
流程的输出是沟通计划的起点（见第 7.8 节）
。
成功的利益相关者管理的益处是：
• 提早识别出最有权力的利益相关者，并随后利用
其意见来塑造架构，以确保获得持续支持，并提
高生成模型的质量。
• 更有权力的利益相关者的支持可帮助架构工作
赢得更多资源，从而使架构工作更有可能取得
成功。
• 通过尽早与利益相关者频繁地沟通，架构团队可
以确保利益相关者充分理解架构流程以及企业
架构的好处，从而让利益相关者在必要时更积极
地支持架构团队。
• 架构团队可以更有效地预测利益相关者对架构
模型和报告可能产生的反应，以便在行动方案里
安排一系列行动，以产生积极的反应，同时避免

103
TOGAF®标准第 10 版口袋指南（中文版）

或解决消极反应。
• 架构团队可以尽早识别利益相关者之间具有冲
突性或对抗性的目标，并制定策略来解决这些
问题。

5.3.2 差距分析

差距分析技术通常是一个阶段的最后一步。差距分
析的基本前提是，强调基线架构和目标架构之间的差异，
即被故意省略、意外遗漏或尚未定义的项目。
步骤如下：
• 绘制一个矩阵，将所有基线架构的架构构建块
（ABB）放在垂直列，将所有目标架构的架构构
建块放在水平行。
• 在基线架构一列的最后增加一行，标记为“新
增”
，在目标架构行的最后增加一列，标记为“已
删除”
。
• 如果一个 ABB 同时存在于基线架构和目标架构
中，则在交叉单元格将其记录为“已包括”
。

104
 第5章 TOGAF 基本内容

• 如果基线架构中的 ABB 在目标架构中缺失，则

必须检查每一个 ABB。如果确实应该将其删除，
则在相应的“已删除”单元格中对其进行相应的
标记。如果不应将其删除，则代表这是目标架构
中的一处意外遗漏，必须通过在下一轮架构设计
迭代中恢复 ABB 来解决—在相应的“已删除”
单元格中对其进行相应的标记。
• 如果目标架构中的 ABB 在基线架构中缺失，则
在“新增”行的交叉单元格上将 ABB 标记为
待弥补的差距，可以通过开发或采购构建块来
实现。
完成上述操作以后，所有出现在“已删除”列或“新
增”行中的都是差距，这些差距要么解释为应该被消除，
要么被标记出来，以便通过复原或开发/采购功能的方式
来解决。

5.3.3 迁移规划技术

TOGAF 标准定义了许多用于在阶段 E 和阶段 F 支

105
TOGAF®标准第 10 版口袋指南（中文版）

持迁移规划的技术。下面将介绍相关内容。

1．实施因素目录

实施因素目录用于记录对架构实施和迁移计划有影

响的因素。目录应包括需要考虑的因素的列表、对它们

的描述以及对制定计划时必须考虑的行动或限制因素的

推论（结论）
。典型因素包括风险、问题、假设、依赖关

系、行动和影响。目录示例如表 5-3 所示。

表 5-3 实施因素目录

因素 描述 推论

<因素名称> <因素描述> <对迁移计划的影响>

减少呼叫中心 需要对人员进行培训和重新分配
技术变革 的员工，用人工智 人工智能技术可节省大量人力资
能系统取代 500 人 源，应优先考虑

服务整合 …… ……

新客户服务引入 …… ……

2．差距、解决方案和依赖关系综合矩阵

通过使用差距、解决方案和依赖关系综合矩阵，架

106
 第5章 TOGAF 基本内容

构师将能够对领域架构差距分析得出的差距进行分组，
并评估一个或多个差距的潜在解决方案和依赖性，示例
如表 5-4 所示。在创建工作包时，该矩阵可用作一种规
划工具。识别出的依赖性有助于在阶段 E 和 F 中创建项
目和迁移规划。

表 5-4 差距、解决方案和依赖关系综合矩阵

# 架构 差 距 潜在的解决方案 依赖关系

使用 COTS 软件工具流程
1 业务 新订单处理流程 驱动应用 #2
实施定制的解决方案

2 应用 新订单处理应用 COTS 软件工具 X 自研

使用 COTS 客户数据库
3 数据 整合的客户数据库
开发客户数据集市

3．架构定义增量表

通过使用架构定义增量表，架构师将能够对一系列
过渡架构做出规划，列出企业在特定时间点上的状态。
架构师应绘制一张表（如表 5-5 所示）
，列出项目，然后
在过渡架构中分配其增量交付物。

107
TOGAF®标准第 10 版口袋指南（中文版）

表 5-5 架构定义增量表示例

2020 年/2021 年 2021 年/2022 年 2022 年/2023 年

项 目 备注
4月 4月 4月

过渡架构 1： 过渡架构 2： 过渡架构 3：

准备 初始运行能力 收益

企业电子服 培训和业务 电子招聘的

电子许可能力
务能力 流程 收益

IT 电子表单 设计与构建

客户公共数据 企业公共数据
IT 电子信息 设计并构建信
网页内容设 文档管理设
环境 息环境
计和构建 计和构建

…… …… …… …… ……

4．过渡架构状态演进表

通过使用过渡架构状态演变表，架构师可以使用为
企业定义的分类法展示各个级别的建议架构状态。
绘制一张表，列出企业的各类服务、各个过渡架构
和建议的转型，如表 5-6 所示。该表应该描述出所有解
决方案构建块（SBB）的交付情况及其对这些服务的影
响。此外还应对它们进行标记，以表明企业架构开发工
作的进展。在下面的示例中，当已经达到目标能力时，

108
 第5章 TOGAF 基本内容

应该将 SBB 标记为“新增”或“保留”

；当能力过渡到
新的解决方案时，将 SBB 标记为“过渡”
；且当需要替
换能力时，将 SBB 标记为“替换”
。

表 5-6 过渡架构状态演进表示例

子 域 服 务 过渡架构 1 过渡架构 2 过渡架构 3

解决方案系 解决方案系 解决方案系

基础设施应用 信息交换服务
统 A（替换） 统 B-1（过渡） 统 B-2（新增）

解决方案系 解决方案系 解决方案系

数据管理服务
统 D（保留） 统 D（保留） 统 D（保留）

…… ……

5．业务价值评估矩阵

业务价值评估矩阵是一个基于价值指标维度和风险
指标维度的矩阵，可用于评估项目的业务价值。
图 5-1 的示例展示了项目 A～H 的业务价值。价值
指标应包括原则遵循度、财务贡献、战略一致性以及竞
争地位等标准。风险指标应包括规模和复杂性、技术、
组织能力和失败影响等标准。每个标准都应被分配一个
单独的权重。

109
TOGAF®标准第 10 版口袋指南（中文版）

图 5-1 业务价值评估矩阵示例

5.3.4 风险管理

阶段 A 最先确定的就是业务转型风险及缓解活动。
风险管理是一种在实施架构项目时缓解风险的技术。
风险管理流程由下列活动组成：
• 风险分类。
• 风险识别。
• 初始风险评估。
• 风险缓解及残余风险评估。
• 风险监控。

110
 第5章 TOGAF 基本内容

建议将风险缓解活动纳入架构工作说明书（见 7.6 节）
。

5.3.5 架构替代方案与权衡

通常有多个可能的目标架构符合架构愿景、架构原
则和需求。最重要的是确定替代目标架构和了解不同的
可能性，并在不同的替代方案之间做出权衡。创建架构
通常需要在相互对抗的影响力之间进行权衡。向利益相
关者提供不同的替代方案和权衡考量，可以帮助架构师
提炼出可能影响最终目标架构的隐含条件、原则及需求。
图 5-2 展示了架构权衡方法。

图 5-2 架构权衡方法

111
TOGAF®标准第 10 版口袋指南（中文版）

5.4 应用 ADM

本文档提供了有关如何调整 TOGAF ADM 以应对

多种使用场景的指南。应用 ADM 文档的具体内容如表
5-7 所示。

表 5-7 应用 ADM 的总结

章 节 描 述

配合不同的架构风
讨论如何调整框架以适应不同的架构风格
格使用 TOGAF 框架

讨论了迭代的概念，并展示了对 ADM 应用迭代概

对 ADM 应用迭代
念的潜在策略

讨论了企业不同层级上出现的不同类型的架构工
在架构景观中应用
作，本节随后还讨论了 ADM 流程如何支持不同的参
ADM
与类别

架构分区 讨论了如何使用分区简化企业架构的开发和管理

5.4.1 架构风格

架构开发方法（ADM）流程可用于众多不同的使用

112
 第5章 TOGAF 基本内容

场景，包括不同的流程风格（例如使用迭代）以及特定
的专业架构（例如安全架构）
。架构风格在聚焦点、形式、
技巧、材料、主题和时间段方面存在差异。TOGAF 标准
是一种通用框架，旨在用于多种环境中。TOGAF 是一种
灵活、可扩展的框架，可随时根据不同的架构风格进行
调整。
组织的架构景观可以包含以多种架构风格开发的架
构工作。在其他利益相关者和基线架构的背景环境下，
TOGAF 标准可确保每个利益相关者需求都得到妥善地
满足。
当使用 TOGAF 支持一种特定的架构风格时，从业
者必须考虑到执行或表达架构所依据的独特特性组合。
识别出架构风格的独特特性是第一步。
第二步是确定如何应对这些独特特性。应对一种独
特的架构风格时不应该对 TOGAF 进行重大变更，而应
经由从业者调整所使用的模型、视角和工具。
在阶段 B、阶段 C 和阶段 D 中，从业者应该选择
相关架构资源（包括模型、视角和工具）来恰当地描述

113
TOGAF®标准第 10 版口袋指南（中文版）

架构领域，并证明利益相关者关注的问题能够得到解
决。不同的架构风格将根据这些独特特性添加必须描述
的新元素、强调现有元素，调整用来描述架构的符号，
并使架构师聚焦于某些利益相关者或利益相关者关注
的问题。
为应对这些特性，架构师通常应该扩展架构内容元
模型，使用特定符号或建模技术，并识别视角。如果特
定架构风格占据主导地位，从业者可以重新步入预备阶
段，以变更架构能力，或在单个 ADM 周期的预期范围
内支持某一项特性。特定风格的参考模型和成熟度模型
是从业者常用的辅助工具。

5.4.2 迭代和 ADM

TOGAF ADM 的图形表达和对各个 ADM 阶段的依

次描述中暗含了瀑布方法论。使用这种表述方法是为了
快速传达架构开发的基本要素和架构开发周期。在实践
中，面对复杂的企业架构开发及其生命周期管理，我
们通常使用迭代和层级这两个关键概念进行管理。

114
 第5章 TOGAF 基本内容

这两个概念紧密关联。
ADM 支持很多具有迭代特征的概念。
开发完整架构景观的迭代：
• 项目会从阶段 A 开始在整个 ADM 周期内进行
迭代。每轮 ADM 周期都受架构工作要求书的
约束。架构输出将充实架构景观，或扩展所描
述的景观，或在需要时变更该景观。
• 独立的项目可同时运行各自的 ADM 周期，尽管
不同项目之间具有联系。
• 一个项目可触发另一个项目的启动。一般情况
下，当较高层级的架构计划识别出需要更详细的
架构的机遇或解决方案时，或者当一个项目识别
出其架构工作要求书范围之外的景观影响时，触
发项目的连锁启动。
一个 ADM 周期内的迭代（架构开发迭代）
：
• 项目可能同时运行多个 ADM 阶段。通常情况下，
这种迭代可用来管理业务架构、信息系统架构和
技术架构之间的相互关系。

115
TOGAF®标准第 10 版口袋指南（中文版）

• 项目可在涵盖多个阶段的计划周期内的 ADM 阶
段之间循环。通常情况下，当没有较高层级的
架构来提供背景环境和约束时，可使用这种
迭代来汇聚出详细的目标架构。
• 项目可返回到之前的阶段，循环回去使用新的信
息更新工作产物。通常情况下，当实施变革的
细节和范围触发利益相关者需求的变更或重新
排列优先顺序时，可使用这种迭代在可执行的
架构路线图或实施与迁移计划上进行汇聚。
管理架构能力的迭代（架构能力迭代）
：
• 在阶段 A 解决架构工作要求书后，输出的结
果可能要求对预备阶段进行新的迭代，以调
整组织的架构能力。
• 在阶段 H 中确定的变更可能要求对预备阶段进
行新的迭代，以调整组织的架构能力。
TOGAF ADM 的建议迭代周期如图 5-3 所示。这些
迭代周期可用于有效地对相关架构活动进行分组，以实
现特定目的。

116
 第5章 TOGAF 基本内容

图 5-3 迭代周期

迭代周期说明如下：
• 架构能力迭代支持创建和演进所需的架构能力。
这类迭代包括建立或调整架构方法、原则、范围、

117
TOGAF®标准第 10 版口袋指南（中文版）

愿景和治理方式，以针对既定的目的或架构参与
类型首次启动架构活动。
• 架构开发迭代支持通过循环开展或整合业务、信
息系统和技术架构的各个阶段来创建内容。这类
迭代可确保架构被作为一个整体来考虑。在这类
迭代中，利益相关者审查通常较为广泛。随着迭
代开展，趋于汇聚的目标向机会和解决方案阶段
及迁移规划阶段扩展，可确保在最终确定架构时
将架构的可实施性考虑在内。
• 过渡规划迭代支持为已定义的架构创建正式的
变更路线图。
• 架构治理迭代支持对朝着已定义的目标架构演
进的变更活动进行治理。
我们可以通过多种技术来将 ADM 用作一个支持架
构层次结构（即层级）的流程。基本上有两种策略可以
应用：
• 在 ADM 流程的单一周期内，通过迭代的方式开
发不同层级的架构。

118
 第5章 TOGAF 基本内容

• 通过并行执行分层级的 ADM 流程开发不同层

级的架构（见图 4-9）
。

5.4.3 在架构景观中应用 ADM

在一个典型的企业中，很多架构都在架构景观中的
各个时点上进行了描述。有些架构是为了解决非常具体
的需求，有些架构则更关注普遍性；有些架构更偏细节，
有些架构则更加宏观。为了解决这种复杂性，TOGAF
标准使用了层级的概念。
层级提供了一个框架，将架构景观划分并归纳总结
为三个粒度层级，如图 5-4 所示。
1）战略架构为运行和变革活动提供了一个组织框
架，并允许在高级管理层面上规划方向。
2）分段架构为运行和变革活动提供了一个组织框
架，并允许在项目群或项目组合层面上规划方向和制定
有效的架构路线图。
3）能力架构为开展变革活动和制定有效的架构路
线图（用于实现能力增量）提供了一个组织框架。

119
TOGAF®标准第 10 版口袋指南（中文版）

图 5-4 架构景观分类模型总结

5.4.4 架构分区

分区用于简化企业架构的开发和管理。架构分区的
原因如下：
• 组织单元架构彼此冲突。

120
 第5章 TOGAF 基本内容

• 不同团队需要同时开发不同的架构元素，分
区支持特定架构师群体拥有并开发特定架构
分段。
• 有效的架构复用需要使用模块化的架构分段，
后者可以采用并整合至更广泛的架构和解决方
案中。
为架构提供一个不容更改的分区模型是不切实际
的。每个企业都需要采用反映其自身运营模式的分区模
型。TOGAF 标准包含了在架构分区时可以应用的分类
标准，以及在预备阶段建立分区的活动指南。

5.5 架构内容

该文档描述了 TOGAF 内容框架（架构制品的结构

化元模型），并概括介绍了典型的架构交付物、交付物
中的制品以及制品所代表的 ABB。架构内容的大纲如
表 5-8 所示。

121
TOGAF®标准第 10 版口袋指南（中文版）

表 5-8 架构内容大纲

章 节 描 述

架构内容文档概述，介绍了架构工作产物
概述 的类别、TOGAF 内容框架、企业元模型、
企业连续序列和企业存储库等关键概念

描述了内容框架，一种用于构建架构描述
TOGAF 内容框架和 和架构描述模型的分类框架。企业元模型定
企业元模型 义了出现在架构描述模型中的实体类型，以
及这些实体之间的关系

论述了架构制品相关的概念，并描述了建
架构制品 议为架构开发方法（ADM）中的每个阶段创
建的制品

架构交付物 描述了 ADM 中引用的交付物

解释了构建块的概念及其在 ADM 中的
构建块
使用

随着从一般基础架构演变到组织特定架
企业连续序列 构，企业连续序列提供了划分架构存储库内
外部架构和解决方案制品的方法

提供了架构存储库的结构框架，支持企业
架构存储库 区分存在于组织不同抽象级别的不同类型的
架构资产

122
 第5章 TOGAF 基本内容

5.5.1 内容框架概述

执行 ADM 的架构师会输出多个工作成果，例如，

流程、架构需求、项目计划、项目合规性评估等。

TOGAF 内容框架旨在：

• 提供架构工作产物的详细模型。

• 在遵循 ADM 时确保已创建的输出保持一致。

• 提供完整的可创建架构输出的清单。

• 降低一套最终架构交付物中出现差距的风险。

• 帮助企业制定标准架构概念、术语和交付物。

本文提供的内容框架可支持将 TOGAF 框架用作

企业内部架构的独立框架。但是，业内也有其他内容

框架（例如，由 ArchiMate 规范提供的内容框架），有

些企业可能会将 TOGAF 框架与外部框架搭配使用。

在这些情况下，TOGAF 内容框架（大纲如图 5-5 所示）

将为 TOGAF 内容映射到其他框架的元模型提供参考

和基础。

123
TOGAF®标准第 10 版口袋指南（中文版）

图 5-5 内容框架大纲

5.5.2 架构工作产物

为了支持新工作产物的分类以及与其他内容框架
（包括当前任何已经分类的架构工作产物）相关联的潜在
需求，内容框架使用以下三个类别来描述使用环境中的
架构工作产物类型：

124
 第5章 TOGAF 基本内容

• 交付物是合同规定的工作产物，通常由其利益相
关者审核、批准和签发—交付物通常代表项目
的输出。
• 制品是描述架构某一方面的架构工作产物。制品
通常分为目录（事物清单）
、矩阵（显示事物之间
的关系）和图（显示事物的图）
。例如，需求目录、
应用交互矩阵和价值链图。架构交付物可包含多个
制品，制品构成了架构存储库的内容。
• 构建块代表业务、IT 或架构能力组件（具有潜在
的可复用性），能够结合其他构建块共同交付架
构和解决方案。

5.5.3 企业连续序列

如图 5-6 所示，企业连续序列对企业存储库中的制
品进行了分类。随着从一般基础架构演变到特定组织架
构，企业连续序列也提供架构、解决方案制品等资产的
分类方法。企业连续序列包含两个互补的概念：架构连
续序列和解决方案连续序列。

125
TOGAF®标准第 10 版口袋指南（中文版）

图 5-6 企业连续序列

5.5.4 架构存储库

在大型企业中运行成熟架构能力将创建大量架构输
出。有效管理并充分利用这些架构工作产物需要对不同
类型的架构资产进行统一分类，并使用架构内容存储专
用流程和工具。
TOGAF 标准提供了架构存储库的结构框架（如图
5-7 所示）
，支持企业区分存在于组织不同抽象级别的不

126
 第5章 TOGAF 基本内容

同类型的架构资产。此架构存储库是更广泛的企业存储
库的一部分，提供了将架构资产与详细设计、部署和服
务管理存储库组件相关联的能力。

图 5-7 架构存储库概述

5.6 企业架构能力和治理

该文档提供了一系列资源、指南指导原则、模板、

127
TOGAF®标准第 10 版口袋指南（中文版）

背景信息等，旨在帮助组织在内部建立架构实践和治理

框架（大纲如表 5-9 所示）

。它描述了在企业内建立和运

行架构职能所需的组织、流程、技能、角色和职责，并

介绍了企业架构治理框架。

表 5-9 企业架构能力和治理大纲

章 节 描 述

关于如何使用 ADM 在组织内部建立架构能力的指

建立架构能力
导原则

架构治理 架构治理的框架和指导原则

架构委员会 企业架构委员会的建立和运营指导原则

架构合同 架构合同的定义和使用指导原则

架构合规性 确保项目符合架构需求的指导原则

5.6.1 架构能力

TOGAF 架构能力概述如图 5-8 所示。

128
 第5章 TOGAF 基本内容

图 5-8 架构能力概述

5.6.2 架构治理

TOGAF 标准包含了为架构治理提供的框架和指导
原则。架构治理是在整个企业范围内管理和控制企业架
构及其他架构的实践。它包括以下几方面：
• 实施创建和监控所有架构组件及活动的控制体
系，以确保架构在组织内有效引入、实施和演进。

129
TOGAF®标准第 10 版口袋指南（中文版）

• 实施确保遵守内外部标准和监管义务的体系。
• 建立可靠流程，可支持在协定参数范围内有效管
理上述流程。
• 建立和记录影响企业架构的决策结构，其中包括
为决策提供意见的利益相关者。
• 制定实践，确保对组织内外明确标明的利益相关
者社区负责。

5.6.3 架构委员会

企业架构不仅仅只是使用 ADM 流程后生成的制

品，也是为确保组织按照架构中规定的原则行事，需要

的一个决策框架。TOGAF 标准为建立和运营企业架构委

员会提供了一系列指导原则。

架构委员会负责运营项目，必须能够在可能发生冲

突的情况下做出决策，并对这些决策行为负责。因此，

该机构应代表架构中的所有关键利益相关者，通常包括

一组负责审核和维护整体架构的管理人员。架构委员会

130
 第5章 TOGAF 基本内容

的成员必须涵盖架构、业务和项目群管理领域，这一点

很重要。

架构委员会负责以下事务并承担相应责任：

• 为架构变更方面的所有决策奠定基础。

• 子架构之间的一致性。

• 识别可复用的组件。

• 企业架构的灵活性；满足业务需求和利用新技术。

• 执行架构合规性。

• 提高组织内架构规程的成熟度。

• 确保采用基于架构的开发规程。

• 为越限决策提供可见的上报能力。

架构委员会还负责运营项目，例如架构合同的监测

和控制（见第 7.18 节）
，以及治理项目，例如生成可用

的治理材料。重点任务有：

• 分配架构任务。

• 正式批准架构产物。

• 解决架构冲突。

131
TOGAF®标准第 10 版口袋指南（中文版）

第 6 章 TOGAF 架构开
发方法

本章描述了 TOGAF 架构开发方法（ADM）

，包括
每个 ADM 阶段的汇总表。

6.1 什么是 ADM

ADM 为架构开发提供了一个经验证且可复用的流
程。该方法专为满足业务需求而设计，可帮助建立针对
特定组织的企业架构。它包括建立架构框架、开发架构
内容、完成架构过渡并实施架构治理。这些活动在架构
定义中不断迭代循环，使企业以一种可控的方式实现转
型，以响应业务目的和机遇，详见图 6-1。

132
 第6章 TOGAF 架构开发方法

图 6-1 架构开发周期

133
TOGAF®标准第 10 版口袋指南（中文版）

6.2 ADM 包括哪些阶段

表 6-1 总结了 ADM 的各个阶段及其目的。

表 6-1 ADM 的各个阶段

ADM 阶段 目 的

描述了创建架构能力所需的准备和启动活动，
预备阶段
包括定制 TOGAF 框架和定义架构原则

需求管理 在整个 ADM 过程中执行架构需求管理流程

描述了架构开发周期的初始阶段

该阶段包括定义架构开发计划的范围、识别
阶段 A：架构愿景
利益相关者、创建架构愿景并获得批准以继续
推进架构开发工作

阶段 B： 描述了四种架构的开发，它们是公认的整体企
业务架构 业架构的子集，目的是支持达成一致的架构愿景：

阶段 C：信息系统架构 业务

（数据和应用） 信息系统—数据

阶段 D： 信息系统—应用

技术架构 技术

阶段 E： 制定初步实施计划，并为之前阶段定义的架构
机会和解决方案 确定交付载体

134
 第6章 TOGAF 架构开发方法

（续）

ADM 阶段 目 的

阶段 F： 解决了如何通过最终确定的详细实施和迁移计
迁移规划 划，实现从基线架构向目标架构的迁移

阶段 G：
为实施提供架构监督
实施治理

阶段 H：架构变更管理 建立了新架构的变更管理程序

TOGAF 标准对 ADM 阶段的描述侧重于定义和部署

企业架构的建议。TOGAF 系列指南还提供了有关如何应
用这些建议的其他更多指导。
其中一项重要的建议是，应调整 ADM 以满足企业
的需求，并支持不同的架构风格。尤其需要指出的是，
在启动架构开发周期后，ADM 不要求以任何特定顺序
执行各个阶段，也不要求采用“瀑布”方法。

6.3 ADM 详细介绍

表 6-2、表 6-3 总结了每个 ADM 阶段的目标、步骤
以及输入和输出。

135
TOGAF®标准第 10 版口袋指南（中文版）

6.3.1 预备阶段

预备阶段描述了为满足新的企业架构能力的业务要
求需要开展的准备和启动活动，包括定义特定组织架构
框架和原则。
表 6-2 对预备阶段进行了概述，表 6-3 对预备阶段
的输入和输出进行了概述。

表 6-2 预备阶段的目标和步骤

目 标 步 骤

确定组织所期望的架构能力： 界定受影响的企业组织的范
审核实施企业架构的组织背景环境 围

识别并界定受架构能力影响的企业组织 确认治理和支持框架
元素及范围 定义并建立企业架构团队和
识别与架构能力相交叉的已有框架、方 组织
法及流程
识别和建立架构原则
建立能力成熟度目标
裁剪 TOGAF 框架及选定的
建立架构能力：
其他架构框架（如有）
定义并建立企业架构的组织模型
为工具和技术制定战略和实
定义并建立详细的架构治理流程和资源 施计划
选择并实施支持架构能力的工具
定义架构原则

136
 第6章 TOGAF 架构开发方法

表 6-3 预备阶段的输入和输出

输 入 输 出

TOGAF 库 企业架构的组织模型
其他架构框架 经裁剪的架构框架，包括架构
委员会战略、业务计划、业务战略、IT 战 原则、配置和部署的工具
略、业务原则、业务目的和业务驱动因素 初始架构存储库
业务中运行的主要框架
对业务原则、业务目的和业务
治理和法律框架 驱动因素的重申或引用
架构能力 架构工作要求
合作和合同协议
架构治理框架
企业架构的现有组织模型
企业架构能力架构
现有架构框架（如有）
，包括：
架构方法
架构内容
配置和部署的工具
架构原则
架构存储库

6.3.2 阶段 A：架构愿景

阶段 A 是 ADM 的第一个阶段。
该阶段包括定义范围、
识别利益相关者、创建架构愿景和获得批准的信息。表 6-4
和表 6-5 分别概述了阶段 A 的目标和步骤、输入和输出。

137
TOGAF®标准第 10 版口袋指南（中文版）

表 6-4 阶段 A 的目标和步骤

目 标 步 骤

为拟议的企业架构所 建立架构项目
交付的能力和业务价值 识别利益相关者、关注点和业务需求
制定高级愿景
确认和详细阐述业务目的、业务驱动因素和约束
获得对定义了工作计
评估能力
划的架构工作说明书的
评估业务转型就绪度
批准，以开发和部署架构
定义范围
愿景中概述的架构
确认和阐明架构原则，包括业务原则
制定架构愿景
定义目标架构价值主张和关键绩效指标 (KPI)
识别业务转型风险和缓解活动
开发架构工作说明书；确保批准

表 6-5 阶段 A 的输入和输出

输 入 输 出

架构工作要求 获批的架构工作说明书
业务原则、
业务目的和业务 对业务原则、业务目的和业务驱动因素的细化
驱动因素 说明
企业架构的组织模型 架构原则能力评估
经裁剪的架构框架，包括 经裁剪的架构框架
裁剪的架构方法、架构内 架构愿景，包括：
容、架构原则、配置和部署
细化的关键高层级利益相关者需求
的工具
草拟的架构定义文档，其中可能包括任何架构域
已添加文档的架构存储库；

138
 第6章 TOGAF 架构开发方法

（续）

输 入 输 出

即现有架构文档（框架描 的基线和/或目标架构
述、架构描述、现有基线的 沟通计划
描述等） 添加文档的架构存储库的补充内容

6.3.3 阶段 B：业务架构

阶段 B 描述了支持协定的架构愿景所需的业务架
构开发工作。表 6-6 和表 6-7 分别概述了阶段 B 的目标
和步骤，输入和输出。

表 6-6 阶段 B 的目标和步骤

目 标 步 骤

选择参考模型、视角和工具
开发目标业务架构，该架构描述了
开发基线业务架构描述
企业需要如何运行才可解决架构工作
开发目标业务架构描述
说明书和利益相关者关注的问题，从
执行差距分析
而达成业务目的，并响应架构愿景中
定义候选路线图组件
提出的战略驱动因素
化解贯穿整个架构景观的影响
根据基线业务架构与目标业务架
进行正式的利益相关者审核
构之间的差距，识别候选架构路线
最终确定业务架构
图组件
创建/更新架构定义文档

139
TOGAF®标准第 10 版口袋指南（中文版）

请注意，阶段 B、C 和 D 有一些相同的、通用的

步骤。

表 6-7 阶段 B 的输入和输出

输 入 输 出

架构参考资料
架构愿景阶段交付物经过细化和更新
架构工作要求
的版本（如适用）
，包括：
业务原则、业务目的和业务驱动
架构工作说明书
因素
确认的业务原则、业务目的和业务驱
能力评估
动因素
沟通计划
架构原则
企业架构的组织模型
草拟的架构定义文档，包括内容更新：
经裁剪的架构框架
获批的基线业务架构（如适用）
获批的架构工作说明书
目标业务架构（获批的业务能力、业
预先存在的架构原则，包括业务 务数据模型、业务流程等）
原则
与所选视角相对应的视图，主要用于
企业连续序列 解决关键利益相关者的关注
架构存储库 草拟的架构需求规范，包括内容更新：
架构愿景，包括： 差距分析结果
细化的关键高层级利益相关者需求 技术需求
草拟的架构定义文档，其中可能 更新的业务需求
包括任何架构域的基线和/或目标
架构路线图的业务架构组件
架构

140
 第6章 TOGAF 架构开发方法

6.3.4 阶段 C：信息系统架构

阶段 C 描述了架构项目的信息系统架构，包括数
据架构和应用架构的开发。数据架构和应用架构可能
按顺序开发，也可能同步开发，两者在信息系统架构
中会出现某种形式的组合。
1．数据架构
表 6-8 和表 6-9 分别概述了阶段 C—数据架构的
目标和步骤，输入和输出。

表 6-8 阶段 C—数据架构的目标和步骤

目 标 步 骤

开发所需的目标数据架构，以解决架构工作说明书和利益
与阶段 B 的步
相关者的关注，实现业务架构和架构愿景
骤相同，请参见
根据基线数据架构与目标数据架构之间的差距，识别候选
表 6-6。
架构路线图组件

表 6-9 阶段 C—数据架构的输入和输出

输 入 输 出

架构参考资料 架构愿景阶段交付物经过细化和更新的
架构工作要求 版本（如适用）
，包括：

141
TOGAF®标准第 10 版口袋指南（中文版）

（续）

输 入 输 出

架构工作说明书
能力评估
确认的数据原则或新数据原则
沟通计划
草拟的架构定义文档，包括：
企业架构的组织模型
基线数据架构
经裁剪的架构框架
目标数据架构
数据原则
与所选视角相对应的视图，主要用于解
架构工作说明书
决关键利益相关者的关注
架构愿景
草拟的架构需求规范，包括：
架构存储库
差距分析结果
草拟的架构定义文档，其中可
数据互操作性需求
能包括任何架构域的基线和/或目
标架构 适用于架构开发周期演进的相关技术
需求
草拟的架构需求规范，包括：
对技术架构的约束
差距分析结果
更新的业务需求
相关技术需求
更新的应用需求
架构路线图的业务架构组件
架构路线图的数据架构组件

2．应用架构
表 6-10 和表 6-11 分别概述了阶段 C—应用架构
的目标和步骤，输入和输出。

142
 第6章 TOGAF 架构开发方法

表 6-10 阶段 C—应用架构的目标和步骤
目 标 步 骤

开发所需的目标应用架构，以解决架构工作说明 与阶段 B 的步骤相同，

书和利益相关者的关注，实现业务架构和架构愿景 请参见表 6-6。
根据基线应用架构与目标应用架构之间的差
距，识别候选架构路线图组件

表 6-11 阶段 C—应用架构的输入和输出

输 入 输 出

架构愿景阶段交付物经过细化
架构参考资料 和更新的版本（如适用）
，包括：
架构工作要求 架构工作说明书
能力评估 确认的应用原则或新应用原则
沟通计划 草拟的架构定义文档，包括：
企业架构的组织模型 基线应用架构

经裁剪的架构框架 目标应用架构
与所选视角相对应的视图，主要
应用原则
用于解决关键利益相关者的关注
架构工作说明书
草拟的架构需求规范，包括内容
架构愿景
更新：
架构存储库 差距分析结果
草拟的架构定义文档，其中可能包括任 应用互操作性需求
何架构域的基线和/或目标架构 适用于架构开发周期演进的相
草拟的架构需求规范，包括： 关技术需求
差距分析结果 对技术架构的约束
相关技术需求 更新的业务需求

架构路线图的业务和数据架构组件 更新的数据需求
架构路线图的应用架构组件

143
TOGAF®标准第 10 版口袋指南（中文版）

6.3.5 阶段 D：技术架构

阶段 D 描述了架构项目中技术架构的开发工作，
其目标和步骤、输入和输出分别如表 6-12 和表 6-13
所示。

表 6-12 阶段 D 的目标和步骤

目 标 步 骤

开发所需的目标技术架构，通过技术组件和 与阶段 B 的步骤相同，

技术服务交付架构愿景、目标业务、数据和应 请参见表 6-6。
用构建块，以解决架构工作说明书和利益相关
者的关注

根据基线技术架构与目标技术架构之间的差
距，识别候选架构路线图组件

表 6-13 阶段 D 的输入和输出

输 入 输 出

架构参考资料 架构愿景阶段交付物经过细化和更
候选产品的产品信息 新的版本（如适用）
，包括：

架构参考资料 架构愿景阶段交付物经过细化和更

候选产品的产品信息 新的版本（如适用）
，包括：

架构工作要求 架构工作说明书

144
 第6章 TOGAF 架构开发方法

（续）

输 入 输 出

能力评估
确认的技术原则或新技术原则（如
沟通计划
果已在该阶段生成）
企业架构的组织模型
草拟的架构定义文档，包括：
经裁剪的架构框架
基线技术架构（如适用）
技术原则
目标技术架构
架构工作说明书
与所选视角相对应的技术架构视
架构愿景
图，主要用于解决关键利益相关者的
架构存储库 关注
草拟的架构定义文档，其中可能包 草拟的架构需求规范，包括内容
括任何架构域的基线和/或目标架构 更新：
草拟的架构需求规范，包括： 差距分析报告
差距分析结果 阶段 B 和 C 的需求输出
相关技术需求 更新的技术需求
架构路线图的业务、数据和应用架 架构路线图的技术架构组件
构组件

6.3.6 阶段 E：机会和解决方案

阶段 E 描述了识别各种交付载体（项目、项目群
或项目组合）的流程，以便有效地交付此前各阶段识别

145
TOGAF®标准第 10 版口袋指南（中文版）

的目标架构，其目标和步骤、输入和输出如表 6-14 和
表 6-15 所示。阶段 E 是首个与实施直接相关的阶段。
表 6-14 阶段 E 的目标和步骤

目 标 步 骤

确定/确认关键公司级变革属性

确定实施中的业务约束

根据阶段 B、C 和 D 的差距分 审查并整合阶段 B－D 的差距分析

析及候选架构路线图组件，
生成架构 结果
路线图初始的完整版 审核所有相关业务功能的整合需求
确定是否需要增量方法，如需要， 整合并协调互操作性需求
则识别可交付连续业务价值的过渡架
细化和确认依赖关系
构
确认业务转型就绪度和风险
定义整体解决方案构建块
(SBB)，以根据 ABB 最终确定目标 制定实施和迁移战略

架构 识别主要工作包并对其分组

识别过渡架构

创建架构路线图及实施和迁移计划

表 6-15 阶段 E 的输入和输出

输 入 输 出

架构参考资料 架构愿景阶段交付物经过细化
产品信息 和更新的版本（如适用）
，包括：

架构工作要求 架构愿景

能力评估 架构工作说明书

146
 第6章 TOGAF 架构开发方法

（续）

输 入 输 出

架构愿景，必要时进行更新

沟通计划 草拟的架构定义文档，包括：

规划方法 任何架构域的基线和/或目标架构

企业架构的组织模型 过渡架构及其数量和范围（如有）

治理模型和框架 草拟的架构需求规范，包括已

经裁剪的架构框架 整合的差距、解决方案和依赖性
综合评估
架构工作说明书
能力评估，包括：
架构愿景
业务能力
架构存储库
IT 能力
草拟的架构定义文档，其中可能包括任
何架构域的基线和/或目标架构 架构路线图，包括

草拟的架构需求规范 工作包组合

对现有业务项目群和项目的变更要求 过渡架构的识别（如有）

来自阶段 B、C 和 D 的候选架构路线 实施建议

图组件 草拟的实施和迁移计划，包括：

实施和迁移战略

6.3.7 阶段 F：迁移规划

阶段 F 论述了迁移规划，即如何通过最终确定的详
细实施和迁移计划，实现从基线架构向目标架构的迁移，

147
TOGAF®标准第 10 版口袋指南（中文版）

其目标和步骤、输入和输出如表 6-16 和表 6-17 所示。

表 6-16 阶段 F 的目标和步骤

目 标 步 骤

为实施和迁移计划确认管理框架交互
关系
最终确定架构路线图和支持的 指定每个工作包的业务价值
实施和迁移计划
评估资源需求、项目时间安排和可用性/
保证实施和迁移计划与企业
交付载体
整体变革组合中企业管理和实施
通过执行成本/收益评估和风险评估确
变革的方式相协调
定迁移项目优先级
确保关键利益相关者了解工作
确认架构路线图并更新架构定义文档
包和过渡架构的业务价值和成本
完成实施和迁移计划

完成架构开发周期并记录经验教训

表 6-17 阶段 F 的输入和输出

输 入 输 出

架构参考资料
实施和迁移计划（详案）
，包括：
架构工作要求
实施和迁移战略
能力评估
实施的项目和项目组合分解
沟通计划
项目章程（可选）
企业架构的组织模型
最终确定的架构定义文档，包括：
治理模型和框架
最终确定的过渡架构（如有）
经裁剪的架构框架

148
 第6章 TOGAF 架构开发方法

（续）

输 入 输 出

架构工作说明书

架构愿景

架构存储库
最终确定的架构需求规范
草拟的架构定义文档，其中可能包括任
何架构域的基线和/或目标架构 最终确定的架构路线图

草拟的架构需求规范 可复用的 ABB

对现有业务项目群和项目的变更要求 用于开展 ADM 周期新一轮迭

代的架构工作要求（如有）
架构路线图
实施治理模型
能力评估，包括：
由经验教训产生的架构能力变
业务能力
更要求
IT 能力

草拟的实施和迁移计划，包括：

高层级实施和迁移战略

6.3.8 阶段 G：实施治理

阶段 G 描述了如何监管架构的实施，其目标和步
骤、输入和输出如表 6-18 和表 6-19 所示。

149
TOGAF®标准第 10 版口袋指南（中文版）

表 6-18 阶段 G 的目标和步骤

目 标 步 骤

通过开发管理确认部署范围和优先次序
通过实施项目确保与目标架
明确部署资源和技能
构的一致性
指导解决方案部署开发
为解决方案和任何由实施驱 执行企业架构合规性审查
动的架构变更要求执行适当的
实施业务和 IT 运营
架构治理职能
执行实施后审核并结束实施

表 6-19 阶段 G 的输入和输出

输 入 输 出

架构参考资料 架构合同（已签署）

架构工作要求 合规性评估

能力评估 变更要求

企业架构的组织模型 所部署的符合架构的解决方案，包括：

经裁剪的架构框架 已实施的符合架构的系统

架构工作说明书 已添加文档的架构存储库

架构愿景 架构合规建议与特许

架构存储库 服务交付需求建议

架构定义文档 绩效指标建议

架构需求规范 服务级别协议 (SLA)

架构路线图 架构愿景，实施后更新

实施治理模型 架构定义文档，实施后更新

150
 第6章 TOGAF 架构开发方法

（续）

输 入 输 出

架构合同（标准）
已实施的解决方案的业务和 IT 运营
阶段 E 和 F 中确定的架构工作
模型
要求
ABB
实施和迁移计划

6.3.9 阶段 H：架构变更管理

阶段 H 建立了管理新架构变更的程序，其目标和
步骤、输入和输出如表 6-20 和表 6-21 所示。

表 6-20 阶段 H 的目标和步骤

目 标 步 骤

建立价值实现流程

部署监控工具

确保架构开发生命周期得以维持 管理风险

确保架构治理框架得以执行 提供架构变更管理分析

确保企业架构能力符合当前需求 确定变更需求，以实现绩效目标

管理治理流程

启动实施变更流程

151
TOGAF®标准第 10 版口袋指南（中文版）

表 6-21 阶段 H 的输入和输出

输 入 输 出

架构参考资料 架构更新（支持维护变更）

架构工作要求 架构框架和原则的变更（支持维护

企业架构的组织模型 变更）

经裁剪的架构框架 新的架构工作要求，用于启动另一个
ADM 周期（支持重大变更）
架构工作说明书
架构工作说明书，必要时进行更新
架构愿景
架构合同，必要时进行更新
架构存储库
合规性评估，必要时进行更新
架构定义文档

架构需求规范

架构路线图

技术变更导致的变更要求

业务变更导致的变更要求

从经验教训中获得的变更要求

实施治理模型

架构合同（已签署）

合规性评估

实施和迁移计划

6.3.10 需求管理

此阶段涉及贯穿整个 ADM 的架构需求管理流程，适

152
 第6章 TOGAF 架构开发方法

用于 ADM 周期的所有阶段。
需求管理是一个动态的过程，
它解决了企业需求的识别和存储问题，同时也会在相关的
ADM 阶段输入和输出这些需求。如图 6-1 所示，该流程
是驱动 ADM 流程的核心。需求管理阶段的目标和步骤、
输入和输出如表 6-22 和表 6-23 所示。
表 6-22 需求管理的目标和步骤

目 标 步 骤

识别/记录需求

基线需求

监控基线需求

识别新需求和变更的需求；删除、添加、

确保需求管理流程在所有相关 修改和重新评估优先级
ADM 阶段得以维持并运行 识别变更的需求并记录优先级；识别
管理在执行 ADM 周期或其中 和解
一个阶段期间识别的架构需求 决冲突；生成需求影响说明书
确保在执行该阶段时相关架构 评估变更的需求对当前和先前 ADM
需求可供每个阶段使用 阶段的影响

实施从阶段 H 中产生的需求

更新架构需求存储库

在当前阶段中实施变更

为已结束的阶段评估并修订差距分析

153
TOGAF®标准第 10 版口袋指南（中文版）

表 6-23 需求管理的输入和输出

输 入 输 出

已添加文档的架构存储库 变更需求

企业架构的组织模型 更新的需求规范

经裁剪的架构框架

架构工作说明书

架构愿景

添加架构需求规范的架构需求

需求影响说明书

154
 第7章 ADM 交付物

第 7 章 ADM 交付物

本章描述了架构交付物的典型基线，以便更好地定
义 ADM 中所需的活动，并作为在特定组织内定制的
起点。
表 7-1 显示了可以创建、使用或丰富交付物的各个
ADM 阶段，是 ADM 交付物路线图。

表 7-1 ADM 交付物路线图

ADM 阶段 引用源

第 7.1 节 裁剪的架构框架
第 7.2 节 企业架构的组织模型
预备阶段 第 7.3 节 架构原则
第 7.4 节 业务原则、业务目的和业务驱动因素
第 7.5 节 架构工作要求

第 7.6 节 架构工作说明书
第 7.7 节 架构愿景
阶段 A：架构愿景 第 7.8 节 沟通计划
第 7.9 节 能力评估
第 7.10 节 架构定义文档

155
TOGAF®标准第 10 版口袋指南（中文版）

（续）
ADM 阶段 引用源

第 7.10 节 架构定义文档
第 7.11 节 架构需求规范
阶段 B：业务架构
第 7.12 节 架构路线图
第 7.13 节 架构构建块

第 7.10 节 架构定义文档
第 7.11 节 架构需求规范
阶段 C：
信息系统架构
第 7.12 节 架构路线图
第 7.13 节 架构构建块

第 7.10 节 架构定义文档
第 7.11 节 架构需求规范
阶段 D：技术架构
第 7.12 节 架构路线图
第 7.13 节 架构构建块

第 7.10 节 架构定义文档
第 7.13 节 架构构建块
第 7.12 节 架构路线图
阶段 E：机会和解决
第 7.14 节 解决方案构建块
方案
第 7.15 节 实施和迁移计划
第 7.16 节 过渡架构
第 7.17 节 实施治理模型

第 7.12 节 架构路线图
第 7.15 节 实施和迁移计划
阶段 F：迁移规划
第 7.16 节 过渡架构
第 7.17 节 实施治理模型

第 7.17 节 实施治理模型
阶段 G：实施治理
第 7.18 节 架构合同

156
 第7章 ADM 交付物

（续）
ADM 阶段 引用源

第 7.19 节 变更要求
阶段 G：实施治理
第 7.20 节 合规性评估

第 7.17 节 实施治理模型
第 7.18 节 架构合同
第 7.19 节 变更要求
阶段 H：
架构变更管理
第 7.20 节 合规性评估
第 7.5 节 架构工作要求
第 7.21 节 需求影响评估

第 7.11 节 架构需求规范
ADM 架构需求管理
第 7.21 节 需求影响评估

7.1 裁剪的架构框架

在将 TOGAF 框架有效用到架构项目中之前，在多个
层级上进行裁剪是很有必要的，并且应在预备阶段进行。
首先，必须要裁剪框架以集成到企业中。这种裁剪将包括
与管理框架的集成、术语定制、演示样式的开发、架构工
具的选择、配置和部署等。此外，采用的任何框架的正式
程度和细节还应与企业的其他背景环境因素保持一致，例

157
TOGAF®标准第 10 版口袋指南（中文版）

如文化、利益相关者、企业架构的商业模型及架构能力的
现有水平。在为企业裁剪框架后，架构师需要为特定架构
项目进一步裁减框架。这种级别的裁剪将选择适当的交付
物和制品，以满足项目和利益相关者需求。
裁剪的架构框架通常包含以下内容：
• 裁剪的架构方法。
• 裁剪的架构内容（交付物和制品）
。
• 配置和部署的工具。
• 治理模型和其他框架的接口：
◦ 公司业务规划。
◦ 企业架构。
◦ 项目组合、项目群、项目管理。
◦ 系统开发/工程。
◦ 运营（服务）
。

7.2 企业架构的组织模型

预备阶段生成的一个重要交付物就是企业架构的组

158
 第7章 ADM 交付物

织模型。
为了成功使用架构框架，必须由企业内正确的组织、
角色和职责提供支持。不同企业架构从业者之间边界的
定义及跨越这些边界的治理关系尤为重要。
企业架构组织模型通常包含以下内容：
• 受影响的组织范围。
• 成熟度评估、差距和解决方法。
• 架构团队的角色和职责。
• 对架构工作的限制。
• 预算需求。
• 治理和支持战略。

7.3 架构原则

7.3.1 架构原则的概念

架构原则是与架构工作有关的一套通用原则和指
南，是预备阶段的输出。有关指南和详细的通用架构原

159
TOGAF®标准第 10 版口袋指南（中文版）

则，包括业务、数据、应用和技术原则，请参阅《TOGAF
标准—ADM 技术》文档（架构原则）
。
架构原则通常由企业架构师与关键利益相关者联合
制定，并且需获得架构委员会的批准。架构原则将以该
企业层级上的原则（如有）为依据。
以下因素通常会影响架构原则的制定：
• 企业使命和计划：企业的使命、计划和组织基础
设施。
• 企业战略举措：企业的特征（优势、劣势、机遇
和威胁）及其当前整个企业范围的举措（如流程
改进和质量管理）
。
• 外部限制：市场因素（上市时间要求、客户期望
等）
；现有和潜在的法律。
• 当前系统和技术：在企业内部署的一套信息资
源，包括系统文档、设备清单、网络配置图、策
略和程序。
• 新兴行业趋势：影响企业环境的经济、政治、技
术和市场因素预测。

160
 第7章 ADM 交付物

7.3.2 定义架构原则

TOGAF 标准包括一个描述原则的建议模板，如
表 7-2 所示。除了描述定义之外，每项原则还应说明
理由依据和影响，以加强对原则的理解和认可，并支
持使用这些原则来解释做出特定决策的原因以及决策
的合理性。

表 7-2 用于定义原则的 TOGAF 模板

应既表达出规则的实质，又便于记忆。原则的名称或
说明不应提到特定技术平台。避免在名称和说明中使用
歧义词，例如“支持”
“开放”
“考虑”
，并且由于缺乏良
名 称
好的衡量标准，不要使用“避免”一词；谨慎使用“管
理”一词，注意不要使用不必要的形容词和副词（无用
的词语）

应简洁、准确地传达基础性的规则。在多数情况下，
说 明 信息管理原则的说明在不同组织之间具有相似性。原则
说明务必避免含糊不清

应使用业务术语来强调遵循该原则可带来的业务
好处。应指出信息和技术原则与业务运营治理原则的
逻辑依据 相似性。此外，还应描述与其他原则的关系和关于平
衡解释的意图。描述在哪些情况下进行决策时优先考
虑某一原则

161
TOGAF®标准第 10 版口袋指南（中文版）

（续）
应强调对业务和 IT 的需求，以便从资源、成本和活
动/任务的角度贯彻该原则。现行系统、标准或实践在采
用时经常会出现与原则不符的情况，应明确说明采用原
影 响 则对业务的影响及带来的后果。读者应该能够轻松了解
该原则对自身的影响。重要的是，不要过分简单化、淡
化或断定该影响的优点。其中的一些意义将仅被确定为
潜在影响，并且可能具有推测性，而并非经过充分分析

一套良好的原则应该能达到以下五个标准，如
表 7-3 所示。
表 7-3 高质量原则的建议标准
标 准 描 述

为组织治理信息和技术管理的每个潜在重要原则都应
完整性 该进行定义。
这些原则涵盖预见到的每种情况
支持对待制定的架构和计划、待创建的可执行方针和
稳健性 标准做出高质量决策。每项原则都应足够明确且精确，
以便在有潜在争议的复杂情况下支持进行一致的决策
可以让整个组织中的任何人迅速掌握和理解其基本宗
易于理解 旨。这些原则具有毫不含糊的明确目标，以尽量避免违
背（无论有意还是无意）
如果要求严格遵守一项原则，那么可能就需要适当地
放宽另一项原则。一套原则在进行表述时，应该在各项
解释之间实现平衡
一致性
原则不应相互矛盾，即不得因为遵守一个原则就违背
另一个原则的精神。原则说明中的每个字都应仔细斟酌，
以便在保持一致性的同时，确保解释的灵活性
原则应该既具有持久性，又能够适应变化。在最初批
稳定性
准原则之后，应建立一个添加、删除或更改原则的流程

162
 第7章 ADM 交付物

7.4 业务原则、目的和驱动因素

一般情况下，在架构活动开始之前，业务原则、
目的和驱动因素就已经在企业的其他地方进行了定
义。架构师会将它们重新定位为预备阶段的输出，并
作为“阶段 A：架构愿景”的一部分再次进行审核。
阶段 A 的活动是为了确保当前定义正确且清晰。
《TOGAF 标准—ADM 技术》文档（架构原则）提供
了一组示例，其中包含九项业务原则，是一个非常实
用的起点。

7.5 架构工作要求书

架构工作要求书是发起组织发送给架构组织的文
档，可触发启动架构开发周期。它是在架构组织的协助

163
TOGAF®标准第 10 版口袋指南（中文版）

下生成的，是预备阶段的输出。之所以要创建架构工作
要求，是因为架构变更要求获得了批准，或者是为了履
行迁移计划生成的架构工作职责。
一般而言，本文档中的所有信息应位于概要层面。
本文档通常包含以下内容：
• 组织发起人。
• 组织的使命声明。
• 业务目的（和变更）
。
• 业务战略计划。
• 时间限制。
• 业务环境变更。
• 组织限制。
• 预算信息、财务限制。
• 外部限制、业务限制。
• 当前业务系统描述。
• 当前架构/IT 系统描述。
• 开发组织的描述。
• 开发组织可用资源的描述。

164
 第7章 ADM 交付物

7.6 架构工作说明书

架构工作说明书作为阶段 A 的交付物创建而成，
实际上是架构开发组织与架构项目发起人之间的架构合
同。本文档是对架构工作要求输入文档的响应（见第 7.5
节）
。它应该描述解决工作要求的总体计划，并提出如何
在架构工作过程中处理已经确定的问题解决方案。
本文档通常包含以下内容：
• 标题。
• 架构项目要求和背景。
• 架构项目描述和范围。
• 架构愿景的概述。
• 具体的范围变更程序。
• 角色、职责和交付物。
• 验收准则和程序。
• 架构项目计划和进度表。
• 批准。

165
TOGAF®标准第 10 版口袋指南（中文版）

7.7 架构愿景

架构愿景是在阶段 A 创建的，高度概括了成功部署
目标架构会给企业带来哪些变化。愿景的目的是让大家
在一开始就对架构工作的预期成果达成共识，从而让架
构师专注于验证可行性所需的细节。此外，通过提供完
整架构定义的概要版本，提供架构愿景还支持利益相关
者沟通。业务场景可以被看作是架构愿景文档开发流程
中的一个环节，是一项恰当和重要的技术。
架构愿景文档通常包含以下内容：
• 问题描述：
◦ 利益相关者及其关注点。
◦ 将解决的问题/场景列表。
• 架构工作说明书目标。
• 架构工作要求和创建草拟业务、数据、应用和技
术架构所需的概要视图。
• 映射要求。

166
 第7章 ADM 交付物

• 起草架构定义文档的参考资料。

7.8 沟通计划

企业架构包含大量复杂和相互依赖的信息。适时将
目标信息有效地传达给正确的利益相关者是企业架构的
关键成功因素（Critical Success Factor，CSF）
。通过在阶
段 A 制定架构沟通计划，这些信息可以在已计划的管理
流程中更好地进行传达。
沟通计划通常包含以下内容：
• 确定利益相关者并按沟通要求进行分组。
• 确定沟通需求、与架构愿景相关的关键消息、沟
通风险和 CSF。
• 确定用于与利益相关者沟通并支持访问架构信
息的机制（如会议、新闻简报、存储库等）
。
• 确定沟通时间表，显示每项沟通将在何时何地与
哪些利益相关者群组进行。

167
TOGAF®标准第 10 版口袋指南（中文版）

7.9 能力评估

在开始制定详细的架构定义之前，了解企业的基线
和目标能力水平十分重要。该能力评估首先在阶段 A
进行，随后在阶段 E 进行更新。
能力评估交付物通常包含以下内容：
• 业务能力评估，包括：
◦ 业务能力。
◦ 每个能力绩效水平的基线状态评估。
◦ 对每个能力绩效水平未来状态的期望。
◦ 对如何实现每个能力的基线状态评估。
◦ 对应如何实现每个能力未来状态的期望。
◦ 评估成功部署目标架构可能给业务组织带来
的影响。
• IT 能力评估，包括：
◦ 变更流程的基线和目标成熟度水平。

168
 第7章 ADM 交付物

◦ 运营流程的基线和目标成熟度水平。
◦ 基线能力和能力评估。
◦ 评估成功部署目标架构可能给 IT 组织带来的
影响。
• 架构能力评估，包括：
◦ 架构治理流程、组织、角色和职责。
◦ 架构技能评估。
◦ 架构存储库中景观定义的广度、深度和质量。
◦ 架构存储库中标准定义的广度、深度和质量。
◦ 架构存储库中参考模型定义的广度、深度和
质量。
◦ 可复用可能性的评估。
• 业务转型就绪度评估，包括：
◦ 就绪度因素。
◦ 每个就绪度因素的愿景。
◦ 当前和目标就绪度评定。
◦ 就绪度风险。

169
TOGAF®标准第 10 版口袋指南（中文版）

7.10 架构定义文档

架构定义文档是项目期间创建的核心架构制品和重
要相关信息的交付物载体。架构定义文档涵盖包括业务、
数据、应用和技术的所有架构域，并审查架构的基线、
过渡和目标在内的所有相关状态。
架构定义文档先在阶段 A 创建，在这个阶段它会
使用创建的制品进行填充，以支持架构愿景。它在阶段
B 使用与业务架构相关的材料进行更新，然后在阶段 C
使用信息系统架构材料进行更新，接下来再在阶段 D
使用技术架构材料进行更新。只要实施目标架构的变更
范围需要增量方法，架构定义文档就会进行更新，从而
在阶段 E 涵盖一个或多个过渡架构。
架构定义文档是架构需求规范的配套文件，两者的
目标具有互补性：
• 架构定义文档提供了解决方案的定性视图，旨在
传达架构师的意图。

170
 第7章 ADM 交付物

• 架构需求规范提供了解决方案的定量视图，说明了
在实施支持架构的解决方案的过程中必须满足的
可衡量准则。
架构定义文档通常包含以下内容：
• 范围。
• 目的、目标和限制。
• 架构原则。
• 基线架构。
• 架构模型（面向需要建模的每个状态）
：
◦ 业务架构模型。
◦ 数据架构模型。
◦ 应用架构模型。
◦ 技术架构模型。
• 架构方法的理由依据和合理性。
• 映射到架构存储库：
◦ 映射到架构景观。
◦ 映射到参考模型。
◦ 映射到标准。
◦ 复用评估。

171
TOGAF®标准第 10 版口袋指南（中文版）

• 差距分析。
• 影响评估。
• 过渡架构（见第 7.16 节）
。
以下章节更详细地介绍了每种架构。

7.10.1 业务架构

业务架构在阶段 B 开发。架构定义文档应探讨与业
务架构相关的以下主题：
• 基线业务架构（如适用）—这是对现有业务架构
的描述。
• 目标业务架构，包括：
◦ 组织结构—确定业务位置，并与组织单元相
关联。
◦ 业务目的和目标—适用于企业和每个组织
单元。
◦ 业务功能—一个详细的递归步骤，包括将主
要职能领域逐步分解为子功能。
◦ 业务能力—企业为实现其目的和目标所需

172
 第7章 ADM 交付物

拥有或交流的能力。
◦ 业务服务—通过封装独特的“业务行为元
素”来支持业务的服务；外部提供给企业的服
务可能由业务服务提供支持。
◦ 产品—提供给客户的业务产生的输出；产品
包括材料和/或服务。
◦ 业务流程，包括衡量标准和交付物。
◦ 业务角色，包括确定和修改技能需求。
◦ 业务数据模型。
◦ 组织与功能的关联—以矩阵报告的形式将
业务功能与组织单元相关联。
• 与所选视角相对应的视图，主要用于解决关键利
益相关者关注的问题。

7.10.2 信息系统架构

信息系统架构是在阶段 C 开发的。架构定义文档
应探讨与信息系统架构相关的以下主题：
• 基线数据架构（如适用）
。

173
TOGAF®标准第 10 版口袋指南（中文版）

• 目标数据架构，包括：
◦ 业务数据模型。
◦ 逻辑数据模型。
◦ 数据管理流程模型。
◦ 数据实体/业务功能矩阵。
• 与所选视角相对应的数据架构视图，主要用于解
决关键利益相关者关注的问题。
• 基线应用架构（如适用）
。
• 目标应用架构。
• 与所选视角相对应的应用架构视图，主要用于解
决关键利益相关者关注的问题。

7.10.3 技术架构

技术架构作为阶段 D 的一部分开发。架构定义文
档应探讨与技术架构相关的以下主题：
• 基线技术架构（如适用）
。
• 目标技术架构，包括：
◦ 技术组件及其与信息系统的关系。

174
 第7章 ADM 交付物

◦ 技术平台及其分解，可表明实现特定技术堆栈
所需的技术组合。
◦ 环境和位置—所需技术在计算环境中的分
组（如开发、生产）
。
◦ 期望的处理负载和负载在技术组件中的分布。
◦ 物理（网络）通信。
◦ 硬件和网络规范。
• 与所选视角相对应的视图，主要用于解决关键利
益相关者关注的问题。

7.11 架构需求规范

架构需求规范提供了一组定量说明，概述了实施项
目必须如何做才能遵从架构要求。架构需求规范通常构
成实施合同或合同的主要组成部分，有助于获得更详细
的架构定义。如本章前面部分所述，作为架构定义文档
的配套文件，架构需求规范提供了定量视图，两者的目
标具有互补性。

175
TOGAF®标准第 10 版口袋指南（中文版）

架构需求规范通常包含以下内容：
• 成功衡量标准。
• 架构需求。
• 业务服务合同。
• 应用服务合同。
• 实施指南。
• 实施规范。
• 实施标准。
• 互操作性需求。
• IT 服务管理需求。
• 限制。
• 假设。

7.11.1 业务架构需求

在阶段 B 填充架构需求规范的业务架构需求包括：
• 差距分析结果。
• 技术要求。应生成一组初始技术要求作为阶段 B
（业务架构）的输出。这些技术要求是后续架构

176
 第7章 ADM 交付物

工作的驱动力，应该确定它们对其余架构域工作
的影响，并对这些影响进行分类和优先级排序。
• 更新的业务需求。业务场景技术可用于发现和记
录业务需求。

7.11.2 信息系统架构需求

在阶段 C 填充架构需求规范的信息系统架构需求
包括：
• 差距分析结果。
• 数据互操作性需求。
• 应用互操作性需求。
• 为了适应数据和/或应用架构的变更，业务架构可
能需要做出变更的领域。
• 对即将设计的技术架构构成的限制。
• 更新的业务需求（如适用）
。
• 更新的数据需求（如适用）
。
• 更新的应用需求（如适用）
。

177
TOGAF®标准第 10 版口袋指南（中文版）

7.11.3 技术架构需求

在阶段 D 填充架构需求规范的技术架构需求包括：
• 差距分析结果。
• 更新的技术需求。

7.11.4 互操作性需求

互操作性的确定工作应贯穿整个 ADM 周期。

ADM 技术文档提供了一套定义和建立互操作性需求的
指南。

7.12 架构路线图

架构路线图列出了将实现目标架构的各个工作
包，并将它们按照时间轴排列，以显示从基线架构到
目标架构的进展情况。架构路线图强调各阶段各个工
作包的业务价值，有效实现目标架构所必需的过渡架

178
 第7章 ADM 交付物

构被确定为中间步骤。架构师应以阶段 B、C 和 D 开
发的路线图组件为依据，在阶段 E 和阶段 F 逐步制
定架构路线图。
架构路线图通常包含以下内容：
• 工作包组合：
◦ 工作包描述（名称、描述、目标、交付物）
。
◦ 功能要求。
◦ 依赖关系。
◦ 与机会的关系。
◦ 与架构定义文档及架构需求规范的关系。
◦ 业务价值。
• 实施因素目录，包括：
◦ 风险。
◦ 问题。
◦ 假设。
◦ 依赖关系。
◦ 行动。
◦ 影响。

179
TOGAF®标准第 10 版口袋指南（中文版）

• 差距、解决方案和依赖关系综合矩阵，包括：
◦ 架构域。
◦ 差距。
◦ 潜在的解决方案。
◦ 依赖关系。
• 过渡架构（如有）
。
• 实施建议：
◦ 项目有效性的准则/衡量标准。
◦ 风险和问题。
◦ SBB。

7.13 架构构建块

架构构建块（ABB）是企业架构存储库中的架构文
档和模型，根据架构连续序列进行了分类。它们是在应
用 ADM 后进行的定义或做出的选择（主要在阶段 A、
B、C 和 D）
。ABB 的特点如下：

180
 第7章 ADM 交付物

◦ 获取架构需求；例如，业务、数据、应用和技术
需求。
◦ 指导 SBB 的开发和采购。
ABB 规范至少包括以下内容：
◦ 基本功能性和属性：语义明确，包括安全能力和
可管理性。
◦ 接口：已选定、已提供的接口（应用程序接口
（API）
、数据格式、协议、硬件接口、标准）
。
◦ 与其他构建块的互操作性和关系。
◦ 具有所需功能和命名用户接口的从属构建块。
每个 ABB 都应包含企业架构存储库中可在架构开
发中重复使用的任何架构文档和模型的相关说明。使用
ADM 的构建块的规范是一个不断演进和迭代的过程。

7.14 解决方案构建块

解决方案构建块（SBB）与解决方案连续序列相关
联。它们是在企业架构连续序列中确定的架构实施选择，

181
TOGAF®标准第 10 版口袋指南（中文版）

可以通过采购或开发的形式获得。SBB 出现在 ADM 的

阶段 E，这个阶段首次考虑了针对特定产品的构建块。
SBB 定义了实施功能的产品和组件，因此也就定义了实
施。它们能够满足业务需求，并且注重产品或厂商。SBB
规范至少包括以下内容：
• 特定功能和属性。
• 接口；实施集合。
• 搭配使用所需 SBB 和所需功能及所用接口名称。
• 从 SBB 映射至 IT 拓扑和运行策略。
• 共享属性的规范，例如安全性、可管理性、本地
化能力、可扩展性。
• 性能、可配置性。
• 设计驱动因素和限制，包括物理架构。
• SBB 和 ABB 之间的关系。

7.15 实施和迁移计划

实施和迁移计划在阶段 E 和 F 开发，为目标架构

182
 第7章 ADM 交付物

的实施提供了项目进度表。实施和迁移计划包括可执行
的项目，这些项目又划分为可以管理的项目组合和项目
群。实施和迁移战略（确定了变更方法）是实施和迁移
计划的关键要素。
实施和迁移计划通常包含以下内容：
• 实施和迁移战略：
◦ 战略实施方向。
◦ 实施排序方法。
• 实施的项目和项目组合分解：
◦ 将工作包分配至项目和项目组合。
◦ 项目交付的能力。
◦ 里程碑和时间安排。
◦ 工作分解结构。
◦ 可能包括对现有项目组合、项目群和项目的
影响。
可能包括：
• 项目章程：
◦ 包含的工作包。

183
TOGAF®标准第 10 版口袋指南（中文版）

◦ 业务价值。
◦ 风险、问题、假设、依赖关系。
◦ 资源需求和成本。
◦ 确定的迁移优势（包括映射到业务需求）
。
◦ 迁移选项的估算成本。

7.16 过渡架构

如果实施目标架构的变更范围需要增量方法，就要
在阶段 E 的架构定义文档输出中定义一个或多个过渡
架构。过渡架构显示了企业在基线和目标架构之间的重
要架构状态。过渡架构描述了有效实现目标架构所需的
中间架构。这种方法可以帮助架构师沿着通往目标架构
的路线图明确中间的各个参考点。
过渡架构通常包含以下内容：
• 过渡状态的定义。
• 每个过渡状态的业务架构。
• 每个过渡状态的数据架构。

184
 第7章 ADM 交付物

• 每个过渡状态的应用架构。
• 每个过渡状态的技术架构。

7.17 实施治理模型

在定义了架构之后，必须对如何在实施过程中治理
架构进行规划。在已建立架构功能的组织内，可能已有
一个治理框架，但具体流程、组织、角色、职责及衡量
标准可能需要基于具体项目来定义。
阶段 F 输出和生成的实施治理模型可确保过渡
到实施的项目也能够平稳过渡到适当的架构治理（阶
段 G）。
实施治理模型通常包含以下内容：
• 治理流程。
• 治理组织结构。
• 治理角色与职责。
• 治理检查点和成功/失败标准。

185
TOGAF®标准第 10 版口袋指南（中文版）

7.18 架构合同

架构合同可能出现在 ADM 的各个阶段，例如“阶

段 G：实施治理”
。架构合同是开发合作伙伴和发起人之
间就架构交付物、质量和适用性而达成的联合协议。有
效的架构可确保这些协议的成功实施。通过对合同管理
采取治理方法，可确保以下方面：
• 持续监控系统，用于检查组织内所有架构相关活
动的完整性、变更、决策和审计。
• 遵循现有或开发中架构的原则、标准和需求。
• 根据公认的标准、策略、技术和产品，确定架构
开发和实施各个方面（包括内部开发工作）的风
险及架构运营方面的风险，以便组织能够在一个
弹性环境中持续开展业务。
• 一系列流程和实践，可确保在所有架构制品开发
和使用方面的追责性、责任性和纪律性。
• 正式了解负责合同的治理组织、其权限级别及本

186
 第7章 ADM 交付物

机构治理下的架构范围。
架构设计和开发合同通常包含以下内容：
• 简介与背景。
• 协议本质。
• 架构范围。
• 架构及战略原则和要求。
• 合规性要求。
• 架构开发和管理流程与角色。
• 目标架构度量。
• 交付物的已定义阶段。
• 优先处理的联合工作计划。
• 时间窗口。
• 架构交付和业务指标。
业务用户架构合同通常包含以下内容：
• 简介与背景。
• 协议本质。
• 范围。
• 战略要求。

187
TOGAF®标准第 10 版口袋指南（中文版）

• 合规性要求。
• 架构采纳。
• 时间窗口。
• 架构业务指标。
• 服务架构（包括 SLA）
。

7.19 变更要求

架构变更要求是“阶段 H：架构变更管理”的一个
考量因素。在架构实施期间，随着更多事实变为已知信
息，起初的架构定义和要求可能不适合或不足以完成解
决方案的实施。这种情况下，实施项目有必要脱离建议
的架构方法或请求范围扩展。此外，市场因素、业务战
略变更和新技术机会等外部因素可能为扩展和完善架构
提供机会。
在这种情况下，为启动架构工作的下一个周期，可
提交变更要求。
变更要求通常包含以下内容：

188
 第7章 ADM 交付物

• 提议变更的描述。
• 提议变更的理由依据。
• 提议变更的影响评估，包括：
◦ 特定需求的参考资料。
◦ 到目前为止利益相关者的需求优先级。
◦ 需回顾的阶段。
◦ 引导需求优先级排序的阶段。
◦ 阶段调查的结果和修订的优先级。
◦ 需求管理建议。
• 存储库参考数量。

7.20 合规性评估

在定义了架构之后，必须在实施过程中治理架构，以
确保适度实现原始架构愿景，并将任何实施经验教训反馈到
架构流程中。阶段 G 的定期合规性审核提供了一种审核项
目进度的机制，可以确保设计和实施符合战略与架构目标。
合规性评估通常包含以下内容：

189
TOGAF®标准第 10 版口袋指南（中文版）

• 项目进度和状态的概述。
• 项目架构/设计的概述。
• 已完成的架构检查单：
◦ 硬件和操作系统检查清单。
◦ 软件服务和中间件检查清单。
◦ 应用检查清单。
◦ 信息管理检查清单。
◦ 安全检查清单。
◦ 系统管理检查清单。
◦ 系统工程检查清单。
◦ 方法和工具检查清单。

7.21 需求影响评估

与架构有关的新信息的收集贯穿 ADM 过程。随着

此类信息的收集，可能会出现新的实际情况，使架构的
现有方面失效。需求影响评估可评估当前架构需求和规
范，从而确定应当做出的变更及其影响。

190
 第7章 ADM 交付物

它记录了对变更的评估以及对架构变更的建议。需
求影响评估通常包含以下内容：
• 特定需求的参考资料。
• 到目前为止利益相关者的需求优先级。
• 需回顾的阶段。
• 引导需求优先级排序的阶段。
• 阶段调查的结果和修订的优先级。
• 需求管理建议。
• 存储库参考编号。
这些通常作为对变更要求的响应而产生。

191
TOGAF®标准第 10 版口袋指南（中文版）

附录 A 词汇表和首字母
缩略词
ABB (Architecture Building Block)
架构构建块。架构模型的一个组成部分，描述了整
体模型的一个方面。
ADM (Architecture Development Method)
架构开发方法。这是 TOGAF 框架的核心，一种开
发和使用企业架构塑造和治理业务转型和实施项目的多
阶段迭代方法。
Agile
敏捷。快速、轻松地移动/更改，通常是为了提供能
够创造价值的成果。
Agile Architecture
敏捷架构。开发架构的“行为”——通过交付迭代
架构，以增量方式提供可创造价值的成果，从而快速、

192
 附录 A 词汇表和首字母缩略词

轻松地应对变革。架构“本身”——种灵活（即易于修
改或调整）的架构。
Agile Product Owner
敏捷产品所有者。敏捷产品团队的成员，负责定义
用户故事并确定待办事项的优先级，确保其他团队成员
理解这些内容，同时协助交付团队维护特性或组件的概
念完整性。在 TOGAF 框架中，产品具有更广泛的语境，
但是此处使用敏捷产品语境。
API (Application Programming Interface)
应用程序接口。
Application Architecture
应用架构。描述了应用的结构和交互，这些应用是
负责提供关键业务功能和管理数据资产的若干组能力。
Architecture
架构。系统在其环境中的基本概念或属性体现在其
元素、关系以及其设计和演化的原则中。
组件的结构、它们的相互关系以及管理它们的设计
和演变的原则和指导方针。

193
TOGAF®标准第 10 版口袋指南（中文版）

Architecture Contiuum
架构连续序列。企业连续序列的一部分，是一种内
容和专业性都将不断进阶的架构元素存储库。
Architecture Framework
架构框架。用于计划、开发、实施、治理和维护架
构的概念结构。
Architecture Landscape
架构景观。企业在一个特定时间点使用或计划的资
产的架构呈示。
Architecture Principle
架构原则。对架构目标的定性描述。
Architecture Project
架构项目。为定义和描述要实施的企业架构而开展
的工作。在 TOGAF 术语中，它涵括了从 ADM 阶段 A
到阶段 F 的所有活动，以及这些阶段的需求管理。实际
上，它可以是一个独立的项目，也可以是更大计划的一
部分（例如一个项目群）
。
Architecture View
架构视图。从一系列相关关注点的角度呈现系统。

194
 附录 A 词汇表和首字母缩略词

Architecture Viewpoint
架构视角。对特定类型架构视图的约定规范。
Artifact
制品。描述架构某一方面的架构工作产物。
Backlog
待办事项列表。一个不断演变的需求列表，由利益
相关者确定优先级，以便向敏捷团队传达需要首先处理的
需求。业务变革设计和开发通常采用顶级待办事项（称为
，每个实施 Sprint 的敏捷团队通常为
业务变革待办事项）
每个 Sprint 创建一个待办事项（称为 Sprint 待办事项）
。
Baseline
基线。已经正式审查和商定的规范，是此后进一步
开发或变更的基础，并且只能通过正式的变更控制程序
或配置管理等程序进行变更。
BDUF (Big Design Up Front)
大设计先行。
Business Architecture
业务架构。对全面、多维业务视图的描述，包括：

195
TOGAF®标准第 10 版口袋指南（中文版）

能力、端到端价值交付、信息和组织结构；以及这些业务
视图与战略、产物、政策、举措和利益相关者之间的关系。
Capability
能力。组织、个人或系统拥有的能力。
Capability Architecture
能力架构。对实现特定解决方案或解决方案方面的
架构方法的高度详细描述。
Capability Increment
能力增量。能够交付特定价值的能力架构的独立组
成部分。所有增量都完成后，也就实现了这种能力。
C-MDM (Customer Master Data Management)
客户主数据管理。
CMM (Capability Maturity Model)
能力成熟度模型。
CSF (Critical Success Factor)
关键成功因素。
Data Architecture
数据架构。对企业主要数据类型和来源、逻辑数据

196
 附录 A 词汇表和首字母缩略词

资产、物理数据资产和数据管理资源结构和交互的描述。
DBRM (Digital Business Reference Model)
数字化业务参考模型。
DoDAF (Department of Defense Architecture
Framework)
美国国防部架构框架。
DTRA (Digital Transformation Readiness Assessment)
数字化转型就绪度评估。
Enterprise
企业。对组织最高级别（代表性）的描述，通常包
括所有任务和职能部门。企业往往包含多个组织。
EA (Enterprise Architecture)
企业架构。通过创建、交流和改进描述企业未来状
态并推动其发展的关键原则和模型，将业务愿景和战略
转化成有效的企业变革的过程（来源：Gartner）
。
一组用于简化和传达复杂的结构、流程、规则和约
束的抽象概念和模型，目的是改善认识、实施、预测和
资源分配（来源：DoDAF）
。

197
TOGAF®标准第 10 版口袋指南（中文版）

EC (Enterprise Continuum)
企业连续序列。一种对从通用向特定适用性演进的
架构和解决方案制品进行分类的分类机制。
ERD (Entity Relationship Diagram)
实体关系图。
ERM (Enterprise Rish Management)
风险管理。企业风险管理。
Foundation Architecture
基础架构。通用构建模块、构建块之间的相互关系
以及为构建更多特定架构提供基础的原则和指南。
Framework
框架。一种可用作构思工具的内容或流程结构，能
够确保一致性和完整性。
Gap
差距。两种状态之间的差异描述。用于差距分析情
境中，其中基线与目标架构之间的区别已确定。
Governance
治理。监控、管理和指导业务（或信息系统/信息技

198
 附录 A 词汇表和首字母缩略词

术（IS/IT）环境）交付所需的业务成果。
GRM (Government Reference Model)
政府参考模型。
IS/IT (Information Systems / Information Technology)
信息系统/信息技术。
ISM(Information Security Management)
信息安全管理。
KPI (Key Performance Indicator)
关键绩效指标。
Metamodel
元模型。描述如何以结构化方式描述架构的模型。
MVA(Minimum Viable Architecture)
最小可行架构。可以实现并可增加业务价值的最小
（企业）架构。一种支持交付产品特性的架构，其内容刚
好可以部署在项目的特定阶段，并且满足事先已知的需
求（尤其是质量属性要求）
。
MVBD(Minimum Viable Business Development)
最小可行业务开发。为利益相关者带来重要价值的

199
TOGAF®标准第 10 版口袋指南（中文版）

最小业务变革集合。
MVP (Minimum Viable Product)
最小可行产品。可满足最低功能和非功能需求集合
的输出，并可在实际操作环境中实施时实现。可能的最
小成果，可带来可接受的经验，为客户提供价值（内部
或外部）
，为未来扩展奠定基础。
Practitioner
从业者。开发、维护和使用企业架构的人员。
Product
产品。由业务产生并提供给客户的成果。产品包括
材料和/或服务。
Project Management
项目管理。全方位的项目规划、委派、监控和控制，
以及参与者在时间、成本、质量、范围、收益和风险等
预期绩效目标范围内实现项目目标的动机。PRINCE2 和
PMBOK 均为市场领先的项目管理方法。
Repository
存储库。管理企业所有数据的系统，包括数据和流

200
 附录 A 词汇表和首字母缩略词

程模型以及其他企业信息。
Requirement
需求。对特定架构或工作包必须满足的需求的
说明。
Retrospective
回顾。在 Sprint 结束时举行的有时间限制的会议，
Sprint 团队在会议上检查其流程，确定取得的成功和需
要改进的地方；回顾是敏捷团队在“持续改进”的过程
中及时进行“检查和调整”的关键。
Risk Management
风险管理。对可能威胁企业架构实践成功与否的风
险和问题的管理，其具有满足愿景、目的和目标的能力；
更为重要的是其提供服务的能力。
Segment Architecture
分段架构。对企业内领域的详细、正式描述，可用
在项目群或项目组合层级上，以组织和协调变更活动。
Service
服务。重复性活动；可能会请求或触发构建块执行
的独立行为。

201
TOGAF®标准第 10 版口袋指南（中文版）

Service-Orientation
面向服务。根据提供和使用的服务查看企业、系统
或构建块。
SOA (Sevice-Oriented Architecture)
面向服务的架构。支持服务导向的架构风格。
SLA (Service-Level Agreement)
服务级别协议。
Solution Architecture
解决方案架构。对独立和集中的业务运营或活动以
及 IS/IT 如何支持此类运营的描述。
SBB
解决方案构建块。符合架构构建块（ABB）规范的
备选解决方案。
Solutions Continuum
解决方案连续序列。企业连续序列的一部分，是一种
内容和专业性都将不断进阶的解决方案实施元素存储库。
Sprint
冲刺。一个有时间限制的短周期，是敏捷方法的核

202
 附录 A 词汇表和首字母缩略词

心。敏捷团队将在此期间努力完成一定数量的工作，以
支持有效的解决方案的交付。
Stakeholder
利益相关者。对系统有兴趣的个人、团队、组织或
组织阶层。
TAFIM（Technical Architecture Framework for
Information Management）
信息管理技术架构框架。
Target Architecture
目标架构。对组织开发架构未来状态的描述。
TRM Technical Reference Model
技术参考模型。一种允许以一致的方式描述信息系
统组件的结构。
Technology Architecture
技术架构。对技术服务的结构和交互以及逻辑和物
理技术组件的描述。
Transition Architecture
过渡架构。对处于重要架构意义时间点的架构状态

203
TOGAF®标准第 10 版口袋指南（中文版）

的正式描述。
Value Stream
价值流。对增值活动端到端集合的展现，这些活动
可为客户、利益相关者或最终用户创造整体效益。
View
视图。请参阅“架构视图”
。
Viewpoint
视角。请参阅“架构视角”
。
Work Package
工作包。为实现一个或多个业务目标而确定的一系
列行动。工作包可以是项目的一部分，也可以是完整的
项目或项目群。

204