TOGAF架构内容框架之架构制品（上）

TOGAF架构内容框架之架构制品（上）

4. 架构制品（Architectural Artifacts）

架构制品是针对某个系统或解决方案的模型描述，与架构交付物和构建块相比，架构制品既不是架构开发方法过程各阶段的合约性产物，亦不是企业中客观存在的各种可重用解决方案，而是针对包括这些构建块在内的企业客观现实的描述，并以解答不同干系人的关注点为其最终目标。可以说，架构交付物面向于企业架构的产生，架构构建块倾向于企业架构的结果，而架构制品则注重于针对企业架构的应用（虽然架构交付物可以包含若干架构制品，但是架构制品在本质上还是被用来为不同的干系人按照其视角提供相应的企业客观视图，况且架构交付物对架构制品的包含本身也是架构制品的应用之一，其目的也是为了在架构开发过程中所涉及的不同干系人之间达成共识）。

企业架构并不是一个静态的过程，并且不能将建设一个包含企业架构内容的信息资源库当作唯一目标。对于任何企业来说，企业架构的意义都应该在于将其自身的战略决策、业务和信息技术资源联系为一个有机整体，并且不同的干系人都可以从企业架构中获得其所需的关于企业的自上而下（自业务至用于支持各项业务实现的解决方案）的视图，而这方面的内容属于针对企业架构内容的使用范畴。在这一范畴之中，所有的企业架构框架理论，哪怕是几乎不涉及企业架构内容的框架，都会关注于两个概念：视角与视图。关于这两者的概念，在前面的内容已经有所涉及，其中视角是针对不同干系人企业架构内容的需求描述，而视图是基于某一视角的具体架构内容描述，因而也可以说视角是视图的元类型定义。在这两个概念中，视图比较好理解，亦即根据视角的定义而对企业客观现状的某一侧面描述，相比之下，用于对视图进行定义的视角概念则更为关键。对于视角的定义来说，仅仅一句“一个视角描述了你站在何处进行观察”好像只能给人一种朦朦朦胧的感觉，为了更进一步描述这一概念，笔者通过对多个企业架构框架理论进行综合后，做出了如下的理解：视角是不同干系人对于企业架构内容需求的体现，亦即其采用何种角度对企业客观存在或计划存在的自顶层战略、业务至底层解决方案而进行观察。这些角度的定义基本上应该包括如下几个方面：

• 目标需求：不同的干系人担当着不同的角色及责任，其看问题的角度与担当的任务也因此有着非常紧密的联系。一般来讲，目标需求大体可以分为：
• 设计层面：包括了用于指导和支持与设计决策相关的各种制品。例如架构师、开发人员以及业务流程建模人员等干系人经常会用到的UML图、流程建模图（例如BPMN图）、以及用于描述数据的关系-实体图等制品都属于这一范畴。
• 决策层面：包括了用于支持高层决策的制品（例如，交叉引用表、情景图、以及各种报告等制品），适用于企业中处于管理高层的各种决策人，例如CEO、CIO等。
• 告知层面：包括了用于为相关干系人进行解释、说服以及获得其承诺方面的制品（流程概述、图表、宣讲动画等）。这些干系人可能会是一般职工、客户，或者其他在企业中从业务到解决方案这条线上虽不占关键位置却需要对企业架构进行了解的干系人。
• 抽象级别需求：上面一点描述了不同干系人由于其担负任务的不同，因而对于企业的观察也具有着不同的角度，从而对不同的制品产生兴趣。然而，即使不同的干系人针对企业的相同侧面有着共同的兴趣，但是他们对于描述的抽象级别或详细程度也可能有着不同的要求。例如，对于相同的业务流程来说，可能对于高层管理人员来说需要关注的仅是此流程的输入、输出，而对于其实现细节并不一定关心，而对于流程建模人员来说此业务流程恐怕就需要被细化为粒度更加细小的业务功能组合，而对于软件开发人员来讲，可能还要为某个具体业务行为而考虑其相关的数据结构和实现方案。
• 展示需求：上述两点可以说是依据干系人所持的角度在内容方面所进行的分类，而除此之外，由于不同的干系人由于各自的偏好不同，他们可能会对视图的展示也有着非常不同的要求。虽然在TOGAF中，架构制品的描述方式被定义为目录、矩阵和图形三种方式，但就其具体展示方式来说，不同的干系人还可能具有不同的要求和偏好。例如，对于组织结构的展示，有的干系人可能偏好于采用简单的树形结构的展示，而其他干系人则可能更加倾向于图形化的结构图。这种展示需求在图形展示方面尤其突出，某些干系人（特别是来自于内部的干系人，例如领域专家等）可能习惯于采用某种标准的标注体系来对架构内容进行展示，而对于其他干系人来讲（例如客户或非专业的干系人）采用如此方式可能并不能取得很好的效果，而采用更加贴近现实的图标来代替标准图标（通常是若干简单的形状、连线和颜色的组合）则更加友好。虽然展示需求也是视角定义所需靠虑的元素之一，但是在大多数情况下这一层面的定义往往可以采用松耦合的方式来进行描述，即将视角的定义分为内容和展示两个层面，并在两者之间建立关联（通常一个内容定义可以包含若干展示定义）。

上述关于视角分类的定义很容易让人产生非此即彼的感觉，即视角是为干系人服务的，因而应该仅从属于某种干系人。这样的思想除了源于思想的惯性，最主要的还是由于忽视了企业架构的核心精神—在组织中创建无障碍的沟通信息流。作为企业架构的核心概念，如果只把视角看作为企业架构描述用的约束和定义，而忽视了沟通这一本质则是违反企业架构最终目标的。每种干系人对于视角的采用都要着自己的要求，但反过来讲，视角却不一定从属于某种干系人，不同的干系人之间可以共享同样的视角，也只有这样才能保证不同干系人之间的顺畅沟通。正像TOGAF中所举的例子一样，飞机的飞行员和航空管制员对于飞行的视角各具特点，并采用不同的语言和元素来对“飞行”进行描述，但是他们同时也采用一种通用的语言（高度、速度等）来进行沟通。在这个例子中，飞行员和航空管制员在自己的领域内分别采用了自己的视角来对“飞行”进行理解和描述，不过作为沟通用的通用语言却形成了第三个，并且是他们所共享的视角。

企业架构开发过程的结果可以说是在架构资源库中按照架构元模型定义而填充的各种实体元素，这也方便了在对企业架构的使用中按照各个干系人的视角为其提供相应的视图。针对架构的使用需要自动化工具的支持，该工具需要支持视角的定义和管理，并能够从企业架构资源库中根据选定的视角生成相应的视图。

视角、工具和架构内容

不同的企业架构开发框架对于架构制品、视角和视图的定义，有着不同的描述。例如在Zachman框架中，每一个单元格所代表的是某一种干系人视角针对系统某个方面的描述，而在TOGAF中，The Open Group则采用了一种独特的方式对视角进行了组织和定义（需要注意的是，在上一节所提到的视角分类定义只是笔者针对几个框架理论所做的总结性描述，并不说每种框架理论都是通过这些方面来对视角进行分类和定义的）。与其他框架理论不同，TOGAF定义了一系列原子架构制品，并倡议在企业架构过程中根据不同干系人的需要对这些原子架构制品进行组合，从而生成对于视角的定义。这些原子架构制品业可被看为原子级的视角定义，实际上在TOGAF中也正是用视角（ViewPoint）这个词来称呼各个架构开发阶段相关的原子架构制品。TOGAF并不强制其用户遵循这些原子架构制品，用户可以根据自己的需要增加新的原子架构制品，或对已经定义的原子架构制品进行修订。根据架构制品的描述形式，TOGAF将这些原子架构制品分为以下三类：

• 目录（Catalogs）：此种类型的原子架构制品（视角）以列表的形式对各种构建块进行列举。
• 矩阵（Matrices）：此种类型的原子架构制品（视角）用于展示特定构建块之间的关系。
• 图形（Diagrams）：此种类型的原子架构制品（视角）采用了一种具有丰富表现力的方式对构建块以及他们之间的关系进行了展示。此种方式特别适合用于在干系人之间进行沟通的场合。

4.1 架构开发过程与架构制品

表面上架构制品并不像架构交付物那样与架构开发方法的各个阶段有着很强的契约性关联，但是做为架构交付物的重要组成部分，架构制品与架构开发方法之间也有着非常紧密的联系。在TOGAF中，针对架构制品的组织和描述也是以架构开发方法各阶段为基础的，它详尽展示了在每个架构开发方法阶段中所产生的各个原子架构制品，以及这些架构制品与架构内容元模型各扩展之间的关系。

架构开发方法阶段	架构制品类型	架构制品	内容元模型扩展
预备阶段	目录	原则目录	核心
	矩阵	N/A
	图形	N/A
架构愿景	目录	N/A
	矩阵	干系人映射矩阵	Core
	图形	价值链图	Core
		解决方案概念图	Core
业务架构	目录	组织/执行者目录	Core
		驱动力/目标/阶段目标目录	Motivation
		角色目录	Core
		业务服务/功能目录	Core
		位置目录	Infrastructure Consolidation
		流程/事件/控制/产品目录	Process
		合同/评测目录	Governance
	矩阵	业务/交互矩阵	Core
		执行者/角色矩阵	Core
	图形	业务足迹图	Core
		业务服务/信息图	Core
		功能分解图	Core
		产品生命周期图	Core
		目标/阶段目标/服务图	Motivation
		用例图	Service
		组织分解图	Service
		流程图	Process
		事件图	Process
信息系统架构 （数据）	目录	数据实体/数据组件目录	Core
	矩阵	数据实体/业务功能矩阵	Core
		系统/数据矩阵	Core
	图形	类图	Core
		数据传播图	Core
		数据安全图	Data
		类层次结构图	Data
		数据迁移图	Data
		数据生命周期图	Data
信息系统架构 （应用）	目录	应用组合目录	Core
		接口目录	Core
	矩阵	系统/组织矩阵	Core
		角色/系统矩阵	Core
		系统/功能矩阵	Core
		应用交互矩阵	Core
	图形	应用通信图	Core
		应用及用户位置图	Core
		系统用例图	Core
		企业管理能力图	Governance
		流程/系统实现图	Infrastructure Consolidation
		软件工程图	Infrastructure Consolidation
		应用迁移图	Infrastructure Consolidation
		软件分布图	Infrastructure Consolidation
技术架构	目录	技术标准目录	Core
		技术组合目录	Core
	矩阵	系统/技术矩阵	Core
	图形	环境及位置图	Core
		平台分解图	Core
		处理图	Infrastructure Consolidation
		网络计算/硬件图	Infrastructure Consolidation
		通信工程图	Infrastructure Consolidation
机会及解决方案	目录	N/A
	矩阵	N/A
	图形	项目背景图	Core
		效益图	Core
需求管理	目录	需求目录	Core
	矩阵	N/A
	图形	N/A

4.2 架构制品定义

4.2.1 原则目录（Principles catalog）

原则目标对各项业务原则及架构原则进行列举，用以表明一个好的解决方案或架构看起来应该是什么样子。原则用于对各架构决策点的输出进行评估和认可。原则也可在针对变更举措的架构治理中充当辅助工具。

4.2.2 干系人映射矩阵（Stakeholder Map Matrix）

干系人映射矩阵用于明确参与架构活动的各个干系人、他们的影响、他们的主要问题，以及架构框架所必须解答的关注点。通过对于干系人的识别，并对他们的需求进行理解，架构师可以将注意力集中在能够满足干系人需求的各个领域之中。此目录所涉及到的内容元模型实体包括：

• 原则

4.2.3 价值链图（Value Chain Diagram）

价值链表提供了一张面向高层的企业视图，用于表示企业如何与外界环境交互。与在业务架构阶段中开发出来的更加正式的功能解构图相比较，价值链表更着重于表象上的影响。价值链表的目标是使一个特定的变更主张能够快速地在干系人中获得一致性认识，从而使得所有参与者能够对架构所涉及到的高层次功能性和组织性环境进行理解。

4.2.4 解决方案概念图（Solution Concept Diagram）

解决方案概念图提供了一个解决方案的高层次方向，用于达成架构所涉及的各个目标。与后续架构开发方法阶段开发出来的、更正式且更详细的架构图相比较，解决方案概念图更像是在一开始阶段关于期望解决方案的一张草图。这张图体现了关键的目标、需求和约束，并对将采用正式架构模型来进行更详细描述的各个工作区域进行了标明。解决方案概念图的目标是使一个特定的变更主张能够快速地在干系人中获得一致性认识，从而使所有的参与者能够理解架构所需要的究竟是什么，以及一个特定的解决方案被期望以何种方式来满足企业的需求。

4.2.5 组织/执行者目录（Organization/Actor Catalog）

该目录的目标是得到一份明确的包括用户和IT系统所有者在内的所有与IT有互动的参与者列表。该列表可以在开发需求时作为完备性检测的参考。例如，针对于一个对客户进行服务支持的应用的需求，我们可以通过如下几个方面对其进行完备性检测：

• 需要对何种类型的客户进行支持。
• 是否某种类型的用户存在特定需求或约束。

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

• 组织单位
• 执行者
• 位置（如果一个单独的位置目录并不存在，则关于位置的信息就需要在这个目录中加以维护）

4.2.6 驱动力/目标/阶段目标目录（Driver/Goal/Objective Catalog）

该目录的目标是描述组织如何通过目标、工作目标和评测（可选内容）来满足其驱动力的需要，并为此提供一份跨越组织的参考。通过针对驱动力、目标和阶段目标的层层分解，各个变更举措可以采用一种跨越组织边界的方式进行协同，并在随后的活动中使得各个干系人得以被明确，此外，相关的变更举措也能够被整合或协调起来。此目录所涉及到的内容元模型实体包括：

• 组织单元
• 驱动力
• 目标
• 阶段目标
• 评测（可选内容）

4.2.7 角色目录（Role Catalog）

角色目录的目标是为企业中所有的授权级别或区域提供一份列表。一般情况下，应用的安全或行为应该按照其对授权概念的理解而分别进行定义，但在与用户的计算机相绑定时却造成了复杂且不被期望的后果。如果角色在整个组织和所有应用中都得到了定义、理解和共识，那么更加安全并能够提供更加无缝的用户体验的应用将会出现，因为管理员无需通过迂回的解决方法来使用户执行他们的工作。除了对企业的安全定义进行支持，角色目录还可以是明确组织变更管理影响、定义工作职能，以及执行最终用户培训这些方面的关键输入。

由于每个角色都暗含着关于一系列业务功能的访问，如果这些功能被影响到，那么变更管理将必不可少，组织的职责也需要被重新定义，同时新的培训可能也是需要的。此目录所涉及到的内容元模型实体包括：

• 角色

4.2.8 业务服务/功能目录（Business Service/Function Catalog）

业务服务功能目录的目标是提供一份功能性的解构，使得各种功能可以被过滤、汇报和查询，并能够作为功能结构图的一个有力补充。服务功能目录可以被用来对组织中的各项能力进行明确，并对组织中施加到各种功能上的治理水平加以理解。通过功能解构，用于支持业务变化所需要的各种新能力能够被识别出来，或者对变更措施、应用以及技术组件的范围进行确定。此目录所涉及到的内容元模型实体包括：

• 组织单位
• 业务功能
• 业务服务
• 信息系统服务（可选内容）

4.2.9 位置目录（Location Catalog）

位置目录为企业的业务运营或房屋建筑相关的资产（例如数据中心或终端用户计算设备）所处位置提供了一份列表。针对此位置列表的维护，各个变更举措的位置范围得以被快速地定义出来，并且针对当前情况和建议的目标解决方案进行评估时，完备性测试也得以被执行。例如，一个用于更新台式计算机操作系统的项目需要识别出这些系统所部署的位置。与此相似，当实施一个新的系统时，一张关于位置的图形描述对于开发适当的部署策略是非常关键的，该部署策略被用于对用户和应用的位置进行了解，并且各个与位置相关的问题（例如，国际化、本地化、针对可用性的时区影响、延时距离影响、网络带宽影响和访问）也得以被明确。此目录所涉及到的内容元模型实体包括：

• 位置

4.2.10 流程/事件/控制/产品目录（Process/Event/Control/Product Catalog）

流程/事件/控制/产品目录为流程、触发流程的事件、流程的输出和施加到流程执行之上的控制提供了一份层次结构，并可被用来作为流程图（Process Flow diagram）的一个有力的补充，这些流程图使得企业可以进行跨越组织和流程的过滤、汇报和查询操作，从而对其范围、通用性或影响进行明确。例如，流程/事件/控制/产品目录使得企业可以查看流程与各子流程之间的关系，从而明确源自于一个高层流程的变更所能带来的影响链。此目录所涉及到的内容元模型实体包括：

• 流程
• 事件
• 控制
• 产品

4.2.11 合同/评测目录（Contract/Measure Catalog）

此目录提供了一份关于所有经过批准的服务合同以及与此相关的评测的列表，从而形成了在整个企业内获得批准的服务水平的主列表。此目录所涉及到的内容元模型实体包括：

• 业务服务
• 信息系统服务（可选内容）
• 合同
• 评测

4.2.12 业务交互矩阵（Business Interaction Matrix）

此矩阵用于描述企业中各组织与业务功能之间的交互关系。理解企业中的业务交互是很重要的，因为它有助于突出整个组织中的价值链以及相互依赖关系。此矩阵所涉及到的内容元模型实体包括：

• 组织
• 业务功能
• 业务服务
• 业务服务之间的通信关系
• 业务服务之间的依赖关系

4.2.13 执行者/角色矩阵（Actor/Role Matrix）

此矩阵用于展示哪些执行者扮演何种角色，并支持对安全性和技能需求的定义。理解执行者与角色之间的关系对定义培训需求、用户安全设置和组织变更管理具有关键性作用。此矩阵所涉及到的内容元模型实体包括：

• 执行者
• 角色
• 执行者与角色之间的担当关系

4.2.14 业务足迹图（Business Footprint Diagram）

业务足迹图描述了业务目标、组织单元、业务功能和服务之间的关联，并将这些功能映射到各个提供了所需能力的技术组件之上。它在从技术组件到业务目标的映射中提供了清晰的可追溯性，同时还对已经明确的服务的所有权进行了阐述。业务功能图仅对联系组织单元功能与交付服务的关键因素进行描述，并且还可被用来作为与高层次干系人（CIO、CEO等）进行沟通的平台。

4.2.15 业务服务/信息图（Business Service/Information Diagram）

业务服务/信息图展示了用于对一个或多个业务服务进行支持的信息，包括了由业务服务使用或者产生的数据及其信息源。服务/信息图对信息在架构中的最初表现形式进行了展现，因此为数据架构阶段的进一步描述打下了基础。

4.2.16 功能分解图（Functional Decomposition Diagram）

功能分解图的目标是将组织中与架构相关的各项能力展现在一张图纸之上。通过从功能的视角检视组织的各项能力，企业可以快速针对组织所做的事情进行建模，而不用陷入针对组织如何做所进行的额外讨论之中。

4.2.17 产品生命周期图（Product Lifecycle Diagram）

产品生命周期图的目标是对企业中关键实体的理解进行辅助。就关于产品从生产到撤销过程中所必须遵守的环境的关注、立法和规章来说，理解产品生命周期变得越来越重要。与此相同，在为了保证在控制、流程和程序的设计严谨而进行的业务架构开发过程中，创建涉及个人或敏感信息产品的组织必须对产品生命周期具有一个详尽的理解，例如信用卡、借记卡、智能卡以及用户身份认证等信息。

4.2.18 目标/阶段目标/服务图（Goal/Objective/Ser viceDiagram）

此图的目标是为服务对业务愿景或策略的达成而定义方法。通过将服务与驱动力、目标、阶段目标和相关的评测进行关联，企业可以了解到哪些服务贡献于相似的业务效能方面。此外，该图还为针对某一特定服务所形成的高效能的认定提供了定性的输入。

4.2.19 业务用例图（Business Use-Case Diagram）

业务用例图展示了业务服务的提供者和使用者之间的关系。业务服务被各个执行者或其他的业务服务所使用，而业务用例图则通过针对业务能力在何时以及如何被使用的描述，为业务能力的描述方面提供了额外的价值。此图形的目标是对各执行者和他们在各流程和功能中所担当的角色之间的交互关系进行描述和验证。随着架构过程的演进，这些用例图也将从业务级别发展至包括数据、应用和技术在内的更加详尽的级别。除此之外，业务用例图也可在系统设计工作中得到复用。

4.2.20 组织分解图（Organization Decomposition Diagram）

组织分解图描述了执行者、角色以及他们在组织树中所处位置之间的关系。一份组织分解图应提供了一条组织中决策者和业务拥有者的命令链。虽然组织分解图并不打算将组织与其目标联系在一起，但是在这张图中为最终目标与干系人之间建立直观的联系也是可以的。

4.2.21 流程图（Process Flow Diagram）

流程图的目标是对流程元模型实体相关的所有模型和映射进行描述，它展示了位于各个活动之间的顺序化控制流，并可借助于泳道技术来表达各个流程步骤的归属和实现。例如，用于支持一个流程步骤的应用就可以作为一条泳道来展示。除此之外，流程图也可以被用来细化赋予在流程之上的控制、触发某流程或产生于流程结束时的事件，以及由于流程执行所产生的各种输出产物。流程图在为主题专家描述架构时非常有用，它可以为这些专家描述一个特定功能的工作是如何被完成的。通过这样一个过程，每个流程步骤可以被细化为更小粒度的功能块，而且这些功能块在以后亦可以被当作一个流程来进行进一步的阐述。

4.2.22 事件图（Event Diagram）

事件图的目标是描述事件与流程之间的关系。诸如某些特定信息的到来，或者是某个特定的时间点这样的特定事件会致使业务中特定的工作和行为得以进行，同时也经常会有被称为业务事件（或简称事件）的信息被当作某个流程的触发者。

4.2.23 数据实体/数据组件目录（Data Entity/Data Component Catalog）

数据实体/数据组件目录的目标是明确和维护企业中使用的所有数据的列表，包括数据实体，以及用于存储数据实体的数据组件。一个经过批准的数据实体/数据组件目录支持对信息管理和数据治理策略的定义和应用，并且鼓励对数据进行有效地共享和重用。此目录所涉及到的内容元模型实体包括：

• 数据实体
• 逻辑数据组件
• 物理数据组件

4.2.24 数据实体/业务功能矩阵（Data Entity/Business Function Matrix）

此矩阵用来描述企业中数据实体和业务功能之间的关系。业务功能被具有明显边界的业务服务所支持，并通过业务流程加以实现。通过数据实体与业务功能之间的映射，企业可以得到：

• 将数据实体的所有权分配给各个组织。
• 理解业务服务的数据和信息交换需求。
• 支持差距分析，并决定是否有需要被创建的数据实体被遗漏。
• 为数据实体定义源系统、记录系统和引用系统。
• 启动企业的数据治理程序的开发（建立数据管家、开发与业务功能相关的数据标准等）。

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

• 数据实体
• 业务功能
• 数据实体与其所属组织单位的“从属”关系

4.2.25 系统/数据矩阵（System/Data Matrix）

此矩阵用于描述系统与系统所访问和更新的数据实体之间的关系（一张两维表，其中一个纬度对应逻辑应用组件，而另外一个则对应数据实体）。系统用于创建、读取、更新和删除与他们相关联的特定数据实体。例如，一个客户关系系统将创建、读取、更新和删除客户实体信息。处在一个被封包好的服务环境中的数据实体可以被分为主数据、引用数据、事务数据、内容数据和历史数据，而用于操作这些数据实体的应用则包括事务应用、信息管理应用和业务仓库应用。针对应用组件和数据实体之间映射是一个非常重要的步骤，因为它可以使得：

• 针对数据的访问能力被分配给组织中的具体应用。
• 了解在不同应用中数据重复的程度，以及数据生命周期的规模。
• 了解在何处相同的数据会被不同的应用所更新。
• 支持差距分析，并确定是否本应存在的应用被遗漏了。

4.2.26 类图（Class Diagram）

类图的主要目标是描述企业中重要数据实体（或类）之间的关系。此图用于清晰地展示数据之间的关系，并帮助干系人理解企业下层数据模型。

4.2.27 数据传播图（Data Dissemination Diagram）

数据传播图的目标是展示数据实体、业务服务和应用组件之间关系。此图展示了各个逻辑实体如何被应用组件所实现。它使得针对数据大小的调整得以被有效地执行，同时IT足迹也会得以改善。而且，通过为数据设置业务价值，应用组件的业务重要性的指标也能够在同时被获得。另外，此图还可以展示针对数据复制和主引用的所有权，即它可以展示数据的两个备份以及数据之间的主-备份关系。此图还能够包含服务，比如，封装数据并且驻留在应用之内的服务，或者驻留在应用之上并能够访问封装在应用中的数据的服务。

上面所说的IT footprint中，footprint，即足迹，的本意是由动物遗留下的包含了遗留者本身标识和信息的事物。在信息技术领域，根据哈佛商学院Andrew McAfee所述，技术足迹表示了其在地理、逻辑分区和/或功能方面所能延展到范围，是针对一个信息技术所期望的覆盖范围的描述（A technology's footprint is its geographic, divisional, and/or functional reach. It's a description of how much territory a piece of IT is intended to cover）。在TOGAF中并没有说明数据大小的调整与IT足迹改善之间的关系，也没有说明所谓的IT足迹改善的具体含义。不过通过互联网上的一个关于IT足迹改善的实例，即将原本有着十几台计算机的教室用一台中心计算机和若干终端来代替，笔者有感而发，粗浅的认为这里IT足迹改善意思是说由于数据尺寸得到了很好的调整，那么不必需的冗余信息被削减，因而数据和应用的“足迹”，即其涉及到的范围，将比冗余剔除前更加清晰有效

4.2.28 数据安全图（Data Security Diagram）

数据可以看作是企业的一项资产，简单的讲，数据安全可被认为是确保企业数据不被损害，并且针对数据的访问也要在适当的控制之下。数据安全图的目标是描述何执行者可以访问企业中的哪些数据。此外，此图也可以被用来阐述与数据隐私法规以及其他应用性法规的符合度。此图还需要考虑发生在企业合作伙伴或其他团体对企业系统进行访问之处的信任含义，例如在外包的情形下，信息可能会被企业之外的其他人员（甚至身处国门之外）所管理。

4.2.29 类层次结构图（Class HierarchyDiagram）

类层次结构图的目标是为技术方面的干系人展示一个有关类层次的视图。此图的优点是干系人可以得到一份关于数据实体在技术层面上如何被使用的图形描述，它使得干系人可以了解何人正在针对数据进行使用，以及他是在何时、如何以及为何进行这项活动。

4.2.30 数据迁移图（Data Migration Diagram）

在实现一个以封包服务为基础的解决方案时，数据迁移是非常重要的，特别是将现存的遗留系统替换为一个服务封包时，或者当企业将要迁移到一个更大的封包服务时。每个服务包都倾向于具有属于他们自己的数据模型，并且在数据迁移过程中，遗留的应用数据可能需要在载入到服务封包之前需要进行某种转化。数据迁移活动通常包含如下的步骤：

• 从原有应用中抽取出数据。
• 配置源数据
• 执行数据转换，其中包括数据质量相关的各个过程：
• 对数据进行标准化、归一化，并消除数据的重复性（数据清洗）。
• 针对不同来源的数据进行比对、合并和整合。
• 进行自源头至目标的映射
• 将数据加载到目标应用之中。

数据迁移图的目标是展示数据如何从源头应用流入到目标应用之中。此图为数据从源头到目标过程的进行提供了一个可视化表达，并可在数据审计和追溯中作为辅助工具。此外，此图所展示的细节程度可以按照需要进行调整。例如，数据迁移图可以仅仅包含一个关于迁移情况的整体布置，也可以为单独的应用提供元数据元素级别的详细信息。