一直想要整理架构设计相关的方法论。

背景

TOGAF，全称The Open Group Architecture Framework，是由组织The Open Group在1995年发布的企业架构框架，最新版本是9.2。The Open Group（开放群组）是国际著名标准化组织，拥有超过20年的标准制定与推广历史，而TOGAF框架可以说是它最著名的贡献了。TOGAF可以说是企业架构理论从政府进入到社会各研究机构的一个典型案例，它起源于美国国防部的信息管理技术架构框架（TAFIM，Technical Architecture Framework for Information Management），并在获得美国国防部的允许和鼓励之后，借助于美国政府大笔资金的投入，经过多年的努力最终于1995年发布了TOGAF的第一版。到目前为止，可以说TOGAF是最主流、最为人所广知的一个EA框架。由80%全球排名前50的公司都在使用它，中国企业对TOGAF的认可度也超过50%，以至于说起企业架构，很多人第一时间就以为是TOGAF。它还是唯一一个提供认证的框架。

[whfeng[简书]] [https://www.jianshu.com/p/0a867fe89e90] [企业架构框架之TOGAF]

框架介绍

图中具有彩色的部分就是TOGAF几大组成部分，下面分别说明一下。

TOGAF架构开发方法（TOGAF ADM（Architecture Development Method））：这是TOGAF框架的核心部分，是TOGAF针对企业架构建设方法的论述，它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤，并对每个步骤的输入、输出以及所采用方法都进行了详尽的阐述。
TOGAF内容框架（Architecture Content Framework）：这部分是TOGAF 9新加入的部分，是针对企业架构中所包含的各种工作产品以及他们之间的关系作出了详细的描述，从此改变了只重视架构开发过程和方法的风格，填补了以往没有架构内容描述和指导方面的空白。
TOGAF能力框架（TOGAF Capability Framework）：为了在一个企业中有效地操作企业架构并使其发挥最大的效能，一系列适当的组织结构、流程、技能、角色和责任需要被定义并结合起来，而TOGAF的能力框架正为如何组织好这些元素提供了指南。
TOGAF企业迭代框架和工具（TOGAF Enterprise Continuum and Tools）：企业连续体是企业架构资源库的一张视图，它为企业中的各种架构和解决方案制品提供了一种分类和组织的方法。
上述四部分相对独立，其中能力框架方面的内容着重于帮助企业更好地使用企业架构，架构开发方法和内容框架着重于帮助企业提高其企业架构建设和维护过程的标准化水平和执行效率，而企业连续体以及各种方法工具则更关注于为企业在企业架构的开发、使用和维护过程中提供参考和最佳实践。虽然这三个部分相对独立，但是一个优良的企业架构的创建、使用和维护是他们三者紧密配合、相互作用的结果。

在这四部分中，个人认为架构开发方法ADM是TOGAF最核心的部分，把它搞懂了，TOGAF就八九不离十了。

ADM介绍

ADM方法被迭代式的应用在架构演进的整个过程中、阶段之间和每个阶段内部。

ADM便形成了3个级别的迭代概念：

基于ADM整体的迭代，应用ADM方法，表明在一个架构开发循环结束后又进入新的循环。
多个架构过程的迭代，列入在完成了技术架构阶段的设计工作后又重新回到业务架构设计阶段。
在一个阶段内部的迭代，TOGAF支持基于一个阶段内部的多个开发活动，对复杂的架构内容进行迭代设计。

ADM方法中各个阶段的活动：

The Architecture Development Method Cycle

准备阶段: 为实施成功的企业架构做好准备，包括定义组织机构特定的架构框架(?文档范围？大纲)，架构原则和架构工具。
需求管理: 完成需求识别，需求管理和交付（持续的过程）？需求管理是贯穿整个架构设计的全生命周期的。具体和架构相关的活动可能包括需求分析及需求评审(可能时间上在设计开始之前)，需求确认(设计过程中)，需求验证(设计及开发活动结束之后)三种活动。按照优先级进行持续迭代。TOGAF项目的每个阶段，都是建立在业务需求至上并且需要对需求进行确认。
架构愿景阶段(规划): 设置TOGAF项目的范围，约束和期望。
- 创建架构愿景。
- 定义利益相关者（干系人）。
- 确认业务的上下文及环境，外部系统之间的调用关系及依赖。
- 创建架构设计说明书（大纲，条目？）
- 取得上层批准。
阶段B：业务架构阶段C：信息系统架构（应用架构，数据架构），阶段D：技术架构。
- 从业务，信息系统和技术三个层面进行架构设计，在每一个层面分别完成以下三个活动：
  - 开发基线架构描述。
  - 开发目标架构描述。
  - 执行差距分析。
阶段E：机会和解决方案：
- 进行初步的实施规划，提出实施计划，并且确认在前面的各个阶段中确定的各种构建块的交付物形式；确定主要实施项目。
- 对项目分组并且纳入过渡架构。
- 决定各个模块的落地方案（制造，购买，重用，外包，商用，使用开源框架）。
- 评估优先级顺序。
- 识别依赖项。
阶段F: 迁移规划
- 对阶段E确定的项目进行绩效分析和风险评估。
- 制定一个详细的实施和迁移计划。
阶段G: 实施治理
- 定义实施项目的架构限制。
- 提供实施项目的架构监督。
- 发布实施项目的架构合同。
- 检测实施项目以确保符合架构要求。
阶段H: 架构变更管理
- 提供持续检测和变更管理的流程，以确保架构可以响应企业的需求并且将架构对于业务的价值最大化。

方法的详细说明

在ADM过程的应用过程中，根据ADM提供的相位目标，根据一些输入和步骤产生许多输出。比如：

流程、
架构要求、
项目计划
。。。

为了以一致和结构化的方式整理和展示这些主要的工作产品，TOGAF定义了一个结构模型，用于放置他们。

这些只是建议，不需要完全遵循。
生成的每个可交付成果应进行版本化以指示何时发生更改。
显示的版本编号也只是一个建议，大致表示处于哪个阶段。

以下的文档从目标、步骤、输入和输出几个方面对ADM环中每个阶段进行了分析和描述。

准备阶段

整理一个文档，回答如下问题。

目标

对进行企业架构活动的组织的背景和环境进行审查;
确认利益相关者、他们的需求、优先级和需要承担的义务;
确定并审视企业机构中受到影响的部分，并且对其范围进行界定，定义约束条件和假设条件，这一点在使用联邦式体系结构环境的大型机构中特别重要;
定义组织的“架构足迹”，包括确定执行架构开发工作的人是谁、他们在哪里，以及他们的责任是什么;
定义用于进行企业架构建设的框架和详细方法，这里通常是对ADM进行适应性的改变（裁剪或者修改）;
确定一个治理和支持框架，用来在整个ADM过程中为架构治理提供业务流程和资源方面的支持，此种框架将会确保目标架构的适用性（fitness-for-purpose），并对其在进行过程中的效能进行评测；
选择和落实用于支持架构活动的各种工具和基础设施；
定义架构原则，而这些原则将会成为约束架构工作的一个部分。

步骤

界定将要受到影响的企业组织的范围；
确定治理和支持框架；
建立企业架构团队；
定义架构原则；
选择架构框架并裁减定义；
落实相关架构工具；

输入

TOGAF架构框架资料；
其他的架构框架资料；
业务原则、业务目标和驱动力；
架构治理策略;
IT战略；
当前企业架构组织模型；
当前企业架构框架；
当前企业架构原则；
当前企业架构资源库；

输出

企业架构的组织模型；
定制的企业架构框架，包括架构原则；
企业架构资源库的雏形；
针对业务目标，原则和驱动力的声明或者引用；
治理框架；
架构工作要求说明书；

阶段A-架构的愿景

在架构愿景阶段，将启动一次架构开发过程的迭代，设置迭代工作范围，约束和期望，创建架构愿景、验证业务上下文，创景架构工作说明书并且取得大家的一致认可。
愿景表达了我们对架构的期望结果，阐明重要涉众关注的问题和目标，可帮助团队关注架构的核心领域。

目标

获取管理层对这次特定的ADM循环的相关承诺;
制定一个架构开发周期;
确认业务原则、业务目标、驱动力和KPI(Key Performance Indicators);
定义基线架构的范围，明确其所包含的组件以及组件的优先级;
确认相关的干系人，他们的关注点和目标;
定义架构工作所要解决的关键业务需求，以及必须应对的各项约束;
阐明架构愿景，并且定制价值主张，这些价值主张被用来阐述对于那些需求和约束的回应；
创建一个符合企业项目管理框架要求的综合计划；
去的继续下一个步骤工作的正式批准；
理解与其他并行的企业架构开发循环之间的相互影响；

步骤

成立架构项目（这里应该融合进企业整体的项目管理范畴）；
识别干系人、关注点和业务需求；
确定并且拆书业务目标、驱动力和约束；
评估业务能力；
评估业务转型的准备情况；

输入

架构工作要求说明书；
业务原则、业务目标和驱动力；
企业架构的组织模型，包括受影响的组织范围、成熟度评测、差距及解决办法、架构团队所担当的角色和职责；
定制的架构框架，包括定制的架构方法、架构内容、架构原则和配置部署工具；
初具内容的架构资源库（包括初始的框架说明、架构描述和基线描述内容）

输出

得到批准的架构工作说明书；
范围和约束；
架构工作计划；
角色和职责；
风险和应对措施；
工作产品效能评测；
业务案例与KPI指标；
改善的业务原则、业务目标和驱动力说明；
架构原则；
能力评估；
定制的架构框架（方法、内容、工具）；
架构愿景；
改善的关键高层次干系人的需求；
基线业务架构0.1版
基线数据架构0.1版（信息架构）
基线应用架构0.1版
基线技术架构0.1版
目标业务架构0.1版
目标应用架构0.1版
目标数据架构0.1版
目标技术架构0.1版
沟通计划
纳入到架构资源库中的新增内容

阶段B-业务架构

在业务架构阶段，将开发一个支持架构愿景的业务架构。架构愿景中概括的基线和目标业务架构将在此被细化，从而使它们可以作为技术分析的有用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术，这又包含了所期望状态的差距分析。
本阶段的核心内容包括组织如何满足业务目标；企业静态特征（业务目标、业务组织结构、业务角色）；企业动态特征（流程、功能、服务）。

目标

描述基线业务架构；
设计出目标业务架构；
执行以上二者的差距分析；
选择和开发相关的架构视角，通过这些视角架构师可以阐述业务架构是如何对各个干系人的关注点进行解答的；
确定与架构视角相关的工具和技术；

步骤

选择参考模型、视角和工具；
开发基线业务架构描述；
开发目标业务架构描述；
执行差距分析；
定义架构路线图组件；
分析对整个架构的影响；
涉众评审；
最终确定业务架构；
创建架构定义文档；

输入

架构工作要求书；
业务原则、业务目标和驱动力；
能力评估；
沟通计划
企业架构的组织模型;
得到批准的架构工作说明书；
业务架构原则、包括在此之前已经存在了的业务原则；
定制的架构框架；
企业连续体；
架构资源库：
- 可重用的组件和模块；
- 公开且可得的参考模型；
- 组织特定的参考模型；
- 组织标准；
架构愿景，包括：
- 经过改善的关键高层次干系人的需求
- 基线业务架构0.1版
- 基线数据架构0.1版
- 基线应用架构0.1版
- 基线技术架构0.1版
- 目标业务架构0.1版
- 目标应用架构0.1版
- 目标数据架构0.1版
- 目标技术架构0.1版

输出

架构工作说明书（更新）
经过验证的业务原则、业务目标和驱动力；
详细的业务架构原则；
架构定义文档草稿；
基线业务架构1.0版本；如果有
目标业务架构1.0版本
组织结构；
业务目标；
业务功能；
业务服务；
业务流程，包括测评和交付物；
业务角色，包括相关技能需求的发展与改进；
业务数据模型；
组织和功能之间的相互关联；
主要涉众关注的业务架构视图；
架构需求说明书草稿；
差距分析的结果；
技术需求；
更新的业务需求；
架构路线图和业务架构组件；

阶段C-信息系统架构

在信息系统架构设计阶段，确定主要的信息类型和处理这些信息的应用系统。在本阶段有两个主要的步骤，数据架构设计（信息架构）和应用架构设计，二者既可以依次开发，也可以并行开发。核心内容为：IT系统如何满足企业的业务目标；信息以及信息之间的关系；应用以及应用之间的关系。

数据架构(归纳且符合企业整体的信息架构)-目标

定义业务运行所需的数据源和数据类型。

步骤

选择参考模型、视角和工具；
开发基线数据架构1.0版本；
开发目标数据架构1.0版本；
执行差距分析；
定义组件；
分析对整个架构的影响；
涉众评审；
确定最终的数据架构；
完善架构定义文档；

输入

架构工作要求说明书；
能力评估；
沟通计划；
企业架构的组织模型；
定制的架构框架；
数据原则（如果有，在整体的信息架构基础上）；
架构工作说明书；
架构资源库；
可重用的构建快；
公开可得的参考模型；
组织特定的参考模型；
组织标准；
按机构定义文档草稿-包括:
- 基线业务架构1.0版；
- 目标业务架构1.0版；
- 基线数据架构0.1版；
- 目标数据架构0.1版；
- 基线应用架构（0.1或1.0版）；
- 目标应用架构（0.1或1.0版）；
- 基线技术架构（0.1版）；
- 目标技术架构（0.1版）；
架构需求说明书:
- 差距分析结果；
- 适用于此阶段的相关技术需求；
- 在架构路线图中的业务架构组件；

输出

经过改善或者更新的架构与安静阶段中的各交付物；
架构工作说明（update）
经过验证的数据原则或者新增的数据原则；
更新的架构定义文档草稿；
基线数据架构1.0版本；
目标数据架构1.0版本；
业务数据模型；
逻辑数据模型；
数据管理流程模型；
数据实体/业务功能矩阵；
主要涉众关注的数据架构视图；
更新的架构需求说明书；
差距分析结果；
数据集成需求；
适用于当前阶段的相关技术需求；
对于下一步将要设计的技术架构约束；
更新的也无需求；
更新的应用需求；
架构路线图中的数据架构组件；

应用架构-目标

定义处理数据并支撑业务运行所需的各种应用系统；

步骤

选择参考模型、视角和工具；
开发基线应用架构1.0版本；
开发目标应用架构1.0版本；
执行差距分析；
定义组件；
分析对整个架构的影响；
涉众评审；
最终确定应用架构；
完善架构定义文档；

输入

架构工作要求说明书；
能力评估；
沟通计划；
企业架构的组织模型；
定制的架构框架；
应用原则；
架构工作说明书；
架构资源库；
架构定义文档草稿-包括：
- 基线业务架构1.0版；
- 目标业务架构1.0版；
- 基线数据架构（0.1或者1.0版本);
- 目标数据架构（0.1版或1.0版）；
- 基线应用架构0.1版；
- 目标应用架构0.1版；
- 基线技术架构0.1版；
- 目标技术架构0.1版；
架构需求说明书草稿，包括：
- 差距分析结果；
- 适用于此阶段的相关技术需求；
- 架构路线图的业务架构组件和数据架构组件；

输出

经过改善和更新的架构愿景阶段中的各交付物：
架构工作说明（Update）；
经过验证的应用原则或新增的应用原则；
更新的架构定义文档：
基线应用架构1.0版
目标应用架构1.0版
主要涉众关注的应用架构视图
更新的架构需求说明书：
差距分析结果
应用交互需求
适用于当前阶段的相关技术需求；
对于将要设计的技术架构的约束；
更新的业务需求；
更新的数据需求；
架构路线图的应用架构组件。

阶段D-技术架构

在技术架构阶段，完成对IT系统基础服务设施的设计，定义了架构解决方案的物理实现，包括硬件、软件和通信技术。

目标

开发一个目标技术架构，并以此作为后续的实施和迁移计划的基础。
将应用架构中定义的各种应用组件映射为相应的技术组件，
这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。

步骤

选择参考模型，视角和工具；
开发基线技术架构1.0版；
开发目标技术架构1.0版；
执行差距分析；
定义组件；
分析对整个架构的影响；
涉众评审；
技术架构定稿；
完善架构定义文档。

输入

架构工作要求说明书
能力评估；
沟通计划
企业架构的组织模型；
定制的架构框架；
技术原则；
架构工作说明书；
架构资源库（四个方面）；
架构定义文档草稿-包括：
- 基线业务架构1.0版
- 目标业务架构1.0版
- 基线数据架构1.0版
- 目标数据架构1.0版
- 基线应用架构1.0版
- 目标应用架构1.0版
- 基线技术架构0.1版
- 目标技术架构0.1版
架构需求说明书草稿-包括：
- 差距分析结果；
- 来自于之前各个阶段的相关技术需求；
- 架构路线图的业务、数据和应用架构组件；

输出

经过改善和更新的架构愿景阶段中的各个交付物；
架构工作说明（update）
经过验证的或者新增的技术原则；
更新的架构定义文档；
基线技术架构1.0版
目标技术架构1.0版
个技术组件以及他们与信息系统之间的关系；
各个技术平台以及他的结构组成；
环境和位置；
期望的处理符合以及技术组件间的负荷分布；
物理（网络）通信；
硬件及网络说明；
主要涉众关注的技术架构视图；
更新的架构需求说明书；
差距分析结果；
从业务架构和信息系统架构阶段输出的需求；
更新后的技术需求；
架构路线图的技术架构组件；

机会及解决方案

这是第一个直接关注实施的阶段，该阶段主要描述确定目标架构交付物（项目、程序或文件）的过程。

目标

重新审查业务目标和业务能力，合并从阶段B到阶段D的差距分析，确定主要工作包并分组；
重新审查并确认企业承受变化的能力；
获得一系列过渡架构，它们可以通过对各种机会的开发利用，来为各构建块的实现提供持续的业务价值；
产生概要性的实施与迁移策略，并取得共识。

步骤

确定关键的公司变更属性；
确定项目实施的业务约束；
审查并合并从阶段B到阶段D的差距分析结果；
从功能的角度审查IT需求；
确定并加强交互需求；
改善并验证依赖关系；
确认业务转型的准备情况和风险；
制订高层次的实施和迁移策略；
识别主要的工作包并进行分组；
确定过渡架构；
创建项目投资组合和项目章程，同时对架构进行更新。

输入

产品信息；
架构工作要求书；
能力评估；
沟通计划；
规划方法；
企业架构的组织模型；
定制的架构框架；
架构工作说明书；
架构愿景；
架构资源库；
架构定义文档草稿（v1.0版的4个基线架构和4个目标架构）；
架构需求说明书草稿：
差距分析结果（业务、数据、应用和技术架构）
架构需求
IT服务管理一体化要求
现存业务程序或项目的变更请求。

输出

经过改善和更新的架构愿景、业务架构、信息系统架构和技术架构阶段中的各交付物：
架构工作说明（Update）；
架构愿景（Update）；
架构定义文档草稿：
识别出的增量内容
交互和共存需求
实现和移植策略
项目清单和项目章程
架构需求说明书草稿（Update）；
能力评估：
企业架构成熟度概况
转型准备工作报告
过渡架构1.0版：
确定的关于差距、解决方案和依赖性的评估
风险注册表1.0版本
影响分析（项目列表）
依赖性分析报告
实施因素的评估和推导矩阵(Deduction Matrix)
实施和迁移计划0.1版本（概述）

阶段F-迁移规划

该阶段通过制订一个详细的实现和迁移计划完成从基线架构向目标架构的转变。

目标

确保实施和迁移规划与企业中正在使用的各种管理框架相协调；
通过分配业务价值和执行业务成本分析，划分所有工作包、项目和构建块的优先级；
最终确定架构愿景和架构定义文档，使其与共同商定的实施方法一致；
与相关干系人一起确认在机会和解决方案阶段中定义的过渡架构；
创建、演进并监控详细的实施和迁移规划，提供实现过渡架构所需的各种资源。

步骤

确定管理框架与实施和迁移规划之间的相互作用；
为每个项目指定业务价值；
估算资源需求、项目时间和交付工具；
通过绩效评估和风险验证，确定迁移项目的优先级；
确定过渡架构的增量内容并更新架构定义文档；
生成架构实现路线图（有时间标识）和迁移计划；
创建架构演进循环并记录收到的经验教训。

输入

架构工作要求书；
能力评估（企业架构成熟度概况和转型准备报告）；
沟通计划；
企业架构的组织模型；
治理模型和框架：
企业架构管理框架
能力管理框架
投资组合管理框架
项目管理框架
运营管理框架
定制的架构框架；
架构工作说明；
架构愿景；
架构资源库；
架构定义文档草稿：
迁移规划策略
影响分析（项目列表和章程）
架构需求说明书草稿：
差距分析结果（业务、数据、应用和技术架构）
架构需求
IT服务管理一体化要求
现存业务程序和项目的变更请求；
经过确认和验证的架构路线图；
过渡架构1.0版：
确定的关于差距、解决方案和依赖性的评估
风险注册表1.0版本
影响分析（项目列表）
依赖性分析报告
实施因素评估和推导矩阵
实现和迁移计划0.1版。

输出

实施和迁移计划1.0版；
定稿的架构定义文档；
定稿的架构需求说明书；
定稿的架构路线图；
定稿的过渡架构；
可重用的架构构建块；
架构工作要求书（各实施项目，如果有的话）；
架构契约（关于各实施项目）；
实施治理模型；
从经验教训中产生的变更请求。

阶段G——实施治理

该阶段定义了实施项目的架构约束，提供项目构建的架构监督，产生一个架构契约。

目标

为每个实施项目给予建议；
对涵盖整个实施和部署过程的架构契约进行治理；
在解决方案正在实施和部署时，行使恰当的治理职责；
确保各实施项目符合于规定的架构；
确保按工作计划成功部署了解决方案的相关程序；
确保已经部署的解决方案与目标架构一致；
组织各种支持性行动，确保被部署的解决方案长期有效。

步骤

通过开发管理工作，确认部署的范围和优先级；
明确用于部署的资源和技能；
指导部署解决方案的开发工作；
执行企业架构合规审查；
实施业务和IT运营；
执行实施后审查并结束实施工作。

输入

架构工作要求说明书；
能力评估；
企业架构的组织模型：
受影响的组织范围
成熟度评测、差距及解决方法
架构团队所担当的角色和职责
架构工作的约束
预算需求
治理和支持策略
定制的架构框架：
定制的架构方法
定制的架构内容（交付物和制品）
配置和部署工具
架构工作说明书；
架构愿景；
架构资源库：
可重用的构建块
公开且可得的参考模型
组织特定的参考模型
组织标准
架构定义文档；
架构需求说明书：
架构需求
差距分析结果（业务、数据、应用和技术）
架构路线图；
过渡架构；
实施治理模型；
架构契约；
架构工作要求书（经过机会与解决方案和迁移规划阶段明确的）；
实施和迁移计划。

输出

架构契约（签字）；
变更请求；
影响分析（实施）；
建议；
可部署的符合架构要求的解决方案：
实现的符合架构要求的系统
填充了相关资料的架构资源库
架构合规性建议与特许
对服务交付需求的建议
关于效能指标的建议
服务水平协议（SLAs）
在实施后经过更新的架构愿景
在实施后经过更新的架构定义文档
在实施后经过更新的过渡架构
已实施解决方案的业务和IT运营模型

阶段H——架构变更管理

该阶段确保能够以一种可控制的方式对架构的改变进行管理。

目标

确保基线架构持续符合当前实际情况；
评估架构性能并提出改进建议；
评估在之前阶段中制定的框架和原则的变化；
为实施治理阶段建立的新的企业架构基线建立一个架构变更管理流程；
将架构和运营的业务价值最大化；
运用治理框架。

步骤

建立价值实现过程；
部署监控工具；
管理风险；
提供架构变更管理分析；
开发变更需求以满足性能目标；
管理治理过程；
启动实施变更的流程。

输入

在阶段E和F中确认的架构工作要求书；
企业架构的组织模型；
架构工作说明书；
架构愿景；
架构资源库；
架构定义文档；
架构需求说明书；
架构路线图；
由技术变化产生的变更请求：
新技术报告
资产管理成本削减措施
技术退出报告
各标准举措
由业务变化产生的变更请求：
业务发展
业务异常
业务革新
业务技术革新
战略变化发展
由经验教训产生的变更请求；
过渡架构；
实施治理模型；
架构契约（签字）；
合规性的评估；
实施和迁移计划。

输出

架构的各种更新；
对架构框架和原则的变更；
新的架构工作要求书，用于发起另一次ADM循环；
架构工作说明书（Update）；
架构契约（Update）；
合规性的评估（Update）。

需求管理

架构需求管理适用于ADM的所有阶段，这是一个动态的过程，完成对企业需求的识别、存储并把它们插入或取出相应的ADM阶段。需求管理是ADM流程的中心。处理需求变化的能力对于ADM过程是非常重要的，架构通过其天然处理不确定性和变化的能力在涉众诉求之间架起桥梁并交付一个可实践的解决方案。

目标

定义一个可以贯穿ADM循环各个阶段的管理架构需求的过程；
识别和存储企业需求并与相应的ADM阶段进行交互。

步骤

通过业务情景或其它模拟技术来识别并记录需求（ADM各阶段）；
建立需求基线：
确定产生于当前架构开发方法阶段的各优先级事项
确认干系人认可各个结果优先级事项
记录需求优先级并将其放入需求库
监控需求基线；
识别发生变更的需求（ADM各阶段）：
增、删、改处理并重新评定优先级
识别并解决冲突
生成需求影响说明
评估变更的需求对现在和之前的ADM阶段产生的影响（ADM各阶段）；
实施架构变更管理阶段的需求（ADM架构变更管理阶段）；
更新需求资源库；
实施当前阶段的需求变更（ADM各阶段）；
评估并修订先前阶段的差距分析（ADM各阶段）。

输入

各个ADM阶段中与需求相关的输出就是需求管理流程的输入；
最初高层次的需求是作为一部分的架构愿景所产生；
每个架构领域都有相应的详细需求，之后的ADM阶段交付物也包含了对新的需求类型的映射（如一致性需求）。

输出

更新的架构需求说明（如有必要）；
需求影响的评估，识别出需要回到的ADM阶段。最终版本必须包含需求的全部含义（如成本、时间范围和业务流程）。

建立架构活动的范围

ADM方法不能够确定架构活动的范围，这必须由企业自己确定。需要限定架构活动范围的原因与以下因素有关：

创建架构的团队所具备的组织权力；
需要在架构中实现的目标和干系人的诉求；
可利用的人、资金以及其它资源。

选定的架构活动范围理论上应该地支持企业中的架构师高效地完成治理和整合工作。这需要一套一致的“架构分区”，确保架构师不会从事重复劳动或冲突的活动。这同样需要定义重用和多个架构分区间的服从关系。下面从四个维度对架构活动范围的限定进行了说明。

企业范围或焦点

企业最大的业务范围是什么？其中又有多少是需要架构工作聚焦的？
许多企业的规模非常大，实际上形成了一个组织单位成员的联盟，每个成员都有自己独立的企业权利。(如事业部或者子公司)
现代企业越来越突破它的传统界线，包括了一个由供应商、客户和合作伙伴形成的模糊的传统行业企业联盟。

架构领域

一个全面的企业架构描述应该包括全部四个架构领域（业务、数据、应用、技术），但是实际的资源和时间约束经常意味着没有充分的时间、资金或其它资源去设计一个自顶而下的、包含全部四个架构领域的架构描述。即使在选定的架构活动范围小于企业整体业务范围时也是这样。

详述垂直范围或级别

架构工作应该细化到第几层？怎么样的架构工作才算充分的？
架构工作和其它相关工作（系统设计、系统工程以及系统开发）的界线是什么？一般是配合的，松散的分工

时间周期

架构愿景的准确时间周期是什么？它是否意味着要在这个时间期间内用详细的架构描述填充满？如果不是，那么需要定义多少个中间级别的目标架构，并且它们的时间周期是多少？

TOGAF方法论系列文章

系统架构设计方法论-TOGAF-概述: 背景介绍，ADM，以及TOGAF各个阶段的输入输出说明
TOGAF架构能力框架说明
各种架构方法论的对比

参考文档

https://segmentfault.com/a/1190000019704801
https://baike.baidu.com/item/TOGAF/9832356?fr=aladdin
https://www.cnblogs.com/xiang--liu/p/9710229.html
https://blog.csdn.net/watermelonbig/article/details/77620847
https://www.jianshu.com/p/0a867fe89e90
https://zhuanlan.zhihu.com/p/83618027
https://zhuanlan.zhihu.com/p/84110694

https://www.visual-paradigm.com/cn/features/togaf-adm-tools/

本文标题:97-系统架构设计方法论-TOGAF

文章作者:盛领

发布时间:2020年05月19日 - 21:39:41

原始链接:http://blog.xiaoyuyu.net/post/320fd534.html

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际转载请保留原文链接及作者。

如您有任何商业合作或者授权方面的协商，请给我留言：sunsetxiao@126.com

欢迎您扫一扫上面的微信公众号，订阅我的博客！

坚持原创技术分享，您的支持将鼓励我继续创作！