WHY

• 什么是 ADM 架构开发方法

• 如何掌握 ADM 架构开发方法

WHAT

定义

TOGAF ADM 是大量架构从业者不断贡献的结果。它描述了一种开发和管理企业架构生命周期的方法，并构成了 TOGAF 标准的核心。

它集成了本文档中描述的 TOGAF 标准的元素以及其他可用的架构资产，以满足组织的业务和 IT 需求。

架构开发是一个持续的、循环的过程，随着时间的推移重复执行 ADM，架构师逐渐将越来越多的内容添加到组织的架构存储库中。虽然 ADM 的主要关注点是开发企业特定的架构，但在更广泛的背景下，ADM 也可以被视为使用从“左侧”获取的相关可重用构建块填充企业自己的架构存储库的过程”，企业连续体更通用的一面。

应用 ADM 之前的任务之一是审查其组件的适用性，然后根据个别企业的情况对其进行调整。这种活动很可能会产生一个“企业特定的”ADM。

理想情况下，为架构活动选择的范围应该允许企业内所有架构师的工作得到有效管理和集成。这需要一组对齐的“架构分区”，以确保架构师不会从事重复或冲突的活动。对于大型复杂企业，联合架构——独立开发、维护和管理的架构，随后集成在一个集成框架中——是典型的。这样的框架指定了互操作性、迁移和一致性的原则。这允许特定的业务部门将架构作为独立的架构项目进行开发和管理

一张图了解 ADM 架构开发方法

ADM 各阶段概览

ADM 初步阶段

这个初步阶段是关于在相关企业中定义“我们在哪里、什么、为什么、谁和如何做架构”。

目标

1. 确定组织所需的架构能力：

2. 审查执行企业架构的组织环境

3. 识别受架构能力影响的企业组织的元素并确定其范围

4. 识别与架构能力相交的已建立的框架、方法和流程

5. 建立能力成熟度目标

6. 建立架构能力：

7. 定义和建立企业架构的组织模型

8. 定义和建立架构治理的详细流程和资源

9. 选择并实施支持架构能力的工具

10. 定义架构原则

输入

• 参考资料

• TOGAF 图书馆

• 其他架构框架（如果需要）

• 非架构输入

• 预先存在的董事会战略和董事会业务计划、业务战略、IT 战略、业务原则、业务目标和业务驱动因素

• 业务中运行的主要框架；例如，项目/投资组合管理

• 预先存在的治理和法律框架，包括架构治理策略

• 架构能力

• 伙伴关系和合同协议

• 架构输入 (用于运营企业架构能力的预先存在的模型可以用作初步阶段的基线)

• 企业架构的组织模型(受影响组织范围，成熟度评估，架构团队职责，预算要求，治理和支持战略)

• 现有架构框架（架构方法，架构内容，配置和部署工具，架构原则，架构库)

操作过程

• 影响企业组织的范围

• 确认治理和支持框架

• 定义和建立企业架构团队和组织

• 识别和建立架构原则

• 定制 TOGAF 框架和其他选定的架构框架（如果有）

• 制定工具和技术的战略和实施计划

如何定制 TOGAF 架构框架

• 术语定制

• 流程定制，目标是连接到项目组合管理流程，项目生命周期，运营移交流程，运营管理流程，采购流程

• 内容剪裁

战略包含内容

该战略应包括管理技术、决策管理、研讨会技术、业务建模、详细的基础架构建模、办公产品、语言和存储库管理以及更正式的架构工具。例如，平衡计分卡技术是商学院和许多组织使用的最佳实践绩效衡量工具，可成功用于建筑项目。

输出

• 企业架构的组织模型：

• 受影响的组织范围

• 成熟度评估、差距和解决方法

• 架构团队的角色和职责

• 对架构工作的限制

• 预算要求

• 治理和支持战略

• 定制架构框架，包括：

• 量身定制的架构方法

• 量身定制的架构内容（可交付成果和工件）

• 架构原则

• 配置和部署的工具

• 初始架构存储库，填充了框架内容

• 重述或引用业务原则、业务目标和业务驱动因素

• 架构治理框架

输出可能包括以下部分或全部：

• 目录：

• 原理目录

方法和技巧

建议与 TOGAF 框架协调的主要框架有如下， 这些框架不是离散的，它们与业务能力管理之间有很大的重叠。后者包括交付绩效衡量的业务价值。

• 业务能力管理 ，确定交付业务价值所需的业务能力，包括投资回报的定义和必要的控制/绩效措施

• 确定公司如何管理其变革计划的项目/投资组合管理方法

• 描述公司如何运行其日常运营（包括 IT）的运营管理方法

• 解决方案开发方法 ，根据 IT 架构中开发的结构将业务系统交付方式正式化

架构愿景

目标

• 对提议的企业架构所交付的能力和业务价值制定高层次的理想愿景

• 获得架构工作声明的批准，该声明定义了开发和部署架构愿景中概述的架构的工作计划

输入

• 企业外部参考资料

• 非架构输入

• 架构工作请求

• 业务原则、业务目标、业务驱动因数

• 架构输入

• 企业架构组织模型（组织范围、成熟度评估、团队角色和职责、工作限制、重用要求、预算要求、变更请求、治理和支持框架）

• 定制架构框架（架构方法、架构内容-可交付成果和工件、架构原则、配置和部署工具)

操作过程

• 建立架构项目

• ADM 的每个周期通常应该使用企业的项目管理框架作为一个项目来处理

• 识别利益相关者、关注点和业务需求

• 此步骤产生的主要产品是参与的利益相关者地图，显示参与的利益相关者、他们的参与程度和他们的主要关注点

• 确认和阐述业务目标、业务驱动因素和约束

• 包括企业范围的约束和项目特定的约束（时间、进度、资源等）

• 评估能力

• 评估业务转型准备情况

• 业务转型准备情况评估可用于评估和量化组织对变革的准备情况

• 定义范围

• 架构的分区特性、特定架构领域、时间段、企业连续统一体中的架构资产（企业 ADM 创建的资产、其他框架、系统模型、垂直行业模型）

• 确认和阐述架构原则，包括业务原则

• 制定架构愿景

• 此步骤从业务、信息系统和技术的角度生成基线和目标环境的第一个非常高级的定义，这些架构的初始版本应该存储在架构存储库

• 定义目标架构价值主张和 KPI

• 识别业务转型风险和缓解活动

• 制定架构工作说明书；安全批准

输出

可以使用多个业务场景来生成单个架构愿景。输出可能包括以下部分或全部：

• 矩阵：

• 利益相关者地图矩阵

• 图表：

• 商业模式图

• 业务能力图

• 价值流图

• 价值链图

• 解决方案概念图

方法和技巧

本练习应检查和搜索有关基本业务架构概念的现有材料，例如：业务能力、价值流、组织图

业务架构

业务架构是整体、多维业务视图的表示：能力、端到端价值交付、信息和组织结构；以及这些业务观点和战略、产品、政策、倡议和利益相关者之间的关系。

业务架构将业务元素与其他领域的业务目标和元素联系起来

目标

• 开发目标业务架构，描述企业需要如何运营以实现业务目标，

• 以解决架构工作声明和利益相关者关注的方式响应架构愿景中设定的战略驱动因素

• 根据基线和目标业务架构之间的差距确定候选架构路线图组件

输入

• 前步骤资料

• 架构输入

• 参考 ADM 初步阶段

• 架构定义文档草案

• 基线业务架构，版本 0.1

• 基线技术架构，版本 0.1

• 基线数据架构，版本 0.1

• 基线应用程序架构，版本 0.1

• 目标业务架构，版本 0.1

• 目标技术架构，版本 0.1

• 目标数据架构，版本 0.1

• 目标应用程序架构，版本 0.1

操作过程

• 选择参考模型、观点和工具

• 根据业务驱动因素、利益相关者和关注点，从架构存储库中选择相关的业务架构资源

• 选择相关的业务架构观点（例如，运营、管理、财务）；即，那些将使架构师能够演示如何在业务架构中解决利益相关者关注的问题

• 输出比如业务能力映射、组织因素映射、价值流图、结构化分析、用例分析、流程建模

• 开发基线业务架构描述

• 开发目标业务架构描述

• 执行差距分析

• 定义候选路线图组件

• 解决整个建筑景观的影响

• 进行正式的利益相关者审查

• 完成业务架构

• 创建架构定义文档

输出

• 架构愿景阶段可交付成果的改进和更新版本（如适用），包括：

• 架构工作声明

• 经验证的业务原则、业务目标和业务驱动因素

• 架构原则

• 架构定义文档草案，包括：

• 基线业务架构，版本 1.0（详细），如果适用

• 目标业务架构，版本 1.0（详细），包括：

• 组织结构 - 识别业务地点并将其与组织单位相关联

• 业务目标和目的 - 为企业和每个组织单位

• 业务功能 - 一个详细的递归步骤，涉及将主要功能区域连续分解为子功能

• 业务服务——企业和每个企业单位向其客户提供的服务，包括内部和外部

• 业务流程，包括措施和可交付成果

• 业务角色，包括技能要求的开发和修改

• 业务数据模型

• 组织与职能的相关性——以矩阵报告的形式将业务职能与组织单位联系起来

• 与解决关键利益相关者关注的选定观点相对应的观点

• 架构需求规范草案，包括以下业务架构需求：

• 差距分析结果

• 技术要求——识别、分类和优先考虑对其余架构领域工作的影响；例如，通过依赖/优先级矩阵（例如，指导交易处理速度和安全性之间的权衡）；列出预期生成的特定模型（例如，表示为 Zachman 框架的原语）

• 更新业务需求

• 识别所需矩阵

• 价值流/能力矩阵（显示支持价值流每个阶段所需的能力）

• 战略/能力矩阵（显示支持特定战略声明所需的能力）

• 能力/组织矩阵（显示实现每个能力的组织元素）

• 业务交互矩阵（显示组织和参与者之间的依赖和通信）

• 演员/角色矩阵（显示每个演员承担的角色）

• 识别所需图标商业模式图

• 业务能力图

• 价值流图

• 组织图

• 业务足迹图

• 业务服务/信息图

• 功能分解图

• 目标/目的/服务图

• 业务用例图

• 组织分解图

• 工艺流程图

• 事件图

方法和技巧

• 与组织的行业部门相关的行业参考模型就企业连续体而言，这些是“行业架构”。它们保存在架构存储库的参考库中。例如：

• 对象管理组 (OMG) - www.omg.org - 拥有许多垂直领域任务组，开发与特定垂直领域相关的行业参考模型，例如医疗保健、交通运输、金融等。

• TM 论坛 - www.tmforum.org - 开发了与电信行业相关的详细参考模型

• 不同国家的政府部门和机构都有强制使用的参考模型和框架，旨在促进跨部门的整合和互操作性一个例子是联邦企业架构业务参考模型，它是一个功能驱动的框架，用于描述联邦政府的业务运营，独立于执行它们的机构。

• IT4IT 参考架构提供了可在架构的 IT 部分中使用的高级 IT 价值链 IT4IT 1 级参考架构可用于指导为 IT 部门创建业务能力图。

• 企业特定的业务架构视图（能力图、价值流图、组织图等）

• 企业特定的构建块（流程组件、业务规则、工作描述等）

信息架构

信息架构分为数据架构和应用架构两部分

数据架构

目标：

• 开发目标信息系统架构，描述企业的信息系统架构将如何以解决架构工作声明和利益相关者关注的方式实现业务架构和架构愿景

• 根据基线和目标信息系统（数据和应用程序）架构之间的差距确定候选架构路线图组件

输入

• 基于业务架构输入

• 数据原则

• 架构定义文档草案，包括：

• 基线业务架构，版本 1.0（详细），如果适用

• 目标业务架构，版本 1.0（详细）

• 基线数据架构，版本 0.1，如果可用

• 目标数据架构，版本 0.1，如果可用

• 基线应用程序架构，版本 1.0（详细）或版本 0.1（愿景）

• 目标应用架构，1.0 版（详细）或 0.1 版（愿景）

• 基线技术架构，版本 0.1（愿景）

• 目标技术架构，版本 0.1（愿景）

操作过程

• 选择参考模型、观点和工具

• 开发基线数据架构描述

• 开发目标数据架构描述

• 执行差距分析

• 定义候选路线图组件

• 解决整个建筑景观的影响

• 进行正式的利益相关者审查

• 完成数据架构

• 创建架构定义文档

输出

• 目录：

• 数据实体/数据组件目录

• 矩阵：

• 数据实体/业务功能矩阵

• 应用/数据矩阵

• 图表：

• 概念数据图

• 逻辑数据图

• 数据传播图

• 数据安全图

• 数据迁移图

• 数据生命周期图

方法和技巧

当企业选择进行大规模架构转型时，了解和解决数据管理问题非常重要，

• 数据管理

• 清楚地了解业务功能、流程和服务如何利用数据实体

• 清楚地了解创建、存储、传输和报告企业数据实体的方式和位置

• 支持应用程序之间的信息交换需求所需的数据转换的级别和复杂性是多少

• 数据迁移

• 数据架构应识别数据迁移要求，并提供有关转换、清除和清理级别的指标，符合目标应用程序的要求和约束的格式呈现数据

• 数据治理

• 结构、管理系统、人员

作为此阶段的一部分，架构团队将需要考虑组织的架构存储库中可用的相关数据架构资源，特别是与组织的行业“垂直”相关的通用数据模型部门。例如：

• Energistics® - 上游石油和天然气行业的数据交换标准

• 国家信息交换模型（美国政府）

• ARTS 操作数据模型和 ARTS 数据仓库模型（零售）

应用架构

目标

同上

输入

• 基于业务架构

• 应用原则

• 架构定义文档草案，包括：

• 基线业务架构，版本 1.0（详细），如果适用

• 目标业务架构，版本 1.0（详细）

• 基线数据架构，1.0 版（详细）或 0.1 版（愿景）

• 目标数据架构，版本 1.0（详细）或版本 0.1（愿景）

• 基线应用程序架构，版本 0.1（如果适用且可用）

• 目标应用程序架构，版本 0.1，如果可用

• 基线技术架构，版本 0.1（愿景）

• 目标技术架构，版本 0.1（愿景）

操作方法

• 选择参考模型、观点和工具

• 开发基线应用架构描述

• 开发目标应用架构描述

• 执行差距分析

• 定义候选路线图组件

• 解决整个建筑景观的影响

• 进行正式的利益相关者审查

• 完成应用架构

• 创建架构定义文档

输出

• 目录：

• 应用组合目录

• 接口目录

• 矩阵：

• 应用/组织矩阵

• 角色/应用矩阵

• 应用/功能矩阵

• 应用交互矩阵

• 图表：

• 应用通信图

• 应用程序和用户位置图

• 应用用例图

• 企业可管理性图

• 流程/应用实现图

• 软件工程图

• 应用程序迁移图

• 软件分布图

方法和技巧

• TOGAF 集成信息基础设施参考模型 (III-RM) - 该模型侧重于提供必要的应用程序级组件和服务综合信息基础设施

技术架构

目标

• 开发目标技术架构，使架构愿景、目标业务、数据和应用程序构建块能够通过技术组件和技术服务以解决架构工作声明和利益相关者关注的方式交付

• 根据基线和目标技术架构之间的差距确定候选架构路线图组件

输入

• 基于技术架构内容

• 架构定义文档草案

• 基线技术架构，版本 0.1（愿景）

• 目标技术架构，版本 0.1（愿景）

操作过程

• 选择参考模型、观点和工具

• 开发基线应用架构描述

• 开发目标应用架构描述

• 执行差距分析

• 定义候选路线图组件

• 解决整个建筑景观的影响

• 进行正式的利益相关者审查

• 完成应用架构

• 创建架构定义文档

输出

• 目录：

• 技术标准目录

• 技术组合目录

• 矩阵：

• 应用/技术矩阵

• 图表：

• 环境和位置图

• 平台分解图

• 加工图

• 网络计算/硬件图

• 网络和通信图

方法和技巧

• IT 存储库或 IT 服务目录中记录的现有 IT 服务

机会和解决方案

E 阶段专注于如何交付架构。它考虑了所有体系结构域中目标体系结构和基线体系结构之间的完整差距，并在逻辑上将更改分组到企业投资组合中的工作包中。这是基于利益相关者要求、企业的业务转型准备情况、已识别的机会和解决方案以及已识别的实施限制条件来构建最合适的路线图的努力。关键是在实现增量业务价值的同时，专注于最终目标。

目标

• 根据差距分析和阶段 B、C 和 D 的候选架构路线图组件，生成架构路线图的初始完整版本

• 确定是否需要增量方法，如果需要，确定将提供持续业务价值的过渡架构

• 定义整体解决方案构建块，以基于架构构建块 (ABB) 完成目标架构

输入

• 架构参考资料、产品信息

• 架构工作请求、能力评估、沟通计划、规划方法

• 其他 ADM 输入

• 架构需求规范草案，包括：

• 架构要求

• 差距分析结果（来自业务、数据、应用程序和技术架构）

• IT 服务管理要求

• 现有业务计划和项目的变更请求

• B、C 和 D 阶段的候选架构路线图组件

操作过程

• 确定/确认关键的公司变更属性

• 确定实施的业务约束

• 审查和整合阶段 B 到 D 的差距分析结果

• 审查相关业务功能的合并要求

• 整合和协调互操作性要求

• 细化和验证依赖关系

• 确认业务转型的准备情况和风险

• 制定实施和迁移策略

• 识别和分组主要工作包

• 识别过渡架构

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

输出

• 架构需求规范草案，包括：

• 综合差距、解决方案和依赖性评估

• 能力评估，包括：

• 业务能力评估

• IT 能力评估

• 架构路线图，包括：

• 工作包组合：

• 工作包描述（名称、描述、目标）

• 功能要求

• 依赖项

• 与机会的关系

• 与架构定义文档和架构需求规范的关系

• 与任何能力增量的关系

• 商业价值

• 实施因素评估和推演矩阵

• 影响

• 确定过渡架构（如果有），包括：

• 与架构定义文档的关系

• 实施建议：

• 有效性的衡量标准

• 风险和问题

• 解决方案构建模块 (SBB)

• 图表：

• 项目上下文图

• 效益图

方法和技巧

以下四个概念是从开发过渡到交付目标架构的关键：

• 架构路线图

• 工作包

• 过渡架构

• 实施和迁移计划

迁移计划

F 阶段的重点是与项目和项目组合经理合作制定实施和迁移计划。

目标

• 最终确定架构路线图和支持的实施和迁移计划

• 确保实施和迁移计划与企业在企业整体变革组合中管理和实施变革的方法相协调

• 确保关键利益相关者了解工作包和过渡架构的业务价值和成本

输入：

• 前阶段输入

• 实施和迁移计划

操作过程

• 确认实施和迁移计划的管理框架交互

• 为每个工作包分配业务价值

• 估计资源需求、项目时间和可用性/交付工具

• 通过进行成本/收益评估和风险验证来确定迁移项目的优先级

• 确认架构路线图并更新架构定义文档

• 完成实施和迁移计划

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

输出

• 实施和迁移计划，包括：

• 实施和迁移策略

• 实施的项目和投资组合细分：

• 将工作包分配给项目和投资组合

• 项目交付的能力

• 与目标架构和任何过渡架构的关系

• 里程碑和时机

• 工作分解结构

• 项目章程（可选）：

• 相关工作包

• 商业价值

• 风险、问题、假设、依赖关系

• 资源需求和成本

• 迁移的好处

• 迁移选项的估计成本

实施治理

在这里汇集了成功管理各种实施项目的所有信息。请注意，与阶段 G 并行的是，执行特定于组织的开发过程，实际开发发生在该过程中。

目标

• 通过实施项目确保符合目标架构

• 为解决方案和任何实施驱动的架构变更请求执行适当的架构治理功能

输入

• 实施治理模型

操作过程

• 与开发管理确认部署的范围和优先级

• 识别部署资源和技能

• 解决方案部署指导开发

• 执行企业架构合规审查

• 实施业务和 IT 运营

• 执行实施后审查并关闭实施

输出

• 架构合同，如架构兼容的已实施架构中所建议的那样

• 合规评估

• 变更请求

• 部署的架构兼容解决方案包括：

• 填充架构存储库

• 架构合规性建议和豁免

• 关于服务交付要求的建议

• 关于性能指标的建议

• 服务水平协议 (SLA)

• 架构愿景，实施后更新

• 架构定义文档，实施后更新

• 已实施解决方案的业务和 IT 运营模式

方法和技巧

首选方法是将目标架构部署为一系列转换。每一次转变都代表着朝着目标迈进的一步，每一次转变都以自己的方式带来了商业利益。

架构变更管理

目标

• 确保维护架构生命周期

• 确保执行架构治理框架

• 确保企业架构能力满足当前要求

输入

• 变更请求，- 技术变更：

• 新技术报告

• 资产管理成本降低举措

• 技术退出报告

• 标准举措

• 变更请求，- 业务变更：

• 业务发展

• 业务例外

• 业务创新

• 商业技术创新

• 战略变革发展

• 变更请求，- 来自经验教训

操作步骤

• 建立价值实现流程

• 部署监控工具

• 管理风险

• 为架构变更管理提供分析

• 制定变更要求以满足绩效目标

• 管理治理过程

• 激活流程以实施变更

输出

• 架构更新（用于维护更改）

• 架构框架和原则的更改（用于维护更改）

• 新的架构工作请求，移动到另一个周期（重大更改）

• 架构工作声明，必要时更新

• 架构合同

• 合规评估

方法和技巧

治理机构建立标准来判断变更请求是否仅需要架构更新或是否需要启动架构开发方法 (ADM) 的新周期至关重要。避免“渐行渐远的优雅”尤为重要

ADM 需求管理

目标

• 确保需求管理流程在所有相关的 ADM 阶段持续并运行

• 管理在 ADM 周期或阶段的任何执行期间确定的架构要求

• 确保在执行阶段时，每个阶段都可以使用相关的架构要求

输入

• 需求影响评估

操作步骤

• 识别记录需求-使用业务场景或技术

• 基线要求以及监控

• 识别变更需求并记录优先级

• 评估需求变更影响

• 实施 H 产生的要求

• 更新需求存储库

• 在当前阶段实施变革

• 评估过去阶段和差距分析

输出

• 需求影响评估

• 如有必要，更新架构需求规范

方法

需求工程的世界充满了需求管理的新兴建议和流程。TOGAF 标准不强制或不推荐任何特定的流程或工具；它只是说明了一个有效的需求管理过程应该实现什么（即“需求的需求”，如果你愿意的话）。业务场景技术是一种发现和记录业务需求的适当且有效的技术。

HOW

下一步将详细了解 ADM 里面的具体方法细节

• 应用迭代

• 架构领域

• 架构原则

• 利益相关者分析

• 架构模式

• 差距分析

• 迁移规划技巧

• 互操作性

• 业务转型评估

• 风险管理

• 能力规划