写在前边
一开始，我准备结合 TOGAF 核心 ADM 的九个阶段（预备阶段、架构愿景阶段、业务架构阶段、信息系统架构阶段、技术架构阶段、机会与解决方案阶段、迁移计划阶段、实现治理阶段、架构变更管理阶段） 5 个方面（目标、输入、工作步骤、输出、工作方法）的规范内容，展示每阶段“输出”在 EA 中的建模效果，以这样的思路来写这篇文章。但是当把 ADM 各阶段内容翻译完后，我发现如果按原来的写作思路，文章将会用大篇幅介绍 ADM 方法论，而其在 EA 中的应用只有较少涉及，偏离了写作初衷。所以关于 TOGAF 的 ADM 规范内容，可参见文末译文。本文将以某保险公司案例为例，介绍在 EA 中 ADM 建模应用的部分成果。
1.TOGAF & ADM
首先，回顾一下 TOGAF 和 ADM 。
TOGAF 支持企业架构包含的内容：
• 目标与愿景：企业的价值定位，实现及价值的指导方针和发展战略。
• 业务架构：定义了商业策略、管理、组织和关键业务流程。
• 应用架构：为部署各个系统提供蓝图，包括应用程序系统之间的交互以及与基本业务流程的关系。
• 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构。
• 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。这种软件有时也叫做中间件
TOGAF 的内容有 7 个部分：
• 介绍
• ADM （架构开发方法）
• ADM 指南和技术
• 架构内容框架
• 企业连续体和工具
• TOGAF 参考模型
• 架构能力框架
关于 TOGAF 与企业架构更多的内容，可阅读文章《 企业架构、 TOGAF 与 ArchiMate 》。
1.1 ADM （架构开发方法）
ADM 是一种描述开发和管理企业架构生命周期的方法，是 TOGAF 标准的核心。它集成 TOGAF 标准的元素以及其他可用的架构资产，来满足组织的业务和 IT 需求。
ADM 的基本架构如下图所示： 1 个核心和 9 个阶段
1 个核心是：需求管理作为一个贯穿整个企业架构过程的阶段， 9 个阶段是：
1.预备阶段
2.架构前景阶段
3.业务架构阶段
4.信息系统架构阶段
5.技术架构阶段
6.机会与解决方案阶段
7.迁移计划阶段
8.实现治理阶段
9.架构变更管理阶
在整个过程中、各阶段之间和每个阶段内， ADM 是迭代的。
2.用 EA 进行 ADM 建模
以某保险公司“在线服务系统”项目应用 ADM 建模为示例。
2.1 预备阶段（ Preliminary Phase ）
预备阶段描述为了满足企业架构的业务要求，所需要的准备和启动活动，包括组织特定的架构框架定义和原则的定义。这个阶段的成果主要是文档，如：架构组织模型、架构框架、架构原则、架构工作描述等等。
2.2 架构愿景阶段（ Phase A ）
架构愿景阶段是 ADM 的开始阶段，包括关于定义范围、确定干系人、创建架构愿景以及获得批准的信息。
下边展示的是保险公司“在线服务系统”“管理层”和“同行”对架构的愿景：
1. 通过应用在线服务系统，提高企业获得的利润，保持企业在市场中的持续竞争力；
2. 尽量复用已有的 IT 资产、 IT 系统及当前的资源，建立一个既可以对接当前企业服务系统，又满足业务要求的新的“在线服务系统”。
建模视图如下：
建模中使用的元素有：
• 利益相关者
• 驱动器：一个外部或者内部的条件，相当于触发器。
• 目标
• 准则
• 价值
• 方式
• 需求
• 约束
• 行动方针
元素之间的关系有：
• 分配
• 关联
• 实现
2.3 业务架构阶段（ Phase B ）
业务架构阶段描述业务架构的开发，用来支持已达成一致的架构愿景。
在这个阶段，依次对业务架构中的业务角色、业务流程和业务对象进行建模。
2.3.1 对业务角色建模
保险公司业务角色有：业务部、寿险行政部、财务部、法务部，其中寿险行政部有主管、理赔专员角色，理赔专员又分为受理员、审核员、复核员。
建模视图如下：
建模中使用的元素有：
• 业务主角
• 业务角色
• 业务接口
• 业务协作
元素之间的关系有：
• 组成
• 聚合
• 分配
2.3.2 对业务流程建模
保险理赔有线下理赔和网上理赔，流程是：
首先由被保人提交理赔申请，然后理赔系统依次进行受理、审核、支付，最后被保人收到理赔款。
建模视图如下：
建模中使用的元素有：
• 业务事件
• 业务过程
• 业务功能
• 业务交互
• 业务角色
• 业务服务。
元素之间的关系有：
• 聚合
• 分配
• 触发
• 专门化
• 实现
2.3.3 对业务对象建模
以理赔流程中的“被保人”这个业务对象为例，被保人承载的信息有理赔申请单、保单、保险合同等。
建模视图如下：
建模中使用的元素有：
• 业务目标
• 表象
• 契约
元素之间的关系有：
• 关联
• 专门化
• 组成
• 实现
2.4 信息系统架构阶段（ Phase C ）
信息系统架构阶段描述一个架构项目的信息系统架构，包括数据架构和应用架构的开发。
下边是对应用架构的建模。
2.4.1 应用组件建模
理赔系统中的 “ 理赔受理、理赔审核、理赔支付 ” 三个环节互相协作实现 “ 团险理赔 ” ，这三个环节可以访问数据库， “ 理赔支配 ” 实现与支付接口的连接。
建模视图如下：
建模中使用的元素有：
• 组件
• 接口
• 应用协作
组件之间的关系有：
• 聚合
• 访问
• 实现
2.4.2 应用流程建模
如下是理赔应用流程：理赔过程由理赔请求触发，触发后，各个理赔过程之间进行交互，为理赔提供服务。
建模视图如下：
建模中使用的元素有：
• 应用事件
• 应用过程
• 应用服务
• 应用协作
组件之间的关系有：
• 触发
• 服务
• 实现
• 聚合
2.4.3 应用对象建模
在理赔流程中处理的对象是一些结构化的数据，有理赔申请单、保险合同、发票、保单、保户、申请资料等。
建模视图如下：
建模中使用的元素有：数据对象
组件之间的关系有：
• 组成
• 关联
• 专门化
2.5 技术架构阶段（ Phase D ）
这一阶段描述为支持业务、数据和应用服务必须的软件和硬件能力。
2.5.1 部署模型建模
保险公司在线服务系统要求具备应用服务器、数据库服务器、客户端、中间件、虚拟机等软硬件。
建模视图如下：
建模使用的元素有：
• 设备
• 技术协作
• 技术接口
• 系统软件
• 节点、
• 通信网络
• 路径
组件之间的关系有：
• 组成
• 关联
• 分配
2.5.2 过程视图建模
在线系统实现消息传递的过程是：消息处理功能模块跟“订阅通知”模块进行交互，为消息服务模块提供消息，由消息更新事件触发消息订阅者。
建模视图如下：
建模使用的元素有：
• 设备
• 技术协作
• 技术接口
• 系统软件
• 节点
• 通信网络
• 路径
组件之间的关系有：
• 组成
• 关联
• 分配
2.5.3 工件视图建模
保险在线服务系统的技术架构阶段过程中的数据有：客户数据库、购买档案、报价档案、业务逻辑文档、数据库访问档案等等。
建模视图如下：
建模使用的元素有：工件。
组件之间的关系有：
• 组成
• 专门化
• 关联
2.6 机会与解决方案阶段（ Phase E ）
机会与解决方案阶段描述了识别交付工具的过程，这些工具能有效地交付在前几个阶段确定的目标架构。
2.7迁移计划阶段（ Phase F ）
迁移计划阶段描述如何通过最终确定详细的实现和迁移计划，从基线转移到目标架构。
保险在线服务系统在这阶段要实现的是：根据存在的架构问题，对架构进行重构，并转移到目标架构。
建模视图如下：
建模使用的元素有：
• 实现事件
• 工作包
• 交付物
• 稳定期
• 间隙
组件之间的关系有：
• 访问
• 触发
• 实现
• 专门化
• 关联
附文：《 ADM 规范》译稿
1 预备阶段（ Preliminary Phase ）
目标
1）确定组织所需的架构能力
2）建立架构能力
• 定义并建立企业架构的组织模型
• 定义并建立架构治理的详细过程和资源
• 选择并实现支持架构能力的工具
• 定义架构原则
输入
1) 企业外部参考资料： TOGAF Library ，其他体系结构框架（如需要）
2) 非架构输入
• 董事会战略和董事会业务计划、业务战略、 IT 战略、业务原则、业务目标和业务驱动因素
• 在业务中操作中的主要框架时，例如，项目 / 项目组合管理
• 治理和法律框架 ，包括已存在的架构治理策略
• 架构能力
• 合作关系和合同协议
3) 架构输入
• 企业架构的组织模型
• 已存在的架构框架，包括：架构方法、架构内容、配置和部署的工具、架构原则、架构存储库。
步骤
1) 受影响的企业组织范围
2) 确认治理和支持框架
3) 定义和建立企业架构团队和组织
4) 确定并建立体系结构原则
5) 定制 TOGAF 框架，以及其他选择的体系结构框架（如果有的话）
6) 为工具和技术制定策略和实施计划
输出
1) 企业架构组织模型
2) 定制的架构框架，包括：定制的架构方法、架构内容（可交付物和组件）、配置和部署的工具
3) 用框架内容填充的初始架构存储库
4) 对业务原则、业务目标和业务驱动因素的重述或引用
5) 架构工作请求
6) 架构治理框架
方法
初步阶段是关于定义 “在哪里、做什么、为什么、谁以及如何做架构”的阶段。主要有以下几个方面 :
1) 定义企业
2) 识别组织环境中的关键驱动因素和要素
3) 定义架构工作的需求
4) 定义架构工作的架构原则
5) 定义要使用的框架
6) 定义管理框架之间的关系
7) 评估企业架构成熟度
2 架构愿景阶段（ Phase A ）
目标
1） 开发一个高级的具有交付价值的功能和业务的理想愿景，并且这个愿景可作为企业架构的结果。
2） 获得架构工作陈述的批准，该陈述定义了一个工作计划，去开发和部署在愿景架构中所概述的架构。
输入
1） 企业外部参考资料
2）非架构输入
• 架构工作请求
• 业务原则、业务目标和业务驱动因素
3）架构输入
• 企业架构组织模型
• 定制的架构框架
• 已添加数据的架构资产
步骤
1） 建立体系结构项目
2） 确定涉众、关注点和业务需求
3） 确认和阐述业务目标、业务驱动因素和约束条件
4） 评估能力
5） 评估业务转型准备情况
6） 定义作用域
7） 确认和阐述架构原则，包括业务原则
8） 发展架构远景
9） 定义目标架构价值主张和 kpi
10） 确定业务转型风险和缓解活动
11） 制定体系结构工作报告 ; 获得批准
输出
1) 批准的架构工作报告
2) 业务原则、业务目标和业务驱动的详细陈述 // 动机模型
3) 架构原则
4) 能力评估
5) 定制的架构框架
6) 架构愿景
7) 架构定义文件草案
8) 沟通计划
9) 添加到架构资产的补充内容
方法
创建架构愿景
• 架构愿景为发起人提供了一个关键工具，用来向企业内的涉众和决策者推销所提议功能的好处。
• 架构愿景描述了新功能将如何满足业务目标和战略目标，并在实现时处理涉众关注的问题。
• 架构愿景中不可或缺的是对新兴技术及其对行业和企业的潜在影响的理解，如果没有这些理解，许多商业机会可能会被错过。
• 架构愿景的关键元素——例如企业任务、愿景、策略和目标——已经作为更广泛的业务策略或企业计划活动的一部分被记录下来，这些活动在企业中具有自己的生命周期。
3 业务架构阶段（ Phase B ）
目标
1) 开发目标业务架构，该架构描述企业以一种架构工作陈述和涉众关注的方式，需要如何操作以实现业务目标，以及需要如何对架构愿景中列出的战略驱动因素做出响应。
2) 根据基线和目标业务 架构 之间的差距 ， 确定候选 架构 路线图组件
输入
1) 企业外部参考资料
2) 非架构输入
• 架构工作请求
• 业务原则、业务目标和业务驱动因素
• 能力评估
• 沟通计划
3) 架构输入
• 企业架构组织模型
• 定制的架构框架
• 已批准的架构工作描述
• 架构原则
• 企业连续体
• 架构存储库
• 架构愿景
• 架构定义文档草案
步骤
1) 选择参考模型、视点和工具
2) 制定基线业务架构描述
3) 制定目标业务架构描述
4) 执行差距分析
5) 定义候选路线图组件
6) 解决贯穿架构全景的影响
7) 进行正式的涉众评审
8) 最终确定业务架构
9) 创建架构定义文档
输出
1) 细化和更新架构愿景阶段交付成果的版本
2) 架构定义文件草案
3) 架构需求规范草案
4) 架构路线图的业务架构组件
方法
1) 制定基线描述
2) 应用业务能力
3) 应用价值流
4) 应用组织地图
5) 应用建模技术
6) 架构存储库
4 信息系统架构阶段（ Phase C ）
信息系统架构阶段描述一个架构项目的信息系统架构，包括数据架构和 应用架构 的开发。
目标
1) 以解决架构工作陈述和涉众关注的方式，开发目标信息系统架构，描述企业信息系统架构如何实现业务架构和架构愿景
2) 根据基线和目标信息系统 ( 数据和应用 ) 架构之间的差距确定候选架构路线图组件
方法
阶段 C 涉及到数据架构和应用架构的某种组合，无论顺序如何，两种顺序都有支持者。
针对每个架构领域，分别给出了阶段 C 的详细描述 :
• 信息系统体系结构 - 数据架构
• 信息系统体系结构 - 应用架构
5 技术架构阶段（ Phase D ）
目标
1) 开发目标技术架构，以解决架构工作声明和涉众关注因素的方式，使架构愿景、目标业务、数据和应用程序构建块能够通过技术组件和技术服务进行交付。
2) 根据基线和目标技术 / 架构之间的差距，确定候选架构路线图组件。
输入
1) 企业外部参考资料
• 架构参考材料
• 关于候选产品的产品信息。
2) 非架构输入
• 架构工作请求
• 能力评估
• 沟通计划
3) 架构输入
• 企业架构组织模型
• 定制的架构框架
• 技术原则
• 架构工作报告
• 架构愿景
• 架构存储库
• 架构定义文件草案
• 业务、数据和架构路线图的应用架构组件
步骤
1) 选择参考模型、视点和工具
2) 开发基线技术架构描述
3) 开发目标技术架构描述
4) 执行差距分析
5) 定义候选路线图组件
6) 解决贯穿架构全景的影响
7) 进行正式的涉众评审
8) 确定技术架构
9) 创建架构定义文档
输出
1) 细化和更新架构愿景阶段交付成果的版本
2) 架构定义文件草案
3) 架构需求规范草案 4) 架构路线图的技术架构组件
方法
1) 新兴技术
2) 架构存储库
6 机会与解决方案阶段（ Phase E ）
机会与解决方案阶段描述了识别交付工具的过程，这些工具能有效地交付在前几个阶段确定的目标架构。
目标
1) 基于差距分析和来自阶段 B 、 C 和 D 的候选架构路线图组件，生成架构路线图的初始完整版本。
2) 确定是否需要增量方法，如果需要，则确定能交付持续业务价值的过渡架构。
3) 定义整体的解决方案构建块，以基于架构构建块 (ABBS) 完成目标架构
输入
1) 企业外部参考资料，
• 架构参考材料
• 产品信息
2) 非架构输入
• 架构工作请求
• 能力评估
• 沟通计划
• 计划方法
3) 架构输入
• 企业架构组织模型
• 治理模型框架
• 定制的架构框架
• 技术原则
• 架构工作报告
• 架构愿景
• 架构存储库
• 架构定义文件草案
• 架构需求说明草案
• 现有业务计划和项目的变更请求
• 来自阶段 B 、 C 和 D 的候选架构路线图组件
步骤
1) 确定 / 确认关键企业变更属性
2) 确定实现的业务约束
3) 审查和巩固从 B 到 D 阶段的差距分析结果
4) 审查跨相关业务功能的统一需求
5) 巩固和协调互操作性需求
6) 细化和验证依赖项
7) 确认业务转换的准备情况和风险
8) 制定实施和迁移策略
9) 识别和分组主要工作包
10) 识别过渡架构
11) 创建架构路线图、实现和迁移计划
输出
1) 在适用的地方对架构愿景阶段交付成果进行的改进和更新
2) 架构需求规范草案
3) 架构定义文件草案
4) 能力评估
5) 架构路线图
6) 执行和迁移计划
7) 表：项目背景图、利益表
方法
1) 架构路线图
2) 工作包
3) 过渡架构
4) 实施和迁移计划
7 迁移计划阶段（ Phase F ）
迁移计划阶段描述如何通过最终确定详细的实现和迁移计划，从基线转移到目标架构。
目标
1) 最终确定的架构路线图和支持的实现及迁移计划
2) 确保实施和迁移计划与企业管理和实现企业整体变更组合中的变更方法相协调
3) 确保关键涉众理解工作包和产品化架构的业务价值和成本
输入
1) 企业外部参考资料，
• 架构参考材料
2) 非架构输入
• 架构工作请求
• 能力评估
• 沟通计划
3) 架构输入
• 企业架构组织模型
• 治理模型框架
• 定制的架构框架
• 架构工作报告
• 架构愿景
• 架构存储库
• 架构定义文件草案
• 架构需求说明草案
• 现有业务计划和项目的变更请求
• 架构路线图 V1.0
• 能力评估报告
• 执行和迁移计划 V1.0
步骤
1) 确认实施和迁移计划的管理框架交互
2) 为每个工作包赋予业务价值
3) 估算资源需求、项目时间和可用性 / 交付工具
4) 通过进行成本 / 效益评估和风险验证确定迁移项目的优先级
5) 确认架构路线图并更新架构定义文档
6) 完成实施和迁移计划
7) 完成架构开发周期并记录经验教训
输出
1) 执行和迁移计划 V1.0
2) 最终确定的架构定义文档
3) 最终确定的架构需求规范
4) 最终确定的架构路线图
5) 可重用的架构构建块
6) 对于 ADM 周期的新迭代的架构工作请求
7) 实现治理模型 ( 如果有的话 )
8) 从经验教训中产生的架构能力的变更请求
方法
阶段 F 的重点是与项目和项目组合经理合作创建一个实施和迁移计划。
阶段 E 提供了一个不完整的架构路线图、实现和迁移计划，该计划处理架构工作的陈述。在阶段 F 中，此路线图、实现和迁移计划与企业的其他变更活动集成在一起。
活动包括在企业其他活动的上下文中评估各种迁移项目的依赖性、成本和收益。架构路线图版本 0.1 和来自阶段 E 的版本 0.1 将形成最终的实现和迁移计划的基础，该计划将包括项目组合和项目级别的细节。然后应该完成架构开发周期，并记录得到的经验教训，以实现持续的过程改进。
8 实现治理阶段（ Phase G ）
本阶段提供实现的架构监督。
目标
1) 通过实施项目，确保与目标架构的一致性。
2) 为解决方案和任何实现驱动的架构变更请求执行适当的架构治理功能。
输入
1) 企业外部参考资料，
• 架构参考材料
2) 非架构输入
• 架构工作请求
• 能力评估
3) 架构输入
• 企业架构组织模型
• 定制的架构框架
• 架构工作报告
• 架构愿景
• 架构存储库
• 架构定义文档
• 架构需求说明
• 现有业务计划和项目的变更请求
• 架构路线图
• 执行治理模型
• 架构合同
• 架构工作请求
• 执行和迁移计划
步骤
1) 使用开发管理确认部署范围和优先级
2) 确定部署资源和技能
3) 指导方案部署的开发工作
4) 执行企业架构遵从性审查
5) 实现业务和 IT 操作
6) 实施后审查，关闭实施
输出
1) 架构合同 ( 已签署 ) ，作为按照符合架构的实现架构的建议
2) 合规性评估
3) 变更请求
4) 合规性架构解决方案
方法
1) 建立一个实现计划，该计划将支持在迁移计划阶段为实现产品化架构的交付。
2) 采用反映架构路线图中包含的业务优先级的分阶段部署计划。
3) 遵循公司、 IT 和架构治理的组织标准。
4) 使用组织已经建立的项目组合 / 计划管理方法。
5) 定义操作框架，以确保已部署解决方案的有效长生命周期。
阶段 G 通过架构合同，建立架构和实现组织之间的联系。
9 架构变更管理阶段（ Phase H ）
本阶段着眼于建立管理新架构变更的过程。
目标
1) 确保架构生命周期得到维护
2) 确保架构治理框架得到执行
3) 确保企业架构能力满足当前的需求
输入
1) 企业外部参考资料，
• 架构参考材料
2) 非架构输入
• 架构工作请求
• 架构输入
• 企业架构组织模型
• 定制的架构框架
• 架构工作报告
• 架构愿景
• 架构存储库
• 架构定义文档
• 架构需求说明
• 架构路线图
• 技术变更请求
• 业务变更请求
• 变更请求经验总结
• 执行治理模型
• 架构合同
• 合规性评估
• 实现及迁移计划
步骤
1) 建立价值实现流程
2) 部署监控工具
3) 管理风险
4) 为架构变更管理提供分析
5) 制定变更需求以满足性能目标
6) 管理治理过程
7) 激活流程以实现变更
输出
1) 架构更新 ( 用于维护更改 )
2) 架构框架和原则的变更 ( 用于维护更改 )
3) 架构工作的新请求，以转移到另一个周期 ( 对于主要的变更 )
4) 架构工作说明（如有必要则更新）
5) 架构合同（如有必要则更新）
6) 合规性评估（如有必要则更新）
方法
架构变更管理过程的目标是确保架构实现其原始的目标业务价值。这包括以内聚和架构化的方式管理更改。
这个过程通常将提供对诸如治理请求、技术的新发展和业务环境的变化等事项的持续监视。当确定变更时，变更管理将决定是否正式启动一个新的架构演进周期。
1) 变更驱动因素
• 改变必须集成的现有基础设施的三种方法：
• 战略性的、自上而下的、有指导的变更，以增强或创建新的能力 ( 资本 )
• 自底向上的变更，以纠正或增强操作管理下基础设施的能力 ( 操作和维护 )
• 先前交付的项目增量在运营管理方面的经验，但仍由正在进行的项目交付
• 技术相关的驱动因素：
• 新技术报告
• 降低资产管理成本
• 技术撤退
• 标准计划
• 业务驱动因素
• 正常的业务发展
• 业务异常
• 业务创新
• 业务技术创新
• 战略变化
2) 企业架构变更管理过程
这个方法基于将所需的架构变更分为以下三类 :
• 简化变更 : 简化变更通常可以通过变更管理技术进行处理。
• 增量变更 : 增量变更可以通过变更管理技术来处理，或者它可能需要部分的重构架构，这取决于变更的性质。
• 重构变更 : 重构变更需要再次将整个架构置于架构开发周期中。
3) 维护 vs 架构重新设计的指南
一个良好的指南是 :
• 如果变更影响两个或更多涉众，那么很可能需要重新设计架构并重新进入 ADM ；
• 如果变更只影响一个涉众，那么它更有可能成为变更管理的候选项；
• 如果变更可以在分配下被允许，那么它更有可能成为变更管理的候选项。
后记
希望您读了此文后有所受益。
如果您有经验乐于分享，欢迎投稿给我们。
如果您对我们的培训、咨询和工具感兴趣：
课程：
工具：
咨询方案：
如果您希望了解更多信息：
| 
