《DAMA数据管理知识体系指南》04—第4章 数据架构 知识点记录

第4章 数据架构 知识点记录

知识点记录

4.1 引言

1.企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。

2.考虑数据架构的几个方面：
1）数据架构成果，包括不同层级的模型、定义、数据流，这些通常被称为数据架构的构件。
2）数据架构活动，用于形成、部署和实现数据架构的目标。
3）数据架构行为，包括影响企业数据架构的不同角色之间的协作、思维方式和技能。
以上三方面的内容是数据架构的基本组成部分。
数据架构是数据管理的基础。

3.数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控策略中要求的数据资产管理规范。

4.1.1 业务驱动因素

4.数据架构的目标是在业务战略和技术实现之间建立起一座通畅的桥梁。

5.数据架构主要职责为：
1）利用新兴技术所带来的业务优势，从战略上帮助组织快速改变产品、服务和数据。
2）将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效数据。
3）管理复杂数据和信息，并传递至整个企业。
4）确保业务和IT技术保持一致。
5）为企业改革、转型和提高适应性提供支撑。
以上业务驱动的职责是评判数据架构任务完成情况或价值的重要指标，这些指标直接影响对数据架构工作好坏的评估。

4.1.2 数据架构成果和实施

6.数据架构的主要成果包括：
1）数据存储和处理需求。
2）设计满足企业当前和长期数据需求的结构和规划。

7.架构师寻求一种能够为组织带来价值的方式对组织的数据架构进行设计。
数据架构师需要定义和维护的具体事宜如下：
1）定义组织中数据的当前状态。
2）提供数据和组件的标准业务词汇。
3）确保数据架构和企业战略及业务架构保持一致。
4）描述组织数据战略需求。
5）高阶数据整合概要设计。
6）整合企业数据架构蓝图。

8.总体数据架构实施包括：
1）使用数据架构构件（主蓝图）来定义数据需求、指导数据整合、管控数据资产，确保数据项目投入与企业战略保持一致。
2）与参与改进业务或IT系统开发的利益相关方合作，学习并影响他们。
3）通过数据架构及通用的数据词汇，搭建企业数据语言。

4.1.3 基本概念

1.企业架构类型

9.企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。
该四类架构的具体描述和比较如下：

同类型的架构师除了致力于自己所属的架构设计和实施工作外，还必须了解与其紧密关联的架构需求，因为每个架构都不是孤立存在的，要么对其他架构产生影响，要么受制于其他架构

2.企业架构框架

10.企业架构框架是用于开发广泛的相关架构的基础结构。架构框架提供了思考和理解架构的方式。他们代表了一个总体的“架构的架构”。
11.最著名的企业架构框架是由John A Zachman在20世纪80年代开发的Zachman框架。Zachman框架是一个本体，即6 × 6矩阵构成了一组模型，这组模型可以完整地描述一个企业以及相互之间的关系。它并不定义如何创建模型，只是显示哪些模型应该存在。

矩阵框架的两个维度为：问询沟通（如是什么、怎样做、在哪里、是谁、什么时间和为什么）在列中显示，重新定义转换（如识别、定义、描述、规范、配置和实例）在行中显示。框架分类按照单元格呈现（问询和转换之间的交叉）。框架的每个单元格代表一个独特的设计组件。

3.企业数据架构

12.数据架构定义了对组织非常重要元素的标准术语和设计。企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。
13.企业数据架构描述必须包括企业数据模型（如数据结构和数据规范）和数据流设计。
1）企业数据模型。企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。通常用于表示高层级简化的数据模型，也表示了不同抽象层级。企业数据模型包括数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性，它为所有数据和数据相关的项目奠定了基础。任何项目级的数据模型必须基于企业数据模型设计。企业数据模型应该由利益相关方审核，以便它能一致有效地代表企业。
2）数据流设计。定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。这些数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的流动。
这两种模型需要互相配合。如前面所提到的，这两个模型都需要反映当前状态和目标状态（架构视角）及过渡状态（项目视角）。
注意：采用行业标准模型能够加快开发企业数据模型的效率。这些模型提供了有用的指南和参考。然而，即使组织已经开始着手购买数据模型，但设计企业级的数据模型仍需要大量的投资。其工作包括定义和管理企业词汇、业务规则和企业知识。企业级数据模型设计、开发完成后，后继维护和丰富企业数据模型也仍然需要投入持续的时间和精力。

14.下图显示了不同的模型是如何关联的，以及概念模型如何最终与物理应用数据模型关联。

各层级的模型是企业数据模型的组成部分，模型链接定义和管理了模型的纵向从上到下以及横向之间的关联路径。

15.企业概念数据模型是由主题域模型相结合构建的。每个企业数据模型既可以采用自上而下，也可以采用自下而上的方法进行构建。自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成。通常推荐两种方法相结合，即自下而上地从分析现有模型开始，自上而下地设计主题模型，通过两种方法的结合来共同完成企业数据模型的设计工作。
16.主题域的识别准则必须在整个企业模型中保持一致。常用的主题域识别准则包括：使用规范化规则，从系统组合中分离主题域，基于顶级流程（业务价值链）或者基于业务能力（企业架构）从数据治理结构和数据所有权（或组织）中形成主题领域。
数据流设计
17.数据流是一种记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动。端到端的数据流包含了数据起源于哪里，在哪里存储和使用，在不同流程和系统内或之间如何转化。数据血缘分析有助于解释数据流中某一点上的数据状态。
18.数据流映射记录了数据与以下内容的联系：
1）业务流程中的应用。
2）某个环境中的数据存储或数据库。
3）网段（有助于安全映射）。
4）业务角色（描述哪些角色有职责创建、更新和删除数据）。
5）出现局部差异的位置。
19.数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系。系统可以通过网络、平台、常用应用集或独立服务器呈现。数据流可以通过二维矩阵（图4-5）或数据流图（图4-6）的方式呈现。

4.2 活动

20.简化数据和企业架构所面临的复杂问题，基于以下两种方式解决：
1）面向质量。专注于业务和IT开发周期内对数据架构进行不断改进。如果架构没有得到妥善管理，也会慢慢遭到破坏，系统逐渐变得越来越复杂和缺乏扩展性，因而给组织带来风险。对数据整合、数据复制以及“意大利面”式接口关系无法控制，这会使组织效率越来越低，并降低数据的真实性。
2）面向创新。专注于业务和IT转换，致力于新的期待和机会。用创新性技术和数据使用驱动创新，已经成为现代企业架构的一种功能。

4.2.1 建立企业数据架构

21.建立企业数据架构通常包括以下工作，这些工作可以串行或并行执行。
1）战略。选择框架，制定方法，开发路线图。
2）沟通与文化。建立沟通机制，并激励积极参与者。
3）组织：通过明确责任和职责来组织数据框架工作。
4）工作方法。与企业架构保持一致，在开发项目中定义最佳实践并执行数据架构工作。
5）结果。在总体路线图中产出数据架构产品。

22.企业数据架构也会影响项目和系统开发的范围边界。如：
1）定义项目数据需求。通过数据架构为企业提供每个项目的数据需求。
2）审评项目数据设计。通过设计审评来确保概念、逻辑和物理数据模型与架构一致，与组织的长期策略一致。
3）确定数据溯源影响。确保数据流在应用中的业务规则一致并且可追溯。
4）数据复制控制。复制是一种常见的，能够提供改善应用性能和便于获取数据的方法，但是也有可能导致数据的不一致。数据架构治理能保证充分的复制控制（方法和机制）来达到所需的一致性（并不是所有应用要求的严格程度都一致）。
5）实施数据架构标准。为企业数据架构生命周期制定和实施标准。标准可以表示为原则、流程、指南和规划蓝图。
6）指导数据技术和更新决策。数据架构与企业架构一起管理每个应用的数据技术版本、补丁和数据技术路线图策略。

1.现有数据架构规范评估

23.每个组织都保存着现有系统的一系列文档。为了了解当前数据架构，需要识别这些文件，并评估其准确性、完整性和详细程度。如果必要，还需要更新这些文件使其真实反应系统的当前状态。

2.开发路线图

24.路线图提供了一种管理这些依赖性并做出前瞻性决策的方法。路线图有助于组织权衡并制订夯实的项目计划，使其与业务需求和机会、外部需求、可用资源保持一致。
25.企业数据架构路线图描述了架构3～5年的发展路径。考虑到实际情况和技术评估，路线图和业务需求共同将目标架构变为现实。企业数据架构路线图必须与企业架构路线图相整合，企业架构路线图包括：高层次里程碑事件、所需资源、成本评估、业务能力工作流划分。路线图应以数据管理成熟度评估为指导（参见第15章）。
26.多数业务能力都需要数据输入，有些业务能力还可以生成其他业务能力依赖的数据。在业务能力之间的依赖链上，解析这些数据能够形成一致的企业架构和企业数据架构。
27.业务数据驱动路线图可以从最独立的业务能力开始（如对其他业务能力依赖最小），再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力，需要遵循整体业务数据生成顺序。图4-7是一个业务能力数据依赖链的例子，顶部模块依赖最底部模块。产品管理和客户管理不依赖任何模块，因此属于主数据。依赖度最高的模块位于底部，客户发票管理依赖客户管理和销售订单管理，而销售订单管理也依赖另外两个管理模块。
因此，在理想中，建议从产品管理和客户管理能力开始路线图，然后从上到下解决每一步依赖关系。

图4-7 业务能力的数据依赖

3.在项目中管理企业需求

架构不应该受开发时间的限制。利用数据模型及其有关规范描述的组织数据架构必须足够灵活，并能适应未来需求。构建架构层级的数据模型不仅应有企业全局观，而且要有能够让企业内部完全清楚理解的定义。
对获取、存储、分发数据的开发项目实施解决方案，需要以业务需求和企业数据架构的标准为基础。这个过程是需要逐步完成的。
在项目级别上，通过数据模型定义需求的过程是从审查业务需求开始的。通常，这些需求是特定于项目目标的，不会对企业产生影响。该过程还应包括开发术语定义和支持数据使用的其他活动。

28.数据架构师必须能够理解需求与其他整体架构的关系。当项目范围完成时，数据架构师应该决定：
1）规范中所描述实体是否符合标准。
2）在需求中，哪些实体应该被包括在整体企业数据架构中。
3）规范中的实体和定义是否需要扩大或加深以满足将来的趋势。
4）是否更新了数据架构或者是否向开发人员指出了哪些可以重用。
组织经常要等到项目需要重新设计数据存储和集成的时候，才来解决数据架构问题。但是，最好在规划的早期和整个项目生命周期中考虑这些因素。

29.企业数据架构项目相关的活动包括：
1）定义范围。保证范围和接口与企业数据模型一致。理解项目对整体企业数据架构的潜在贡献、项目的建模和设计、哪些现有组件应该或能够被重用。在需要设计的部分，对项目应该确定项目范围外的利益相关方的依赖性，如下游流程。确定项目共享或重要的数据构件，把它们整合到企业逻辑数据模型和指定的存储库中。
2）理解业务需求。获取数据相关的需求，如实体、资源、可用性、质量和痛点，以及评估满足这些需求的业务价值。
3）设计。形成详细的目标规范，包括：数据生命周期内的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等。企业逻辑数据模型和企业架构知识库可用于项目数据架构师查询，为企业内可重用数据结构共享提供很好的支撑。同时，审核和使用数据技术标准。
4）实施。
①什么时候购买。可以考虑购买支持逆向工程的软件（商用产品）、逆向数据库中的数据模型，对比项目建设期提供的设计文档或模型，识别并记录数据模型、定义、规则等方面的差异和不同。在理想情况下，供应商应提供其产品的数据模型，然而因考虑到优先事项，许多产品中并不提供数据模型。如果可能，尽量与供应商协商，让他们提供深度定义的数据模型。
②什么时候重用数据。通过建立应用数据模型与通用数据结构、现有流程和新流程之间的对比映射关系，来理解CRUD操作。强制使用管理该结果的系统记录或其他权威数据，以便识别和存储差异。
③什么时候构建。根据数据结构进行数据存储；根据标准或设计并评审通过的规范进行集成（参见第8章）。

30.项目中的企业数据架构角色依赖软件开发过程。将架构活动嵌入到项目中,具体采用的方式有以下三种：
**1）瀑布方式。**作为整个企业设计的一部分，在连续阶段中理解需求和构建系统。这种方法包括设计用于控制变化的关口。按照这种方式开展数据架构活动通常没有太多问题，但需确保能够从企业视角设计架构和考虑问题，以避免局限性。
**2）迭代方式。**逐步学习和构建（如小型瀑布模型）。这种方式适合总体需求模糊的原型。这种方式在启动阶段至关重要，最好是早期迭代中创建一个全面的数据设计。
**3）敏捷方式。**这种方式是指在离散的交付包中学习，构建并测试（称为“sprints”冲刺）。离散的交付包很小，如需要丢弃，也不会损失太多。敏捷模型（Scrum，快速开发，统一流程）能提高目标导向的模型，强调用户界面设计、软件设计和系统行为。使用数据模型、数据捕获、数据存储和数据分布规范完成这些方法。当程序员和数据架构师有很强的工作联系，并且他们的标准和指南兼容时，可以采用DevOps方法。DevOps是一种新兴且流行的敏捷方法，它可以帮助改进数据设计，并使得数据设计的选择更有效。

4.2.2 整合其他企业架构

从主题域层级到更细化的层面，对每个层面都需要建立与其他类型架构的联系。开发企业数据架构规范的工作通常是在某些项目中一并进行的，这些项目决定了架构工作的优先级。然而，企业范围的架构问题应该及早解决。事实上，数据架构可能会影响项目的范围。因此，最好把企业数据架构问题和项目组合管理进行整合。这样做能促进路线图的实施，有助于获得更好的项目效果。
同样，企业数据架构师的工作应被包含在企业应用开发和整合计划中，同时将数据架构视图应用于目标应用场景以及该场景的路线图中。

4.3 工具

31.数据架构工具包含数据建模工具、资产管理软件、图形设计应用。

4.3.1 数据建模工具

在管理所有层级数据模型的过程中，数据模型工具和模型库都是非常必需的。市场上，很多数据模型工具具有数据血缘和关系跟踪功能，这便于架构师能够管理为了不同目的及在不同抽象层级中创建的数据模型（参见第5章）。

4.3.2 资产管理软件

资产管理软件用于管理数据资源目录，描述其内容以及跟踪它们之间的关系。另外，利用这些工具还可以确保组织遵循软件许可相关的合同义务，并收集资产相关的数据，最小化成本，优化IT流程。由于通过数据资产管理软件盘点了IT资产，所以这些工具收集并包含了关于系统及相关数据的元数据。在创建数据流或研究当前状态时，这些元数据非常有用。

4.3.3 图形设计应用

图形设计应用可以用于创建架构设计图形、数据流、数据价值链和其他架构构件。

4.4 方法

4.4.1 生命周期预测

32.架构设计可以是针对当前的，也可以是面向未来的，还可以是已实施并完成的，甚至是准备退役的产品。无论哪种情况，其工作成果都应该存档管理。
1）当前的。当前支持和使用的产品。
2）部署周期的。未来1～2年内部署使用的产品。
3）策略周期的。未来两年后期待使用的产品。
4）退役的。一年内，组织已经停止使用或打算停止使用的产品。
5）优先的。被多数应用优先使用的产品。
6）限制的。在一定应用中限制使用的产品。
7）新兴的。为将来可能的部署研究和试行的产品。
9）审核的。已经评估的产品，评估结果目前不能用于以上状态的产品。

4.4.2 图标使用规范

33.图标使用规范如下：
运用模型和图标呈现信息是指以已定义好的且达成共识的一套图标来表达待说明内容的一种方式。该方式是通过使用图标来实现视觉转换，以达到提高可读性和便于理解的目的。对图标的使用必须保持一致，如果使用不当，会给读者造成误解或者曲解，那么就可能会适得其反。对图标的使用需要遵从干扰最小化、有用信息最大化的原则。具体使用规范如下所示：
1）清晰一致的说明。应该清晰标识并说明所有对象和线条及图标所代表的内容。
在所有图表中，应该在统一的位置描述说明。
2）所有图表对象与说明相匹配。在使用的说明模板中，并不是所有的说明对象都会在图标中出现，但是所有的图标对象都应该有与之相匹配的说明。
3）清晰一致的线条方向。所有线条的流向都应该从某一侧或角（通常为左侧）开始，尽可能流向对侧或对角。有可能会出现循环或者环，但仍然要确保回流和循环的线条方向清楚可见。
4）一致的交叉线显示方法。要清楚交叉点并非连接点，在无法避免交叉的情况下允许线交叉；对同一个方向上的所有线使用跨线；不要将线与线直接连接；尽可能减少线交叉现象出现的次数。
5）一致的对象属性。对任何大小、颜色、线条粗细等不同的图标均要求表示不同的内容，否则会因此增加读者的理解难度，容易造成混淆。
6）线性对称。行和列排放整齐的图标比随机摆放的图标易读性更好，更容易理解。虽然几乎不可能使所有对象都能够保持一致，且能够实现行和列排放整齐，但至少在某一个方向上（水平或垂直）排列整齐，这也将在很大程度上提高图标的可读性。

4.5 实施指南

34. 数据架构包括构件、活动和行为。

35. 实施企业数据架构主要包含的工作内容为：
    1）建立企业数据架构团队和举办问题讨论会。
    2）生成数据架构构件的初始版本。例如，企业数据模型、企业范围数据流和路线图。
    3）在开发项目中，形成和建立数据架构工作方式。
    4）提高组织对数据架构工作价值的认识。

36.数据架构实施应该至少包括其中两项工作内容，因为这样可以实现互补，以获得相对较好的效果。所选择的两项工作内容最好可以串行进行，如因各种原因选择两项工作内容存在困难，则至少通过并行方式确保其实施活动。实施可以从部分组织中开始，或从某些数据域中开始，如产品数据或消费者数据。认知和工作方式成熟以后，可以逐步扩大实施范围。

37.在开发模型中获取数据模型和其他数据架构构件，然后被数据架构师标准化和管理。因此，数据架构工作在第一个项目中的投入相对比较大，但在此过程中形成的构件可以被后继项目重复使用，因而后继项目投入就会减少。这些早期的项目应该用特殊的架构资金来实施。

38.企业数据架构师要与其他业务和技术架构师合作，架构师的共同目标是提高组织的有效性和灵活性。整体企业架构的业务驱动策略也会明显影响企业数据架构实施决策。

39.在以解决问题为导向的文化中，当使用新兴技术创新时，建议企业数据架构考虑敏捷的实施方法。这就要求包括一个主题的全层级模型在敏捷实施的冲刺过程中被详细设计。因此，企业数据架构是一个逐步演变的过程。然而，对这种灵活的方法需要数据架构师尽早参与到开发活动中，因为在技术创新的文化中，它们演变得特别快。
对企业设计架构的质量驱动需求要求在规划项目时，强制将数据架构工作内容纳入企业的所有项目的开发计划中。通常，从非常需要改进的主数据域开始建立企业数据架构，一旦被接受，就扩展到包括面向业务事件的数据（即事务性数据）中。这是传统的实现方法，企业数据架构师生成蓝图和模板，以便在整个系统环境中使用，并使用各种治理方法确保落地和遵守。

4.5.1 就绪评估和风险评估

40.架构类项目可能相比其他项目，特别是在组织中第一次尝试时，容易暴露出更多的风险。最明显的风险有：
1）缺少管理层支持。在计划的项目执行过程中，任何企业组织都可能影响架构流程。例如，新作决定的人可能对流程产生疑问，试图撤出参与数据架构工作的相关人员。管理层的支持是数据架构流程在组织重组过程中被应用的关键所在。因此，确保在数据架构开发过程中多寻求一些能够理解数据架构并愿意支持的高层管理人员，这是数据架构成败的关键。
2）成功与否缺乏证据。高层支持对于这项工作的成功至关重要，因为他或她的信任对成功执行数据架构功能是非常重要的。执行最重要的步骤时，须寻求资深架构师的帮助。
3）缺乏管理者的信任。如果高层要求所有沟通都需要经过他们允许，这可能暗示这些人不确定他们的角色，可能只对除了数据架构流程目标之外的东西感兴趣或不信任数据架构师的能力。不管哪种原因，高层必须允许项目经理和数据架构师在项目中发挥主导作用。争取获得高层信任，并在工作中保持独立。
4）管理层不正确的决策。可能有一种情况，尽管管理层能够理解数据架构的价值，但是却不知道如何去实现它。因此，他们可能会作出与架构师工作相反的决定。这不是说管理不当，而是提示数据架构师需要经常清晰地与管理层进行沟通。
5）文化冲击。考虑数据架构工作文化将如何在那些将受数据架构体系影响的人中发生变化。试着想象一下，对于员工来说，改变他们在组织中的行为是多么的容易或困难。
6）缺乏有经验的项目经理。确保项目经理具有企业数据架构经验，特别是项目具有非常重要的数据组件时。如果不是这样，鼓励高层更换或培养项目经理（Edvinsson，2013）。
7）单一维度视角。有时业务应用的所有者可能会决定他们对整个企业级数据架构（如ERP系统的所有者）的看法，而牺牲一个更平衡、更包容的观点。

4.5.2 组织和文化

组织架构实施的速度依赖于适应文化的程度。设计工作中要求架构师与组织中开发者和其他有创意的思想者进行合作。这些人往往习惯按照自己的工作方式工作。他们有可能欣然接受，也有可能抵制为适应规范的数据架构原则和工具而需要做的改变。
以产出为导向，战略一致的组织能更好地适应架构实施。这些组织通常以目标为导向，能意识到客户和合作方的挑战，而且能根据共同目标确定优先级。
41.一个组织接受并实施数据架构的能力依赖于以下几个方面：
1）对架构方法的接受度（开发架构的友好性）。
2）确认数据属于组织的业务资产，而不仅仅是IT的任务。
3）放弃局部数据视角，接受企业级数据视角的能力。
4）将架构交付成果整合到项目实施中的能力。
5）规范数据治理的接受程度。
6）立足企业全局，而不是仅仅局限于项目交付成果和IT解决问题的能力（Edvinsson，2013）。

4.6 数据架构治理

数据架构活动能直接支持数据模型不同层级的映射管理及控制数据。数据架构师通常充当数据治理活动的业务联络人。因此，企业数据架构和数据治理组织必须保持一致。在理想情况下，数据架构师和数据管理员对每个主题域，甚至每个主题域的实体都保持一致。而且，数据监督应该与流程监督保持一致。业务事件主题域应该与流程监督保持一致，因为每个事件实体通常与业务流程相对应。

4.6.1 数据架构治理活动

42.数据架构治理活动包括：
1）项目监督。这包括确保项目符合所需的数据架构活动、使用和提高架构资产，且必须根据架构标准实施。
2）管理架构设计、生命周期和工具。必须对架构设计进行定义、评估和维护。数据架构是企业长期整合规划的“分区规划”之一。数据架构的未来状态不仅影响项目目标，而且也影响项目在项目群中的优先级。
3）定义标准。制定数据在组织内如何使用的规则、指南和规范。
4）创建数据相关构件。支持治理规范的构件。

4.6.2 度量指标

43.数据架构的度量指标：
企业数据架构衡量指标反映了架构目标：架构接受度、实施趋势、业务价值。数据架构衡量工作通常作为项目总体业务客户满意度的一部分，每年开展一次。
（1）架构标准接受率
可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度。追踪项目预期的衡量指标也有助于理解和采纳执行过程中出现的问题。
（2）实施趋势
对跟踪企业架构改善组织实施项目能力的程度，至少沿两个方向进行改善：
1）使用/重用/代替/废弃测量。决定使用新架构构件与重用、代替或废弃构件的比例。
2）项目执行效率测量。测量项目的交付时间和可重用构件及指导构件的交付改进成本。
（3）业务价值度量指标
追踪向期待的业务效果和利益方向的发展过程：
1）业务敏捷性改进。解释生命周期改进或改变的好处，改进延误成本的测量方法。
2）业务质量。测量业务案例是否按期完成；基于新创建或集成的数据导致业务发生的改变，测量项目是否实际交付了这些变更。
3）业务操作质量。测量改进效率的方法。实例包括准确性改进、时间减少，由于数据错误而导致的纠错费。
4）业务环境改进。实例包括由于数据错误减少而改变的客户保留率和在递交报告中当局评论的减少率。