架构推进方法论-核心术语
一、概述
架构是基于本体论的方法。斯坦福大学的Gruber在1995年给出了得到广泛认可的定义，即本体论是对概念化的精确描述，用于描述事物的本质。其核心作用就在于定义某一领域内的专业词汇以及它们之间的关系，这一系列的基本概念如同工程一座大厦的基石，为交流各方提供了一个统一的认识。在这一系列基本概念的支持下，知识的搜索、积累和共享的效率将大大提高，真正意义上的知识重用和共享也成为可能。
本文参考大量资料，对架构中经常出现的概念与术语进行统一定义与解释说明，建立共同的认知与沟通的统一语意。
二、术语及定义
2.1 施动者（Actor）
以某种角色发起活动或与活动进行交互的个人、组织或系统，例如旅行访问客户的销售代表。施动者可以处于组织内部或外部。在汽车行业，汽车经销商就将原始设备制造商视为与其供应链活动进行交互的一个施动者。
2.2 应用（Application）
一个已部署和运行的IT系统，用以支持各种业务功能和服务，例如薪资系统。应用使用数据并被多重技术组件支持，但与支持其的技术组件截然不同。（定义来源：《TOGAF标准9.1版本》）
为满足IT治理需要，在逻辑层面根据特定业务需求确定的应用组件/应用功能的组合边界，应用中所包含的应用该组件之间存在较高级别的互操作性，一个应用承载选型、实施、部署等方面的治理要求。在实现层面，应用往往与软件系统实体对应。
2.3 应用架构（Application Architecture）
对应用结构和应用间交互的描述应用架构，这些应用作为能力群组提供关键业务功能并管理数据资产。
2.4 应用组件（Application Component）
满足业务服务需求的模块化、可部署、可重用、可替换的组成单元，封装了行为和数据等实现过程并提供了一系列可用的接口，可独立运行、独立部署，应用组件可嵌套。
2.5 应用平台（Application Platform）
提供支持各类应用的多种服务的硬件和软件的技术组件集合。
2.6 应用平台界面（Application Platform Interface, API）
应用软件和/或应用平台之间的界面或功能集。
2.7 架构（Architecture）
一个系统的基本组织，具体体现于其组成部件，部件之间与环境之间的关系以及支配其设计和演进的原则（定义来源：ISO/IEC 42010:2011）。
组件结构、组件之间相互关系，以及对这些组件的设计和随时间演进进行治理的原则和指南。
2.8 架构构建块（Architecture Building Block, ABB）
描述总体模型单一方面的架构模型的一种构成要素。
2.9 架构连续统一体（Architecture Continuum）
复杂组织体的连续统一体的一部分。它是具有不断增加的细节和特定性的架构元素的存储库。架构连续统一体以诸如参考模型、核心策略和基本构建块等基础定义开始，在此基础上扩展到行业架构，并最终扩展成为组织特定架构。
2.10 架构开发方法（Architecture Development Method, ADM）
TOGAF的核心。开发和使用Enterprise Architecture的一种循序渐进的实施途径。
2.11 架构域（Architecture Domain）
架构开发中需要考虑的架构领域。TOGAF中包括四个架构域：业务、数据、应用和技术。
2.12 架构框架（Architecture Framework）
用于开发、实施并维持架构的概念性结构。
2.13 架构治理（Architecture Governance）
在整个复杂组织体范围层级管理和控制复杂组织体架构和其他架构的实践和定位。架构治理关注变革流程（设计治理）和产品系统运行（运行治理）。
2.14 架构全景（Architecture Landscape）
在特定时点下对复杂组织体使用或计划的资产的架构表达。
2.15 架构原则（Architecture Principles）
对架构应满足的意图的定性申明，至少具备一个支持的理由和一个重要性的测度。
2.16 架构愿景（Architecture Vision）
对目标架构的简要描述，架构愿景描述目标架构的业务价值，以及复杂组织体因目标架构的成功部署而出现的变化。架构愿景是详细架构开发的强烈渴望的愿景和边界。
2.17 制品（Artifact）
描述架构某一方面的一种架构工作产物。
2.18 基线（Baseline）
已经过正式审视并且取得一致认可的规范，基线确立后，将作为进一步开发或变更的基础，而且它仅可通过正式的变更控制程序或如构型管理等程序进行变更。
2.19 构建块（Building Block）
代表业务、IT或架构能力的一种（潜在可复用的）组件，它能够与其他构建块进行结合，以交付架构和解决方案。
构建块可以在不同细节层级上被定义，这取决于架构开发所达到的阶段。例如，在初期阶段，构建块可以只包括名称或概述。其后，一个构建块可分解成多重支持的构建块，并可随附一份完整的规范。构建块可以与“架构”或“解决方案”相关。
2.20 业务架构（Business Architecture）
对业务战略、组织、功能、业务流程和信息需要之间的结构和交互的描述。
2.21 业务组件（Business Component）
在逻辑层面由业务分解得到的独立且具有业务能力要求的业务模块。
2.22 业务数据（Business Data）
为完成业务处理而产生的事务性数据，是业务活动的描述，更新频繁且快速增长。
2.23 基础元素模型（Basic Element Model）
架构制品的一种表达形式，以树形结构或列表、目录等方式呈现，表达单一或相关联元素从属与对应关系的基础性模型。基础元素模型的生成可直接定义或由元素关系模型提取两种方式。
2.24 业务功能（Business Function）
交付与组织密切协调一致的业务能力，但这些能力并非必须由该组织明确治理。
2.25 业务治理（Business Governance）
致力于确保业务流程和策略（及其运行）交付业务产出并遵循相关的业务规定。
2.26 业务服务（Business Service）
通过明确定义的界面支持业务能力，并由组织明确管控。
2.27 能力架构（Capability Architecture）
对实现特定解决方案或解决方案某方面的架构途径的非常详细的描述。
2.28 组件（Component）
通过用途、关键活动、资源、治理、服务五个维度进行描述，用以定义业务边界，描述业务能力。
2.29 数据架构（Data Architecture）
对复杂组织体的主要数据类型及来源、逻辑数据资产、物理数据资产，以及数据管理资源的结构及交互的描述。
2.30 交付物（Deliverable）
以契约方式规定，并依次由利益攸关者正式审视、同意并签发的架构工作产物。交付物代表项目的输出，文档形式的交付物通常在项目完成时存档，或过渡到架构库中当作参考模型、标准或作为架构全景在某个时点的“快照”。
2.31元素（Element）
构成组织存在并维持其正常运转的必要的最小单位,是构成组织必不可少的因素。
2.32 元素分析矩阵（Element Analysis Matrix）
架构制品的一种表达形式，矩阵展现两个或多个架构元素之间的各类关系，用以支持元素之间适配性分析的模型。
2.33 元素关系模型（Element Relationship Model）
架构制品的一种表达形式，是基于复杂组织体架构元模型，为了满足特定表达与分析视角需要而设计的表达多个架构元素关联关系的模型。元素关系模型中的元素实例应与基础元素模型中包含的元素实例一致，并根据架构开发要求定义产生。
2.34 复杂组织体（Enterprise）
对组织的最高层级（通常是）描述，通常涵盖所有使命和职能。一个复杂组织体通常跨越多重组织。
2.35 复杂组织架构（Enterprise Architecture）
复杂组织体的逻辑蓝图，基于背景环境建立复杂组织体的完整性，多层次一致的结构化描述，用于支持组织业务模型设计、技术采用与战略方向的对准。
2.36 复杂组织体的连续统一体（Enterprise Continuum）
在架构和解决方案制品从一般基础性架构演变为组织特定架构时，可用于对架构库内部或外部的架构和解决方案制品进行归类的分类机制。
2.37 基础架构（Foundation Architecture）
由一般构建块、通用构建块与其他构建块的相互关系以及有关的原则和指南构成，并为在其之上构建更具体的架构提供了基础。
2.38 IT治理（Information Technology Govarnance）
将IT资源和信息联系到复杂组织体目标和战略的框架及结构。此外，IT治理使规划、获取、实施和监控IT绩效的最佳实践制度化，以确保复杂组织体的IT资产支持其业务目的。
2.39 逻辑技术组件（Logical Technology Component）
与特定设施无关的技术基础设施的封装形式的描述，从形式上看是一类技术产品或技术合集。如：TCP/IP网络通信协议是通信技术的一个组件。
2.40 主数据（Master Data）
需在组织全局保持一致的核心业务实体的数据，是在集团公司范围内需要统一规范和共享的数据，包括基础公共数据和基础资源数据。
2.41 元数据（Metadata）
任何介质中存在的任何类型的“数据的数据”，描述实体的特征。描述数据的数据，主要描述业务数据、主数据和主题分析数据的数据对象的结构、数据仓库中有关数据源定义和转化规则。
2.42 元模型（Metamodel）
一种说明如何以及使用什么元素以结构化方式描述架构的模型。
2.43 物理技术组件（Physical Technology Component）
一种特定的技术基础设施产品或技术基础设施产品的实例的描述，从形式上看是一类或一种软/硬件货架商品。如服务器、操作系统等。
2.44 平台服务（Platform Service）
为了提供支持应用交付的使能性基础设施必需的一种技术能力。
2.45 存储库（Repository）
一个管理复杂组织体所有数据的系统，包括数据和流程模型，以及其他复杂组织体信息。因此，存储库中的数据比数据字典中的数据更加广泛，数据字典一般只定义构成数据库的数据。
2.46 分部架构（Segment Architecture）
对复杂组织体内各区域正式而详细的描述。分部架构在项目群或项目谱系层级使用，旨在对变更活动进行组织和使其协调一致。
2.47 解决方案架构（Solution Architecture）
对目标明确且独立的业务运行或活动以及对IS/IT如何支持该业务运行的描述。解决方案架构通常应用于一个单一的项目或项目发布，协助将需求转变为一个解决方案愿景、高层级业务和/或IT系统规范和一个实施任务谱系。
2.48 解决方案构建块（Solution Building Block, SBB）
一种符合架构构建块（ABB）规范的候选解决方案。
2.49 解决方案连续统一体（Solutions Continuum）
复杂组织体的连续统一体的一部分。一个用于未来实施工作并可复用的解决方案的存储库。它包含架构连续统一体中对应定义的实现。
2.50 战略架构（Strategic Architecture）
对复杂组织体的概括性正式描述，提供面向运行和变革活动的组织框架以及用于制定方向的执行层级长期视图。
2.51 主题分析数据（Subject Analysis Data）
按照业务逻辑结构对各业务数据进行识别和运算，根据业务需要统一定义和组织的相关数据，由业务数据按照分析需要抽取后按主题存储。
2.52 目标架构（Target Architecture）
针对组织开发的架构的未来状态的描述。若干未来状态可形成路线图，以展示架构向目标状态的演进。
2.53 技术架构（Technology Architecture）
对平台服务、逻辑技术组件以及物理技术组件的结构和它们之间交互作用的描述。（定义来源：《TOGAF标准 9.1版本》）
应用架构和数据架构的技术实现，其通过物理层面的软件和硬件描述运行环境的构成、通过节点的部署关系描述运行环境的连接关系和部署方式。
2.54 技术谱系框架（Technology Portfolio Framework）
对技术架构包含的所有要素的分类框架，建立和维护技术谱系框架是技术架构设计的基础。
2.55 技术服务（Technology Service）
对支持应用交付的基础设施所需的技术能力的描述，同时也是技术架构对外的服务接口。
2.56 过渡架构（Transition Architecture）
对架构在某个重要时点的某一种状态的正式描述。可以使用一个或多个过渡架构描述从基线架构向目标架构的时间演进。
2.57 视图（View）
一组相关关注点的表达。视图是从某一视角看到的结果。架构视图可以用模型表达，以展示利益攸关者在架构中所关注的领域。视图本质上不一定必须是可视的或图形化。
2.58 视角（Viewpoint）
对获得视图的角度的定义。视角是对构造和使用视图的惯例的规范（经常采用适当的图表或模板）。视图是看到的结果，视角是观察点—决定所见结果的有利位置或角度。