togaf 9.2中文版
尊敬的读者朋友们，本专栏为togaf 9.2 的个人学习笔记，我会尽量将信息完整地传递给大家，以便更多对 togaf 感兴趣的朋友不用花费巨资去购买相关资料。本文档不需要读者具备企业架构的预备知识。
专栏受众：企业架构师、业务架构师、 IT 架构师、数据架构师、系统架构师、解决方案架构师和希望初步了解 togaf 的高级管理者。
章节概览：
- TOGAF介绍
- 架构开发方法
- ADM指南和技术
- 架构内容框架
- 企业连续性和工具
- 架构能力框架
- TOGAF 参考库
一、 TOGAF 介绍
TOGAF 是一个标准的、开放的、具有业界共识的企业架构框架。
TOGAF 标准可用于开发各种不同领域的企业架构。 TOGAF 对其他框架进行了补充，并可与其他框架一起使用，其他这些框架更侧重于特定垂直领域的特定交付物，例如：政府、电信、制造业、国防和金融。而 TOGAF 标准的关键部分是用于开发可满足业务需求的企业架构的方法—— TOGAF 架构开发方法（ADM）。以便开发出符合各类业务需求的企业架构。
1.1 什么是 TOGAF 标准中的架构？
将“架构”定义为：一个系统在其环境中的基本概念或属性体现在它的元素、元素之间的关系以及它的设计和进化的原则中。组件的结构、它们之间的相互关系，以及关于组件设计和随时间演变的原则和指南。
1.2 TOGAF 标准处理哪种架构？
TOGAF 标准涵盖了四种相关类型的架构的开发。这四种类型的架构通常被视为整个企业架构的子集。分别为：
- 业务架构
- 数据架构（有些组织叫信息架构）
- 应用架构
- 技术架构
1.3 TOGAF 标准包含什么？
反应了企业中架构功能的结构和内容
TOGAF 框架的核心是架构开发方法 。架构能力操作该方法。该方法由一些指南和技术进行支持。这将生成存储在存储库中的内容，这些内容根据企业连续统一体进行分类。存储库最初可以使用TOGAF参考模型和其他参考资料填充。
1.3.1 架构开发方法（ADM）
ADM 是 TOGAF 框架的主要组成部分，在多个层次上为架构师提供指导：
- 转接技术：它在一个周期内提供了许多架构开发阶段（业务架构、信息系统架构、技术架构），这些阶段作为架构开发活动的总体过程模板。
- 它提供了每个架构阶段的描述，用目标、方法、输入、步骤和输出来描述该阶段；输入和输出部分给出了架构、内容结构和可交付成果的定义（在架构内容框架中给出了阶段输入和阶段输出的详细描述）。
- 提供涵盖需求管理的跨阶段摘要
1.3.2 ADM 指南与技术
TOGAF 中提供的一些指南和技术，用以支持 ADM 的应用。这些准则包括调整 ADM 以处理一些使用场景，包括不同的流程风格——迭代的使用，以及在整个架构景观中应用 ADM 。还有如何使用不同架构风格的 TOGAF 框架。
这些技术支持 ADM 中具体任务，例如：基于能力的规划、定义原则、差距分析、迁移规划、风险管理、利益攸关方管理等。在 TOGAF 库中还提供了更多的指南和技术。
1.3.3 架构内容框架
架构内容框架提供了架构工作产品的详细模型，包括可交付成果、可交付成果中的构件以及构件所代表的架构构件块（ABBs）
1.3.4 企业连续统一体
企业连续统一提供了一个构建虚拟存储库的模型，并提供了对架构和解决方案工件进行分类的方法，展示了不同类型工件如何演化，以及它们如何被利用和重用。这是基于架构和解决方案（模型、模式、架构描述等）。存在于企业内部和整个行业中的，企业收集来用于其架构开发的。
1.3.5 架构能力框架
架构能力框架是一组资源、指南、模板、背景信息等。帮助架构师在组织中建立架构实践。
二、 架构开发方法
这部分描述架构开发方法（ADM ），它与 TOGAF 框架的其他部分的关系，以及使用它的高层次考虑。还包括了 ADM 中每个阶段的摘要。
2.1 ADM 简介
ADM（Architecture Development Method）是TOGAF标准的核心，是许多架构实践者的贡献的结果。它是一种用于推导特定组织企业架构的方法，专门设计用于满足业务需求。ADM描述了：
- 一种可靠、经过验证的企业架构的开发和使用方法
- 一种在不同层次（业务、应用、数据、技术）上开发架构的方法，使架构师能够确保充分解决一系列复杂的需求
- 一套用于架构开发的指导方针和技术
2.2 ADM 的阶段
ADM包括多个阶段，通过一系列架构领域循环进行，使架构师能够确保充分解决一系列复杂的需求。ADM的基本结构如图所示：
架构开发方法循环
ADM在整个过程中以迭代方式应用，在各个阶段之间以及在各个阶段内部都要应用ADM。在整个ADM循环过程中，应频繁对结果进行验证，验证结果是否符合原始需求，包括整个ADM循环的需求和特定阶段的需求。这种验证应重新考虑范围、细节、进度表和里程碑。每个阶段都应考虑从过程的先前迭代产生的资产和市场上的外部资产（如其他框架或模型）中产生的资产。
2.2.1 ADM支持三个层面上的迭代概念
- 在ADM中循环：ADM以一种循环的方式呈现，表明一个阶段的架构工作的完成将直接反馈到后续阶段的架构工作中
- 在各个阶段之间迭代：TOGAF 标准描述了跨阶段迭代的概念（例如，在完成技术架构后返回到业务架构）
- 在单个阶段内循环：ADM支持在单个ADM阶段内重复执行活动，以此作为详细阐述架构内容的技术
2.2.2 按阶段划分的架构开发方法活动
| 阶段 | 活动 |
| 预备阶段 | 为组织成功地做好 TOGAF架构项目做准备。进行创建架构能力所需的准备和启动活动，包括定制 TOGAF框架，选择工具以及定义架构原则。 |
| 需求管理 | TOGAF项目的每个阶段都基于并验证业务需求。识别、存储需求，并将其输入和输出相关的 ADM 阶段，这些阶段将处理需求并确定其优先级 |
| 阶段 A：架构愿景 | 设置 TOGAF 项目的范围、约束和期望。创建架构愿景。确定利益相关者。验证业务环境并创建架构工作声明，并获得批准。 |
| 阶段 B：业务架构 | 开发架构在如下 4 个域中： 1 、业务 2 、信息系统应用 3 、信息系统数据 4 、技术 对于每次开发案例，都是开发基线架构和目标架构，同时针对线程和目标进行差距分析找出差距 |
| 阶段E：机会与解决方案 | 进行初步的实施规划，并确定之前阶段中识别出的构件块交付载体，确认主要的实施项目，确定是否需要增量方法，如果需要增量，组成各过渡架构 |
| 阶段 F：迁移计划 | 指定详细的实施和迁移计划，以解决如何从基准迁移到目标架构的问题 |
| 阶段 G：实施治理 | 提供实施的架构监督。准备并签发建筑合同。确保实施项目符合架构 |
| 阶段H：架构变更管理 | 架构变更管理提供持续的监视和变更管理过程，以确保架构能够响应企业的需求，以使架构对业务提供最大化的价值。 |
2.3 ADM 阶段的目标、步骤、输入和输出
下面各小结中的表格对 TOGAF ADM 周期中各个阶段的目标、步骤，以及输入和输出进行了总结
2.3.1 预备阶段
预备阶段为了组织成功实施企业架构项目做好了准备。
本阶段的概述如下表所示：
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.2 架构愿景
阶段A主要涉及架构项目的建立，它启动了架构开发周期的新一轮迭代，设定了本次迭代的范围、约束和预期结果。为了能够验证业务背景、创建架构工作说明书并获得批准，这个阶段是必不可少的。
本阶段的概述如下表：
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.3 业务架构
阶段 B 是关于业务架构的开发；业务能力，端到端价值交付，信息和组织结构的整体表示，以及与战略、产品、政策、计划和利益相关者的关系。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.4 信息系统架构
阶段 C 的工作是记录组织 IT 系统的基本组织形式，体现在关键的信息和处理它们的应用系统中。它涉及数据和应用程序架构的某种组合，可以按顺序或同时开发。
2.3.4.1 数据架构
| 目的 | 步骤 |
| 以利益相关者可以理解的方式，定义支持业务所需数据的类型和来源 |
|
| 输入 | 输出 |
|
|
2.3.4.2 应用架构
| 目的 | 步骤 |
| 以利益相关者可以理解的方式，定义支持业务所需数据的类型和来源 |
|
| 输入 | 输出 |
|
|
2.3.4.3 技术架构
| 目的 | 步骤 |
| 开发目标技术架构，这个目标架构将构成后续实施和迁移规划的基础 |
|
| 输入 | 输出 |
|
|
2.3.5 机会与解决方案
阶段 E 是与实施直接相关的第一阶段。它描述了确定交付工具（项目、程序和项目组合）的过程，这些工具交付了先前阶段中确定的目标架构。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.6 迁移规划
阶段 F 解决迁移计划；也就是说，通过完成详细的实施和迁移计划，如何从基准架构过渡到目标架构。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.7 实施治理
阶段 G 定义了架构如何约束实施项目，在构建项目时对其进行监视并生成已签署的架构合同。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.8 架构变更管理
阶段 H确保对架构的更改以受控方式进行管理。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.3.9 需求管理
管理架构要求的过程适用于 ADM 周期的所有阶段。需求管理过程是一个动态过程，该过程解决了企业需求的标识，存储需求，然后将其输入和输出相关的ADM阶段。
应对需求变更的能力对于ADM 流程至关重要，因为架构本质上可以处理不确定性和变更，弥补了利益相关者的期望与实际解决方案之间的鸿沟。
| 目的 | 步骤 |
|
|
| 输入 | 输出 |
|
|
2.4 架构活动的范围
ADM 定义了开发组织范围内的企业架构所涉及的各个阶段和步骤的推荐序列，但是 ADM 不能确定范围：这必须由组织本身决定。
有很多理由来限制要进行的架构活动的范围，其中大多数与以下几个方面的限制有关：
- 组织架构团队的组织权威
- 在架构内有待解决的目标和利益相关者的关注点
- 人力资源、资金和其他资源的可用性
架构活动选择的范围应该理想地允许企业内部所有架构师的工作得到有效的治理和整合。这需要一组对齐的“架构分区”，以确保架构师不处理重复或冲突的活动。它还需要重新定义架构分区之间的重用和遵从关系。企业和其架构相关活动的划分在 TOGAF 中得到解决，下表显示了可以定义和限制范围的四个维度。
| 维度 | 考虑因素 |
| 宽度 | 什么是企业的全部范围，以及构建工作应该处理的程度如何？许多企业非常庞大，有效地组成了一个组织单位联盟，可以被视为企业自身的权利。现代企业日益扩展超越传统界限，接收传统企业与供应商，客户和合作伙伴相结合的模糊组合。 |
| 深度 | 架构工作应该达到何种程度的细节？多少架构“足够”？架构工作与其他相关活动（系统设计、系统工程、系统开发）之间的适当界限是什么？ |
| 时间段 | 什么时候需要为架构愿景阐述的时间段，并且在详细的架构描述中涵盖同一时期内是否有意义（在实用性和资源方面）？如果不是，将定义多少个过渡架构，以及它们的时间段是多少？ |
| 架构领域 | 一个完整的企业架构描述应该包含所有四个架构领域（业务、数据、应用、技术），但是资源和时间限制的现实往往意味着没有足够的时间，资金或资源来构建自上而下的，包含所有四个架构域的包容性架构描述，即使企业范围被选择为小于整个企业的整个范围。 |
3 ADM周期的 32 个关键技术和成果
ADM循环的关键技术和可交付的内容
3.1 定制的架构框架
预备阶段
选择和定制框架是架构项目的实际起点。基于 TOGAF 的构建与从零开始创建框架相比具有许多优势：
- 当任务的规模变得明显时，它避免了最初的恐慌。
- TOGAF 的使用是系统性的“编纂常识”
- TOGAF 捕捉其他人在现实生活中发现的东西
- TOGAF 有一组可重复使用的资源
- TOGAF 库的参考架构制品被广泛的应用在 enterprise continuum 中
但是，在架构项目中可以有效使用 TOGAF 之前，需要在多个级别进行裁剪，并且应该在初步阶段进行。
首先，有必要对TOGAF模型进行定制，以便将其整合到企业中。这种定制将包括与管理框架的整合、术语的定制、表现风格的开发、架构工具的选择、配置和部署等。所采用框架的正式性和细节程度还应与企业的其他上下文因素保持一致，例如文化、利益相关者、企业架构的商业模式以及现有的架构能力水平。
为企业定制了框架，就需要进一步定制，以便为具体架构项目定制框架。在这个层面上的定制将选择适当的可交付成果和工件，以满足项目和利益相关者的需求。以下内容在定制架构框架中是典型的：
- 量身定制的架构方法
- 量身定制的架构内容（交付件和工件）
- 配置和部署的工具
- 与治理模型和其他框架的接口（1）公司业务规划；2）企业架构；3）投资组合，计划，项目管理；4）系统开发/工程；5）运营（服务））
3.2 企业架构的组织模型
预备阶段
初步阶段产生的重要交付成果是企业架构的组织模型。
为了成功地使用架构框架，它必须得到企业中正确的组织、角色和职责的支持。特别重要的是定义不同企业架构从业者与跨越这些边界的治理关系之间的界限。
企业架构组织模型的典型内容是：
- 受影响组织的范围
- 成熟度评估，差距和解决方法
- 架构团队的角色和责任
- 架构工作的限制
- 预算要求
- 治理和支持战略
3.3 架构原则
预备阶段
这套文件是初步阶段的初始输出。这是正在开发的架构的一套通用规则和准则（本文档的建议内容是商业原则、数据原则、应用原则和技术原理）。
3.3.1 架构开发原则
架构原则通常由企业架构师与关键利益相关者共同制定，并由架构委员会批准。
以下通常会影响架构原理的发展：
- 企业任务和计划：企业的任务、计划和组织基础结构
- 企业战略计划：企业的特点 -——它的优势、劣势、机会和威胁 ，以及它当前的全企业范围内的计划（例如流程改进和质量管理）
- 外部制约因素：市场因素（上市时间的必要性，客户期望等）；现有和潜在的立法
- 当前的系统和技术：企业内部部署的一组信息资源，包括系统文档、设备清单、网络配置图、策略和过程
- 计算机行业趋势：对计算机和通信技术的使用，可用性和成本的预测，取自可靠来源以及当前正在使用的相关最佳实践
3.3.2 定义架构的原则
根据组织的不同，可以在不同的领域和不同的级别建立原则。架构的开发和利用有两个关键领域：
- 企业原则为整个企业的决策提供了依据，并指示组织如何履行其使命
此类原则通常用作协调决策的手段。它们是成功的架构治理策略的关键要素。在企业原则的广泛领域中，通常在业务或组织单位中拥有辅助原则；例如 IT 、人力资源、国内运营或海外运营。
- 架构原则是与架构工作相关的一组原则
它们反映了整个企业的共识，提现了企业架构的精神。架构原则支配着架构过程，从而影响企业架构的开发、维护和使用。
TOGAF 标准包括用于描述原理的推荐模板。除定义声明外，每个原则还应具有相关的基本原理和含义声明，以促进对原则本身的理解和接收，并支持在解释和证明做出特定决定的理由时使用原则。
TOGAF 定义原则的模板：
| 名称 | 应该既代表规则的本质，又易于记忆。原则名称或陈述中不应提及特定的技术平台。避免在名称和陈述中使用含糊不请的词语，例如：支持、开放、考虑，并且由于缺乏好的度量，“避免”、“管理”一词本身应谨慎对待，以及避免使用不必要的形容词和副词。 |
| 声明 | 应该简洁明确地传达基本规则。在大多数情况下，组织之间用于管理信息的原则声明相似。原则声明必须毫不含糊。 |
| 基本原理 | 应使用业务术语强调遵守该原则的业务利益。指出信息和技术原理与管理业务运营的原理的相似性。还描述与其他原则的关系，以及有关于平衡解释的意图。描述一种情况，在该情况下一个原则将被赋予优先权或在决策时比另一个原则具有更大的重要性。 |
| 含义 | 应该在资源、成本和活动/任务方面强调对业务和 IT 实施原则的要求。很明显，当前的系统、标准或实践在采用时与该原则不一致。应明确说明采用原则对业务的影响和后果。读者应该很容易看出答案：“这对我有何影响？” 重要的是不要过分简化、琐碎化或判断影响的优劣。其中的某些影响仅会被识别为潜在影响，并且可能是推测性的，而不是进行全面分析的。 |
3.3.3 质量原则
如下表所示，有五个标准可以区分一组好的原则：
| 标准 | 描述 |
| 稳定性 | 原则应该持久，还能够适应变化。最初批准原则后，应建立修订程序以添加、删除或更改原则 |
| 易懂 | 整个组织中的个人可以快速理解和理解原则的基本原理。该原则的意图是清晰和明确的，因此，无论是有意还是无意的违规行为都应最小化 |
| 坚固性 | 原则应使有关架构和设计的高质量决策得以制定，并应制定可以实施的政策和标准。每个原则应足够明确和精确，以支持在复杂且可能引起争议的情况下的一致决策 |
| 完整性 | 定义了管理组织信息和技术管理的每个潜在重要原则。原则涵盖了所感知到的所有情况 |
| 一致性 | 严格遵守了一个原则可能需要对另一个原则进行宽松的解释。原则的表达方式必须允许各种解释之间的平衡。原则不应与坚持一项原则会违反另一项原则的精神相抵触。原则陈述中的每个单词都应该谨慎选择，以允许一致而灵活的解释 |
3.3.4 应用架构原则
架构原则用于捕获有关企业将如何使用和部署 IT 资源和资产的基本事实。原理以多种不同方式使用：
- 提供一个框架，企业可以在其中开始对企业框架和实施目标企业架构的项目做出有意识的决策
- 作为建立相关评估标准的指南，从而在管理企业架构遵从性的后期阶段对产品、解决方案或解决方案架构的选择产生重大影响
- 作为定义架构功能需求的驱动程序
- 作为评估现有实施和未来战略组合的投入，以确保符合已定义的架构；这些评估将提供对现实架构所需的过渡活动的宝贵见解，以支持业务目标和优先级
- 基本原理声明强调了架构对企业的价值，因此为证明架构活动合理性提供了基础
- 影响声明概述了遵循该原则对企业的关键任务、资源和潜在成本；他们还为未来的过渡计划和规划提供了宝贵的意见
- 咋以下方面支持架构治理活动：
1）在允许或需要某种解释的情况下，为标准架构符合性评估提供“支持”
2）支持无法在本地操作程序中解决特定架构修正案影响的情况下发起分配请求的决定
原则是相互关联的，需要作为一个整体来应用。原则有时会竞争；例如，“可访问性”和“安全性”原则。必须在“所有其他事物都平等”的背景下考虑每项原则。有时需要决定哪种原则在特定问题上优先。此类决策的理由应始终记录在案。原则似乎不言而喻的事实并不意味着该原则实际上已在组织中得到遵守，即使有口头上对该原则的认可也是如此。尽管原则声明中没有规定具体的处罚措施，但是违反原则通常会导致运营问题，并阻碍组织履行其使命的能力。
3.4 业务原则、业务目标，和业务驱动程序
预备阶段
业务原则、业务目标和业务驱动程序的声明通常在架构活动之前，在企业的其他地方定义。作为初步阶段的输出重新进行审视，并作为 A 阶段：企业架构展望的一部分再次审查。阶段 A 的活动是确保当前的定义是正确和清晰的。
该交付项目没有明确的内容，因为其内容和结构可能因组织而异。
3.5 架构存储库
预备阶段
架构库 是企业内所有架构相关的项目的控制区域。该存储库允许项目管理其可交付成果，找到可重复使用的资产，并将结果发布给利益相关方和其他相关方。
以下内容在架构库中是典型的：
- 架构框架
- 标准信息库
- 架构景观
- 参考架构
- 治理日志
- 架构需求
- 解决方案景观
3.6 架构工具和技术
预备阶段
作为初步阶段的一部分，架构师应该选择和实施支持架构活动的工具。 TOGAF 不需要或推荐任何特定的工具。
3.7 架构工作请求
预备阶段
这是从发起组织发送到架构组织的文档，以触发架构开发周期的开始。它是在架构组织的协助下生成的，作为初步阶段的输出。架构工作申请也将根据批准的架构变更请求或源自迁移计划的架构工作的职权范围而创建。
本文档的建议内容如下：
- 组织赞助商
- 组织的使命陈述
- 业务目标（和变化）
- 业务的战略计划
- 时间限制
- 商业环境的变化
- 组织约束
- 预算信息，财务约束
- 外部约束，商业约束
- 当前业务系统描述
- 当前架构/IT 系统描述
- 发展中组织的描述
- 对开发组织可用的资源的描述
3.8 架构工作声明
阶段 A 架构愿景
架构工作声明是作为阶段 A 的可交付成功创建的，实际上是架构项目的架构组织和发起人之间的契约。本文件是对企业架构工作请求输入文件的答复。它应该描述解决工作要求的总体计划，并提出如何通过架构过程解决已确定的问题的解决方案
本文件的建议内容如下：
- 标题
- 企业架构项目请求和背景
- 企业架构项目描述和范围
- 架构愿景概述
- 范围程序的具体变更
- 角色、责任和交付成果
- 接收标准和程序
- 企业架构项目计划和时间表
- 批准
3.9 架构愿景
阶段 A 架构愿景
架构愿景是在阶段 A 中创建的，并提供了对成功部署目标架构后将遵循的企业变更的高级总结。这个愿景的目的是从一开始就同意架构的理想结果，以便架构师能够关注验证可行性所需的细节。提供架构愿景还通过提供完整的架构定义的摘要版本来支持利益相关方沟通。
业务场景是一种适当且重要的技术，可用作开发架构愿景文档过程中的一部分。建议内容如下：
- 问题描述
- 利益相关者及其关切
- 待处理的问题/情景列表
- 架构工作声明的目标
- 架构工作请求的高级业务、应用程序、数据和技术架构所需的摘要视图
- 映射的需求
- 参考草案架构定义文件
3.10 利益关系人管理
阶段 A 架构愿景
利益相关者管理是成功的架构师可以用来赢得他人支持的重要学科。它帮助他们确保他们的项目在别人失败的情况下取得成功，在阶段 A 中应该使用该技术来确定参与中的关键参与者，并且还要在每个阶段进行更新。这个过程的输出形成了沟通计划的开始。
成功的利益相关者管理的好处是：
- 最强大的利益相关者可以尽早确定，然后可以使用他们的投入来塑造架构；这确保了他们的支持，并提高了生产模型的质量。
- 来自更强大的利益相关者的支持将有助于参与赢得更多资源；从而使架构参与更有可能取得成功
- 通过早起和频繁地与利益相关者进行沟通，架构团队可以确保他们充分理解架构流程以及企业架构的优势；这意味着他们可以在必要时更积极地支持架构团队
- 架构团队可以更有效地预测对架构模型和报告可能产生的反应，并可以在计划中构建采取积极反应所需的操作，同时避免或解决任何负面反应
- 架构团队可以及早识别利益相关者之间的冲突或竞争目标，并制定解决这些问题的策略
3.10.1 利益相关方管理流程中的步骤
3.10.1.1 利益相关方立场分类（确定利益相关方）
首要任务是确定谁是主要的企业架构利益相关者。
显示了一个样本利益相关者分析，用于区分 22 中类型的利益相关者，分为五大类：
3.10.1.2 确定利益相关方的立场（利益相关方立场分类）
深入了解最重要的利益相关方，并记录此分析，以供项目期间参考和刷新。通过这一步骤，团队可以轻松查看哪些利益相关方有望称为阻挠着或评论者，哪些利益相关者可能成为倡议的倡导者和支持者。
权利矩阵：
利益相关者分析：
| 利益相关者组 | 利益相关者 | 破坏变化的能力 | 当前理解力 | 当前承诺 | 需要承诺 | 需要支持 |
| CIO | 张三 | 高 | 中 | 低 | 中 | 高 |
| 首席财务官 | 李四 | 中 | 中 | 低 | 中 | 中 |
3.10.1.3 裁剪工作的交付物
确定架构参与需要产生的目录、矩阵和图表，并与每个利益相关方群组进行验证，以提供有效的架构模型。
通过定义与特定企业架构模型相关的特定目录、矩阵和图表，特别关注利益相关者的兴趣。使得架构能够传达给所有利益相关者并且被所有利益相关者理解，并使他们能够验证企业架构计划将解决他们的担忧。
3.11 沟通计划
阶段 A 架构愿景
企业架构包含了大量复杂且相关依赖的信息。有针对性的信息在正确的时间有效地传达给合适的利益相关者是企业架构的关键成功因素。在 A 阶段开发架构通信计划允许在计划和管理过程中执行此通信。
沟通计划的典型内容是：
- 通过沟通要求确定利益相关者和分组
- 识别通信需求，与架构愿景相关的关键信息，通信风险和关键成功因素（CSF）
- 确定将用于与利益相关者沟通并允许访问会议、通讯、存储库等架构信息的机制
- 确定沟通时间表，说明哪些利益相关者群体会在何时何地与哪些利益群体进行沟通
3.12 业务转型准备评估
阶段 A 架构愿景
业务转型就绪评估技术在 A 阶段进行，用于评估和量化组织准备进行变革。了解组织接收变化，识别问题，然后处理这些问题的准备情况是成功架构转型的关键部分。该评估建议是企业员工，业务部门和 IT 规划人员的共同努力。
推荐的活动是：
- 确定将影响组织的准备因素
- 使用成熟度模型呈现准备就绪因素
- 评估每个准备就绪因素的风险并确定改进措施以降低风险
- 将结果记录在能力评估中，然后将这些行动纳入实施和迁移计划
3.13 能力评估
阶段 A 架构愿景
在着手详细的架构定义之前，了解企业的基准和目标能力水平是很有价值的。这项能力评估首先在 A 阶段进行，并在 E 阶段进行更新。可以在几个层面进行检查：
- 整个企业的能力水平如何？企业希望增加或优化能力在哪里？什么是支持企业理想发展的架构重点领域？
- 企业中 IT 功能的功能或成熟度级别是什么？根据设计治理、运营管理、技能和组织结构进行架构项目可能会产生什么影响？什么是符合 IT 组织文化和能力的架构项目的适当风格，正式程度和详细程度？
- 企业内部架构功能的功能成熟度入如何？目前存在哪些企业架构资产？他们是否保存准确？需要考虑哪些标准和参考模型？在架构项目期间是否有机会创建可重用资产？
- 在能力差距存在的地方，企业准备好在多大程度上进行转型以实现目标能力？转型的风险，文化障碍以及其他需要考虑的因素是什么？
以下内容是能力评估交付成果中的典型内容：
业务能力评估：
- 能力的性能水平
1）对每项能力实现方式的基线状态评估
2）对每项能力应如何实现的未来状态愿景
3）评估目标成功部署对业务组织可能产生的影响 - IT 能力评估
1）变更过程的基线和目标成熟度水平
2）运营流程的基线和目标成熟度水平
3）基线能力和能力评估
4）评估成功部署目标架构可能对 IT 组织造成的影响 - 架构成熟度评估
1）架构治理流程、组织、角色和职责
2）企业架构技能评估
3）架构存储库中的横向定义的广度、深度和质量
4）架构库中标准定义的广度、深度和质量
5）架构库中参考模型定义的广度、深度和质量
6）评估再利用潜力 - 业务转型准备情况评估
1）准备就绪因素
2）每个准备就绪因素的愿景
3）当前和目标准备状态评级
4）准备风险
3.14 风险管理
阶段 A 架构愿景、阶段 B 业务架构
业务转型风险和减缓活动的识别首先在阶段 A 中确定。风险管理记录在 TOGAF 中，是一种用于在实施架构项目时降低风险的技术。它包括一个由以下活动组成的风险管理流程：
- 风险分类
- 风险识别
- 初始风险评估
- 风险缓解和剩余风险评估
- 风险监测
建议风险缓解活动应包含在企业架构工程声明中。
3.15 架构定义文档
阶段 A 架构愿景、阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构、阶段 E 机会与解决方案
架构定义文档是项目期间创建的核心架构工件的可交付容器，以及重要的相关信息。架构定义文档涵盖所有架构域（业务、数据、应用程序和技术），并检查架构的所有相关状态（基线、转换和目标）。
它首先在 A 阶段创建，并在其中填充了为支持架构愿景而创建的工件。它在 B阶段与业务架构相关的材料进行更新，随后在C 阶段用信息系统架构材料进行更新，然后在阶段D 用技术脚骨材料进行更新。如果实施目标架构的变更范围需要增加量方法，架构定义文档将被更新以包含 E 阶段的一个或多个过渡架构。架构定义文档是架构需求规范的一个配套文件，有一个补充目标：
- 架构定义文档提供了解决方案的定型视图，旨在传达架构师的意图
- 架构需求规范提供了解决方案的定量视图，阐述了在实施架构期间必须满足的可测量标准
以下内容通常在架构定义文档中找到：
- 范围
- 目标，目标和限制
- 架构原则
- 基线架构
- 架构模型（针对每个要建模的州）
1）业务架构模型
2）数据架构模型
3）应用架构模型
4）技术架构模型 - 架构方法的基本原理和理由
- 映射到架构信息库
1）映射到架构景观
2）映射到参考模型
3）映射到标准
4）重新使用评估 - 缺口分析
- 对影响的评估
- 过渡架构
以下各节更详细地介绍了没中架构。
3.15.1 业务架构
业务架构在 B 阶段开发，与业务架构相关的架构定义文档中应解决的主题如下：
- 基准业务架构（如果适用），这是对现有业务架构的描述
- 目标业务架构，包括：
1）组织结构，确定业务地点并将其与组织单位相关联
2）企业目标和目的，针对企业和每个组织单位
3）业务功能，一个详细的递归步骤，涉及将主要功能区域连续分解为子功能
4）商业服务，企业和每个企业单位向其他客户提供的内部和外部服务
5）业务流程，包括措施和可交付成果
6）业务角色，包括技能要求的开发和修改
7）业务数据模型
8）组织和职能的相关性，以矩阵报告的形式将业务职能与组织单位联系起来 - 与选定观点相对应的视图，解决关键利益相关者关注的问题
3.15.2 信息系统架构
信息系统架构在 C阶段开发。与信息系统架构相关的架构定义文档中应涉及的主题如下：
- 基线数据架构（如果适用）
- 目标数据架构，包括：
1）业务数据模型
2）逻辑数据模型
3）数据管理流程模型
4）数据实体/业务功能矩阵
5）与选定观点相对应的数据架构视图，解决关键利益相关者关注的问题 - 基线应用程序架构（如果适用）
- 目标应用程序架构
- 与所选视点对应的应用程序架构视图，以解决关键利益相关者关注的问题
3.15.3 技术架构
技术架构是作为 D 阶段的一部分而开发的。与技术架构相关的架构定义文档中应设计的主题如下：
- 基线技术架构，如果适用
- 目标技术架构，包括：
1）技术组件及其与信息系统的关系
2）技术平台及其分解，展示了实现特定技术“堆栈”所需的技术组合
3）环境和位置，将所需技术分组到计算环境（例如，开发、生产）
4）期望的处理负载和跨技术组件的负载分配
5）物理（网络）通信
6）硬件和网络规范 - 与选定观点相对应的视点，解决关键利益相关者关注的问题
3.16 架构需求规格
阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构、ADM 架构需求管理
架构需求规范提供了一组定量描述，概述了实施项目必须遵守的架构。架构需求规范通常构成实现合同或合同的主要组成部分，以获得更详细的架构定义。
如上所述，架构需求规范是架构定义文档的一个配套，其目的是提供定量的观点。
以下内容在架构需求规范中是典型的：
- 成功的措施
- 架构要求
- 商业服务合同
- 应用服务合同
- 实施指南
- 实施规范
- 执行标准
- 互操作性要求
- IT 服务管理要求
- 约束
- 假设
3.16.1 业务架构请求
在 B 阶段填充架构需求规范的业务架构要求包括：
- 差距分析结果
- 技术要求
作为阶段 B （业务架构）的输出应产生的一组初始技术要求。这些是随后的技术架构工作的驱动因素，应该确定，分类和优先考虑剩余的架构域；例如，依赖性/优先级矩阵（例如，知道交易处理速度与安全性之间的权衡）；列出预期产生的具体模型（例如，表示为 Zachman框架的基元） - 更新业务需求
- 业务场景技术用于发现和记录业务需求
3.16.2 信息架构请求
信息系统架构的要求填充体系的要求规范在 C 阶段包括：
- 差距分析结果
- 数据互操作性要求
- 应用程序互操作性要求
- 业务架构可能需要改变以符合数据和/或应用架构变化的领域
- 将要设计的技术架构的限制
- 如果适用，更新业务需求
- 更新应用程序要求（如果适用）
- 更新数据要求（如果适用）
3.16.3 技术架构请求
在阶段 D 中填充架构要求规范的技术架构要求包括：
- 差距分析结果
- 更新的技术要求
3.16.4 互操作性请求
互操作性的确定贯穿整个 ADM 周期。
3.17 架构路线图
阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构
架构路线图列出了将实现目标架构的各个工作包，并将它们放在时间轴上，以显示从基准架构到目标架构的进度。架构路线图强调了每个工作包在每个阶段的业务价值。有效实现目标架构所需的过渡架构被标识为中间步骤。架构路线图是在 E 和 F 阶段逐步开发的，并通过 B，C 和 D 阶段开发的路线图组件进行开发。
以下内容通常在架构路线图中找到：
- 工作包组合：
1）工作包描述（名称、描述、目标、可交付成果）
2）功能要求
3）依赖
4）与机会的关系
5）与架构定义文档和架构需求规范的关系
6）商业价值 - 实施因素评估和扣除矩阵，包括：
1）风险
2）问题
3）假设
4）依赖
5）行动
6）影响 - 合并差距，解决方案和依赖性矩阵，其中包括：
1）架构域
2）差距
3）潜在的解决方案
4）依赖 - 过渡架构，如果有的话
- 实施建议：
1）项目有效性的标准/措施
2）风险和问题
3）解决方案构建模块(SBB)
3.18 业务场景 (阶段 B 业务架构)
ADM 有自己的方法（一种“方法中的方法”），用于识别和阐明新业务功能中隐含的业务需求，以解决关键的业务驱动因素以及隐含的架构需求。这个过程被称为“业务场景”。业务场景是业务问题的描述，它使得需求可以在整个问题的背景下相互关联。没有这样的描述来作为背景，解决问题的商业价值就不清楚了，潜在解决方案的相关性还不清楚，解决方案存在基于不充分的要求的危险。任何其他重大项目成功的关键因素在于它与业务需求的关联程度，并明确支持企业实现其业务目标。业务场景是帮助识别和了解业务需求的重要技术。该技术可以在商业架构的分层分解中以不同的细节层次迭代使用。通用业务场景流程如下：
- 识别、记录和排列推动项目的问题
- 作为高级架构模型，记录出现问题的业务和技术环境
- 确定并记录期望的目标；成功处理问题的结果
- 确定人类参与者及其在商业模式中的地位，人类参与者及其角色
- 识别计算机参与者及其在技术模型中的位置，计算元素及其角色
- 确定并记录每个角色成功的角色、责任和措施，每个角色所需的脚本以及正确处理情况的理想结果
- 检查鼓励后续架构工作的适用性，并在必要时进行改进
3.19 差距分析
阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构、阶段 E 机会与解决方案
差距分析的技术在 ADM 中被广泛用于验证正在开发的架构。这通常是一个阶段的最后一步。基本前提是突出基线架构和目标架构之间的差距；既故意遗漏、意外遗漏或尚未定义的项目。
步骤如下：
- 在垂直轴上绘制一个矩阵，其中包含基线架构的所有架构构件块（ABB），以及横轴上的目标架构的所有 ABB
- 在基线架构轴上添加标有“new ABBs ”的最后一行，并在目标架构轴上添加标注为“消除的 ABBs”最后一行
- 在基线和目标架构中都有 ABB 的情况下，在交叉单元格中记录“包含”
- 目标架构中缺少基线架构的ABB ，每个都必须进行审查。如果它被正确消除，在适当的“消除”单元格中标记它。如果不是，那么您已经发现了目标架构中的意外遗漏，必须通过在架构设计的下一次迭代中恢复ABB 来解决。
- 如果目标架构中的ABB无法在基线架构中找到，请在与“新”行的交点处将其标记为需要填充的间隙，或者通过开发或购买构件块。
- 练习完成后，“消除服务”或“新服务”下的任何内容都是一个缺口，应该解释为正确消除，或标记为通过恢复或开发/实现功能来解决。
上方差距分析示例表中，显示了基线架构和目标架构之间的差距示例；在这种情况下，缺失的元素是“广播服务” 和“共享屏幕服务”。
3.20 架构视点
阶段 A 架构愿景、阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构
架构师在阶段 A 到阶段 D期间使用 ADM周期中的架构视图和架构视点来开发每个域（业务、数据、应用程序和技术）的架构。“看法”就是你所看到的。一个“观点”是你从哪里寻找的地方；决定你所看到的角度或观点（一个观点业务可以被认为时候一个模式）。视点是通用的，可以存储在库中供重复使用。视图总是特定与它所创建的架构。每个视图都有一个相关的观点来描述它，至少是隐含的。
在视图的内容和模式之间进行这种区分似乎首先是一种不必要的开销，但它提供了在不同架构中重用视点的机制。为了说明架构视图和架构视点的概念，请参考示例，这是一个非常简单的机场系统，有两个不同的利益相关者：飞行员和空中交通管制员
简单机场系统的架构视图和架构视点：
飞行员对系统有一种看法，空中交通管制员有另一种看法。这两种观点都不代表整个系统，因为每个利益相关者的观点都会限制（并减少）每个人对整个系统的看法。驾驶员的视角包括控制器未查看的一些元素，例如，乘客和燃料，而控制器的视图包括飞行员未查看的某些元素，例如，其他飞机。这些观点之间也有共同的要素，比如飞行员和管制员之间的沟通模式，以及飞机本身的重要信息。
视点是包含在视图中的信息的模型（或描述）。在这个例子中，一个观点是飞行员如何看待系统的描述，另一个观点是控制器如何看待系统。飞行员从他们的角度描述该系统，使用他们的位置和矢量模型来往跑道或远离跑道。所有飞行员都使用此模型，并且该模型具有用于捕获信息和填充模型的特定语言。管制员用不同的方式描述系统，使用空域模型和空域内飞机的位置和矢量。同样，所有控制器都使用从通用模型导出的通用语言来捕获和传递与其观点相关的信息。
幸运的是，当管制员与飞行员谈话时，他们使用通用的通信语言。（换句话说，代表各自视点的模型部分相交。）这部分共同语言是关于飞机的位置和矢量，并且对于安全至关重要。所以实质上，每个观点都是一个抽象模型，说明特定类型的所有利益相关者、所有飞行员或所有管制员，如何看待机场系统。
工具的用户界面通常接近与视点相关的模型和语言。飞行员独特的工具是燃料、高度、速度和位置指示器。控制器的主要工具是雷达，常用工具是收音机。
从该示例总结，我们可以看到，一个视图可以通过利益相关者的角度来对系统进行子集化，例如，飞行员与控制器。这个子集可以用称为观点的抽象模型来描述，例如，空中飞行与空间模型。该视图描述以部分专用语言记录，例如“飞行员讲话”与“控制器讲话”，工具被用来帮助利益相关者，并且它们在从观点出发的语言方面相互交流。当利益相关者使用通用工具时，例如飞行员和控制器之间的无线电联系，通用语言是必不可少的。
3.21 架构视图
阶段 A 架构愿景、阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构
架构视图是对系统中的一个或多个利益相关者有意义的整体架构的表示。架构师在阶段 A 到阶段D 期间选择和开发 ADM 周期中的一系列视图，以使架构能够传达给所有利益相关方，并使其能够理解，并使他们能够验证系统将如何解决关注。
3.31.1 在 ADM 中开发视图
选择那种特定的架构视图是开发人员必须制定的关键决策之一。
架构师有责任确保架构的完整性（适用性），以充分解决利益相关方的所有相关问题；以及架构的完整性，在将所有各种观点相互联系方面，令人满意地协调不同利益相关者之间的冲突关注，并展示这样做的权衡（例如，在安全和绩效之间）。
3.22 架构构件块
阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构、阶段 E 机会与解决方案
架构构件块（ABB） 是根据架构连续系列分类的企业架构库中的架构文档和模型。它们在应用ADM期间被定义或选择（主要在阶段 A 、B 、C 和D中）。ABB 的特点如下：
- 他们捕捉架构需求；例如，业务、数据、应用程序和技术要求
- 他们指导解决方案构建模块（SBB）的开发
- ABB 规范的内容至少包括以下内容：
1）基本功能和属性：语意明确，包括安全功能和可管理性
2）互操作性和与其他构件块的关系
3）接口：选择集，提供（API ，数据格式，协议，硬件接口，标准）
4）具有所需功能和命名用户界面的相关构建块
5）映射到业务/组织实体和策略
每个 ABB 应该包含来自企业架构存储库的任何架构文档和模型的声明，这些架构文档和模型可以在架构开发中重新使用。使用 ADM 的构建块的规范是一个渐进的迭代过程。
3.23 解决方案构建块
阶段 B 业务架构、阶段 C 信息系统架构、阶段 D 技术架构、阶段 E 机会与解决方案
解决方案构建块（SBB）涉及解决方案连续系列。它们是企业架构连续系列中标识的架构的实现，可能也是采购或开发。SBB 出现在 ADM 的 E 阶段，首次考虑产品特定的构件。SBB 定义了哪些产品和组件将实施该功能，从而定义实施。他们满足业务需求并且是产品或供应商意识。 SBB 规范的内容至少包括以下内容：
- 特定的功能和属性
- 接口；实施的集合
- 所需的SBB 与所需的功能和所用接口的名称一起使用
- 从SBB映射到 IT 拓扑和操作策略
- 共享属性的规格，例如，安全性、可管理性、可本地化、可伸缩性
- 性能，可配置性
- 设计驱动程序和约束条件，包括物理架构
- SBB 和 ABB 之间的关系
3.24 基于能力的计划
阶段 E 机会与解决方案、阶段 F 迁移计划
E阶段和F阶段是根据基于能力的计划原则定义和规划企业转型的一种详细方法，这是一种专注于业务成果的业务计划技术。它是业务驱动和业务主导的，并结合所有业务领域的必要努力来实现所需的功能。它适应大部分（如果不是全部）公司业务模式，尤其适用于需要潜在响应能力（例如，紧急准备单位）的组织以及相同资源涉及多种能力的组织。通常需要使用业务场景来发现和优化这些功能。
下图显示了基于能力的计划，企业架构和项目组合/项目管理之间的关系。
3.25 迁移计划技术
阶段 E 机会与解决方案、阶段 F 迁移计划
提供了一些支持阶段 E 和 F 的迁移规划的技术，这些技术将在以下各节中描述。
3.25.1 实现因子评价与演绎矩阵
在阶段E 中使用创建实施因素评估和扣除矩阵的技术来记录对架构实施和迁移计划有影响的因素。矩阵应包括一系列因素，它们的描述以及表明在制定计划时必须考虑的行为或约束的扣减（结论）。
典型的因素包括风险、问题、假设、依赖性、行动和影响。下表中显示了一个示例矩阵。
3.25.2 合并的差距，解决方案和依赖性矩阵
创建 合并差距、解决方案和依赖性矩阵的技术允许架构师将领域架构差距分析结果中确定的差距分组，并评估潜在解决方案和依赖关系到一个或多个差距。下表中显示了一个示例，创建工作包时，此矩阵可用作计划工具。所确定的依赖性推动了阶段 E 和 F中的项目创建和迁移计划。
3.25.3 架构定义增量表
通过创建架构定义增量表的技术，架构师可以规划一系列转换架构，在特定时间概述企业架构的状态。如下表所示，应该制定一个表格，列出项目，然后在转换架构中分配增量交付成果。
3.25.4 过渡架构状态演变表
创建过渡架构状态演变表的技术允许架构师使用技术参考模型（TRM），在各个级别显示架构的建议状态。应绘制一张表格，列出企业中使用的 TRM 的服务，转换架构和建议的转换，如下表所示。所有解决方案构建模块（SBB）都应该描述其交付情况以及对这些服务的影响。他们也应该被标记以显示企业架构的进展。在示例中，如果已达到目标功能，则显示为“新”或“保留”；在能力转变为新解决方案的地方，这被标记为“过渡”；并且在能力被替换的地方，这被标记为“替换”
3.25.5 商业价值评估技术
评估业务价值的一种技术是基于价值指数维度和风险指数维度来制定矩阵。下图显示了一个例子。价值指数应该包括符合原则、财务贡献、战略调整和竞争地位等标准。风险指数应包括规模和复杂性、技术、组织能力和失败影响等标准。每个标准应分配一个单独的权重。该指标及其标准和权重应由高级管理层制定和批准。在已知选项之前建立决策标准是很重要的。
商业价值评估矩阵
3.26 实施和迁移计划
阶段 E 机会与解决方案、阶段 F 迁移计划
实施和迁移计划在阶段 E和 F 中制定，并提供实施目标架构项目的时间表。实施和迁移计划包括分为管理投资组合 和计划的可执行项目。实施和迁移战略确定了改变的方法，是实施和迁移计划的一个关键要素。典型内容如下：
- 实施和迁移战略
1）战列实施方向
2）实施测序方法 - 实施项目和投资组合项目
1）将工作包分配给项目和投资组合
2）项目交付的能力
3）里程碑和时间
4）工作分解结构
5）可能包括对现有投资组合、计划和项目的影响，它可能包括：项目章程
- 包括工作包
- 商业价值
- 风险、问题、假设、依赖关系
- 资源需求和成本
- 迁移的好处、确定（包括映射到业务需求）
- 迁移选项的估计成本
3.27 过渡架构
阶段 E 机会与解决方案、阶段 F 迁移计划
如果实现目标架构的变更范围需要增量方法，则在阶段 E 的架构定义文档输出中定义一个或多个转换架构。转换架构将基线和目标架构之间的架构显示为处于架构重要状态的企业。过渡架构用于描述有效实现目标架构所需的过渡目标架构。这些提供了识别沿着路线图实现目标架构的清晰目标的能力。
以下内容在过渡架构中是典型的：
过渡架构：
- 过渡状态的定义
- 每个转换状态的业务架构
- 每个转换状态的数据架构
- 每个转换状态的应用架构
- 每个转换状态的技术架构
3.28 实施治理模型
阶段 E 机会与解决方案、阶段 F 迁移计划、阶段 G 实施治理、阶段 H 架构变更管理
一旦架构定义完毕，就有必要规划实现该架构的转换架构将如何通过实施进行管理。在建立了架构功能的组织内部，可能已经有了一个治理框架，但是具体的流程、组织、角色、责任和措施可能需要逐个项目地定义。
作为阶段 F 的输出而产生的实施治理模型确保项目过渡到实施也顺利地过渡到适当的架构治理。
实施治理模式的典型内容是：
- 治理流程
- 治理组织结构
- 治理角色和责任
- 治理检查点和成功/失败标准
3.29 架构契约/合同
阶段 G 实施治理、阶段 H 架构变更管理
架构契约在阶段 G：实施治理中生成。架构合同是开发合作伙伴和赞助商之间就架构的可交付成果、质量和适用性达成的共同协议。这些协议的成功实施将通过有效的架构来实现。通过实施管理合同管理的方法，将确保以下内容：
- 持续监听系统，用于检查组织内所有与架构相关活动的完整性、变更、决策和审计
- 遵守现有或开发架构的原则、标准和要求
- 根据公认的标准、政策、技术和产品以及架构的运营方面，确定涵盖内部开发的架构开发和实施的所有方面的风险，以便组织可以继续其业务有弹性的环境
- 一套流程和实践，确保在开发和使用所有架构工件方面的问责制、责任和纪律
- 正式理解负责合同的治理组织，其权利级别以及本机构管理下的架构范围
TOGAF 确定了两个示例合同，如下所示：
- 架构设计和开发合同
- 商业用户的架构合同
架构设计和开发合同的典型内容是：
- 介绍和背景
- 协议的性质
- 架构的范围
- 架构和战列原则和要求
- 一致性要求
- 架构开发和管理流程、角色
- 目标架构衡量
- 可交付成果的确定阶段
- 优先联合工作计划
- 时间窗口（s）
- 架构交付和业务指标
G阶段生成的业务用户架构合同的典型内容是：
- 介绍和背景
- 协议的性质
- 范围
- 战列要求
- 一致性要求
- 架构采用者
- 时间窗口
- 架构业务指标
- 服务架构（包括服务级别协议（SLA））
此协议也用于管理 H 阶段企业架构的变更。
3.30 变更请求
阶段 G 实施治理
阶段 H ：架构变更管理中考虑架构变更请求。
在架构实施期间，随着更多事实的公布，原始架构定义和要求可能不适合或不足以完成解决方案的实施。在这些情况下，实施项目有必要偏离建议的架构方法或请求扩展范围。此外，外部因素--例如市场因素、商业战略的变化以及新技术机遇，可能为拓展和完善架构提供了机会。
在这些情况下，可能会提交更改请求以启动进一步的架构工作。更改请求的典型内容是：
- 建议更改的说明
- 拟议变更的理由
- 对拟议变更的影响评估，包括：
1）参考具体要求
2）迄今为止的要求的利益相关者优先权
3）阶段将被重新审视
4）领导需求优先级的阶段
5）阶段调查结果和修改后的优先事项
6）关于需求管理的建议 - 存储库参考号码
3.31 合规性评估
阶段 G 实施治理、阶段 H 架构变更管理
一旦定义了架构，就必须通过实施来管理架构，以确保原始架构愿景得到适当实现，并将任何实施课程反馈到架构过程中。阶段 G 中实施项目的定期合规审查提供了一个机制来审查项目进展情况，并确保设计和实施与战略和架构目标保持一致。
合规性评估的典型内容是：
- 项目进展和状态概述
- 项目架构/设计概述
- 完成的架构清单
1）硬件和操作系统清单
2）软件服务和中间件清单
3）应用清单
4）信息管理清单
5）安全清单
6） 系统管理清单
7）方法和工具清单
3.32 需求影响评估
阶段 H 架构变更管理、ADM 架构需求管理
在整个 ADM 中，收集有关架构的新信息。随着这些信息的收集，新的事实可能会被揭露，从而使架构的现有方面失效。需求影响评估当前的架构要求和规范，以识别应该做出的改变以及这些改变的影响。
它记录了对变化的评估以及对架构进行更改的建议。推荐内容如下：
- 参考特定要求
- 利益相关方迄今为止的优先要求
- 重新审视阶段
- 领导需求优先级的阶段
- 阶段调查的结果和修订的优先事项
- 关于需求管理的建议
- 存储库参考号码
这些通常是作为对变更请求的回应而产生的。
4 适应 ADM 的指导原则
4.1 介绍
ADM 是用于架构开发的通用方法，旨在满足大多数系统和组织要求。但是，经常需要修改或扩展ADM 以适合特定需求。应用 ADM 之前的任务之一是检查流程及其输出的适用性，然后根据各个企业的情况对其进行定制。此活动很可能会产生“企业特定的” ADM。
有很多原因想要针对单个企业的情况来定制ADM 。某些原因概述如下：
- 一个重要的考虑因素是，ADM 阶段的顺序在一定程度上取决于相关企业内部架构规范的成熟度。例如，如果企业架构的商业案例得不到很好的认可，那么创建一个架构愿景是必不可少的；接下来需要详细的业务架构来为剩下的架构工作定义业务案例，并确保主要利益相关者积极参与该项工作。
- 阶段的顺序也可以由企业的业务和架构原则来定义。例如，业务原则可能要求企业准备调整业务流程以满足打包解决方案的需求，以便快速实施，以便快速响应市场变化。在这种情况下，业务架构（或至少完成它）可能会完成信息系统架构。
- 企业可能希望将 ADM 与其他企业架构结合使用或定制，该框架具有特定垂直部门特定的可交付成果集：政府部门、国防部门、电子商务部门、电信部门等。
- ADM 是构成企业公司治理模式的众多企业流程之一。ADM 是对其他标准计划管理流程的补充和支持。企业将调整ADM 以反映与其他管理流程的关系，并依赖与其他管理流程。
- ADM 正被授权由外包领域的主要承包商或主要承包商使用，需要量身定做，以便在承包商的现有做法和承包企业的要求之间达成妥协。
- 企业是一个中小型企业，希望使用ADM 的“精简版”，这种版本更适合于这种环境中典型的资源和系统复杂程度的降低。
- 企业规模庞大而且复杂，在整体协作业务框架内包含许多独立但相互关联的“企业”，架构方法需要适应这种情况。这些企业通常不能作为单一实体成功对待，需要更多联合方式。
ADM 过程也可以适应于处理许多不同的使用场景，包括不同的过程风格（例如迭代的使用）以及特定的专业架构（如安全性）。
4.2 针对 ADM 应用迭代
ADM 支持许多可以被称为迭代的概念。迭代开发全面的架构景观：
- 项目将从阶段 A 开始到阶段 H 遍历整个ADM 周期。
ADM 的每个周期都将受到架构工作请求的约束。架构输出将填充架构景观，或者扩展所描述的景观，或者在需要的地方更改景观。 - 分开的项目可能会同时运行自己的 ADM 周期，并在不同的项目之间建立关系
- 一个项目可能会触发启动另一个项目
通常，当更高层架构计划识别需要更详细架构的机会或解决方案时，或者项目识别其架构工作请求范围之外的地形影响时，通常会使用这种方法。
ADM 周期内的迭代：
- 项目可能同时运行多个ADM 阶段。通常，这用于管理业务架构、信息系统架构和技术架构之间的相互关系。
- 项目可以在ADM 阶段之间循环，涵盖多个阶段的计划周期。通常，这用于在高级架构不存在以提供上下文和约束时用于汇聚在详细的目标架构上。
- 项目可以回到之前的阶段，以便用新的信息对工作产品进行循环和更新。通常，当实现细节和变更范围触发利益相关者需求的变更或重新排序时，这通常用于可执行架构路线图或实施和迁移计划的融合。
通过迭代来管理架构能力：
- 处理阶段 A 中的架构工作请求的结果可能需要对初步阶段进行新的迭代以调整组织的架构功能。
- 阶段 H 中确定的变更可能需要对初步阶段进行新的迭代以调整组织的架构能力
所有这些技术都是 ADM 的有效应用程序，可用于确保架构开发方法足够灵活以适应其他方法和架构。 TOGAF 包括考虑影响应以何种程度迭代使用 ADM 的组织因素，不同类型的迭代以及ADM 阶段到用于架构定义的迭代周期的映射。
下图显示了一个建议的跨越多个ADM 阶段的迭代循环：
- 架构能力迭代支持所需架构能力的创建和演变。这个周期包括通过建立或调整架构方法、原则、范围、愿景和治理，为特定目的或架构参与类型最初动员架构活动。
- 架构开发迭代允许通过循环或集成业务、信息系统和技术架构阶段来创建内容。这些迭代确保了架构被视为一个整体。在这种类型的迭代中，利益相关者评论通常更宽泛。随着迭代收敛于目标，扩展到机遇和解决方案以及迁移计划阶段确保在架构最终确定时考虑架构的可实施性。
- 过渡规划迭代支持为定义的架构创建正式的变更路线图。
- 架构治理迭代支持对定义的目标架构进展的变更活动的治理。
TOGAF 定义了两种风格的架构定义：
1）基线优先：以这种风格，首先评估基线结构。当目标解决方案不清楚时，这个过程是适用的。
2）目标优先：以这种风格，详细阐述目标架构，然后将其映射回基线，以定义更改活动。当目标国家达到高层协议并且企业希望避免将目前的商业惯例扩散到目标中时，这个过程是合适的。
TOGAF 将这两种风格映射到迭代周期，如下图所示：
迭代基线优先的架构定义的活动
迭代目标优先的架构活动定义
备注：颜色越深标识越是核心焦点活动
TOGAF 还描述了迭代的分层应用，其中每个 ADM 周期发生在单个架构描述级别。这种针对ADM 的方法使用一个ADM 周期的迁移计划阶段来启动新的更详细的架构项目，这也将开发架构。这种类型的迭代突出了对更高级架构的需求，以指导和约束更详细的架构。它还强调了完整的架构景观是由多次ADM 迭代开发的。这种方法如下图所示：ADM过程的层次结构示例
4.3 在架构景观中应用 ADM
在典型的企业中，许多架构将在任何时间点在架构景观中进行描述。一些架构将解决非常具体的需求；其他人将更加普遍。一些将解决细节；有些将提供一个大的图片。为了解决这种复杂性，TOGAF使用层次和企业连续的概念为组织架构景观提供了一个概念框架。
级别提供了一个框架，将架构景观/愿景划分为三个粒度级别：
- 战略架构为运营和变革活动提供了一个组织框架，并允许在行政层面进行方向设置
- 分段架构为运营和变更活动提供了一个组织架构，并允许在程序或组织级别进行方向设置和开发有效的架构路线图。
- 能力架构为变革活动提供了一个组织架构，并为实现能力增量而制定有效的架构路线图
显示了架构景观分类模型的总结
TOGAF 标准描述了架构师可能需要执行的参与类型，以及如何使用 ADM 来协调各个不同层次的架构师团队的活动。它还提供了两种将 ADM 用作支持架构层次结构的过程的策略：
- 可以通过单个 ADM 过程中的迭代开发不同级别的架构
- 可以通过同时执行的 ADM 进程层次来开发不同级别的架构
在极端的规模，这两种选择中的任何一种都可以完全采用。实际上，架构师可能需要将每个元素进行混合以适应其架构工作请求的确切要求。
4.4 采用不同的架构风格使用 ADM
架构风格在焦点、形式、技术、材料、主题和时间段方面各不相同。有些风格被认为是通用流行的，而另一些风格则聚焦在企业架构的特定方向上。 TOGAF 标准及其 ADM 被设计为通用的，旨在广泛用于各种环境。它们可以很容易地适应多种架构风格。
许多架构风格被开发出来，以解决从业者面临的关键问题，并演示如何在定义的上下文环境中使TOGAF 框架更加相关联。这些都包括在 TOGAF 库中。其中一些是由特定领域工作的开放小组论坛和工作组制定的，并在《指南》、《白皮书》、《标准》中发表。
5 架构内容框架
架构内容框架是架构制品的一个结构化的元模型。
5.1 架构内容框架概述
在 ADM的执行过程中，将会产生一些结果，比如流程、架构要求、项目计划、项目合规评估等。为了能够整理和呈现这些主要工作产品的一致性结构化的方式，有必要建立一个架构内容框架来放置它们。这形成了参考和标准分类，并且有助于促进组成通常被称为“企业架构”的组成工作产品之间的关系的结构化。
TOGAF 提供的架构内容允许 TOGAF 在企业内用作架构的独立框架。但是，还存在其他内容框架（如ArchiMate 和 Zachman框架 ），并且预计一些企业可能会选择与 ADM 一起使用外部框架。在这些情况下， TOGAF 架构内容框架为 TOGAF 内容映射到其他框架的元模型提供了有用的参考和起点。
为了协调新工作产品的分类以及其他内容框架（包括任何现有的分类架构工作产品）相关的潜在需求，架构内容框架使用以下三个类别来描述其中的架构工作产品的类型使用环境：
- 交付物是合同规定的正式工作产品，通常由其利益相关方进行审查，同意并签署。可交付成功通常代表项目的产出。
- 工件/产出物/制品是描述架构方面的工作产品。工件通常被分类为目录（事物清单），矩阵（显示事物之间的关系）和图表（事物的图片）。示例包括需求目录，业务交互矩阵和用例图。架构交付物可能包含许多工件，并且工件将形成架构存储库的内容。
- 一个构建块表示了业务、 IT 或架构能力的（潜在可重用的）业务构件，它可以和其他构建组合起来共同交付架构或解决方案。
构建块可以在不同细节级别上被定义，并且既可以与“架构”相关，也可以与“解决方案”相关，通常用架构构建块的内容，解决方案构建块表示用于实施所需能力的构件。
显示了可交付成果、工件和构建块之间的关系
总结：架构模型找构建，过程产出叫制品，结果产品交付物，存储库中为重用
5.2 内容元模型
架构内容框架建立在标准内容元模型的基础上，标准内容元模型对架构中存在的所有类型的构建块进行了定义。内容元模型的一个高层概念如下图所示。这个元模型图显示了可以如何去描述这些构建块以及它们之间如何相关联。
在创建架构和管理架构时，有必要考虑业务服务、参与者、应用、数据实体和技术等关注点。内容元模型强调了这些关注点，展示它们之间的关系，并识别可用于以一致的、结构化的方式表示它们的制品/工件。
此外，对于希望使用架构工具来实施其架构的组织，内容元模型还可以用来为其提供指导。
内容元模型概念目标与目标
每个人做事都会有具体目标（目的），而这个目的又应该是从属于一个远大目标
5.2.1 核心与扩展
该模型的结构考虑了核心和扩展内容，其中核心元模型提供了支持制品可追溯的最小架构内容集，并且插入了扩展以支持可能需要的任何更具体或更深入的建模。
扩展确保对特定的领域给予特别的关注。所有的扩展模块都是可选的，并且应在 ADM迭代的预备阶段就被选定，以满足组织的特殊需要。 TOGAF 标准中描述的扩展都只是用于指导的，可以根据需要进行相应的增加或裁剪。
5.3 架构制品
TOGAF 标准描述了围绕架构制品的术语，然后描述了建议为 ADM 中的每个阶段创建的构件。
5.3.1 基本概念
与架构视图相关的概念：
| 概念 | 定义 |
| 系统 | 为达到一个或多个规定目的而组织起来的相互作用的元素的组合 |
| 架构 | 系统在其环境中的基本概念或特性体现在其要素、关系以及设计和演进的原则中 |
| 架构描述 | 一种用于表示架构的工作产品；一组架构视图和模型，它们共同记录架构 |
| 干系人/利益相关者 | 对某一系统感兴趣的个人、团队、组织或阶层 |
| 关注 | 一个或多个利益相关者对系统的兴趣点。关注可能涉及到系统功能运行、开发或操作的任何方面，包括性能、可靠性、安全性、分布式和可演进性等考虑 |
| 架构视图架构 | 从一组相关的关注嗲的角度来表示一个系统 |
| 架构视点 | 一种特定类型的架构视图的约定的规范 |
架构描述的基本概念
5.3.2. 目录、矩阵和图
虽然内容元模型用于支持架构信息的构建，但大多数利益相关者不需要或希望以这种方式了解架构内容框架中包含的详细信息。因此，使用目录、矩阵和图表是为了便于呈现架构信息，因此可以更容易地将其用于参考和治理的目的。
目录是特定类型或相关类型的构件块列表，矩阵是显示两个或多个实体之间关系的网络，图是企业架构内容的图形渲染。
综上所述，ADM 开发的架构的结果由许多定义的 ABBS组成，这些 ABBS 填充到架构目录中，并在架构矩阵中的那些构建块之间指定了关系，并且/或者还以图表的形式表示，以满足利益相关者的关注。
5.4 架构交付物
为了更好地定义 ADM 中所需的活动，TOGAF 提供了一套典型的架构交付物的基准，这条基准交付物可以作为组织裁剪 ADM的起点。更多的细节请参见第3章。
5.5 构建块
TOGAF 中的构建块包括架构构建块（ABBs）和解决方案构建块（SBBs）
“构建块”是TOGAF 和 ADM 中大量用到的一个术语。构建块就是被定义用来满足业务需求的一个功能包。如何将功能、产品和自定义开发组装车构建块，在不同的架构中千差万别。每个组织必须决定，如何对构建块进行组装对它自身来说才是最合适的。好的决策会大大提升遗留系统集成的效率，并在创新新的系统和应用时带来互操作性和灵活性。
系统是从构建块的集合中构建出来的，因此大部分构建块不得不和其他构建块交互。不管怎么说，将构建块的接口发布出来并保持合理的稳定是非常重要的。
根据架构开发到达的阶段，构建块可以在不同细节级别上被定义。
例如，在早期阶段，构建块可以仅仅包含一组功能，如一个客户数据库和一组数据检索工具。在这种功能级别上定义的构建块在 TOGAF 中叫作架构构建块（ABBs）。在后续阶段，真正的产品或定制开发会替代这些简单的功能定义，这时的构建块就叫作解决方法构建块（ABBs）。
在 ADM 中，对构建块进行不断修订和说明的关键阶段和步骤总结如下图所示：架构构建块和 ADM周期中的用法
在阶段 A 中，最早的构建块定义从架构愿景中相对抽象的实体开始。
在阶段 B 、C和D 中，业务、数据、应用和技术架构中的构建块根据一套共同的步骤模式被不断修订。
最后，在阶段 E 中，构建块变得更加与具体实现相关，最后解决方案构建块（SBBs）被识别出来以解决差距。
6 企业的连续系列
6.1 企业连续系列概览
如下图所示，企业连续系列提供了用于构建“虚拟”存储库的模型，并提供了对架构和解决方案工件进行分类的方法，显示了不同工件的发展方式以及如何重复使用它们。它填充了架构资产及其可能的解决方案（模型、模式、架构描述等）。这些资产和解决方案可以从企业内部或整个行业中提取，并用于构建架构。
企业连续性系列
我们在架构和其可能的解决方案之间进行了清晰地划分，于是就有了所谓架构连续系列和解决方案连续系列。如上图所示，它们之间的关系是前者对后者进行指导和支持。
企业连续系列支持两个一般性的思想：一是尽可能的重用，特别是避免重新发明；二是帮助沟通。架构和解决方案连续系列中的资产都根据从一般到特殊的方式进行了组织，目的是提供一种一致的语言来有效地表达架构之间的差异。清楚自己在连续系列中处于什么位置可以帮助每个人进行有效的沟通。当同一组织的不同部门甚至是不同组织在讨论构建企业架构中的概念和术语时，企业连续系列的使用消除了沟通中的歧义。理解架构也有助于更好地理解解决方案。能够去解释解决方案背后的一般性概念，就能够更容易理解可能存在的一些冲突。由于企业连续系列的使用通常都伴随者相关联的架构和解决方案资产的增加，因此组织可以直接从重用中受益。
6.1.1 企业连续性和架构重用
“企业内”资产的例子，比如以前架构工作的交付物，这些交付物是可以重用的。“整个 IT 行业”的资产的例子，比如那些已存在或正不断出现的、各种各样的行业参考模型和架构模式，包括那些高度抽象的（如 TOGAF 技术参考模型）；那些具体到 IT 某个方面的（如 web service 架构）；那些具体到某些信息处理类型的（如 电子商务）；以及那些具体到某些垂直行业的（如 来自零售行业的 ARTS 数据模型）。这些资产中的哪些资产一个具体的企业会考虑成为其企业连续系列的一部分，这类决策通常会构成这个企业整体架构治理职能的一部分。
6.1.2 在 ADM 中使用企业连续系列
在 ADM 中，描述了一个从 TOGAF 基础架构逐步过渡到一个特定组织架构（或一套架构）的过程。这个基础架构是对通用服务和功能的高度抽象的描述，在此基础上，通过添加来自企业连续系列中的相关架构资产、构件和构建块，可以构建出特定的架构构建块（ABBs）。在整个 ADM 过程中的相应地方，都有提醒告诉架构师应该使用哪些架构资产。除了基础架构之外，TOGAF 还提供了另外一个参考模型以供纳入某个特定组织的企业连续系列中去：集成信息基础设施参考模型
6.2 架构分区
在一个典型的企业中，在任一个时间点都可能同时存在多个架构。某些架构会处理一些特殊的需求；而另外一些则更为通用。某些架构处理细节；而另外一些则提供概览。同样地，也会同时有多个解决方案正在被使用或正在被考虑使用，以满足企业的需要。
架构被分割的原因如下：
- 在一个单一的架构中处理所有的问题过去复杂。
- 不同的架构互相间存在冲突（例如，由于企业的状态会随着时间而变化，来自于某个时间段的架构可能会和另一个时间段的架构冲突）。
- 不同的团队需要同时在架构的不同元素上工作 ，而对架构的分割使得某个架构师的团队能够拥有并开发架构的某个片段。
- 有效的架构重用要求将架构模块化，以便将这些模块化的架构分段合并进更大的架构和解决方案中去。
为架构提供明确的分区模型是不切实际的。每个企业都需要采用反映其自身运营模式的分区模型。 TOGAF 包括分区架构时可以应用的分类标准，以及初步阶段内用于建立分区的活动指南。
初级阶段支持架构分区的步骤如下：
- 确定企业内架构的组织结构
- 确定每个常设架构团队的责任
- 确定架构之间的关系
初步阶段完成后，应该理解进行架构的团队。每个团队都应该有一个明确的范围，团队和架构之间的关系应该被理解。
显示了将团队分配到架构范围
6.3 架构知识库
架构存储库的概念对企业连续系列进行了支持，它可以用来存储由ADM 创建的、不同抽象层次上的、不同种类的架构输出。 TOGAF 通过这种方式，促进了不同层次的利益相关者和实践者之间的理解和协作。
从这个意义上讲，可以把 ADM 看作是在组织的整体治理框架之下、在组织的多个层次上运作、产生了协调一致的输出并存放到架构存储库中的过程生命周期的描述。企业连续系列为正确理解架构模型提供了一个很有价值的上下文：
它展示了构建块和它们之间的相互关系，并展示了一个架构开发周期中的约束和需求。
TOGAF 架构存储库的结构
架构存储库中的主要构件如下：
- 架构元模型（Architecture Metamodel）描述了经组织裁剪的架构框架的应用方式，包括一个架构内容的元模型
- 架构能力（Architecture Capability）定义了支持架构存储库治理的参数、结构和流程
- 架构景观（Architecture Landscape）展现了当前组织内使用的构建块的架构视图（如 一份在用的应用系统的列表）。景观很可能存在于多个抽象级别上，以满足不同的架构目的
- 标准信息库（Standard Information Base，SIB）捕获新的架构必须符合的标准，可包括行业标准、选定供应商的产品和服务或已在组织中部署的共享服务
- 参考库（Reference Library）提供指引、模板、模式和其他形式的参考资料，可用来加速企业新架构的创建
- 治理日志（Governance Log）提供整个企业内的治理活动的记录
6.3.1 企业知识库
架构知识库是更广泛的企业知识库的一部分，当架构知识库包括连接企业架构信息和制品间的联系，有相当数据的企业知识库支持这个架构。这些可以包括开发知识库、特定运行环境、指令和配置管理知识库
7 架构能力框架
本章对 TOGAF 能力框架进行了简要介绍
架构能力框架的整体结构
7.1 创建架构能力
在组织内建立架构能力的指南
组织内实现任何能力需要设计四个域架构：业务、数据、应用程序和技术。因此，在组织内建立架构实践需要设计：
- 架构实践的业务架构，重点介绍架构治理、架构过程、架构组织结构、架构信息需求、架构产品等
- 数据架构，定义组织的企业连续系列和架构库的结构
- 应用程序架构，指定启用架构实践所需的功能和/或应用程序服务
- 技术架构，指定架构实践的基础结构要求以支持架构应用程序和企业连续系列
7.2 架构治理
架构能力框架包含架构治理的框架和指导原则。架构治理是企业架构和其他架构在企业范围内进行管理和控制的实践。它包括以下内容：
- 实施对所有架构组件和活动的创建和监控进行控制的系统，以确保在组织内有效地引入实施和演进架构
- 实施一个系统来确保符合内部和外部标准以及监管义乌
- 在商定的参数范围内建立支持上述流程的有效管理的流程
- 建立并记录影响企业架构的决策结构；这包括为决策提供输入的利益相关者
- 制定实践，确保对组织内外明确确定的利益相关者群体负责
7.3 架构委员会
建立和运营企业架构委员会的指导原则
企业架构不仅仅是应用 ADM 过程产生的工件。使组织按照架构中规定的原则行事需要一个决策框架。架构能力框架为建立和运营企业架构委员会提供了一套指导方针。架构委员会负责运营项目，并且必须能够在可能发生冲突的情况下作出决定，并对做出这些决定负责。因此，它应该是架构中所有关键利益相关者的代表，并且通常由负责审查和维护整个架构的一组管理人员组成。架构委员会成员涵盖架构、业务
架构委员会可以对其负责和负责的问题是：
- 为所有关于架构变化的决策提供基础
- 子架构之间的一致性
- 识别可重复使用的组件
- 企业架构的灵活性；满足业务需求并利用新技术
- 执行架构合规性
- 提高组织内部架构规范的成熟度
- 确保采用以架构为基础的发展纪律
- 支持可视化升级功能以进行跨界决策
架构委员会还负责运营项目，如 架构合同的监测和控制，以及治理项目，如 生成可用的治理材料。重要任务是：
- 分配架构任务
- 正式批准架构产品
- 解决架构冲突
7.4 架构合规性
确保项目符合架构的指导原则
使用架构来组织 IT 开发意味着 IT 项目应该遵循架构路线图。如果情况并非如此，那么一定有充分的理由。
要确定是否属于这种情况，应采用架构合规策略并采取特定措施以确保符合架构。架构能力框架包含一系列确保项目符合架构的流程、指导方针和清单，其中包括：
- 项目影响评估，说明企业架构如何影响组织内的主要项目
- 架构合规性审查流程，这是审查项目是否符合企业架构的正式流程
合规评审流程
7.5 架构技能框架
架构能力框架为从事企业架构工作的员工提供了一套角色、技能和经验规范。
“企业架构”和“企业架构师”在当今 IT 行业中被广泛使用但术语不明确。它们被用来表示在各种架构领域中应用的各种实践和技能。需要更好的分类来更加隐含地了解正在描述什么类型的架构师/架构。
这种缺乏统一性会导致寻求招聘或指派/促进员工填补企业架构领域职位的组织的困难。由于术语的用法不同，寻求招聘的人和寻求填补企业架构师各种角色的人之间往往存在误解和沟通不畅。TOGAF 架构技能框架试图通过提供内部或外部人员所需的架构技能和熟练水平的定义来解决这一需求，这些人员将执行 TOGAF 框架中定义的各种架构角色。技能类别包括：
- 通用技能，通常包括领导力、团队合作、人际技能等
- 业务技能和方法，通常包括业务案例、业务流程、战略规划等
- 企业架构技能，通常包括建模、构建块设计、应用程序和角色设计、系统集成等
- 计划或项目管理技能，通常包括管理业务变更、项目管理方法和工具等
- IT 常识技能，通常包括代理应用程序、资产管理、迁移规划、 SLA等
- 技术 IT 技能，通常包括软件工程、安全、数据交换、数据管理等
- 法律环境，通常包括数据保护法、合同法、采购法、欺诈等