企业架构研究总结（34）——TOGAF架构内容框架之架构制品（下）

4.2.31 数据生命周期图（Data Lifecycle Diagram）

数据生命周期图是在业务流程的约束之下对业务数据在其整个生命周期（从概念阶段到最终退出）中对其进行管理的核心部分。数据从本质上讲是一个实体，并独立于业务流程和活动。数据状态的每个变化都被表现在这张图中，这也可以包括引起此状态变化事件或规则。数据与流程的分离使得通用数据需求可以被识别出来，从而使得资源共享得以有效达成。

4.2.32 应用组合目录（Application Por tfolio Catalog）

此目录的目标是明确和维护企业中所有应用的列表。一个经过批准的应用组合目录使得一系列应用得以被定义和治理。此目录为后面的矩阵和图形提供了基础，是应用架构开发阶段的起点。现有的应用注册表和资源库（比如SAP的解决方案管理和系统情况目录产品）也从基线和目标两个角度为这个目录的制定提供了输入。此目录所涉及到的内容元模型实体包括：

• 信息系统服务
• 逻辑应用组件
• 物理应用组件

4.2.33 接口目录（Interface Catalog）

接口目录用来界定应用之间接口的范围，并对这些接口进行文档化记录，从而使得应用间的所有依赖关系得以被尽可地界定。系统可以用来创建、读取、更新和删除其他系统内的数据。无论是通过循环载入的批处理文件、对其他系统数据库的直接连接，还是通过某种形式的应用程序接口或Web服务，这些行为都是通过接口来实现。针对应用组件之间关系的映射是一个非常重要的步骤，它使得如下情形得以实现：

• 了解应用间交互程度的，从而可以站在应用与其他系统之间依赖性的角度识别出各个关键的交互。
• 了解应用之间接口的数量和类型。
• 了解应用之间接口的重复程度。
• 在考虑目标应用组合时明确各接口的简化潜力。
• 支持差距分析，并确定是存在本应建立的应用被遗漏了。

此目录所涉及到的内容元模型实体包括：

• 逻辑应用组件
• 物理应用组件
• 应用之间的通信关系

4.2.34 系统/组织矩阵（System/Organization Matrix）

此矩阵用于描述企业中系统与组织单元之间的关系。业务功能由组织单元来执行，而一些由组织单元执行的功能和服务也将会被IT系统所支持。应用组件与组织单元之间的映射非常重要，它会使得：

• 为执行业务功能的组织单元分配针对应用的使用。
• 理解由组织单元所执行的业务服务和流程对应用支持需求。
• 支持差距分析，并确定是否有需要被建立的应用被遗漏。
• 定义特定组织单元所使用的应用集合。

此矩阵是一张两维表，其中逻辑/物理应用组件在一条坐标轴上，而组织单元在另一条轴上。这两个实体之间的关系包含了一系列需要被验证的元模型关系：

• 组织单位与服务之间的从属关系。
• 执行者与组织单位之间的从属关系，以及其与服务之间的使用关系。
• 服务与逻辑/物理应用组件之间的实现关系。

4.2.35 角色/系统矩阵（Role/System Matrix）

此矩阵用来描述企业中系统与业务角色之间的关系。一个组织中的人们会与各种系统发生交互。在交互过程中，这些用户被假定成为执行一项任务的特定角色，例如，产品购买者。应用组件与角色之间的关系映射非常重要，它使得：

• 在组织内为特定的角色分配针对应用的使用。
• 理解支持功能的业务服务和流程的应用安全需求，并检查是否与现有策略相符合。
• 支持差距分析，并确定是否有应该被创建的应用被遗漏。
• 定义被特定业务角色所使用的应用集合。

此矩阵是一个两维表，其中逻辑应用组件在一条坐标轴上，而角色在另一条轴上。这两个实体之间的关系包含了一系列需要被验证的元模型关系：

• 角色与功能之间的访问关系。
• 功能与服务之间的绑定关系。
• 服务与逻辑/物理应用组件的实现关系。

4.2.36 系统/功能矩阵（System/Function Matrix）

此矩阵用于阐述企业中系统与业务功能之间的关系。业务功能由组织单元所执行。一些业务功能和服务将会被IT系统所支持。应用组件与功能之间的关系映射是非常重要的，它使得如下方面成为可能：

• 为业务功能分配针对应用的使用
• 理解业务服务和流程的应用支持需求
• 支持差距分析，并确定是否有需要被创建的应用被遗漏
• 定义被特定业务功能所使用的应用集合

此矩阵是一张两维表，其中逻辑应用组件位于一条坐标轴上，而功能处在另一条坐标轴之上。这两个实体之间的关系包含了一系列需要被验证的元模型关系：

• 功能与服务之间的绑定关系。
• 服务与逻辑/物理应用组件的实现关系。

4.2.37 应用交互矩阵（Application Interaction Matrix）

应用交互矩阵的目标是阐述系统之间的沟通关系。在矩阵中展示的应用交互映射与接口目录或者应用通信图示相类似的，只不过以矩阵的形式来展示。此矩阵是一张两维表，其中的每一个维度都包含了应用服务、逻辑应用组件和物理应用组件这些概念。在此矩阵中所描述的关系包括：

• 应用服务之间的使用关系。
• 逻辑应用组件之间的通信关系。
• 物理应用组件的通信关系。

4.2.38 应用通信图（Application Communication Diagram）

此图的目标是描述所有与应用之间的沟通相关的模型和映射。应用通信图展示了应用的应用组件和接口，并且接口可以关联数据实体，而应用则可以关联业务服务。此图所表述的“通信”应该是符合逻辑的，并且仅用来展示与架构相关的中介技术。

4.2.39 应用和用户位置图（Application and User Location Diagram）

应用和用户位置图展示了应用的地理分布情况。它可以被用来展示：

• 被最终用户所使用的各个应用的地点分布
• 被执行和/或交付（在客户端情形下）的各个主机应用程序的地点分布情况
• 被开发、测试和发布的应用所处位置的分布情况

此图的目标在于清晰地描述与应用发生交互的业务用户所处的业务位置，而且还包括了应用基础设施的位置。通过此图，我们可以：

• 识别出足以支持分散在各地的用户群的产品包的数量
• 估算产品或软件的用户许可的类型和数量
• 估算用户的支持等级和支持中心的位置
• 选择系统管理工具、结构，以及用于支持本地或远程的企业用户/客户/合作伙伴的管理系统
• 适当规划业务的技术组件，即服务规模、网络带宽等
• 在实施应用和技术架构解决方案时进行性能方面的考虑

用户通常会采用多种方式与应用进行交互，例如：

• 支持日常业务的运营。
• 参与业务流程的执行过程。
• 访问信息（查询、读取等）。
• 开发应用。
• 管理、维护应用。

4.2.40 系统用例图（System Use-Case Diagram）

系统用例图展示了客户与应用服务提供者之间的关系。应用服务被角色或其他应用服务所使用，并且通过描述功能是在何时被如何使用，应用用例图对应用功能的描述提供了更多意义。此图的目标是帮助描述和验证各个参与者与他们对应用所担当的角色之间的交互。随着架构的进展，这些用例能够从功能性信息演进到包含技术实现细节。架构系统用例还可以在更细节的系统设计工作中被复用。

4.2.41 企业管理能力图（Enterprise Manageability Diagram）

企业管理能力图展示了一个或多个应用是如何与用以支持一个解决方案的运营管理的应用和技术组件进行交互的。此图实际上是针对应用通信图的一个过滤，特别是针对企业管理类软件方面。基于此图的分析可以揭示组织的IT服务管理操作方面重复、差距和机遇。

4.2.42 流程/系统实现图（Process/System Realization Diagram）

流程/系统实现图的目标是清晰地阐述在业务流程执行过程中涉及到多个应用时所产生的事件的顺序。此图可以识别出能够被简化的复杂顺序，以及架构中各种可能的合理化点，从而为业务用户提供更加及时的信息。此外，此图还可被用来明确流程中能够通过减少应用之间的交互流量而进行效率改善的地方。

4.2.43 软件工程图（Software Engineering Diagram）

系统工程图从开发的角度将应用分解为包、模块、服务和操作，它使得在各规划迁移阶段和分析机会与解决方案时进行更加详细的影响分析成为可能。在管理复杂开发环境时，系统工程图对应用开发团队和应用管理团队是非常有用的。

4.2.44 应用迁移图（Application Migration Diagram）

应用迁移图表明了应用从基线到目标应用组件的迁移过程，它通过精确地展示哪些应用和接口在迁移各阶段中需要被映射，使得针对迁移成本的估算更加准确。应用迁移图确定了临时的应用、集结区域以及用于支持迁移的各项基础设施。

4.2.45 软件分布图（Software Distribution Diagram）

软件分布图展示了应用软件在整个组织内的结构和布局，它在系统升级或应用整合项目中是非常有用的。此外，软件分布图还展示了物理应用在整个物理技术领域中是如何分布的，以及这些物理技术的位置。软件分布图对软件是如何被托管的这一问题提供了一份清晰的视图，而且还使得管理操作人员能够了解应用软件在安装成功后是如何被维护的。

4.2.46 技术标准目录（Technology Standards Catalog）

技术标准目标记录了企业中被批准的各项技术标准，涵盖了技术、版本、技术生命周期，以及技术的更新周期。根据组织需要，也可能包括地点或者业务的特定领域的标准信息。此目录提供了一个当前或能够被部署的企业标准技术的快照，并有助于在整个企业内搜寻差异。如果当前已经存在了各种技术标准，那么把它们放入到技术组合目录中将会得到一张关于各技术标准符合性的基线视图。此目录所涉及到的内容元模型实体包括：

• 平台服务
• 逻辑技术组件
• 物理技术组件

4.2.47 技术组合目录（Technology Por tfolio Catalog）

此目录的目标是识别和维护整个企业中在用技术的列表，包括硬件、技术设施软件，以及应用软件。一个经过批准的技术组合支持技术产品和版本的生命周期管理，而且还形成了技术标准定义的基础。技术组合目录为后续的矩阵和图形描述提供了基础，是技术架构开发阶段的起点。技术注册表和资源库从基线和目标的视角为此目录提供了输入。在此目录中的技术应该按照TOGAF技术参考模型（可以按照需要来对模型进行扩展，从而符合针对正在使用的技术产品的分类）进行分类。此目录所涉及到的内容元模型实体包括：

• 平台服务
• 逻辑技术组件
• 物理技术组件

4.2.48 系统/技术矩阵（System/Technology Matrix）

系统/技术矩阵记录了业务系统与技术平台之间的映射关系。此矩阵应该是一张或多张平台分解图的补充，并应与这些图保持一致。此矩阵展示了：

• 逻辑/物理应用组件。
• 服务、逻辑技术组件以及物理技术组件。
• 物理技术组件与物理应用组件之间的实现关系。

4.2.49 环境和位置图（Environments and Locations Diagram）

环境和位置图描述了哪些应用处于哪些位置，并标识出什么技术和/或应用被用在了哪些地方，以及表示出业务用户一般在何处与应用进行交互。此图还展示了不同部署环境的存在和位置，包括非生产环境，例如开发和预生产。

4.2.50 平台分解图（Platform Decomposition Diagram）

平台分解图描述了用于支持信息系统架构运行的技术平台。此图涵盖了技术设施平台的所有方面，并提供了一个关于企业技术平台的概览。此图可以通过扩展来将技术平台映射到适当的处于特定功能或流程区域内的应用组件。此图还可以被用来展示规范说明的细节，例如产品版本、CPU数量等，或者只是用来提供技术环境概览的非正式的“过眼图”。

此图应该清楚的展示企业应用和针对每个应用区域的技术平台，它可以被进一步分解为：

• 硬件：
• 逻辑技术组件
• 物理技术组件
• 软件：
• 逻辑技术组件
• 物理技术组件

4.2.51 处理图（Processing Diagram）

处理图关注于代码/配置的部署单元（针对业务功能、服务或应用组件的分组），以及这些单元是如何被部署到技术平台之上的。处理图表明了：

• 哪些应用组件需要被组织起来，并形成部署单元。
• 部署单元之间是如何连接和交互的。
• 应用配置和使用模式是如何针对不同的技术组件而产生负载或容量方面需求。

针对部署单元的组织和分组依赖于对组件的展示、业务逻辑以及数据存储层和服务水平需求这些方面关注点的分离。例如，展示层部署单元是基于如下方面进行分组的：

• 用于提供用户界面或用户访问功能的应用组件。
• 根据位置和用户角色来进行区分的应用组件。

每个部署单元是由若干子单元所组成的，例如：

• 安装单元：包含可执行的代码或封包配置的部分。
• 执行单元：应用组件以及与其相关的运行时状态。
• 持久化单元：代表应用组件的持久化状态的数据。

部署单元可以被部署到专用或共享的技术组件之上（工作站、Web服务器、应用服务器或数据库服务器等）。需要注意的是，技术处理对于服务的定义和粒度具有着较大的影响。

4.2.52 网络计算/硬件图（Networked Computing/Hardware Diagram）

从大型机到客户端-服务器系统的改造开始，以及随后的电子商务和J2EE的出现，大型企业逐步进入到了一个高度网络化的分布式网络计算环境之中。当前，大多数应用都具有一个Web前端，并且就这些应用的部署架构来说，具备三个独立层次的情况还是非常常见的，亦即Web表现层、业务逻辑或应用层，以及一个后台数据存储层。将应用部署到一个共享的通用技术设施环境之中也是一种常见的做法。

由此可见，将逻辑应用与在开发和生产过程中对应用进行支持的技术组件之间的映射关系记录起来是非常重要的。网络计算/硬件图的目标是展示逻辑应用组件在一个分布式网络计算环境中部署的逻辑视图。此图之所以有用，是因为通过此图我们可以：

• 了解应用部署在分布式网络计算环境中的什么地方。
• 建立针对这些技术组件的授权、安全和访问。
• 了解在问题解决和故障排除中用以支持应用的技术架构。
• 对应用所遇到的性能问题进行隔离，确定应用是代码相关的，还是技术平台相关的，并对具体的物理技术组件进行必要的升级。
• 当新的技术出现并能够因此带来成本缩减时，确定可通过此技术进行优化的区域。
• 使得应用/技术审计成为可能，并证明企业技术标准的符合性程度。
• 作为将变更引入到技术架构的用力工具，从而支持有效地变更管理。
• 当应用从一个共享环境迁移到一个专门的环境时，建立可追溯性和正在进行变化的应用的终端地址，反之亦然。

通过适当的定义，网络计算/硬件图的范围可以涵盖某一个特定的应用、业务功能或者是整个企业，而如果选择在企业级别进行开发，那么组织就可以通过一种与应用无关的方式来对网络计算情况进行描述。

4.2.53 通信工程图（Communications Engineering Diagram）

通信工程图描述了处在技术架构中的各资产之间的通信方法（收发信息的方法）。此图展示了客户端和服务器组件之间的逻辑连接，并明确了用于对这些逻辑连接进行实现的网络边界和网络基础设施。需要注意的是，此图并不描述参与通信的信息格式或内容，但它可以对通信协议以及容量方面的问题进行阐述。

4.2.54 项目背景图（Project Context Diagram）

项目背景图展示了作为过渡路线图一部分而实现的工作包的范围。此图会将工作包与在项目中被增加、删除或影响的组织、功能、服务、流程、应用、数据以及技术连接在一起。此图对于项目组合管理和项目动员来说也是一个有价值的工具。

4.2.55 效益图（Benefits Diagram）

效益图展示了在架构定义中识别出来的各种机会，并通过他们的相对规模、效益和复杂度进行分类。此图可被干系人用来对这些识别出来的机会进行选择、对其优先级进行定义，并对他们的顺序进行确定。

4.2.56 需求目录（Requirements Catalog）

需求目录包含企业需要用来满足目标要求的种种事物。在架构行为中所产生的需求一般会通过变更措施来实现，并在机会和解决方案阶段中界定其范围。需求还可以被用来作为质量保证的工具，从而保证针对特定架构的使用始终处在其使用范围之内。

4.3 针对视图的开发

如前所述，TOGAF中定义了一系列基本的架构制品来担当原子性视角，不同的组织可以根据自身的需要创建、改造或利用这些原子视角，并根据不同干系人的关注点将这些架构制品组合为适合于他们的视角定义，因而针对视图的开发需要明确其目标干系人、他们的关注点，以及所采用的各种基本架构制品和建模方法。TOGAF中针对多种视图的开发方法进行了建议，包括：

• 业务架构视图：此视图是为用户而进行开发的，它从系统用户的角度对系统的功能性方面进行关注。
• 企业安全视图：此视图是为系统安全工程师而进行开发的，它从安全的角度对系统如何实现，以及安全如何影响系统特性这些方面进行关注，这其中最重要的是，相关干系人能够了解如何确保系统仅能被具有权限的人员或系统来进行访问，以及如何保护系统不受到非授权地侵扰。
• 软件工程视图：创建一个软件密集型系统是非常耗费资源和时间的，因而建立一个能够帮助最小化劳力付出和风险的导则是非常必要的，而这正是软件工程视图的目标。此视图应该是为开发系统的软件工程师而进行开发的。
• 系统工程视图：此视图应该是为系统的系统工程人员而进行开发的，并从硬件/软件和网络连接的角度对系统如何被实现进行关注。
• 通信工程视图：此视图应该是为系统的通信工程人员而进行开发的，并在通信工程师的角度关注于系统是如何被实现的。
• 数据流视图：此视图应该是为系统的数据库工程师而进行开发的。此视图的主要关注点在于了解如何为正确的人员和应用通过适当的接口并在合适的时间提供正确的数据。
• 企业管理能力视图：此视图应该是为系统的运营、行政和管理人员而进行开发的。此视图的主要关注点在于了解系统是如何做为一个整体而被管理的，以及系统的所有组件是如何被管理的，这其中关键之处在于管理系统变更，并对预防性维护措施进行预测。
• 采购视图：此视图应该是为在架构组件的采购过程中所牵涉的人员而进行开发的。此视图的主要关注点在于了解哪些架构的构建块是需要被采购的，以及与采购行为相关的各种约束。