【声明】

本文档从淘宝购得，以作为togaf9.2认证考试自学之用，如有侵权请联系我处理。

来源：https://item.taobao.com/item.htm?spm=a230r.1.14.22.47b2145fq4djLU&id=646029334526&ns=1&abbucket=19#detail

第一部分：引言

1 第一章 简介

TOGAF标准是企业架构的框架。任何希望开发企业架构以便在该组织内使用的组织都可以免费 使用（见1.4.1节）。

TOGAF标准由The Open Group成员制定和维护，在架构论坛内开展工作（请参阅www.opengroup.org/Architecture）。TOGAF的第1版初始开发是1995年，基于美国国防部（DOD）制定的信息管理技术架构框架（TAFIM）。DOD给予The Open Group明确的许可和鼓励以在TAFIM上创建 TOGAF TAFIM本身是在美国政府投资数百万美元支持下经多年开发工作而形成的成果。

从这个良好的基础开始，The Open Group架构论坛的成员已经开发了多个TOGAF连续版本，并将每个版本发布在The Open Group公共网站上。如果是初次接触本版本基于TOGAF标准的以前版本，并更新了架构从业者可以获得的材料，以帮助他们建立一个可持续的企业架构。白皮书和指南的工作描述了如何将该标准与其他框架和架构风格结合使用，这突出了标准的普遍框架部分，以及行业、架构风格和特定用途的工具、技术和指南。这项工作体现在TOGAF架构存储库。

尽管所有的TOGAF文件作为一个整体协同工作，但是预计组织将在采用期间对其进行定制，并有意地选择一些元素，定制一些元素，排除一些元素和创建其他元素例如，一个组织可能希望釆用TOGAF元模型，但选择不使用关于如何开发内部技术架构的任何指导，因为他们是云计算和Open Platform3.0™的重量级消费者。

无论您过去的经验如何，建议你阅读实施概述（见1.3节），在那里你会找到一个关于The Open Group对企业架构理解概要和对基本问题的回答，例如：

■ 为什么需要企业架构？

■ 为什么使用TOGAF标准作为企业架构的框架？

1. 本文档结构

本文档的结构反映了企业内部架构功能的结构和内容，如图1-1所示。

image.png

Figure 1-1 Structure of the TOGAF Standard
图1-1 TOGAF标准的结构

本文档共有六个部分：

第一部分（简介）本部分对企业架构的关键概念，特别是TOGAF方法进行了概要介绍。它包含整个标准中使用的术语的定义。

第二部分（架构开发方法）这部分是TOGAF框架的核心部分。它描述了TOGAF架构开发方法（ADM）,这是一种逐步开发企业架构的方法。

第三部分（ADM指南和技术）这项技术包含了一系列指南和技术，可用于应用TOGAF方法和TOGAF ADM方法。其它指南和技术可在TOGAF架构存储库查阅。

第四部分（架构内容框架）本部分描述了 TOGAF内容框架，包括一个用于架构制品的结构化元模型、可复用的架构构建块（ABB）的使用以及典型架构交付物的概述。

第五部分（企业连续统一体和工具）本部分论述对企业内架构活动的各种输出进行分类和存储的适用分类法和工具。

第六部分（架构能力框架）本部分讨论在企业中建立和运行架构功能所需的组织、流程、技能、角色和责任。

将TOGAF标准分为这些独立部分的意图是，可以详细考虑不同的专门领域，并可能独立地加以处理。尽管所有部分作为一个整体一起工作，但是选择釆用某些特殊部分而排除其余部分，也是可行的。例如，一个组织可以釆用ADM过程，但选择不使用任何与架构功能相关的材料。

作为一个开放的框架，鼓励这种使用，特别是在下列情况下：

■ 那些不熟悉TOGAF并希望逐步釆用TOGAF概念的组织，期望在初期釆用时关注本规范的某些特殊部分，并在之后将其他领域列入考虑范围。

■ 那些已部署架构框架的组织，可能选择将这些框架与TOGAF规范的一些方面合并。

1. TOGAF架构存储库的结构

伴随本标准的是一组指导材料，称为TOGAF架构存储库，用于支持TOGAF方法的应用。TOGAF架构存储库是一个参考库，包含了指导方针、模板、模式和其他形式的参考资料，以加速为企业创建新的架构。

TOGAF 架构存储库是由 Open Group Architecture Forum 管理。

库资源分为四个部分：

■ 第1节 基础文件

■ 第2节 通用指导和技术

■ 第3节 特定行业的指导和技术

■ 第4节 特定组织的指导和技术

如果库内的资源适用于部署TOGAF ADM,并明确提及TOGAF标准中的“锚点”，则将它们归类为库内的依存文件。就如何利用标准中描述的特性提供指导的资源被归类为支持性文件。一般而言，与企业架构有关的资源，如果没有具体提到TOGAF标准，则被归类为一般文件。

1. 综述

本节提供了企业架构的实施概述、企业架构的基本概念（不仅仅是IT架构的另一个名称）以及为什么需要它。报告概述了建立企业架构和采用TOGAF方法实现这一目标的好处。

什么是企业？

TOGAF标准认为，"企业"是所有具备共同目标的组织的集合。

例如，企业可以是：

■ 整个公司或公司的部门

■ 政府机构或单个政府部门

■ 通过共同所有权联系在一起的地理位置遥远的组织

■ 共同努力创建共同或可共享的交付物或基础设施的国家或政府集团

■ 合作企业的伙伴关系和联盟，如联盟或供应链

"企业架构"中的术语"企业”一词可以适用于整个企业，包括企业的所有业务活动和能力、构成企业的整个基础设施和治理的信息和技术，或者适用于企业内部的一个或多个特定领域。在这两种情况下，架构都跨越多个系统和企业内的多个功能组。

混乱往往是由于"企业"一词不断演变的性质引起的。如今，大型企业经常包括合作伙伴、供应商和客户。如果目标是整合一个扩展的企业，那么企业就包括合作伙伴、供应商、客户以及内部业务部门。

企业运营模型概念对于确定组织内企业架构的性质和范围是有用的。许多组织可以包括多个企业，并且可以开发和维护许多独立的企业架构来满足每一个企业的需求。这些企业之间往往有许多共同之处，包括流程、职能和信息系统，而且在使用共同架构框架方面往往有更大的潜力。例如，一个共同的框架可以为开发共同的构建块和解决方案提供基础，也可以为集成和重复使用业务模型、数据、信息和数据提供可共享的架构存储库。

为什么需要企业架构？

企业架构的目的是在整个企业范围内优化通常分散的流程（手动和自动）遗留下来的问题，将其转化为一个集成的环境，这种环境可以改变和支持业务战略的交付。

今天的首席实施官们知道，有效的信息管理和利用以及数字转型是企业成功的关键因素，也是实现竞争优势不可或缺的手段。企业架构通过为数字能力的演变和覆盖提供战略背景，以满足不断变化的商业环境需求，从而满足这一需求。

例如，社交媒体、物联网和云计算的飞速开发从根本上提高了企业创造新市场机会的能力。

此外，良好的企业架构使您能够在业务转型和持续运营效率之间实现正确的平衡。它允许单个业务部门在追求不断开发的业务目标和竞争优势时安全地进行创新。同时，企业架构使本组织的需要能够通过一个综合战略得到满足，该战略允许企业内外尽可能最密切的协同作用。

企业架构有什么好处？

一个有效的企业架构可以为组织带来重要的效益。企业架构的具体好处包括：

■ 更高效的业务运营：

• 业务运营费用降低
• 更加敏捷的组织
• 跨组织共享的业务能力
• 减少变革管理费用
• 更灵活的劳动力
• 提高企业生产力

■ 更高效IT运营：

• 通过数字能力扩展企业的有效覆盖范围
• 将企业的所有组成部分置于一个统一的环境
• 降低软件开发、支持和维护成本
• 提高应用程序的可移植性
• 改善互操作性，简化系统和网络管理
• 提高解决企业级关键问题（如安全）的能力
• 更容易地升级和交换系统组件

■ 提高现有投资的回报，降低未来投资的风险：

• 降低业务和IT的复杂性
• 最大化现有业务和IT基础设施的投资回报。
• 灵活地制定、购买或外包业务和IT解决方案
• 降低新投资的总体风险和拥有成本

■ 更快、更简单和更便宜的釆购：

• 采购决定更简单，因为有关采购的信息可以在一个连贯的计划中随时提供
• 釆购流程更快速使釆购速度和灵活性最大化，而无需牺牲架构整体一致性。
• 采购多样化、多厂商开放系统的能力。
• 获得更多经济能力的能力

具体什么会促使企业架构的开发？

典型情况下，对业务转型需要或彻底的基础设施变革的准备，可以启动企业架构的审查或开发。通常情况下，关键人员识别出为满足新业务目标所需要变革的领域。在变革过程中，这些人员通常被称为“利益相关者”，架构师的作用是通过以下方式应对其关注点：

■ 识别和细化利益相关者的需求。

■ 开发多个表明要如何应对关注点和需求的架构视图。

■ 展示在协调不同利益相关者关注点的潜在冲突中要做出的权衡。

如果没有企业架构，要考虑并满足所有关注点和需求几乎是不可能的。

什么是架构框架？

架构框架是一种基础架构或一组结构，可用于开发广泛的架构。它应该描述一个方法，以一组构建块的形式设计企业的目标状态，并说明构建块如何组合在一起。它应该包含一套工具并提供通用的词汇。它还应该包括可用于实现构建块的推荐标准和兼容产品的列表。

为什么使用TOGAF标准作为企业架构的框架？

TOGAF标准是在整个社区的共同努力下制定的。在企业架构中使用TOGAF标准的结果是一致的，反映了利益相关者的需求，釆用了最佳实践，并充分考虑了当前需求和业务的预期未来需求。

开发和维护企业架构是一个复杂的技术过程，涉及组织中的许多利益相关者和决策过程。TOGAF标准在规范和降低架构开发过程的风险中起着重要作用。TOGAF标准提供了价值增值的最佳实践框架，并使组织能够制定可行且经济的解决方案来解决其业务问题和需求。

谁会从使用TOGAF标准中受益？

任何正在从事或计划从事支持业务转型的企业架构的开发和实施的组织，均会从TOGAF的使用中受益。寻求无边界信息流「吊的组织可以使用TOGAF标准来定义和实施体系和流程，以便允许在企业内部和企业之间访问集成信息。

使用TOGAF标准设计和实现企业架构的组织可以确保设计和采购规范能够促进开放系统的实现，从而在降低风险的情况下实现开放系统的好处。

1. TOGAF标准使用

1.4.1使用条件

TOGAF标准可免费在线查看，无需许可。或者，可以下载和保存许可证，如TOGAF信息网站所解释的那样。

无论在哪种情况下，任何希望这样做的组织都可以自由地使用TOGAF标准，以开发一种在该组织内使用的架构。未经版权所有人事先许可，不得以任何形式或以任何方式（电子、机械、影印、录音或其他方式）将该文件的任何部分复制、储存在检索系统中，或以任何方式传送，以作任何其他用途，包括但不限于任何用于商业利益的用途。

1.4.2 TOGAF标准费用是多少？

The Open Group致力于提高业务效率，将信息系统的购买者和供应商聚集在一起，以减少在整个企业中整合新技术的障碍。其目标是实现无边界信息流的愿景。

TOGAF标准是其实现这一目标的战略的一个重要组成部分，而The Open Group希望它被采纳并用于实际的架构项目中，并从它的使用经验反馈来帮助改进它。

因此，The Open Group在其公共网络服务器上发布该文件，并允许并鼓励希望在内部使用该文件的任何组织免费复制和使用该文件，以开发企业架构。（但对其商业用途有限制；见第节1.4.1.）

1.4.3下载

TOGAF标准的下载,包括可打印的PDF文件，可从TOGAF信息网站获取许可证（请参阅www.open group.org/TOGAF/downloads）_o该许可证对任何组织都是免费的，可以完全用于内部目的（例如，开发一个企业架构供该组织内部使用）。

1. 为什么要加入The Open Group?

希望减少实施企业内部和企业之间集成的多供应商解决方案的时间、成本和风险的组织需要The Open Group作为其主要伙伴。

The Open Group把世界各地信息系统的买家和供应商聚集在一起，使他们能够共同合作，既确保IT解决方案满足客户的需求，又使整个企业更容易集成IT。TOGAF标准是这项任务的一个关键推动因素。

是的，TOGAF标准本身是免费提供的。但是你在开发或更新你的企业架构方面会花多少钱？你在基于这个架构的釆购上会花多少钱？与这些数额相比，The Open Group成员的价格微不足道。

除了成员资格的一般好处之外，作为The Open Group的成员，您将有资格参加The Open Group 架构论坛，该论坛是一个开发项目，在该项目中，TOGAF标准得以开发，TOGAF用户聚集在一起交换信息和反馈。

架构论坛成员获得：

■ 立即取得目前的TOGAF工作方案的成果（在下一版TOGAF标准公布之前不公开提供）一实际上是关于该标准的最新信息

■ 与参与企业架构的其他客户和供应商组织交流经验，并在世界各地重要的架构开发项目中使用TOGAF标准与架构师建立网络联系

■ 对具体架构案例研究材料的同行审评

2 第二章 核心概念

本章提供的核心概念适用TOGAF标准。

1. TOGAF是什么？

TOGAF是一种架构框架。TOGAF提供方法和工具，有助于企业架构的认识、构建、使用和维护。它基于多个最佳实践所支持的迭代的流程模型，以及一套可复用的现有架构资产。

1. TOGAF中的架构是什么？

ISO/IEC/IEEE 42010： 2011 将"架构”定义为：

系统在其环境中的基本概念或特性，体现在系统的要素、关系以及系统的设计和演化原则中。

TOGAF 标准包括但不严格遵守 ISO/IEC/IEEE 42010： 2011 术语。除 ISO/IEC/IEEE42010： 2011"架构"定义外，TOGAF标准还根据具体情况界定了第二个含义：

“组件的结构，它们之间的相互关系以及支配其设计和演变的原则和准则。”

TOGAF标准将企业视为一个系统，并努力在从相关标准中提取的概念和术语与大多数TOGAF读者所熟悉的公认术语之间取得平衡。有关术语的更多信息，请参阅第三章和第四部分第31章。

1. TOGAF涉及哪些种类的架构？

有四个架构域被普遍接受为整体企业架构的子集，TOGAF标准都支持设计这些架构域：

■ 业务架构定义了业务战略、治理、组织和关键业务流程

■ 数据架构描述了一个组织的逻辑和物理数据资产和数据管理资源的结构

■ 应用架构提供包含待部署的独立应用及其之间交互作用和与组织的核心业务流程间的关系的蓝图

■ 技术架构描述了支持业务、数据和应用服务部署所需的逻辑软件和硬件能力；包括IT基础设施、中间件、网络、通信、处理和标准等。

1. 架构开发方法

TOGAF架构开发方法（ADM）提供用于开发架构的一个经测试的并可重复的流程，ADM包括建立架构框架、开发架构内容、架构转换及对架构实现进行管控。

所有这些活动均在一个连续的架构定义与实现的迭代周期内实施，使得组织能以一种受控的方式实施企业转型，以响应业务目标和机会。

ADM各阶段如下所述：

■ 预备阶段描述了创建架构能力所需的准备和启动活动，包括定制TOGAF框架和定义架构原则

■ 阶段A：架构愿景描述了架构开发周期的初始阶段。它包括定义架构开发计划的范围、确定利益相关者、创建架构愿景、以及获得批准以继续进行架构开发的信息。

■ 阶段B：业务架构描述了业务架构的开发，以支持被认可的架构愿景

■ 阶段C：信息系统架构描述了信息系统架构的开发，以支持被认可的架构愿景

■ 阶段D：技术架构描述了技术架构的开发，以支持被认可的架构愿景

■ 阶段E：机会和解决方案进行初步实施规划，并为在之前阶段中定义的架构进行交付载体的识别。

■ 阶段F：迁移计划通过最后确定详细的实施和迁移计划，解决如何从基线过渡到目标架构的问题

■ 阶段g：实施治理为实施提供架构的监管。

■ 阶段H：架构变更管理建立了管理新架构变更的程序

■ 需求管理审査整个ADM中管理架构需求的过程

1. 交付物、制品和构建块

实施ADM的架构师会产生很多输出作为其工作的结果，例如，过程流、架构需求、项目计划、项目合规性评估等。TOGAF架构内容框架（见第四部分，第29章）为架构内容提供了一个结构模型，允许一致地定义、结构化和呈现主要工作产物。

架构内容框架使用以下三个类别来描述使用背景环境中的架构工作产物的类型：

■ 交付成果是契约规定的工作产物，由利益相关者正式审查、同意和签字

交付物代表项目的输出，以文档形式提供的那些交付物通常将在项目完成时进行归档,或过渡到架构存储库中当作参考模型、标准或作为架构景观在某个时点的“快照”。

■ 制品是描述架构的一个方面的架构工作产物

制品通常分为目录（事物的列表）、矩阵（显示事物之间的关系）和图表（事物的图片）。示例包括需求目录、业务交互矩阵和用例图。架构交付物可能包含许多制品，并且制品将构成架构存储库的内容。

■ 构建块表示企业能力的（潜在可复用的）组件，它可以与其他构建块相结合，以提供架构和解决方案

可以在不同的详细级别定义构建块，具体取决于架构开发达到的阶段。例如，在早期阶段，构建块可以简单地由名称或大纲描述组成。随后，一个构建块可以分解为多个支撑构建块，并且可以伴随一个完整的规范。构建块可以涉及“架构”或“解决方案”。

一架构构建块（ABB）通常描述所需的能力并塑造解决方案构建块（SBB）的规格；例如，企业内部可能需要客户服务能力，这些能力由许多SBB支持，如流程、数据和应用软件

一解决方案构建块（SBB）是用来实现所需能力的组成部分；例如，网络是一个构建块，它可以通过互补的制品来描述，然后用于实现企业的解决方案可交付结果、制品和构建块之间的关系如图2-1所示。

Figure 2-1 Relationships between Deliverables, Artifacts, and Building Blocks

image.png

图2-1可交付结果、制品和构建块之间的关系

例如，架构定义文档是记录架构描述的交付物。本文档将包含一些互补的制品，这些制品是与架构相关的构建块的视图。例如，可以创建过程流程图（制品）来描述目标调用处理流程（构建块）。这种制品还可以描述其他构建块，例如参与过程的参与者（例如客户服务代表）。可交付结果、制品 和构建块之间关系的示例如图29-2所示。

Figure 2-2 Example — Architecture Definition Document

image.png

图2-2示例-架构定义文档

1. 企业连续统一体

TOGAF标准包括企业连续统一体概念，该概念为架构师设定了更广泛的背景，并说明如何利用通用解决方案和专门解决方案，以支持单个组织的需求。企业连续统一体是架构存储库的一个视图，它提供了分类架构和解决人为因素的方法，因为它从一般的基础架构演化到组织特定的架构。企业连续统一体包含两个互补的概念：结构连续体和解决连续体。

[图片上传失败...(image-1a19f6-1657873608859)]

企业连续统一体的结构和背景环境概述如图2-3所示。

Figure 2-3 Enterprise Continuum

image.png

图2-3 企业连续统一体

1. 架构存储库

支持企业连续统一体是一个架构存储库的概念，它可以存储不同层次的架构输出，由ADM创建。通过这种方式，TOGAF标准促进了利益相关者和各级从业人员之间的理解和合作。

通过企业连续统一体和架构存储库，在开发组织特定架构时利用所有其他相关架构资源和资产。

在这种情况下，TOGAF的ADM可以被视为描述了一个流程生命周期，该流程在组织内的多个级别上运行，在整体治理框架内运行并产生驻留在架构存储库中的对齐输出。企业连续统一体为理解架构模型提供了有价值的环境：它显示了构建块彼此之间的关系，以及对架构开发周期的约束和要求。

TOGAF架构存储库的结构如图2-4所示。

image.png

Figure 2-4 TOGAF Architecture Repository Structure
图2-4 TOGAF架构存储库结构

架构存储库中的主要组件如下：

■ 架构元模型描述了架构框架的组织定制应用，包括一个架构内容的元模型

■ 架构能力定义了支持架构存储库管理的参数、结构和流程

■ 架构景观是在特定时间点部署在运营企业内的架构资产的表现形式，这种全景很可能存在于符合不同架构目标的多级抽象中

■ 标准信息库（SIB）收集新架构必须遵守的标准，其中可能包括国际标准、供应商提供的选定产品和服务，或组织内已部署的共享服务

■ 参考资料库提供了指导方针、模板、模式和其他形式的参考资料，可以利用这些参考资料来加速企业新架构的创建

■ 治理日志记录了整个企业的治理活动

■ 架构需求储存库提供了与架构委员会被认可的所有授权架构需求的视图

■ 解决方案全景提供了解决方案构建块（SBB）的架构表现形式，支持企业规划或部署的架构景观

1. 建立和维护企业架构能力

image.png

为了在企业中有效地实施架构活动，有必要通过组织结构、角色、职责、技能和过程为架构建立适当的业务能力。TOGAF架构能力概述如图2-5所示。

image.png

Figure 2-5 TOGAF Architecture Capability Overview
图2-5 TOGAF架构能力概述

1. 将架构能力建立为运营实体

除非将架构能力的建立仅用于支持变革交付项目，否则，应认识到一个成功的企业架构实我必须建立在坚实的运行基础之上。实际上，企业架构实践必须如同业务内任何其他运营单元一样运行，即企业架构实践应被视为一种业务。为此，除了ADM内定义的核心流程外，企业架构实践还应在下述领域建立能力：

■ 财务管理

■ 业绩管理

■ 服务管理

■ 风险管理（见A.54节）

■ 资源管理

■ 沟通和利益相关方管理（见第3.33节）

■ 质量管理

■ 供应商管理（见A.60节）

■ 配置管理（见A.7节）

■ 环境管理

运行持续架构的概念的核心是实施明确界定和有效的治理，从而在单一框架内控制和调整所有架构上的重要活动。

由于治理己经成为一个日益明显的组织管理需求，TOGAF内包含的治理使框架与当前业务最佳实践相一致，并且还确保可见性、引导和控制水平，以支持所有架构利益相关者的需求和义务。

架构治理的好处包括：

■ 提高问责制的透明度，并在知情的情况下授权

■ 受控风险管理

■ 通过最大限度地重复使用现有的架构组件，保护现有的资产基础

■ 主动控制、监测和管理机制

■ 跨所有组织业务单位的流程、概念和组件重用

■ 通过监测、测量、评价和反馈创造价值

■ 增加对内部流程和外部各方需求支撑的可见性；特别是，较低层级上增加的决策可见性确保那些可能对该组织具有深远战略影响的决策在企业内的适当层级得到监督°

■ 更显著的股东价值；特别是，企业架构越来越多地代表企业的核心知识产权研究己经表明，增加的股东价值与治理良好的企业之间的相关性。

■ 与现有流程和方法集成，并通过增加控制能力来完善功能

关于建立企业架构能力的进一步详细信息见第六部分第39章。

1. 使用TOGAF与其他框架

任何企业架构框架的两个关键要素是：

■ 对架构活动应产生的交付物的定义

■ 完成架构活动应采用的方法描述

除一些例外情况，大多数企业架构框架关注于第一种要素――一组交付物――并且对用于生成这些交付成果的方法保持相对沉默（在某些情况下是有意的）。

由于TOGAF是一个通用框架，且旨在用于多种多样的环境，因此它提供了一个灵活的、可扩展的内容框架，作为一组通用架构交付物的基础。

因此，TOGAF框架可以单独使用，其所描述的一般交付物也可以单独使用；或者，这些交付物可能被更具体的集合取代或扩展，该集合在架构师认为相关的任何其他框架中定义。

在所有情况下，架构师都应该适应TOGAF框架并在其基础上进行构建，以定义集成到企业流程和组织结构中的定制方法。这种架构剪裁可能包括采用来自其他架构框架的元素，或将TOGAF方法与其他标准框架或最佳实践集成,（如ITIL®、CMMI®、COBIT®、PRINCE2®、PMBOK®和MSP®）集成。它还可以包括釆用TOGAF架构存储库中的参考数据，例如IT4IT厕参考架构。第二部分第4.3节提供了以这种方式调整TOGAF ADM的指导方针。

TOGAF作为企业架构的一种通用框架和方法，提供了与其他框架集成的能力和协作环境。各组织能够充分利用纵向业务领域、横向技术领域（如安全或可管理性）或应用领域（如电子业务），如安保性和可管理性）或应用领域（如电子业务），以产生具有竞争力的企业架构框架，从而最大限度地利用其业务机会。

3 第三章 定义Definitions

以下术语和定义适用于TOGAF。对于本章未定义的补充定义，应参考附录A。《Merriam-Webster®大学词典》应被引用于本节或附录A中未规定的术语。

3.1 抽象化Abstraction

提供详细和复杂内容的概括或描述的技术。

注：抽象在“抽象层”中，也意味着提供了一个分析的焦点，它涉及到一个一致和共同的细节或抽象层。在这种意义上的抽象通常用于架构中，以便在架构的各个领域实现一致的定义和理解，以支持有效的通信和决策。当处理大型和复杂的架构时，它特别有用，因为它允许在尝试进一步的细节之前先确定相关问题。

3.2 施动者Actor

具有一个或多个角色的人、组织或系统，发起活动或与活动交互；例如，岀差拜访客户的销售代表。施动者可能是组织的内部或外部施动者。

注：在汽车行业中，原设备制造商将被汽车经销商视为与其供应链活动交互的施动者。

3.3 应用架构Application

描述应用程序的结构和交互，作为提供关键业务功能和管理数据资产的一组能力。

注：应用程序架构在第二部分第10章中进行了描述。

3.4 应用组件Application Component

一种与实现结构一致的应用程序功能的封装，它是模块化的，可替换的。它封装其行为和数据，并通过接口提供服务。

注：例如，一种业务应用程序，如记账、薪资或CRM系统。

应用程序组件通常维护数据组件。它由技术组件提供的技术服务来实现。

3.5 应用平台Application Platform

提供用于支持应用程序的服务的硬件和软件的技术组件的集合。

3.6 架构风格Architectural Style

与实施或表达架构的特定环境相关的独特特征的组合；指导或限制架构形成的原则和特征的集合。

3.7 架构Architecture

1. 系统在其环境中的基本概念或特性，体现在系统的要素、关系以及系统的设计和演化原则中。（资料来源：ISO/IEC/IEEE 42010： 2011）
2. 组件的结构、它们之间的相互关系，以及它们的设计和随时间演变的原则和准则。

3.8 架构构建块（ABB）Architecture Building Block

架构模型的一个组成部分，描述了整体模型的一个方面。

另见第3.23节。

3.9 架构连续统一体Architecture Continuum

企业连续统一体的一部分。具有越来越多的细节和专业化的架构元素的存储库。

注：企业的连续统一体的一部分。它是具有不断增加的细节和特定性的架构元素的存储库。架构连续统一体以诸如参考模型、核心策略和基本构建块等基础定义开始，在此基础上扩展到行业架构，并最终扩展成为组织特定架构。

另见第3.39节。

3.10 架构开发方法（ADM）

TOGAF框架的核心。一种多阶段、迭代的方法，用于开发和使用企业架构来塑造和管理业务转型和实施项目。

注：第二部分：架构开发方法（ADM）中描述ADMo

3.11 架构域Architecture Domain

架构开发中需要考虑的架构领域。TOGAF框架有四个主要的架构域：业务、数据、应用和技术。也可考虑其他领域（例如，安全）。

3.12 架构框架Architecture Framework

用于规划、开发、实施、管理和维持架构的概念结构。

3.13 架构治理Architecture Governance

监控和指导架构相关工作的实践。目标是实现预期的结果，并遵守相关的计划、标准和路线图。另见第3.43节。

3.14 架构景观Architecture Landscape

企业在特定时间点使用或计划使用的资产的架构表达。

3.15 架构模型Architecture Model

一个感兴趣的主题的代表。

注：架构模型提供了较小规模、简化和（或）抽象的主题表示。

另见第3.72节、第3.17节和第3.18节。

3.16 架构原则Architecture Principle

结构应满足的意向的定性陈述。

注：架构原则示例集在第三部分第20章中定义。

3.17 架构视图Architecture View

系统的一种表示，从一组相关的系统的角度观察。

注：在本标准的一些章节中，“视图”一词被用作“架构视图"的同义词。

另见第3.72节和第3.18节。

3.18 架构视点Architecture Viewpoint

一种特定类型的架构视图的约定的规范。

注：架构视点也可以视为此类架构视图的定义或架构。它建立了用于构造，解释和使用架构视图的约定，以解决有关关注系统的特定关注点（或关注点集）。

注：在本标准的某些章节中，“视点”一词被用作“架构视点”的同义词。

另见A.38节。

3.19 架构愿景Architecture Vision

对目标架构的简要描述，架构愿景描述目标架构的业务价值，以及企业因目标架构的成功部署而出现的变化。架构愿景是详细架构开发的强烈渴望的愿景和边界。

注：第二部分第六章描述了阶段A（架构愿景）。

3.20 制品Artifact

描述架构某个方面的架构工作产物。

另见第3.23节。

3.21 基线Baseline

已经过正式审查并旦取得一致认可的规范，基线确立后，将作为进一步开发或变更的基础，而且它仅可通过正式的变更控制程序或如构型管理等程序进行变更。

3.22 无边信息流™ Boundaryless Information Flow

“访问综合信息以支持业务流程改进”的一种简短表达，它表达满足特定的组织业务需要的一种企业的基础设施期望状态。

注：TOGAF®系列指南：TOGAF集成信息基础结构参考模型（III-RM）中描述了对无边界信息流（The Open Group商标）的需求。

3.23 构建块Building Block

企业能力的一种（潜在可复用的）组件，可以与其他构建块结合，以提供架构和解决方案。

注：可以在不同的详细级别定义构建块，具体取决于架构开发达到的阶段。例如，在早期阶段，构建块可以简单地由名称或大纲描述组成。稍后，一个构建块可以分解为多个支撑构建块，并且可以伴随一个完整的规范。构建块可以涉及“架构”或“解决方案”。

第四部分第33章介绍了各种构建块。

另见第3.20节。

3.24 业务架构Business Architecture

整体、多层面业务观点的表现形式：能力、端到端价值交付、信息和组织结构；以及这些业务观点和战略、产品、政策、举措和利益相关者之间的关系。

注：业务架构将业务要素与业务目标和其他领域的要素联系起来。

业务架构在第二部分第七章中进行了描述。

3.25 业务能力Business Capability

企业为达到某一特定目的而可能拥有或交换的特殊能力。

3.26 业务功能Business Function

提供与组织密切相关的业务能力，但不一定由组织明确管理。

3.27 企业治理Business Governance

关注确保业务流程和政策（及其运作）提供交付结果并遵守相关业务规范。

3.28 业务模式Business Model

描述企业如何创造、交付和获取价值的原理的模型。

3.29 业务服务Business Service

通过显式定义的接口支持业务能力，并由组织明确管理。

3.30 能力Capability

组织、个人或系统所拥有的能力。

注：例如，企业架构、市场营销、客户联系或推式电话营销。

3.31 能力架构Capability Architecture

对实现特定解决方案或解决方案方面的架构方法的高度详细的描述。

3.32 能力提升Capability Increment

能力架构中提供特定价值的一个离散部分。当所有增量都己完成时，能力已实现。

3.33 沟通和利益相关者管理Communications and Stakeholder Management

对企业架构实践中利益相关者的需要进行的管理。同时，它对企业架构实践与利益相关者之间，以及企业架构实践与其服务使用者之间的沟通实施进行管理。

注：架构利益相关者管理见第21章。

3.34 关注Concern

与一个或多个利益相关者相关的系统中的一种利益。

注：担心可能涉及系统的功能、开发或运行的任何方面，包括性能、可靠性、安全性、分布和可进化性等方面，并可能决定系统的可接受性。

另见第3.72节。

3.35 行动方案Course of Action

战略目的和目标提供的方向和重点，通常是交付业务模式中所体现的价值主张。

3.36 数据架构Data Architecture

描述企业的主要类型和数据源、逻辑数据资产、物理数据资产和数据管理资源的结构和相互作用。

注：数据架构在第二部分第9章中进行了描述。

3.37 交付物Deliverable

一种架构工程产品，根据契约规定，并由利益相关者正式审查、同意和签字。

注：交付物表示项目的输出，而文档表格中的交付物将典型地在项目完成时存档，或者在某个时间点转换为架构存储库，作为架构景观的参考模型、标准或快照。

3.38 企业Enterprise

一个组织的描述的最高级别（通常），通常包括所有的任务和职能。企业通常会跨越多个组织。

3.39 企业连续统一体Enterprise Continuum

一种分类机制，用于对架构和解决方案制品进行分类，无论是内部还是外部的架构存储库，因为它们从通用的基础架构演变为特定于组织的架构。

另见第3.9节和第3.71节。

3.40 基础架构Foundation Architecture

泛型构建块，它们与其他构建块的相互关系，以及为构建更具体的架构提供基础的原则和准则。

3.41 框架Framework

一种用于内容或过程的结构，可用作构造思维、确保一致性和完整性的工具。

3.42 差距Gap

声明两种状态之间的差异。在差距分析的背景下使用，其中确定了基线和目标结构之间的差异。

注：差距分析见第三部分第23章。

3.43 治理Governance

监控、管理和指导业务（或IS/IT信息系统/信息技术全景）以交付所需业务产出的规程。

另见附录a第3.13节、第3.27节和A.40节。

3.44 信息Information

利用包括文字、数值、图形、制图、叙述或视听形式在内的任意介质或形式对各种事实、数据或观念的传达或表达。

3.45 信息系统服务Information System Service

1. 一种可从应用程序中请求的独立行为（例如，登录、预定火车座位、转账）。

注：通过捕获或提供数据或使流程自动化来支持并启用业务角色和流程。可以是粗粒度的也可以是细粒度的（请见用例或用户案例）。可以在接口中找到并通过接口调用。

1. 业务服务的自动化元素。

3.46 信息技术（IT）

1. 组织使用的信息和相关技术的生命周期管理。
2. 一个总括的术语,它包括全部或部分的主题领域涉及计算机行业、业务连续性等业务接口，业务流程建模和管理、沟通、合规和法律、计算机、内容管理、硬件、信息管理、互联网、离岸外包，网络，编程和软件，专业问题，项目管理、安全、标准，存储，语音和数据通信。不同的国家和行业使用其他总括术语来描述这个集合。
3. 通常分配给组织中负责提供上面（2）中描述的部分或全部域的部门的术语。
4. 常用的替代名称包括信息服务、信息管理等。

3.47 互操作性Interoperability

1. 共享信息和服务的能力。
2. 两个或多个系统或组件交换和使用信息的能力。
3. 系统提供和接收来自其他系统的服务以及使用这些服务的能力，从而使它们能够共同有效地运行。

3.48 逻辑的Logical

架构的一种与实施无关的定义，通常按照相关物理实体的目的和结构对它们进行分组。

注：例如，来自多个基础设施软件供应商的产品都可以逻辑地归为Jav/应用程序服务器平台。

3.49 元数据Metadata

任何介质中存在的任何类型的“数据的数据”，描述实体的特征。

3.50 元模型Metamodel

一种说明如何以及使用什么元素以结构化方式描述架构的模型。

3.51 方法Method

应对特定类型问题而被定义且可重复的一种实施途径。

3.52 建模Modeling

一种通过构建模型使主题能够以一种形式表示的技术，这种形式能够对主题内容的本质进行推理、洞察和明晰。

3.53 模型类型Model Kind

一种建模类型的约定。

注：架构视点引用一个或多个模型类型；架构视图包含一个或多个模型。

3.54 目的Objective

组织的一个有时限性的里程碑，用于展示朝着目标的进展，例如，“2009年年底前产能利用率提高30%,以支持市场份额按计划增长。”

3.55 组织地图Organization Map

阐述构成企业、其合作伙伴和利益相关者的主要实体之间的关系。

3.56 模式Pattern

一种将构建块置于背景环境中的技术；例如，描述问题的可重用解决方案。

注：你使用的是构建块：（架构）模式可以告诉你如何使用它们，什么时候，为什么，以及在这样做时你必须做什么权衡。

另见第3.23节。

3.57 物理的Physical

对现实世界实体的描述。企业架构中的物理元素在很大程度上仍然可从解决方案架构、设计或实施视图中抽象出来。

3.58 原则Principle

见第3.16节。

3.59 参考模型(RM) Reference Model

参考模型是一种抽象框架，旨在帮助理解环境中实体之间的重要关系和开发支持该环境的一致标准或规范。

注：参考模型基于少量统一概念，并可以作为基础，用来对非专业人员进行教育和解释标准。参考模型并不直接绑定任何标准、技术或其他具体实施细节，但它试图提供可跨越不同实施以及在不同实施之间明确使用的常用语义。

本定义的来源是OASIS见www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm。

3.60 储存库Repository

一种管理企业所有数据的系统，包括数据和过程模型以及其他企业信息。

注：数据库中的数据比数据字典中的数据要广泛得多，数据字典通常只定义组成数据库的数据。

3.61 需求Requirement

必须由特定架构或工作包满足的需求声明。

3.62 路线图Roadmap

业务或技术变革的抽象计划，通常历时数年跨多个学科。一般用于术语“技术路线图”、“架构路线图”等。

3.63 角色Role

1. 施动者的通常或预期的功能，或某人或某物在特定动作或事件中发挥的部分。施动者可能有许多角色。
2. 一个人在一个组织中扮演的一部分，以及他们通过运用他们的技能、知识、经验和能力而做出的贡献。

另见第3.2节。

3.64 分段架构Segment Architecture

对企业内部领域的详细的、正式的描述，在项目或项目组合一级用来组织和调整变化活动。另见第3.74节。

3.65 服务Service

1. 可重复的活动；可以请求或以其他方式触发构建块实施的一种离散行为。

注：例子包括检查客户信用、提供天气数据和合并钻井报告。它通过提供输出或变更系统状态来服务客户或客户。它可以在定义输入和输出流和/或状态变更的逻辑服务契约中定义。它封装处理输入和输岀流的任何构建块。它可能是服务组合或服务级别协议（SLA）中的几种服务之一。它可以通过接口调用。它可以是粗粒度的（买房子），也可以是细粒度的（检索地址）。

1. 一种行为元素，它提供特定的功能来响应施动者或其他服务的请求。

3.66 面向服务Service Orientation

一种根据服务、基于服务的开发和服务的产出来思考问题的方式。

另见第3.67节。

3.67 面向服务的架构（SOA）Service Orientation Architecture

一种支持面向服务的架构样式。

另见第3.6节和第3.66节。

3.68 服务组合Service Portfolio

一个服务集合，可能是接口定义。

注：它在TOGAF框架中用于定义对构建块或系统的需求。

3.69 解决方案架构Solution Architecture

对目标明确且独立的业务运营或活动以及对IS/IT（信息系统/信息技术）如何支持该业务运营的描述。

注：解决方案架构通常适用于单个项目或项目版本，帮助将需求转换为解决方案愿景、高级业务和/或IT部门规范以及一个实现任务组合。

3.70 解决方案构建块（SBB）Solution Building Block

一种符合架构构建块（ABB）规范的候选解决方案。

3.71 解决方案连续统一体Solutions Continuum

企业连续统一体的一部分。一个可复用的解决方案库，用于今后的实施工作。它包含了架构连续统一体中对应定义的实现。

另见第3.39节和第3.9节。

3.72 利益相关者Stakeholder

个人、团队、组织或其他群体，对一个系统有兴趣。

3.73 标准信息库(SIB) Standards Information Base

一种标准数据库，可用于定义特定于组织的架构的特定服务和其他组件。

注：标准信息库见第五部分第37.4节。

3.74 战略架构Strategic Architecture

对企业概括性正式描述，为业务和变革活动提供组织框架，并为制定方向提供实施级别的长期视图。

3.75 目标架构Target Architecture

针对组织开发的架构的未来状态的描述。

注：若干未来状态可形成路线图，以展示架构向目标状态的演进。

3.76 架构视图分类Taxonomy of Architecture Views

与架构相关的所有架构视图的有序集合。

3.77 技术架构Technology Architecture

技术服务和技术组件的结构和交互的描述。

注：技术架构在第二部分第11章中进行了描述。

3.78 技术组件Technology Component

1.技术构建块。通过提供技术服务(直接或间接)支持和启用应用程序或数据组件的通用基础设施技术。

2.代表一类技术产品或特定技术产品的技术基础结构的封装。

3.79 技术服务Technology Service

提供支持应用程序交付的支持基础设施所需的技术能力。

3.80 过渡架构Transition Architecture

在架构上重要的时间点对架构的一种状态的正式描述。

注：一个或多个过渡架构可用于描述从基线到目标架构的时间演进。

过渡架构见第四部分第32.2.3节。

3.81 价值流Value Stream

为客户、利益相关者或最终用户创建整体结果的端到端的增值活动集合的表示形式。

3.82 视图View

见第3.17节。

3.83 视点Viewpoint

见第3.18节。

3.84 视点库Viewpoint Library

架构存储库的参考库部分中包含的架构视图的规范的集合。

3.85 工作包Work Package

为实现业务的一个或多个目标而确定的一组行动。一个工作包可以是一个项目、一个完整的项目或一个程序的一部分。