导图社区 TOGAF 9.2框架整理（含题库）
- 158
- 2
- 0
- 举报
TOGAF 9.2框架整理（含题库）
这是一篇关于TOGAF 9.2的思维导图，主要内容包括：七大部分的框架梳理，结合了2024年L1题库答案进行梳理。
编辑于2024-09-14 15:25:00- 题库
- TOGAF
- 企业架构框架
- 相似推荐
- 大纲
TOGAF 9.2
第一部分：引言
第一部分描述了TOGAF框架实现企业架构的方法
E企业
有着共同目标的任何集合的组织
A架构
组件、组件之间的关系、组件与环境的关系、治理架构的演进的原则
TOGAF附加
TOGAF:一个系统的形式化描述或系统实现组件级的详细步骤
内嵌在组件中系统的基础组织，他们的相互关系指引设计和演化的原则
一个正式的对系统的描述， 或一个详细的系统组件级别的规划来指引它的实施
EA企业架构
企业各组成部分，构建他们之间关系及设计演化原则
业务流程和IT基础设施的逻辑关系，反应了组织业务运营模式的标准化需求
蓝图：组织结构和运营概念
目的：有效的表达目标，优化企业环境来对应业务需求
一种穿透企业中多层系统和不同功能组织的架构
战略架构，最高级别架构
安全架构
贯穿
解决方案架构
底层
架构域
BA业务架构
流程
业务战略、治理、组织和关键业务流程信息，及其间的交互
让IT理解
DA数据架构
结构
逻辑数据资产结构，物理数据资产结构，数据管理资源（服务器、存储设备、系统调动）
AA应用架构
交互
基于目标需要完善开发的应用服务、应用服务之间的关系、应用和关键业务流程之间的关系（如何完善业务目标定制应用、可理解为系统和系统方案）
TA技术架构
软硬件
支持业务、数据和应用服务必须的软件和硬件能力
软件、硬件、通讯技术
EAF企业架构框架
为什么需要架构框架？
便于复杂性设计
加速架构开发
保证架构全面覆盖
通用词汇表
框架的定义和元素：标准、方法，工具，通用词汇表
元素
一个通用词汇表
一个推荐标准的列表
以构建快描述信息系统的一种方法
一套可以用来开发广泛架构的结构
TOGAF
一种通用企业架构框架
一个流程模型，最佳实践和资产来帮助生产，使用和维护企业架构
文档描述
贯穿：系统、多职能组织
含义：它必须适应满足组织的特定需求
通用：企业在通用框架下的调整和定制
框架：通用
定制：应用
组件关系
提供如何使用ADM来建立架构能力的指引
把建设作为一直要进行的实践
把ADM 应用到特定愿景来建立实践
和其他能力一样使用同样的方法
ADM
如何开发企业架构的流程
开发及风格和方法
客户需求
分析客户
分析AS-IS
基线架构
分析TO-BE
目标架构
1、不知目标，分析基线 2、知目标解决方案映射回基线
过渡架构
TODO
从业务端设计，从技术端实施
第四部分：架构内容框架
包含了架构制品的结构化的元模型
描述了 TOGAF 内容框架，包括一个用于架构制品的结构化元模型、可复用的架构构建块(ABB)的使用以及典型架构交付物的概述
架构内容框架本身不告知用什么模型和文档但是制定了被建模被描述的对象
实施架构开发方法(ADM)的架构师将通过他们的努力产生许多输出，如流程、架构需求、项目计划、项目合规性评估等。内容框架为架构师创建的主要工作产物提供了一个结构模型，可以一致地定义、结构化和呈现这些主要工作产物
ADM 描述了创建架构需要完成的工作，内容框架描述了完成后架构的外观
目的：提供了在ADM过程中建模和文档的指导
内容元模型
按照ADM阶段划分
详细展示
架构工作产物
架构内容框架使用以下三个类别来描述使用背景环境中的架构工作产物的类型：
交付物（交付成果）
合同明确规定、并经各利益相关者正式评审、同意和签署认可的工作产品
架构合同输出
正式文档
最终输出物
制品
从特定视点描述了架构
与特定视点相关的、更细粒度的架构工作产品
制品从通用架构变成组织特定演进最好的描述了架构制品作为项目进度状态从ADM阶段A到D
目录
一种制品来显示列表
一元
矩阵
一种制品来显示事物的关系
二元\无限元
关系
图
阶段交付物
交付物是由架构项目合同指定的输出，而制品不是
构建块
构建块表示企业能力的(潜在可复用的)组件，它可以与其他构建块相结合，以提供架构和解决方案
架构构建块ABB
描述所需的能力并塑造解决方案构建块(SBB)的规格；例如，企业内部可能需要客户服务能力，这些能力由许多SBB支持，如流程、数据和应用软件
定义功能
解决方案构建块SBB
用来实现所需能力的组成部分；例如，网络是一个构建块，它可以通过互补的制品来描述，然后用于实现企业的解决方案
定义功能的实施
一个可能重用的业务能力、IT能力或架构能力的构件
可重用性
日常交付物
描述了一套功能来定义满足整个组织的的业务需求
描述
满足业务需求的功能的打包
稳定，有公开接口允许其他构建块相互操作
多重但独立
可以封装到其他构建块
有定义好的边界
应该按照功能包装来满足组织内业务需求
特点
在E阶段变得更加实施待定
松耦合到实施
可交付成果、制品和构建块之间的关系图
架构视点与架构视图
系统
系统（组件集合）
系统是组件集合来完成特定功能或功能集
系统"是为实现一个或多个既定目的而组织的相互作用要素的组合。
架构
系统的“架构”是一个系统的基本概念或特性，它体现在系统的元素、关系以及系统的设计和演化原则中。
架构（组件的结构、他们的相互关系以及指引他们的设计的演进的原则）
内嵌在组件中系统的基础组织，他们的相互关系指引设计和演化的原则
架构描述
制品集合
“架构描述”是用来表示架构的一种工作产物；架构视图和模型的集合，这些视图和模型一起记录了架构。
利益相关者
利益相关者是对企业架构有着关键角色或关注，利益相关者可以是个人，团队和组织等
“利益相关方”是对系统感兴趣的个人，团队，组织或其类别。
利益相关者（关注系统的人）
关注点
"关注点"是一个系统中与一个或多个利益相关方相关的利益。关切可能涉及系统的运作、开发或运作的任何方面，包括诸如性能、可靠性、安全性、分布和可进化性等考虑因素，并可能决定系统的可接受性
关注是关键兴趣对利益相关者非常重要，并确定系统是否可接受。它们可能包括性能，可靠性，安全，分布，演进等
架构视图
架构视图 （是架构描述的重要制品）
“架构视图”是从一组相关关注点的角度对系统的表示。它由一个或多个系统架构模型组成。
一个视图是一组关注的系统展现
一个视图是用来描述利益相关者的关注是如何满足的
一个视图是系统从一套相关关注的角度的表示
每个架构视图都关联一个视点来描述这个视图， 至少暗含的
架构视图是你所看到的
架构视图将包括一个或多个模型的选定部分，其选择目的是向特定利益相关方或利益相关方组证明在系统架构设计中已充分解决了他们的关注。
创建特定架构的视图推荐的第一步：参考视点库，识别一个可以重用的
架构模型
“架构模型”是感兴趣主题的表示。模型提供主题的较小比例，简化和人或抽象表示。
模型种类
“模型种类”为一种建模类型建立约定。
架构观点引用了一种或多种模型类型。架构视图包含一个或多个模型。
架构视点
“架构观点”是对特定种类的架构视图的约定的规范。也可以将其称为此类架构视图的定义或架构。它建立了用于构造、解释和使用架构视图的约定，以解决有关关注系统的特定关注点(或关注点集)
它定义了如何构建和使用视图, 所需信息, 表示和分析的建模技术以及选择的依据 (如通过表示目的和视图面向的听众）
架构视点是你所观察的地方，它决定你所看到事物的有利位置或视角
视点定义视图从哪里看到
视点被用来作为模板来创建视图
视点代表利益相关者的关注
架构观点是通用的，可以存储在库中供重用；架构视图总是特定于为其创建的架构
视点（视图视角、决定视图的构建和使用）
视点是一个可重用制品，用来创建架构模型来满足利益相关者的关注
视点库
“观点库”是架构库的参考库部分所包含的架构观点规范的集合。
第五部分：企业连续系列和工具
显示了不同特定级别的构建块
一种架构和解决方案制品分类方法，包括架构储藏库内外部，从一般基础架构演变到组织特定架构
对架构活动的输出以重用来分类
以它们的通用架构到组织特定架构演进，来提供分类架构制品的方法
组织内在开发企业架构时
企业连续系列被用来构建可重用的架构和解决方案资产
企业连续系列在架构师之间帮助沟通和理解
企业连续系列最简单的想法是架构储存库的视图
两个专门领域
架构连续系列
基础架构
例如TOGAF提供的基础架构（TOGAF技术参考模型TRM）
主要特点包括开放系统标准和通用构建块
包含最多可以重用的架构元素
共同系统架构
TOGAF集成信息基础架构参考模型III-RM
行业架构
组织特定架构
解决方案连续系列
逻辑角度
解决方案连续系列代表架构的实施对应于架构连续系列的层次
基础架构
通用系统
行业/领域
组织/企业特定
• 特定级别看组织 • 行业级别看产业 • 通用级别看跨越 • 基础级别看标准
连续系列：一个连续不断的方位，顺序整体，除非硬性切割否则不建议将一部分与相邻分区区分
架构储藏库
物理角度文件夹进行治理分类
是用来存储由ADM创建的不同架构分类输出
架构元模型
描述了架构框架的组织定制应用，包括一个架构内容的元模型
架构能力
定义了支持架构存储库管理的参数、结构和流程
支持治理架构储藏库的流程
为了促进有效的架构工作，TOGAF 9提倡建立架构能力
架构景观
在特定时间点部署在运营企业内的架构资产的表现形式，这种全景很可能存在于符合不同架构目标的多级抽象中
分为战略架构、分段架构、能力架构三个层次
完整的架构全景是通过多个 ADM迭代来开发的
战略架构提供整个企业的长期总括性视点
显示了当前组织在使用的构建块
提供了不同颗粒度的构建块视图
标准信息库
收集新架构必须遵守的标准，其中可能包括国际标准、供应商提供的选定产品和服务，或组织内已部署的共享服务
一个存有架构必须遵循的规格的库
治理日志
记录了整个企业的治理活动
参考库
提供了指导方针、模板、模式和其他形式的参考资料，可以利用这些参考资料来加速企业新架构的创建
提供指引、模板和模式来产生新架构
有着最佳实践或模板材料能重用构建架构
老系统和流程将在今后继续使用
TOGAF架构库是一个参考库
架构需求储藏库
提供了与架构委员会被认可的所有授权架构需求的视图
解决方案全景
提供了解决方案构建块(SBB)的架构表现形式，支持企业规划或部署的架构全景
第六部分：TOGAF参考模型
一个例子，被裁剪到符合组织要求的应用
TOGAF集成信息基础设施参考模型：III-RM
共同系统架构
是以无边界信息流为愿景目标的共同系统架构 （应用领域）
满足无边界信息流
应用架构参考模型
共同系统架构
集成信息基础设施参考模型是架构参考模型的一个应用例子
TOGAF技术参考模型：TRM
基础架构，更特定的架构可以基于它
关键指标：定义技术组件（架构）到一组技术平台
TOGAF技术参考模型：一个例子裁剪到符合组织需求
包括一套图形模型和相应的分类法
通用的平台服务模型和分类法：视图和方法
第七部分：架构能力框架
为了在企业中成功地运行架构功能，有必要放置适当的组织结构、过程、角色、职责和技能来实现架构功能
第七部分：架构能力框架为如何建立这样的架构功能提供了一套参考资料
提供了一套参考材料来在组织里建立一个架构职能/功能
描述建立企业架构功能的流程和技能
能力：财务管理、绩效管理、服务管理、风险管理、 资源管理、沟通和利益相关者管理、质量管理、供应商管理、配置管理
目的：有效进行架构活动
建立架构能力：开发小组、治理小组
推荐使用架构开发方法ADM来实施企业架构能力
架构实践
推荐使用ADM周期来建立架构实践
业务
注重架构治理，架构流程，架构组织结构，架构所需信息，架构产品等
数据
定义组织的企业连续系列和架构储藏库结构
应用
功能规格和应用服务
技术
基础设施需求和部署支持所需的架构应用和企业连续系列
架构委员会
由架构师和利益相关者批准开发架构委员会
责任：仅技术层面强制架构合规
职责
负责接受和批准架构合规审查
提供架构变更的决策基础
保证子架构间的一致性
确保架构合规
识别和批准重用组件
提升组织架构纪律的成熟度
监控架构合同
通常负责达到以下目标
不包括准备架构审查报告
不包括架构项目分配资源
批准企业内各个组织建议的战略业务规划
架构合规性
架构合规审查：对项目技术的准备状态做沟通
架构目标相对于已建立的架构标准和业务目标的一致性
架构项目相对于已建立的标准和业务目标的审查
目的
识别架构项目的错误
确保最佳实践的应用
确定项目技术就绪状态
识别架构标准需要更改的地方
不包括
识别架构项目的业务转型风险
步骤
审查范围定义
裁剪审核列表来满足业务需求
架构合规评估：在实施流程中治理架构
架构合同
架构契约
在架构组织和实施组织间建立联系
架构治理
架构治理框架
所定义的架构流程和架构责任矩阵的一个特定视图
一个方法来确保组织架构的有效性
治理的模型，包括流程、内容、背景（上下文）和储藏库
在整个企业范围的层级下管理和控制企业架构及其他架构所借助的实践和方向
是企业架构在企业级别管理和控制的实践
架构治理制品储存在架构储藏库
技能框架
第二部分：ADM（架构开发方法） 第三部分：ADM指引和技术
第三部分提供了很多技术，比如开发原则和差距分析来支持架构开发方法 第三部分提供了一组资源，可以用来适应和更改架构开发方法
概念：迭代、视图、处理业务需求
两大指引
架构分割
广度
深度
时间段
架构领域
迭代
整体
阶段
单个
9大技术
引言
ADM概述
ADM是开发组织特定企业架构的流程
ADM、企业连续系列和架构库
ADM可以被视为把企业连续系列更通用方面相关可重用的构建块传播到企业自身架构储藏库的过程。
架构开发方法ADM产生内容并存储在储藏库，并由企业连续系列分类。
ADM与基础架构
ADM指南与技术
ADM周期（架构开发周期）
输入输出交付物
建议，非完全遵循
后续阶段可能会修改先前阶段的输出
输出使用版本号进行管理
0.1基础版
架构愿景
架构的高层级概要己形成
1.0签字版
架构定义文件
经正式审查的详细架构
架构开发方法版本输出编码制只是例子，而不是强制的，是为了显示交付物的演进
调整ADM
ADM是用于架构开发的通用方法，旨在满足大多数系统和组织要求。但是，经常需要修改或扩展ADM以适合特定需求。
例子
如果做架构的业务案例根本没有得到很好的认可，那么创建架构愿景几乎总是必不可少的。
业务原则可能指示企业准备调整其业务流程以满足打包解决方案的需求，以便可以迅速实施该业务以快速响应市场变化，在这种情况下，业务架构(或至少是IT的完成)很可能紧随信息系统架构或技术架构的完成。
企业可能希望将 TOGAF框架及其通用 ADM与Zachman框架结合使用，或者使用另一个企业架构框架，该框架具有特定于特定垂直部门的一组可交付成果：政府、国防、电子业务、电信等等。
架构治理
界定架构范围
ADM周期各阶段
预备阶段P
架构能力
描述了创建架构能力所需的准备和启动活动，包括定制 TOGAF 框架和定义架构原则
预备阶段是关于在相关企业中定义“在哪里、是什么、为什么、谁及如何进行架构”
目标
建立企业的架构能力
目标是选择和实施工具
定义要用到的框架和方法
定义管理框架之间的关系
定义企业
评估企业架构成熟度
定义架构原则
除了
识别利益相关者和他们的关注
定义架构足迹
输出：架构工作请求
通常由赞助者发起一个架构工作请求
赞助者组织会发送架构工作请求到架构组织来触发ADM迭代的开始
架构工作请求是发起组织发送到架构组织的文档
业务规定
在为企业架构工作设立范围时驱动了需求和指标
用架构能力框架
确定组织所需的架构能力
建立架构能力
建立组织背景（定义企业），定制TOGAF，选择工具，定义架构原则
定义并建立企业架构的组织模型
建立企业背景：审视组织上下文
企业组织范围和元素
驱动力元素
规定了企业架构范围
架构范围说明书，哪些做哪些不做，以业务为中心
业务需求是唯一衡量
广度、深度、时间、架构领域
满足业务特定需要
定义并建立用于架构治理的详细流程和资源
定制TOGAF（裁剪TOGAF分类）
定义架构治理的流程资源
建立实现目标能力的成熟度
框架之间的关系
定义架构的组织模型
选择和应用支持体系架构能力的工具
定义架构原则
技术1：架构原则
架构原则是建立/制造架构、规划决定；构建政策，流程和标准；以及支持对立情况问题解决的基础
架构原则用来指引企业内的决定
架构原则定义是企业架构开发的基础
架构原则定义了通用规则和指引来使用整个企业的资产
基于业务原则，包含业务原则、技术原则、应用原则、数据原则
原则不是具体的行动指南，是方针、理念和价值定位
原则不是强制，是引导和控制，另整个企业反对强制。
定义原则模板
名称Name：描述规则的本质，不提技术平台
陈述statement（声明）：应简明而明确地传达基本规则
理由Rationale（基本原理）：强调坚持原则带来的业务效益（价值收益）
含义Implications（所涉问题）：应该突出业务和 IT方面的需求，以实现原则 一 一 在资源、成本和活动/任务方面。
着重指出执行原则的需求
回答“如何影响到我”
预备阶段P
原则质量：可以理解、稳健、完整、一致、稳定
A架构愿景
战略架构
战略规划
描述了架构开发周期的初始阶段。它包括定义架构开发计划的范围、确定利益相关者、创建架构愿景、以及获得批准以继续进行架构开发的信息
是架构开发周期的第一个阶段，来识别和定义利益相关者的范围
架构愿景为发起人提供了一个关键工具，向企业内的利益相关方和决策者推销拟议能力的好处。
阶段A从接收到发起（赞助）组织的架构工作请求开始
ADM由架构工作请求开启
赞助者组织发送架构工作请求文档触发ADM迭代的开始
目标
目标：确认业务原则，目标，驱动和关键性能指标
目标：确保架构愿景正式批准来往下走
目标：识别利益相关者和他们的关注
目的：提供了最终架构项目的概要方向性的视图
目标：架构愿景阶段获得架构工作说明书的批准
范围、约束、期望，架构愿景、识别和定义利益相关者范围、验证业务场景
架构工作说明书
目的：定义了完成架构工作的范围和方法
合同、全面计划书、以识别问题的解决方案和流程
架构愿景：高层视图、预期结果共识、完整架构定义
内容
架构愿景文档
描述新能力如何满足业务、战略目标
描述新能力如何满足利益相关者关注
架构愿景文档是对基线和目标架构的概要描述
约束
以预备阶段业务原则和架构原则为依据
定义利益相关者
如何应对利益相关者关注点
范围
业务、数据、技术、应用（领域）
大致描述：开发周期、KPI、原则
业务场景（技术）
目的：帮助识别和理解架构必须满足的业务需求
发现记录定义需求表达
表述响应需求的愿景的合适有用技术
AB迭代
SMART准则
业务场景技术可用来开发架构愿景
在A架构愿景阶段最普遍使用
目标：制成架构愿景
步骤
■建立架构项目(见第6.3.1节)
■确定利益攸关者、关注点和业务需求(见第6.3.2节)
■确认和详细阐述业务目标、业务驱动因素和约束条件(见第6.3.3节)
■评估能力(见第6.3.4节)
■评估业务转型的准备情况(见第6.3.5节)
■定义范围(见第6.3.6节)
■确认和阐述架构原则，包括业务原则(见第6.3.7节)
■开发架构愿景(见第6.3.8节)
■定义目标架构的价值主张和KPI(见第6.3.9节)
■确定业务转型风险和缓解活动(见第6.3.10节)
■开发架构工作说明书；获得批准(见第6.3.11节)
B业务架构
领域架构
描述架构实践的组织结构
描述了业务架构的开发，以支持被认可的架构愿景
业务架构被推荐为最先开发的架构的原因：提供预先需要知道的知识来进行其他架构领域的工作
目的
为关键利益相关者选择相关视点
开发基线业务架构描述
在没有架构或很少架构资产情况下开发基线业务架构的通常做法：自下而上
开发目标业务架构描述
描述企业需要如何运营以实现业务目标，并以解决架构工作说明书和利益相关方关注的方式响应架构愿景中规定的战略驱动因素
根据基线和目标业务架构之间的差距确定候选架构路线图组件
业务目标
WHAT
展示利益相关者关注如何在业务架构中满足
SMART目标管理法KPI
业务战略
业务战略定义了成功的目标和驱动因素及度量标准
实现目标中的战略行动项目
VP
业务能力
价值流
业务架构
组织建模
信息建模
最基本的参考模型：III-RM
第一步：选择参考模型，视点和工 具
最后一步：生成架构定义文档
C信息架构
领域架构
描述了信息系统架构的开发，以支持被认可的架构愿景
应用架构和数据架构开发没有先后次序
应用架构
数据架构
目的
定义可被利益相关者理解的架构
定义完整并持续输出的架构
定义稳定的架构
定义企业相关数据实体
方法
业务架构
数据（或应用）架构
应用（或数据）架构
技术架构
与阶段C应用架构最相关的模型：集成信息基础设施参考模型III-RM
第一步：选择参考模型，视点和工 具
最后一步：生成架构定义文档
D技术架构
领域架构
描述了技术架构的开发，以支持被认可的架构愿景
描述了逻辑上的软件和硬件能力
定义基础设施需求
关键目标：定义技术组件到一组技术平台
技术参考模型TRM
与组织的行业相通用的技术模型是阶段D相关架构资源
第一步：选择参考模型，视点和工 具
最后一步：生成架构定义文档
开发基线架构和目标架构，分析差距
架构定义文档（ADD）
可交付容器
跨架构领域
检查基线、过渡、目标状态
一个定性的解决方案视图，表达架构师意图，沟通架构师的目的
因为它更多地关注架构的“什么”（What）和“为什么”（Why）
为沟通架构师目的的描述
架构需求规格书（ARS）
一个定量的解决方案视图来衡量实施
必须满足的度量标准
因为它关注架构的“如何”（How）和“多少”（How much）
分段内容
内容
A
开发目标业务架构
企业如何运作达到业务目标
如何响应架构愿景中的驱动力
解决利益相关者关注点
基于基线与目标的差距识别架构路线图组件
B
数据治理
数据管理
数据迁移
应用组合管理
单一应用架构
软件架构
D
满足架构请求书和利益相关者
E 机会和解决方案
解决方案架构（整合）
进行初步实施规划，并为在之前阶段中定义的架构进行交付载体的识别
第一个直接关注实施目标架构规划的阶段
实施规划
鉴定构建块
构建块变成实施特定
增量，对过渡架构进行识别
解决方案架构、整合BCD结果、输出完整架构
综合了先前阶段的差距分析结果
内容
基于基线目标差距分析和候选路线图组件
生成架构路线图完整版
显示从基线架构到目标架构的变革进度
是否需要增量
需要识别可以持续交代商业价值的过渡架构
以便有效交付前阶段制定的目标架构
将构建块变为工作包（工具包）来满足差距
步骤
确定/确认主要的公司变革属性
确定实施的业务限制
审查和合并阶段B至阶段D的差距分析结果
审查所有相关业务功能的合并需求
合并和协调互操作性要求
完善和验证依存关系
确认业务转型的准备情况和风险
评审
制订实施和迁移策略
查明主要工作包并对其进行分组
确定过渡架构
创建架构路线图和实施及迁移计划
F迁移规划
通过最后确定详细的实施和迁移计划，解决如何从基线过渡到目标架构的问题
阐述如何从基线达成目标
目标
使实施和迁移规划和其他框架合作
确保实施和迁移计划与企业管理和实施企业总体变更组合中的变更的方法相协调
实现企业级变革
最终化架构愿景、架构定义文档、架构需求规范、架构路线图，来与已同意的实施方法取得一致
架构定义文档：作为项目制品交付物的储藏容器
目的：为沟通架构师目的的描述
最后确定架构路线图和支持实施和迁移计划
确保关键利益相关方理解工作包和过渡架构的业务价值和成本
对工作包、项目和构建块的排定优先级
不包括
创建，演进和监控详细的实施和迁移
步骤
确认实施和迁移计划的管理框架交互
为每个工作包分配业务价值
估算资源需求、项目时间和可用性/交付工具
通过进行成本/效益评估和风险验证，对迁移项目进行优先级排序
确认架构路线图并更新架构定义文档
完成实施和迁移计划
完成架构开发周期并记录所吸取的经验教训
计划
解决方案落地计划
开始实施迁移规划E，完成规划是F
阶段E提供了一个不完整的架构路线图和实施和迁移计划，以解决架构工作的声明。在阶段 F,该路线图和实施和迁移计划与企业的其他变更活动相结合
最终化一套过渡架构来支持实施
G实施治理
实施监督
为实施提供架构的监管
目的
为解决方案和任何实施驱动的架构变更请求实施适当的架构治理功能
确保实施的项目与定义好的架构合规
通过实施项目确保与目标架构的一致性
确保对目标架构的合规
ADM流程需要治理的原因是使得方法能够被正确的使用
实施治理只是架构治理的一个方面，包括对企业架构和企业之内的其他架构的开发和演进的所有方面进行的管理和控制
实施、监管
在实施架构时，如果原来的架构定义和需求不合适，一个变更请求可以被提交来发起进一步的架构工作
架构合同
架构契约
通过架构合同建立架构组织和实施组织之间的联系
关注于架构合同的治理和管理来覆盖总体实施流程
开发方和赞助者在架构交付物上的联系
实施确保单个项目（PMP）与企业架构一致
文件应该包括从业务转型准备评估技术所带来的行动
步骤
与开发管理部门确认部署的范围和优先级
确定部署资源和技能
制定解决方案部署指南
进行企业架构合规性审
实施业务和IT运营
实施后审查并结束实施工作
H变更管理
建立了管理新架构变更的程序
目标
确保架构达到它原来的目标业务价值
检测业务成长或下降来检查过去周期交付架构的适当使用
建立准则以判断变更要求是否有更新的必要或是否有开始新周期的必要
负责评估架构性能并提出变更建议
持续监管
变更管理流程
快速响应、架构对业务的价值最大化
简化变更
简化变更可以由变更管理技术处理
多个服务器系统整合成单独一个情况下，简化变更可以由变更管理技术处理
对架构的简化改变往往是由减少投资的要求所驱动的
简化变更分类（Simplification Change）：由减少投资驱动的变更
增量变更
增量变化可以通过变化管理技术来处理，或者可能需要根据变化的性质进行部分重新设计
增量变化的驱动因素是对从现有投资中获得额外价值的要求
由从现有投资得到新价值的需求的变更
重新架构变更
重新架构变更要求将整个架构再次置于架构开发周期中
需要增加投资才能为开发创造新的价值， 这就是重新设计变更的驱动力
重新架构变更分类（Re-architecting Change）：由新加入投资产生新价值的需求驱动的变更
R需求管理
审查整个ADM 中管理架构需求的过程
管理需求流
它被用来在整个ADM周期循环管理架构需求
存储需求并管理需求流在所有ADM相关阶段
验证每一阶段的业务需求
需求被识别、输入、存储，再输出到个阶段
需求优先级排列、处理、阐述
架构需求规格书（文件）
考点难点
视点、视图、关注
定义架构原则模板
技术9:基于能力的规划
原则、方法
聚焦业务成果的业务规划技术
业务驱动和业务导向的
业务线整合以达到企业期望能力
专注于达到业务产出而不是技术交付物
从企业架构和IT角度来看，能力导向规划是确保战略业务计划从自上而下推动企业开发的强大机制
技术8:风险管理
应考虑两个风险级别（水平）
1.初始风险级别（水平）：在确定和实施缓解措施之前进行风险分类
2.残留风险级别（水平）：实施缓解措施后的风险分类（如果有）
风险管理过程
风险分类
风险识别
初始风险评估
风险缓减和剩余风险评估
一旦初始风险得到缓解，那么剩余的风险就称为“剩余风险”。
风险监控
各企业架构活动风险无处不在，应该在ADM的所有阶段进行管理
最终可交付成果
转换风险评估（一个工作表）
1.初始风险评估结果：影响、频率、缓解措施
2.残留风险评估结果：影响、频率
技术7:业务转型就绪状态评估
业务转型就绪评估是架构师与企业领导沟通，企业是否接受能力建设与能力增量
关注：确定该组织是否已准备好接受变更
在A阶段采用业务转型就绪状态评估技术，评估组织经历变 革的状态
使得转型相关的风险被识别和减轻
技术6:互操作需求
共享信息和互操作的能力
A:业务场景确定信息和服务交换的性质和安全考虑
B:业务语言定义信息和服务交换
C:用数据模型和信息交换模型细化信息交换内容
D:指定应用之间共享信息和服务的方式
E:指定信息和服务交换的技术机制
F:选取实际解决方案
G:从逻辑上实施互操作性
技术5:迁移规划技术
实施因素评估和推论矩阵
合并的差距、解决方案和依赖关系矩阵
架构定义增量表
创建架构定义增量表的技术允许架构师在指定的时间规划一系列过渡架构，概述企业架构的状态
企业架构状态演进表
业务价值评估技术
应该被用来确定企业价值和转型的相关风险
E,F
技术4:差距分析
目的：着重指出基线和目标架构间的缺陷
目的：识别潜在不足或功能重叠、识别遗漏的功能
识别基线与目标之间的：差异、故意忽略、意外遗漏、尚未定义
不包括识别潜在供应商来提供新构建块
基有目没有：解决方案
目有基没有：新建能力
B,C,D,E
一个阶段的最后一步，用来突出还未开发的服务
技术3:架构模式
架构模式
构建块组合在一起形成上下文的方式
一个方法把构建块放到背景中
架构风格
基线、目标
A.B.C.D
技术2:利益相关者管理
识别利益相关者，保证输入纳入架构设计
循序渐进的方法
识别利益相关者
职位归类
确定管理办法
裁剪工作交付物
视点、验证
定义企业架构视点、矩阵、视图
输出
利益相关者映射模板
利益相关者对系统有关键角色或者关注
识别视点满足利益相关者的关注
视点是一个可重用制品，用来创建架构模型来满足利益相关者的关注
架构视点、架构视图、利益相关者关注、利益相关者需求之间的关系
利益相关者的需求驱动了架构视图的创建
架构视图反映了架构观点
架构视点帮助解决利益相关者的关注
利益相关者的需求和关注影响架构视点的确定
架构视图作为沟通工具，帮助利益相关者理解架构视点
架构视点指导架构视图的详细设计
利益相关者的关注促使架构师考虑架构视图的多个方面
架构视图和架构视点共同支持对利益相关者的需求的响应
个人、团队、组织
关键角色
关注企业架构的人员
5大分类22项目
CXO
企业安全
项目管理办公室
标准组织
采购
HR
公司职能
行政领导
部门管理层
业务领域专家
业务流程专家
产品流程专家
技术专家
项目组组织
数据拥有者
最终用户组织
IT服务管理
服务台
应用管理
基础设施管理
数据通信
系统运营组织
供应商
监管机构
外部组织