章节概要

第 1 章介绍了 TOGAF的关键概念，企业架构和 TOGAF 内容的高级视图。
第 2 章介绍了架构开发方法（Architecture Development Method），ADM 是TOGAF提供的用来开发企业架构的方法。
第 3 章总体介绍了与 ADM 过程相关的各种关键技术和交付物。
第 4 章总体介绍了对 ADM 过程进行调整的一些指导策略。
第 5 章介绍了架构内容框架，即架构制品的一个结构化元模型。
第 6 章介绍了企业连续系列，即可以和 ADM 一起使用的，用来开发企业架构的一个高级别概念。
第 7 章介绍了架构能力框架，即为建立和运营企业中的架构职能所需的一系列资源。

重要概念

分区：关于如何划分企业中的各种架构的一些技术和注意事项
架构存储库：架构存储库的逻辑信息模型，可用作执行 ADM 所创建的所有输出的集成存储
能力框架：组织、技能、角色和职责的结构化定义，以运行有效的企业
架构能力：TOGAF 标准还提供了一个过程的指导，可以遵循该过程来确定和建立适当的架构能力

第一章企业架构概念

1.文档结构

TOGAF 是一个企业架构框架，是一种标准方法，用于协助接受、生产、使用和维护企业架构。它基于最佳实践所支持的迭代过程模型和现有架构资产的可重用集。
TOGAF标准可用于开发各种不同领域的企业架构。 TOGAF对其他框架进行了补充并可与其他框架一起使用，其他这些框架更侧重于特定垂直领域的特定交付物。TOGAF 标准的关键部分是用于开发可满足业务需求的企业架构的方法，以便开发出符合各类业务需求的企业架构。

2.标准介绍

介绍	定义
架构开发方法	这部分是TOGAF框架的核心。它描述了TOGAF架构开发方法（ADM）是一种逐步开发企业架构的方法。
ADM指南和技术	本部分包含可用于应用TOGAF方法和ADM的指南和技术的集合。其他指南和技术也位于TOGAF库中。
架构内容框架	本部分介绍TOGAF内容框架，包括架构工件的结构化元模型，可重用架构构建块（ ABB）的使用以及典型架构可交付成果的概述。
企业连续性和工具	本部分讨论适当的分类和工具，以对企业内架构活动的输出进行分类和存储。
架构能力框架	本部分讨论了在企业内建立和运行架构实践所需的组织，流程，技能，角色和职责。

3.库的结构

介绍	内容
基础性文件	与TOGAF框架或企业架构主题相关的广泛适用的信息。
通用准则与技术	描述架构风格以及如何调整TOGAF框架和企业架构以利用特定环境的特征的信息。
行业特定的指导和技术	描述如何应用TOGAF框架和企业架构以满足垂直行业细分市场特定需求的信息。
组织特定的指导与技巧	描述如何应用TOGAF框架和企业架构以满足特定企业需求的信息。

4.什么是TOGAF标准中的架构？

一个系统在其环境中的基本概念或属性体现在它的元素、元素之间的关系以及它的设计进化的原则中。
组件的结构、它们之间的相互关系，以及关于组件设计和随时间演变的原则和指南。

5.TOGAF标准处理哪种架构

内容	介绍
业务架构	业务策略，治理，组织和关键业务流程。
数据架构	组织的逻辑和物理数据资产以及数据管理资源的结构。
应用架构	待部署的各个应用程序，它们之间的交互以及与组织核心业务流程的关系的蓝图。
技术架构	支持业务，数据和应用程序服务部署所需的逻辑软件和硬件功准。

6. TOGAF标准包含什么

概览：TOGAF 框架的核心是架构开发方法(在标准的第二部分中有记录)。架构能力操作该方法。该方法由一些指南和技术支持。
这将生成存储在存储库中的内容，这些内容根据企业连续统一体进行分类。存储库最初可以使用 TOGAF 参考模型和其他参考材料填充（在 TOGAF 库中记录）。

架构开发方法(ADM)：描述了如何派生出解决业务需求的特定于组织的企业架构。 ADM是TOGAF 框架的主要组成部分，在多个层次上为架构师提供指导：
ADM 指南和技术：提供了一些指南和技术，以支持 ADM 的应用。这些准则包括调整 ADM 以处理一些使用场景，包括不同的流程风格——迭代的使用，以及在整个架构景观中应用 ADM。本文还对如何使用具有不同架构风格的 TOGAF 框架使用 SOA 作为示例进行了高级描述。这些技术支持 ADM 中的具体任务（例如基于能力的规划、定义原则、差距分析、迁移规划、风险管理、利益攸关方管理等）。在 TOGAF 库（例如，关于业务场景技术的指导）中还提供了更多的指南和技术。
架构内容框架：提供了架构工作产品的详细模型，包括可交付成果、可交付成果中的构件以及构件所代表的架构构建块（ ABBs）。
企业连续统一体：提供了一个构建虚拟存储库的模型，并提供了对架构和解决方案工件进行分类的方法，展示了不同类型工件如何演化，以及它们如何被利用和重用。这是基于架构和解决方案（模型、模式、架构描述等）。存在于企业内部和整个行业中的，企业收集来用于其架构开发的。
架构能力框架：是一组资源、指南、模板、背景信息等,提供帮助架构师在组织中建立架构实践。

第二章架构开发方法ADM

ADM基本概念

1.什么是ADM

一个可靠的、经过验证的企业架构开发和使用方法
在不同层次（业务、应用程序、数据、技术）上开发架构的方法，使架构师能够确保一个复杂的需求集得到充分满足
一套架构开发的指导方针和技术

ADM阶段图解

ADM 由一些阶段组成，这些阶段贯穿于一系列架构域，使架构师能够确保一个复杂的需求集得到充分满足
下面让我们来看看他的几个阶段

ADM的几个阶段

名称	内容
预备阶段	为组织成功地作好TOGAF架构项目做好准备。进行`创建架构能力所需的准备和启动活动，包括定制TOGAF框架，选择工具以及定义架构原则。`
需求管理	TOGAF项目的每个阶段都`基于并验证业务需求。识别，存储需求`，并将其输入和输出相关的ADM阶段，这些阶段将处理，解决需求并确定其优先级。
阶段A:架构愿景	设置TOGAF项目的范围，约束和期望。 `创建架构愿景。确定利益相关者。验证业务环境并创建架构工作声明并获得批准。`
阶段B 业务架构阶段C:信息系统架构(应用/数据) 阶段D:技术架构	开发架构在如下4个域中：`B业务,C1信息系统应用,C2信息系统数据,D技术架构`对于每次开发案例，都是开发基线架构和目标架构
阶段E:机会与解决方案	进行初步的实施规划，并确定之前阶段中识别出的构建块交付载体，确认主要的实施项目，是否需要增量方法，如果需要增量，组成各过渡架构。
阶段F:迁移计划	制定制详细的实施和迁移计划，以解决如何从`基准迁移到目标架构`的问题
阶段G:实施治理	提供实施的`架构监督`,准备并签发`建筑合同`,确保实施项目`符合架构`
阶段H:架构变更管理	架构变更管理提供持续的`监视和变更管理过程`，以确保架构能够`响应企业的需求`，以使架构对业务`提供最大化的价值`

ADM阶段关键技术详解

预备阶段为组织成功实施企业架构项目做好了准备。

主要涉及架构项目的建立，它启动了架构开发周期的新一轮迭代，设定了本次迭代的范围、约束和预期结果。为了能够`验证业务背景`、`创建架构工作说明书并获得批准`，这个阶段是必不可少的。本阶段的概述

是关于业务架构的开发；业务能力，端到端价值交付，信息和组织结构的整体表示，以及与战略，产品，政策，`计划和利益相关者的关系`。

记录组织IT系统的基本组织形式，体现在关键的信息和处理它们的应用系统中。`它涉及数据和应用架构，可以按顺序或同时开发。`

要记录IT系统的基本组织，体现在硬件、软件和通信技术中。

`确定交付工具`的过程，这些工具交付了先前阶段中确定的目标架构。

通过`完成详细的实施和迁移计划`，如何`从基准架构过渡到目标架构`。

定义架构如何约束实施项目，在构建项目时`对其进行监视并生成已签署的架构合同`。

确保`对架构的更改以受控方式进行管理`。

管理架构要求的过程适用于ADM周期的所有阶段。需求管理过程是一个动态过程，该过程`解决了企业需求的标识，存储需求，然后将其输入和输出相关的ADM 阶段`。

ADM 定义了开发组织范围内的企业架构所涉及的各个阶段和步骤的推荐序列。

组织架构团队的组织权威
在架构内有待解决的目标和利益相关者的关注点
人力资源、资金和其他资源的可用性

第三章 ADM周期的32个关键技术和成果

1.定制的架构框架

定制的架构框架需要在多个级别进行裁剪，并且应该在初步阶段进行.首先，有必要调整 TOGAF 模型以整合到企业中。这种剪裁将包括与项目和流程管理框架的整合，术语的定制，演示风格的开发，架构工具的选择，配置和部署等。所采用的任何框架的形式和细节也应与其他背景因素如企业文化，利益相关者，企业架构的商业模式，以及现有的架构能力水平,下列为典型应用
量身定制的架构方法
量身定制的架构内容（交付件和工件）
配置和部署的工具
与治理模型和其他框架的接口

2.企业架构的组织模型

初步阶段产生的重要交付成果是企业架构的组织模型。
为了成功地使用架构框架，它必须得到企业中正确的组织，角色和职责的支持。特别重要的是定义不同企业架构从业者与跨越这些边界的治理关系之间的界限。
企业架构组织模型的典型内容是
受影响组织的范围
成熟度评估，差距和解决方法
架构团队的角色和责任
架构工作的限制
预算要求
治理和支持战略

3.架构原则

架构原则：通常由企业架构师与关键利益相关者共同制定，并由架构委员会批准。通常会影响架构原理的发展：
a.企业任务和计划–企业的任务，计划和组织基础结构。
b.企业战略计划–企业的特征优势，劣势，机会和威胁,及其当前的整个企业范围的计划（例如流程改进和质量管理）。
c.外部制约因素–市场因素（上市时间的必要性，客户期望等）；现有和潜在的立法。
d.当前的系统和技术–企业内部部署的一组信息资源，包括系统文档，设备清单，网络配置图，策略和过程。
e.计算机行业趋势–对计算机和通信技术的使用，可用性和成本的预测，取自可靠来源以及当前正在使用的相关最佳实践。
定义架构原则：根据组织不同，可在不同的领域和不同的级别建立原则。架构的开发和利用有两个关键领域：
a.企业原则为整个企业的决策提供了依据，并指示组织如何履行其使命。此类原则通常用作协调决策的手段。它们是成功的架构治理策略的关键要素。在企业原则的广泛领域中，通常在业务或组织单位中拥有辅助原则；例如 IT，人力资源，国内运营或海外运营。
b.架构原则是与架构工作相关的一组原则,它们反映了整个企业的共识，体现了企业架构的精神。架构原则支配着架构过程，从而影响企业架构的开发，维护和使用。
应用架构原则:用于捕获有关企业将如何使用和部署 IT 资源和资产的基本事实。原理以多种不同方式使用：
1.提供一个框架，企业可以在其中开始对企业架构和实施目标企业架构的项目做出有
意识的决策
作为建立相关评估标准的指南，从而在管理企业架构遵从性的后期阶段对产品，解决方案或解决方案架构的选择产生重大影响
作为定义架构功能需求的驱动程序
作为评估现有实施和未来战略组合的投入，以确保符合已定义的架构；这些评估将提供对实现架构所需的过渡活动的宝贵见解，以支持业务目标和优先级
基本原理声明强调了架构对企业的价值，因此为证明架构活动合理性提供了基础
影响声明概述了遵循该原则对企业的关键任务，资源和潜在成本；他们还为未来的过渡计划和规划活动提供了宝贵的意见
在以下方面支持架构治理活动：
在允许或需要某种解释的情况下，为标准架构符合性评估提供“支持”
支持无法在本地操作程序中解决特定架构修正案影响的情况下发起分配请求的决定。

标准	描述
易懂	整个组织中的个人可以快速理解和理解原则的基本原理。该原则的意图是明确和明确的，因此，无论是有意还是无意的违规行为都应最小化。
坚固性	原则应使有关架构和计划的高质量决策得以制定，并应制定可实施的政策和标准。每个原则应足够明确和精确，以支持在复杂且可能引起争议的情况下的一致决策。
完整性	定义了管理组织信息和技术管理的每个潜在重要原则。原则涵盖了所感知到的所有情况。
一致性	严格遵守一个原则可能需要对另一个原则进行宽松的解释。原则的表达方式必须允许各种解释之间的平衡。原则不应与坚持一项原则会违反另一项原则的精神相抵触。原则陈述中的每个单词都应谨慎选择，以允许一致而灵活的解释。
稳定性	原则应该持久，还能够适应变化。最初批准原则后，应建立修订程序以添加，删除或更改原则。

4.业务原则，业务目标，和业务驱动

作为初步阶段的输出重新进行重新审视，并作为A阶段企业架构展望的一部分再次审查。阶段 A 的活动是确保当前的定义是正确和清晰的。
该交付项目没有明确的内容，因为其内容和结构可能因组织而异。

5.架构库

该存储库允许项目管理交付成果，找到可重复使用的资产，并将结果发布给利益相关方和其他相关方
典型内容为：架构框架、标准信息库、架构景观、参考架构、治理日志、架构需求、解决方案景观

6.架构工具和技术

作为初步阶段的一部分，架构师应该选择和实施支持架构活动的工具。TOGAF 不需要或推荐任何特定的工具。

7.架构工作请求

这是从发起组织发送到架构组织的文档，以触发架构开发周期开始。它是在架构组织的协助下生成的，作为初步阶段的输出。架构工作申请也将根据批准的架构变更请求或源自迁移计划的架构工作的职权范围而创建。
包含以下高级别的内容
组织赞助商
组织的使命陈述
业务目标（和变化）
业务的战略计划
时间限制
商业环境的变化
组织约束
预算信息，财务约束
外部约束，商业约束
当前业务系统描述
当前架构/ IT 系统描发展中组织的描述

8.架构工作声名

架构工作声明是作为阶段A的可交付成果创建的，实际上是架构项目的架构组织和发起人之间的契约。本文件是对企业架构工作请求输入文件的答复（参见第 3.6 节）。它应该描述解决工作要求的总体计划，并提出如何通过架构过程解决已确定的问题的解决方案。
本文件的建议内容如下：
标题
企业架构项目请求和背景
企业架构项目描述和范围
架构愿景概述
范围程序的具体变更
角色，责任和交付成果
接受标准和程序
企业架构项目计划和时间表
批准

9.架构愿景

架构愿景是在阶段A创建的，并提供了对成功部署目标架构后将遵循的企业变更的高级总结。这个愿景的目的是从一开始就同意架构的理想结果，以便架构师能够关注验证可行性所需的细节。提供架构愿景还通过提供完整架构定义的摘要版本来支持利益相关方沟通。
业务场景是一种适当且重要的技术，可用作开发架构愿景文档过程的一部分。
本文件的建议内容如下：
问题描述：
利益相关者及其关切
待处理的问题/情景列表
架构工作声明的目标
架构工作请求和高级业务，应用程序，数据和技术架构所需的摘要视图
映射的需求
参考草案架构定义文件

10.利益关系人管理

利益相关者管理是成功的架构师可以用来赢得他人支持的重要学科。它帮助他们确保他们的项目在别人失败的情况下取得成功在阶段A中应该使用该技术来确定参与中的关键参与者，并且还要在每个阶段进行更新。这个过程的输出形成了沟通计划的开始（参见第 3.11
节)
成功的利益相关者管理的好处是:
a.最强大的利益相关者可以尽早确定，然后可以使用他们的投入来塑造架构; 这确保了他们的支持，并提高了生产模型的质量。
b.来自更强大的利益相关者的支持将有助于参与赢得更多资源; 从而使架构参与更有可能取得成功。
c.通过早期和频繁地与利益相关者进行沟通，架构团队可以确保他们充分理解架构流程以及企业架构的优势; 这意味着他们可以在必要时更积极地支持架构团队。
d.架构团队可以更有效地预测架构模型和报告可能产生的反应，并可以在计划中构建采取积极反应所需的操作，同时避免或解决任何负面反应。
e.架构团队可以及早识别利益相关者之间的冲突或竞争目标，并制定解决这些问题的策略。
利益相关方管理流程中的步骤:确定谁是主要的企业架构利益相关者,分为五大类
利益相关方立场分类:深入了解最重要的利益相关方，并记录此分析（如表中的示例所示），以供项目期间参考和刷新。
确定利益相关方的立场:通过这一步骤，团队可以轻松查看哪些利益相关方有望成为阻挠者或评论者，哪些利益相关者可能成为倡议的倡导者和支持者。
裁剪工作的交付物:确定架构参与需要产生的目录，矩阵和图表，并与每个利益相关方群组进行验证，以提供有效的架构模型。通过定义与特定企业架构模型相关的特定目录，矩阵和图表，特别关注利益相关者的兴趣非常重要。这使得架构能够传达给所有利益相关者并且被所有利益相关者理解，并且使他们能够验证企业架构计划将解决他们的担忧。

11.沟通计划

企业架构包含大量复杂且相互依赖的信息。有针对性的信息在正确的时间有效地传达给合适的利益相关者是企业架构的关键成功因素。在A阶段开发架构通信计划允许在计划和管理过程中执行此通信。
沟通计划的典型内容是：
a.通过沟通要求确定利益相关者和分组
b.识别通信需求，与架构愿景相关的关键信息，通信风险和关键成功因素（CSF）
c.确定将用于与利益相关者沟通并允许访问会议，通讯，存储库等架构信息的机制。
d.确定沟通时间表，说明哪些利益相关者群体会在何时何地与哪些利益群体进行沟通

12.业务转型准备评估

业务转型就绪评估技术在A阶段进行，用于评估和量化组织准备进行变革。了解组织接受变化，识别问题，然后处理这些问题的准备情况是成功架构转型的关键部分。该评估建议
是企业员工，业务部门和IT 规划人员的共同努力
推荐的活动是：
a.确定将影响组织的准备因素
b.使用成熟度模型呈现准备就绪因素
c.评估每个准备就绪因素的风险并确定改进措施以降低风险
d.将结果记录在能力评估中（见第 3.13 节），然后将这些行动纳入实施和迁移

13.能力评估

在着手详细的架构定义之前，了解企业的基准和目标能力水平是很有价值的。这项能力评估首先在A阶段进行，并在E阶段更新。可以在几个层面进行检查：
a.整个企业的能力水平如何？企业希望增加或优化能力在哪里？什么是支持企业理想发展的架构重点领域？
b.企业中 IT 功能的功能或成熟度级别是什么？根据设计治理，运营管理，技能和组织结构进行架构项目可能会产生什么影响？什么是符合 IT 组织文化和能力的架构项目的适当风格，正式程度和详细程度？
c.企业内部架构功能的功能和成熟度如何？目前存在哪些企业架构资产？他们是否保持准确？需要考虑哪些标准和参考模型？在架构项目期间是否有机会创建可重用资产？
d.在能力差距存在的地方，企业准备好在多大程度上进行转型以实现目标能力？转型的风险，文化障碍以及其他需要考虑的因素是什么？

14.风险管理

业务转型风险和减缓活动的识别首先在阶段A中确定。风险管理记录在TOGAF 第三部分第31章中，是一种用于在实施架构项目时降低风险的技术。它包括一个由以下活动组成的风险管理流程：
a. 风险分类
b. 风险识别
c. 初始风险评估
d. 风险缓解和剩余风险评估
e. 风险监测
建议风险缓解活动应包含在企业架构工程声明

15.架构定义文档

架构定义文档是项目期间创建的核心架构工件的可交付容器，以及重要的相关信息。架构定义文档涵盖所有架构域（业务，数据，应用,技术），并检查架构的所有相关状态（基线，转换和目标)。
它首先在 A 阶段创建，并在其中填充了为支持架构愿景而创建的工件。它在 B 阶段与业务架构相关的材料进行更新，随后在 C 阶段用信息系统架构材料进行更新，然后在阶段 D 用技术架构材料进行更新。如果实施目标架构的变更范围需要增量方法，架构定义文档将被更新以包含 E 阶段的一个或多个过渡架构（见第 3.27 节）。
架构定义文档是架构需求规范的一个配套文件，有一个补充目标：
a.架构定义文档提供了解决方案的定性视图，旨在传达架构师的意图。
b.架构需求规范提供了解决方案的定量视图，阐述了在实施架构期间必须满足的可测量标准。
c.范围
目标和限制
架构原则
d.基线架构
架构模型（针对每个建模）：
业务架构模型
数据架构模型
应用架构模型
技术架构模型
e.架构方法的理由和理由
映射到架构信息库：
映射到架构景观
映射到参考模型
映射到标准
重新使用评估
f.差距分析
g.对影响的评估
h.过渡架构（参见第 3.27 节）

业务架构：在B阶段开发。与业务架构相关的架构定义文档中应解决的主题如下
组织结构:确定业务地点并将其与组织单位相关联
企业目标和目标:针对企业和每个组织单位
业务功能:一个详细的递归步骤，涉及将主要功能区域连续分解为子功能
商业服务:企业和每个企业单位向其客户提供的内部和外部服务
业务流程:包括措施和可交付成果
业务角色:包括技能要求的开发和修改
业务数据模型
组织和职能的相关性 - 以矩阵报告的形式将业务职能与组织单位联系起来
信息系统(数据)架构：在C阶段开发。与信息系统架构相关的架构定义文档中应涉及的主题如下
业务数据模型
逻辑数据模型
数据管理流程模型
数据实体/业务功能矩阵
与选定观点相对应的数据架构视图，解决关键利益相关者关注的问题
技术架构：是D阶段的一部分而开发。与技术架构相关的架构定义文档中应涉及的主题如下
技术组件及其与信息系统的关系
技术平台及其分解，展示了实现特定技术“堆栈”所需的技术组合，
环境和位置:将所需技术分组到计算环境（例如开发，生产）
期望的处理负载和跨技术组件的负载分配
 物理（网络）通信
 硬件和网络规范

16.架构需求规格

架构需求规范提供了一组定量描述，概述了实施项目必须遵守的架构。架构需求规范通常构成实现合同或合同的主要组成部分，以获得更详细的架构定义。架构需求规范是架构定义文档的一个配套，其目的是提供定量的观点。以下内容在架构需求规范中是典型的：
架构要求
商业服务合同
应用服务合同
实施指南
实施规范
执行标准
互操作性要求（见第 3.16.4 节）
IT 服务管理要求
约束
假设
业务架构请求：在 B 阶段填充架构需求规范的业务架构要求包括
a.差距分析结果
b.技术要求:作为阶段 B（业务架构）的输出应产生一组初始技术要求。这些是随后的技术架构工作的驱动因素，应该确定分类和优先考虑剩余的架构域; 例如，依赖性/优先级矩阵（例如，指导交易处理速度与安全性之间的权衡） ; 列出预期产生的具体模型（例如，表示为 Zachman 框架的基元）。
c.更新业务需求
d.业务场景技术用于发现和记录业务需求。
信息架构请求:在 C 阶段充体系的要求包括
a.差距分析结果
b.数据互操作性要求
c.应用程序互操作性要求
d.业务架构可能需要改变以符合数据和/或应用架构变化的领域
e.将要设计的技术架构的限制
f.如果适用，更新业务需求
g.更新应用程序要求（如果适用）
h.更新数据要求（如果适用）
技术架构请求:在阶段 D 中填充架构要求规范的技术架构要求包括
a.差距分析结果
b.更新的技术要求
互操作性请求:互操作性的确定贯穿整个 ADM 周期。该标准的第 III 部分第 25 章提供了一组准则，用于定义和建立互操作性要求。

17.架构路线图

架构路线图列出了将实现目标架构的各个工作包，并将它们放在时间轴上，以显示从基准架构到目标架构的进度。架构路线图强调了每个工作包在每个阶段的业务价值。有效实现目标架构所需的过渡架构被标识为中间步骤。架构路线图是在E和F阶段逐步开发的，并通过B，C和D阶段开发的路线图组件进行开发.
以下内容通常在架构路线图中找到：
a.工作包组合：工作包描述（名称，描述，目标，可交付成果）、功能要求、依赖、与机会的关系,与架构定义文档和架构需求规范的关系、商业价值
b.实施因素评估和扣除矩阵，包括：风险、问题、假设、依赖、行动、影响、合并差距
c.解决方案和依赖性矩阵，其中包括：架构域、差距、潜在的解决方案、依赖
d.过渡架构，如果有的话实施建议：项目有效性的标准/措施、风险和问题、解决方案构建模（SBB）

18.业务场景

ADM 有自己的方法，用于识别和阐明新业务功能中隐含的业务需求，解决关键的业务驱动因素以及隐含的架构需求。这个过程被称为“业务场景”。业务场景是业务问题的描述，它使得需求可以在整个问题的背景下相互关联。没有这样的描述来作为背景，解决问题的商业价值就不清楚了，潜在解决方案的相关性还不清楚，解决方案存在基于不充分的要求的危险。
任何其他重大项目成功的关键因素在于它与业务需求的关联程度，并明确支持并支持企业实现其业务目标。业务场景是帮助识别和了解业务需求的重要技术。该技术可以在商业架构的分层分解中以不同的细节层次迭代使用。通用业务场景流程如下：
a.识别，记录和排列推动项目的问题
b.作为高级架构模型，记录出现问题的业务和技术环境
c.确定并记录期望的目标; 成功处理问题的结果
d.确定人类参与者及其在商业模式中的地位，人类参与者及其角色
e.识别计算机参与者及其在技术模型中的位置，计算元素及其角色
f.确定并记录每个角色成功的角色，责任和措施，每个角色所需的脚本以及
g.正确处理情况的理想结果
h.检查鼓励后续架构工作的适用性，并在必要时进行改

19.差距分析

差距分析的技术：在 ADM 中被广泛用于BCDE阶段验证正在开发的架构的。这通常是一个阶段的最后一步。基本前提是突出基线架构和目标架构之间的差距; 即故意遗漏，意外遗漏或尚未定义的项目。
步骤如下：
a.在垂直轴上绘制一个矩阵，其中包含基线架构的所有架构构件块（ABB），以及横轴上的目标架构的所有 ABB。
b.在 Baseline Architecture 轴上添加标有“New ABBs”的最后一行，并在Target Architecture 轴上添加标注为“Eliminated ABBs”的最后一列。
c.在基线和目标架构中都有 ABB 的情况下，在交叉单元格中记录“包含”。
d.目标架构中缺少基线架构的 ABB，每个都必须进行审查。如果它被正确消除，在适当的“消除”单元格中标记它。如果不是，那么您已经发现了目标架构中的意外遗漏，必须通过在架构设计的下一次迭代中恢复 ABB 来解决 - 在相应的“已删除”单元格中标记它。
e.如果目标架构中的 ABB 无法在基线架构中找到，请在与“新”行的交点处将其标记为需要填充的间隙，或者通过开发或购买构件块。
f.练习完成后，“消除服务”或“新服务”下的任何内容都是一个缺口，应该解释为正确消除，或标记为通过恢复或开发/实现功能来解决

20.架构视点

架构视点:架构师在阶段 A 到阶段 D 期间使用 ADM 周期中的视图和视图来开发每个域（业务，数据，应用程序和技术）的架构。 “看法”就是你所看到的。一个“观点”是你从哪里寻找的地方; 决定你所看到的角度或观点（一个观点也可以被认为是一个模式）。视点是通用的，可以存储在库中供重复使用。视图总是特定于它所创建的架构。每个视图都有一个相关的观点来描述它，至少是隐含的。

讲个小故事：

飞行员对系统有一种看法，空中交通管制员有另一种看法。这两种观点都不代表整个系
统，因为每个利益相关者的观点都会限制（并减少）每个人对整个系统的看法。
驾驶员的视角包括控制器未查看的一些元素，例如乘客和燃料，而控制器的视图包括飞行
员未查看的某些元素，例如其他飞机。这些观点之间也有共同的要素，比如飞行员和管制
员之间的沟通模式，以及飞机本身的重要信息。
视点是包含在视图中的信息的模型（或描述）。在这个例子中，一个观点是飞行员如何看
待系统的描述，另一个观点是控制器如何看待系统。飞行员从他们的角度描述该系统，使
用他们的位置和矢量模型来往跑道或远离跑道。所有飞行员都使用此模型，并且该模型具
有用于捕获信息和填充模型的特定语言。管制员用不同的方式描述系统，使用空域模型和
空域内飞机的位置和矢量。同样，所有控制器都使用从通用模型导出的通用语言来捕获和
传递与其观点相关的信息。
幸运的是，当管制员与飞行员谈话时，他们使用通用的通信语言。（换句话说，代表各自
视点的模型部分相交。）这部分共同语言是关于飞机的位置和矢量，并且对于安全至关重
要。所以实质上，每个观点都是一个抽象模型，说明特定类型的所有利益相关者 - 所有飞行员或所有管制员 - 如何看待机场系统。工具的用户界面通常接近与视点相关的模型和语
言。飞行员独特的工具是燃料，高度，速度和位置指示器。控制器的主要工具是雷达。常
用工具是收音机。
从示例 1 总结，我们可以看到，一个视图可以通过利益相关者的角度来对系统进行子集
化，例如飞行员与控制器。这个子集可以用称为观点的抽象模型来描述，例如空中飞行与
空间模型。该视图描述以部分专用语言记录，例如“飞行员讲话” 与“控制器讲话”。工
具被用来帮助利益相关者，并且它们在从观点出发的语言方面相互交流。当利益相关者使
用通用工具时，例如飞行员和控制器之间的无线电联系，通用语言是必不可少的。

21.架构视图

架构视图是对系统中的一个或多个利益相关者有意义的整体架构的表示。架构师在阶段A到阶段 D 期间选择和开发 ADM 周期中的一系列视图，以使架构能够传达给所有利益相关方，并使其能够理解，并使他们能够验证系统将如何解决关注。 5.3 节中的概念是 TOGAF 中使用架构视图的核心。

选择哪种特定的架构视图是开发人员必须制定的关键决策之一。
架构师有责任确保架构的完整性（适用性），以充分解决利益相关方的所有相关问题; 以及架构的完整性，在将所有各种观点相互联系方面，令人满意地协调不同利益相关者之间的冲突关注，并展示这样做的权衡（例如，在安全和绩效之间）。

22.架构构件块

架构构件块（ABB）是根据架构连续系列（见第6章）分类的企业架构库中的架构文档和模型。它们在应用ADM期间(ABCD阶段)被定义或选择。特点如下：
a.他们捕捉架构需求; 例如业务，数据，应用程序和技术要求。
b.他们指导和指导解决方案构建模块（SBB）的开发。
c.ABB 规范的内容至少包括以下内容：
d.基本功能和属性：语义明确，包括安全功能和可管理性
e.接口：选择集，提供（API，数据格式，协议，硬件接口，标准）
f.互操作性和与其他构件块的关系
g.具有所需功能和命名用户界面的相关构建块
h.映射到业务/组织实体和策略
每个 ABB 应该包含来自企业架构存储库的任何架构文档和模型的声明，这些架构文档和模型可以在架构开发中重新使用。使用ADM的构建块的规范是一个渐进的迭代过程。有关更多信息，请参阅第 5.5节。

23.解决方案构建块

解决方案构建块（SBB）涉及解决方案连续系列。它们是企业架构连续系列中标识的架构的实现，可能也是采购或开发。SBB 出现在 ADM 的 E 阶段，首次考虑产品特定的构件。SBB 定义了哪些产品和组件将实施该功能，从而定义实施。他们满足业务需求并且是产品或供应商意识。SBB 规范的内容至少包括以下内容：
a.特定的功能和属性
b.接口; 实施的集合
c.所需的 SBB 与所需的功能和所用接口的名称一起使用
d.从 SBB 映射到 IT 拓扑和操作策略
e.共享属性的规格，例如安全性，可管理性，可本地化，可伸缩性
f.性能，可配置性
g.设计驱动程序和约束条件，包括物理架构
h.SBB 和 ABB 之间的关系

24.基于能力的计划

E 阶段和 F 阶段是根据基于能力的计划原则定义和规划企业转型的一种详细方法，这是一种专注于业务成果的业务计划技术。它是业务驱动和业务主导的，并结合所有业务领域的必要努力来实现所需的功能。它适应大部分（如果不是全部）公司业务模式，尤其适用于需要潜在响应能力（例如，紧急准备单位）的组织以及相同资源涉及多种能力的组织。通常需要使用业务场景来发现和优化这些功能。图 5 显示了基于能力的计划，企业架构和项目组合/项目管理之间的关系。

25.迁移计划技术

提供了一些支持阶段 E 和 F 的迁移规划的技术，这些技术将在以下各节中描述。

实现因子评价与演绎矩阵:在阶段 E 中使用创建实施因素评估和扣除矩阵的技术来记录对架构实施和迁移计划有影响的因素。矩阵应包括一系列因素，它们的描述以及表明在制定计划时必须考虑的行为或约束的扣减。
合并的差距，解决方案和依赖性矩阵:允许架构师将领域架构差距分析结果中确定的差距分组，并评估潜在解决方案和依赖关系到一个或多个差距。此矩阵可用作计划工具。所确定的依赖性推动了阶段 E 和 F 中的项目创建和迁移计划。
架构定义增量表:通过创建架构定义增量表的技术，架构师可以规划一系列转换架构，在特定时间概述企业架构的状态。在转换架构中分配增量交付成果。
过渡架构状态演变表:所有解决方案构建模块（SBB）都应该描述其交付情况以及对这些服务的影响。他们也应该被标记以显示企业架构的进展。在示例中，如果已达到目标功能，则显示为“新”或“保留”; 在能力转变为新解决方案的地方，这被标记为“过渡”; 并且在能力被替换的地方，这被标记为“替换”。
商业价值评估技术:价值指数应该包括符合原则，财务贡献，战略调整和竞争地位等标准。风险指数应包括规模和复杂性，技术，组织能力和失败影响等标准。每个标准应分配一个单独的权重。该指标及其标准和权重应由高级管理层制定和批准。在已知选项之前建立决策标准是很重要的。

26.实施和迁移计划

实施和迁移计划在阶段E和F中制定，并提供实施目标架构项目的时间表。实施和迁移计划包括分为管理投资组合和计划的可执行项目。
实施和迁移战略确定了改变的方法，是实施和迁移计划的一个关键要素。包括
a.实施和迁移战略：战略实施方向、实施测序方法
b.实施项目和投资组合细目：将工作包分配给项目和投资组合、项目交付的能力、里程碑和时间、工作分解结构
c.项目章程：工作包、商业价值、风险，问题，假设，依赖关系、资源需求和成本、迁移的好处、迁移选项的估计成本

27.过渡架构

如果实现目标架构的变更范围需要增量方法，则在阶段 E 的架构定义文档输出中定义一个或多个转换架构。转换架构将基线和目标架构之间的架构显示为处于架构重要状态。过渡架构用于描述有效实现目标架构所需的过渡目标架构。这些提供了识别沿着路线图实现目标架构的清晰目标的能力。
以下内容在过渡架构中是典型的：
a.每个转换状态的业务架构
b.每个转换状态的数据结构
c.每个过渡状态的应用架构
d.每个过渡状态的技术架构

28.实施治理模型

阶段 F的输出而产生的实施治理模型确保项目过渡到实施也顺利地过渡到适当的架构治理（针对阶段 G）。
实施治理模式的典型内容是：
a.治理流程
b.治理组织结构
c.治理角色和责任
d.治理检查点和成功/失败标准

29.架构契约

架构契约在阶段 G实施治理中生成。架构合同是开发合作伙伴和赞助商之间就架构的可交付成果，质量和适用性达成的共同协议。这些协议的成功实施将通过有效的架构来实现。通过实施管理合同的方法，将确保以下内容：

持续监控系统，用于检查组织内所有与架构相关活动的完整性，变更，决
遵守现有或开发架构的原则，标准和要求
根据公认的标准，政策，技术和产品以及架构的运营方面，确定涵盖内部开发和实施的所有方面的风险，以便组织可以继续其业务有弹性的环境
一套流程和实践，确保在开发和使用所有架构工件方面的问责制，责任和
正式理解负责合同的治理组织，其权力级别以及本机构管理下的架构范围示例合同，如下所示：
架构设计和开发合同
商业用户的架构合同

30.变更请求

阶段H：架构变更管理考虑架构变更请求。在架构实施期间，随着更多事实的公布，原始架构定义和要求可能不适合或不足以完成解决方案的实施。在这些情况下，实施项目有必要偏离建议的架构方法或请求扩展范围。此外，外部因素 - 例如市场因素，商业战略的变化以及新技术机遇 - 可能为拓展和完善架构提供了机会。在这些情况下，可能会提交更改请求以启动进一步的架构工作。更改请求的典型内容是：
a.建议更改的说明
b.拟议变更的理由
c.对拟议变更的影响评估，包括
参考具体要求
迄今为止的要求的利益相关者优先权
阶段将被重新审视
领导需求优先级的阶段
阶段调查结果和修改后的优先事项
关于需求管理的建议
d.存储库参考号码

31.合规性评估

一旦定义了架构，就必须通过实施来管理架构，以确保原始架构愿景得到适当实现，并将任何实施课程反馈到架构过程中。阶段 G 中实施项目的定期合规审查提供了一个机制来审查项目进展情况，并确保设计和实施与战略和架构目标保持一致。
合规性评估的典型内容是：
a.项目进展和状态概述
b.项目架构/设计概述
c.完成的架构清单：
硬件和操作系统清单
软件服务和中间件清单
应用清单
信息管理清单
安全清单
系统管理清单
系统工程清单
方法和工具清单

32.需求影响评估

在整个ADM中，收集有关架构的新信息。随着这些信息的收集，新的事实可能会被揭露，从而使架构的现有方面失效。需求影响评估评估当前的架构要求和规范，以识别应该做出的改变以及这些改变的影响。
它记录了对变化的评估以及对架构进行更改的建议。推荐内容如下：
a.参考特定要求
b.利益相关方迄今为止的优先要求
c.重新审视阶段
d.领导需求优先级的阶段
e.阶段调查的结果和修订的优先事项
f.关于需求管理的建议
g.存储库参考号码

第四章 ADM适应ADM的指导原则

1.Introductio介绍

一个重要的考虑因素是， ADM 阶段的顺序在一定程度上取决于相关企业内部架构规范的成熟度。例如，如果企业架构业的商业案例得不到很好的认可，那么创建一个架构愿景是必不可少的; 接下来需要详细的业务架构来为剩下的架构工作定义业务案例，并确保主要利益相关者积极参与该项工作。
阶段的顺序也可以由企业的业务和架构原则来定义。例如，业务原则可能要求企业准备调整业务流程以满足打包解决方案的需求，以便快速实施，以便快速响应市场变化。在这种情况下，业务架构（或至少完成它）可能会完成信息系统架构。
企业可能希望将 ADM 与其他企业架构框架结合使用或定制，该框架具有特定垂直部门特定的可交付成果集：政府部门，国防部门，电子商务部门，电信部门等。
ADM 是构成企业公司治理模式的众多企业流程之一。 ADM 是对其他标准计划管理流程的补充和支持。企业将调整 ADM 以反映与其他管理流程的关系，并依赖于其他管理流程。
ADM 正被授权由外包领域的主要承包商或主承包商使用，需要量身定做，以便在承包商的现有做法和承包企业的要求之间达成妥协。
企业是一个中小型企业，希望使用 ADM 的“精简版”，这种版本更适合于这种环境中典型的资源和系统复杂程度的降低。
企业规模庞大而且复杂，在整体协作业务框架内包含许多独立但相互关联的“企业”，架构方法需要适应这种情况。这些企业通常不能作为单一实体成功对待，需要更多联合方式。

2.ADM针对ADM应用迭代

ADM 的每个周期都将受到架构工作请求的约束。架构输出将填充架构景观，或者扩展所描述的景观，或者在需要的地方更改景观。
项目可能同时运行多个 ADM 阶段。通常，这用于管理业务架构，信息系统架构和技术架构之间的相互关系。
a.项目可以在 ADM 阶段之间循环，涵盖多个阶段的计划周期。通常，这用于在高级架构不存在以提供上下文和约束时用于汇聚在详细的目标架构上。
b.项目可以回到之前的阶段，以便用新的信息对工作产品进行循环和更新。通常，当实现细节和变更范围触发利益相关者需求的变更或重新排序时，这通常用于可执行架构路线图或实施和迁移计划的融合。

架构能力迭代支持所需架构能力的创建和演变。这个周期包括通过建立或调整架构方法，原则，范围，愿景和治理，为特定目的或架构参与类型最初动员架构活动。
架构开发迭代允许通过循环或集成业务，信息系统和技术架构阶段来创建内容。这些迭代确保了架构被视为一个整体。在这种类型的迭代中，利益相关者评论通常更宽泛。随着迭代收敛于目标，扩展到机遇和解决方案以及迁移计划阶段确保在架构最终确定时考虑架构的可实施性。个人 PDF 版个人版
过渡规划迭代支持为定义的架构创建正式的变更路线图。
架构治理迭代支持对定义的目标架构进展的变更活动的治理。

TOGAF 定义了两种风格的架构定义：

基线优先：以这种风格，首先评估基线结构。当目标解决方案不清楚时，这
个过程是适用的。

目标优先：以这种风格，详细阐述目标架构，然后将其映射回基线，以定义
更改活动。当目标国家达成高层协议并且企业希望避免将目前的商业惯例扩
散到目标中时，这个过程是合适的。

3.架构景观中应用ADM

战略架构为运营和变革活动提供了一个组织框架，并允许在行政层面进行方向设置
分段架构为运营和变更活动提供了一个组织框架，并允许在程序或组合级别进行方向设置和开发有效的架构路线图。
能力架构为变革活动提供了一个组织框架，并为实现能力增量而制定有效的架构路线图

4.采用不同的架构风格使用ADM

许多架构风格被开发出来，以解决从业者面临的关键问题，并演示如何在定义的上下文环境中使 TOGAF 框架更加相关联。这些都包括在 TOGAF 库中。其中一些是由在特定领域工作的开放小组论坛和工作组制定的，并在《指南》、《白皮书》和《标准》中发表。

第五章架构内容框架

本章简单介绍了架构内容框架，它是架构制品的一个结构化的元模型。

1.架构内容框架概述

在ADM的执行过程中，将会产生一些结果，比如流程，架构要求，项目计划， 项目合规评估等。为了能够整理和呈现这些主要工作产品的一致性结构化的方式，有必要建立一个架构内容框架来放置它们。这允许更容易的参考和标准分类，并且还有助于促进组成通常被称为“企业架构”的组成工作产品之间的关系的结构化。
架构内容框架使用以下三个类别来描述其中的架构工作产品的类型使用环境：

交付物是合同规定的正式工作产品，通常由其利益相关方进行审查，同意并签署。可交
付成果通常代表项目的产出。

工件/产出物/制品是描述架构方面的工作产品。工件通常被分类为目录（事物清单），
矩阵（显示事物之间的关系）和图表（事物的图片）。示例包括需求目录，业务交互矩
阵和用例图。架构交付物可能包含许多工件，并且工件将形成架构存储库的内容。

一个构建块表示了业务、 IT或架构能力的（潜在可重用的） 业务构件，它可以和其他构
建块组合起来共同交付架构或解决方案

总结：架构模型找构建,过程产出叫制品,结果产品交付物,存储库中为重用

2.内容元模型

在创建架构和管理架构时，有必要考虑业务服务、参与者、应用、数据实体和技术等关注点。内容元模型强调了这些关注点，展示它们之间的关系，并识别可用于以一致的、结构化的方式表示它们的制品/工件.使用架构工具来实施其架构的组织，内容元模型还可以用来为其提供指导。

核心元模型提供了支持制品可追溯的最小架构内容集，并且插入了扩展以支持可能需要的任何更具体或更深入的建模。
架构制品：ADM中的每个阶段创建的构件。

系统	架构	架构描述	干系人/ 利益相关者	关注	架构视图	架构视点
为达到一个或多个规定目的而组织起来的相互作用的元素的组合。	系统在其环境中的基本概念或特性体现在其要素、关系以及设计和演进的原则中	一种用于表示架构的工作产品；一组架构视图和模型，它们共同记录架构。	个人、团队、组织或阶层。	一个或多个利益相关者对系统的兴趣点。关注可能涉及到系统功能运行、开发或操作的任何方面，包括性能、可靠性、安全性、分布式和可演进性等考虑	从一组相关的关注点的角度来表示一个系统	一种特定类型的架构视图的约定的规范

目录，矩阵和图：便于呈现架构信息，因此可以更容易地将其用于参考和治理的目的。目录是特定类型或相关类型的构件块列表，矩阵是显示两个或多个实体之间的关系网格，图是企业架构内容的图形渲染。
ADM开发的架构的结果由许多定义的 ABBS 组成，这些ABBS填充到架构目录中，并在架构矩阵中的那些构建块之间指定了关系，并且/或者还以图表的形式表示，以满足利益相关者的关注。
架构交付物: 这套基准交付物可以作为组织裁剪 ADM 的起点.

3.构建块

在阶段 A 中，最早的构建块定义从架构愿景中相对抽象的实体开始。
在阶段 B、 C 和 D 中，业务、数据、应用和技术架构中的构建块根据一套共同的步骤模式被不断修订。
在阶段 E 中，构建块变得更加与具体实现相关，最后解决方案构建块（SBBs）被识别出来以解决差距。

构建块（building blocks）: 构建块就是被定义用来满足业务需求的一个功能包可以在不同细节级别上被定义，并且既可以与“架构”相关。系统是从构建块的集合中构建出来的，因此大部分构建块不得不和其他构建块交互

架构构建块（Architecture Building Block, ABB）来描述所需的能力，并决定解决方案构建块（Solution Building Block， SBB）的内容
解决方案构建块表示用于实施所需能力的构件。

第六章企业的连续

1.企业连续系列概览

企业连续系列提供了用于构建“虚拟”存储库的模型，并提供了对架构和解决方案工件进行分类的方法，显示了不同工件的发展方式以及如何重复使用它们。它填充了架构资产及其可能的解决方案（模型，模式，架构描述等）。这些资产和解决方案可以从企业内部或整个行业中提取，并用于构建架构。
a. 一是尽可能的重用，特别是避免重新发明。例如交付物，构建块
b. 二是帮助沟通。架构和解决方案连续系列中的资产都根据从一般到特殊的方式进行了组织，目的是提供一种一致的语言来有效地表达架构之间的差异。

TOGAF 还提供了另外一个参考模型以供纳入某个特定组织的企业连续系列中去：集成信息基础设施参考模型

2.架构分区

在一个典型的企业中，在任一个时间点都可能同时存在多个架构。某些架构会处理一些特殊的需求；而另外一些则更为通用。某些架构处理细节；而另外一些则提供概览。同样地，也会同时有多个解决方案正在被使用或正被考虑使用，以满足企业的需要。
架构被分割的原因如下：
a.在一个单一的架构中处理所有的问题过于复杂。
b.不同的架构互相间存在冲突（例如，由于企业的状态会随着时间而变化，来自于某个时间段的架构可能会和另一个时间段的架构冲突）。
c.不同的团队需要同时在架构的不同元素上工作，而对架构的分割使得某个架构师的团队能够拥有并开发架构的某个片段。
d.有效的架构重用要求将架构模块化，以便将这些模块化的架构分段合并进更大的架构和解决方案中
初步阶段完成后，应该理解进行架构的团队。每个团队都应该有一个明确的范围，团队和架构之间的关系应该被理解。

3.架构知识库

架构存储库的概念对企业连续系列进行了支持，它可以用来存储由 ADM 创建的、不同抽象层次上的、不同种类的架构输出。 TOGAF 通过这种方式，促进了不同层次的利益相关者和实践者之间的理解和协作。
可以把 ADM 看作是在组织的整体治理框架之下、在组织的多个层次上运作、产生了协调一致的输出并存放到架构存储库中的过程生命周期的描述。企业连续系列为正确理解架构模型提供了一个很有价值的上下文：它展示了构建块和它们之间的相互关系，并展示了一个架构开发周期中的约束和需求。

架构存储库中的主要构件如下：
a.架构元模型（Architecture Metamodel）描述了经组织裁剪的架构框架的应用方
式，包括一个架构内容的元模型。
b.架构能力（Architecture Capability）定义了支持架构存储库治理的参数、结构和流程。
c.架构景观（Architecture Landscape）展现了当前组织内使用的构建块的架构视图（如，一份在用的应用系统的列表）。景观很可能存在于多个抽象级别上，以满足不同的架构
目的。
d.标准信息库（Standard Information Base， SIB）捕获新的架构必须符合的标准，可包括行业标准、选定供应商的产品和服务或已在组织中部署的共享服务。
e.参考库（Reference Library）提供指引、模板、模式和其他形式的参考资料，可用来加速企业新架构的创建。
f.治理日志（Governance Log）提供整个企业内的治理活动的记录。
架构知识库是更广泛的企业知识库的一部分,当架构知识库包括连接企业架构信息和制品间的联系,有相当数据的企业知识库支持这个架构.这些可以包括开发知识库,特定运行环境,指令和配置管理知识库。

第七章架构能力框架

建立架构能力	在组织内建立架构能力的指南。
架构委员会	建立和运营企业架构委员会的指导原则。
架构合规性	确保项目符合架构的指导原则。
架构合同	定义和使用架构合同的准则。
架构治理	架构管理的框架和指导方针
架构成熟度模型	用于评估和量化企业架构中组织成熟度的技术。
架构技能框架	为从事企业架构工作的员工制定的一套角色，技能和经验规范

1.创建架构能力

在组织内实现任何能力需要设计四个域架构：业务，数据，应用程序和技术。因此，在组织内建立架构实践需要设计：
a.架构实践的业务架构，重点介绍架构治理，架构过程，架构组织结构，架构信息需求，架构产品等。
b.数据架构，定义组织的企业连续系列和架构库的结构。
c.应用程序架构，指定启用架构实践所需的功能和/或应用程序服务。
d.技术架构，指定架构实践的基础结构要求以支持架构应用程序和企业连续系列。

2.架构治理

架构能力框架包含架构治理的框架和指导原则。架构治理是企业架构和其他架构在企业范围内进行管理和控制的实践。它包括以下内容：
a.实施对所有架构组件和活动的创建和监控进行控制的系统，以确保在组织内有效地引入，实施和演进架构
b.实施一个系统来确保符合内部和外部标准以及监管义务
c.在商定的参数范围内建立支持上述流程的有效管理的流程
d.建立并记录影响企业架构的决策结构; 这包括为决策提供输入的利益相关者
e.制定实践，确保对组织内外明确确定的利益相关者群体负责
架构委员会:业架构不仅仅是应用 ADM 过程产生的工件。使组织按照架构中规定的原则行事需要一个决策框架。架构能力框架为建立和运营企业架构委员会提供了一套指导方针。架构委员会负责运营项目，并且必须能够在可能发生冲突的情况下作出决定，并对做出这些决定负责。因此，它应该是架构中所有关键利益相关者的代表，并且通常由负责审查和维护整个架构的一组管理人员组成。架构委员会成员涵盖架构，业务。
为所有关于架构变化的决策提供基础
子架构之间的一致性
识别可重复使用的组件
企业架构的灵活性; 满足业务需求并利用新技术
执行架构合规性
提高组织内部架构规范的成熟度
确保采用以架构为基础的发展纪律
支持可视化升级功能以进行跨界决策
架构委员会还负责运营项目，如架构合同的监测和控制（参见第 3.29 节）以及治理项目，
如生成可用的治理材料。重要任务是：
a.分配架构任务
b.正式批准架构产品
c.解决架构冲突
架构合规性:应采用架构合规策略并采取特定措施以确保符合架构。架构能力框架包含一系列确保项目符合架构的流程，指导方针和清单，其中包括：
a.项目影响评估，说明企业架构如何影响组织内的主要项目
b.架构合规性审查流程（参见图 22），这是审查项目是否符合企业架构
的正式流程

1.架构技能框架

架构能力框架为从事企业架构工作的员工提供了一套角色，技能和经验规范。
a.通用技能，通常包括领导力，团队合作，人际技能等。
b.业务技能和方法，通常包括业务案例，业务流程，战略规划等。
c.企业架构技能，通常包括建模，构建块设计，应用程序和角色设计，系统集成等。
d.计划或项目管理技能，通常包括管理业务变更，项目管理方法和工具等。
e.IT 常识技能，通常包括代理应用程序，资产管理，迁移规划， SLA 等。
f.技术 IT 技能，通常包括软件工程，安全，数据交换，数据管理等。
g.法律环境，通常包括数据保护法，合同法，采购法，欺诈等