目录

4.1引言

4.1.1业务驱动因素

4.1.2数据架构成果和实施

4.1.3基本概念

4.2活动

4.2.1建立企业数据架构

4.2.2整合其他企业架构

4.3工具

4.3.1数据建模工具

4.3.2资产管理软件

4.3.3图形设计应用

4.4方法

4.4.1生命周期预测

4.4.2图标使用规范

4.5实施指南

4.5.1就绪评估和风险评估

4.5.2组织和文化

4.6数据架构治理

4.6.1数据架构治理活动

4.6.2度量指标

声明：未经许可，严禁抄袭。

---

4.1引言

架构是构建一个系统（如可居住性建筑）的艺术和科学，以及在此过程中形成的成果-系统本身。

通俗讲，架构是对组件要素有组织的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。

国际标准中，将架构定义为“系统的基本机构，体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则。”

架构设计工作在信息系统的不同层级（企业架构包括：基础架构、应用架构、业务架构、数据架构等）来开展。

架构师就是通过自身专业技能，将难以理解或迷惑的内容定义和设计清晰，以便浅显易懂，这是架构师的价值之所在。

数据架构主要目标①是有效地管理数据，以及有效地管理存储和使用数据的系统。

本章主要从以下3个方面考虑数据架构(基本组成部分)：

1. 数据架构成果——不同层级的模型、定义、数据流，这些被称为架构的构件；
2. 数据架构活动——用于形成、部署和实现数据架构的目标;
3. 数据架构行为——包括影响企业架构不同角色的协作、思维方式和技能；

为什么需要数据架构：数据架构是数据管理的基础。大多数组织的数据超出了个人可理解的范围，因此有必要爱不同抽象层级上描述组织的数据，以便更好地了解数据，帮助管理层做出决策。

数据架构的作用：良好的企业架构管理有助于组织了解系统的当前状态，加速向期待状态的转变。实现遵守规范，提高效率的目标。

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

组织中的数据架构是指不同抽象层级主要设计文档的集合，主要包括数据的收集、存储、规划、使用和删除等标准。

详细的数据架构设计文件是正式的企业数据模型，它包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。物理数据模型也属于数据架构文件，但物理数据模型是数据建模和设计的产物，而不是数据架构的产物。

数据架构能完全支持整个企业的需求，它才是最有价值的。

架构师设计的数据架构构件是非常有价值的元数据的重要组成部分。数据架构构件应该在企业级元知识库中被集中存储和管理。

4.1.1业务驱动因素

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

数据架构在企业架构中主要职责是：

1. 利用新兴技术带来的优势，从战略上帮助组织快速改变产品、服务和数据
2. 将业务需求转换为数据和应用需求，为业务流程处理提供有效数据
3. 管理复杂数据和信息，并传递至整个企业
4. 确保业务和IT技术保持一致
5. 为企业改革、转型和提高适应性提供支撑

以上业务驱动职责是评判数据架构任务完成情况或价值的重要指标，这些指标直接影响数据架构工作的好坏评估。

4.1.2数据架构成果和实施

主要成果包括（P71——图4-1）：

1. 数据存储和处理需求
2. 涉及满足企业当前和长期数据需求的结构和规划
3. 战略性地为组织做好准备，快速发展其产品、服务和数据，以利用新兴技术中固有的商机

架构师寻求一种能为组织带来价值的方式对组织的数据架构进行设计。这种价值主要通过合适的技术应用、有效运营、项目效率提升以及数据应用能力加强来体现。

为了实现该目标，组织要求具有良好的设计和计划以及确保设计和计划能够被执行的能力。

为了达到该目的，架构师需要定义和维护的具体事宜如下:

1. 定义组织中的数据当前状态
2. 提供数据和组件的标准业务词汇
3. 确保数据架构和企业战略以及业务架构保持一致
4. 描述组织数据战略需求
5. 高阶数据整合概要设计
6. 整合业务数据架构蓝图

总体实施包括：

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

4.1.3基本概念

1.企业架构类型（P72——表4-1）

企业业务架构：

        目的：识别企业如何为消费者和其他利益相关方创造价值

        元素：业务模型、流程、功能、服务、事件、策略、词汇

        依赖项：制定其他架构的需求

        角色：业务架构师和分析师、业务数据管理员

企业数据架构：

        目的：描述数据应该如何组织和管理

        元素：数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口

        依赖项：管理业务架构创建和需要的数据

        角色：数据架构师、建模师、数据管理员

企业应用架构：

        目的：描述企业应用的结构和功能

        元素：业务系统、软件包、数据库

        依赖项：依赖业务需求来处理指定的数据

        角色：应用架构师

企业技术架构：

        目的：描述能使系统发挥功能和传递价值的实体技术

        元素：技术平台、网络、安全、整合工具

        依赖项：承载并执行应用架构

        角色：基础设施架构师

2.企业架构框架（P73——图4-2）

主要讲述了Zahman的6*6矩阵模型，可以完整的描述一个企业以及相互之间的关系。

矩阵框架的两个维度是：问询沟通和重新定义转换

列中显示的是问询沟通（可以寻问任何实体的基本问题，将其转换成企业架构对应每个列的理解）：

1. 是什么——目录列，表示构建架构的实体
2. 怎么做——流程列，表示执行的活动
3. 在哪里——分布列，表示业务位置和技术位置
4. 是谁——职责列，表示角色和组织
5. 什么时间——时间列，表示角色和组织
6. 为什么——动机列，表示目标、策略和手段

每个对应列下行中的值显示其重新定义转换（是将抽象概念转变为具体的实例的必经步骤，如识别、定义、描述、规范、配置和实例[注：每一列中都对应自己的这些步骤，识别→实例]）。

矩阵中的每一行代表不同的角色，包括规划者、所有者、设计师、建造者、实施者和用户。

每个角色对不同问题解决持有不同的视角。例如每个视角与“什么”列交叉。

具体如下：

1. 高管视角（业务背景）——定义不同模型范围的业务元素目录
2. 业务管理视角（业务概念）——不同业务模型涉及的不同的业务概念间的关系
3. 架构师视角（业务逻辑）——作为模型设计的架构师细化系统需求，设计系统逻辑模型
4. 工程师视角（业务实体）——具体的模型建造者，优化和实施具体应用设计的物理模型
5. 技术人员视角（组件程序集）——采用特定技术、脱离上下文语境的视角，并解释配置模型的技术人员如何使用、组装和实施配件组件
6. 用户视角（操作类）——参与人员所使用的实际功能实例

3.企业数据架构

数据架构定义了对组织非常难重要元素的标准术语和设计。设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。

当数据在组织中通过源或接口流动时，需要安全、集成、存储、记录、分类、共享的报表和分析，最终交付给利益相关方使用。在这个过程中数据可能被验证、增强、链接、认证、整合、脱敏处理及用于分析，直到数据被归档或清除。

因此企业数据架构必须包括企业数据模型和数据流设计。

1.企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。

企业数据模型包括数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性，它为所有数据和数据相关项目奠定了基础。

2.数据流设计，定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的移动。

（1）企业数据模型

企业数据模型包括通用的（企业范围的概念和逻辑模型）和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则。

P75——图4-3显示了不同模型是如何关联的，以及概念模型如何最终与物理应用数据模型关联，其明显特征为：

1. 企业主题域的概念概述
2. 各主题域的实体和关系概述
3. 归属与同一主题域的详细逻辑概述
4. 具体到应用或项目的逻辑和物理模型

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

纵向：不同层级模型间的映射

横向：同一个实体和关系可能出现在同一层级的多个模型中（用于关联关系的，主外键）

企业数据模型是由主题域模型相结合构建的。构建方法为自上而下，或自下而上：

自上而下是从主题域开始的：概念模型→主题域模型→逻辑模型→逻辑数据模型——物理数据模型

自下而上是现有逻辑数据模型向上提炼抽象而成。

通常推荐2种方法相结合共同完成企业数据模型的设计工作。

主题域识别的准则必须在整个企业模型中保持一致。通常常用准则包括：

使用规范化，从系统组合中分离主题域，基于顶级流程（业务价值链）或基于业务能力（企业架构）从数据治理结构和数据所有权（或组织）中形成主题领域。

(2)数据流设计

数据流是一种记录数据血缘的数据加工过程。

数据流映射记录了数据与以下内容的联系：

1. 业务流程的应用
2. 某个环境中的数据存储或数据库
3. 网段
4. 业务角色（描述哪些角色有职责创建、更新和删除数据）
5. 出现局部差异的位置

数据流用于描述主题域、业务实体，乃至属性层面的映射关系。

数据流呈现方式有：
1.二维矩阵（P78-图4-5）（横向是业务流程和纵向是主要实体）——通过矩阵图形能清晰地展现创建和使用数据的过程。

采用矩阵的优势是可以清楚看出数据不是只在一个方向上流动的。通过矩阵可以明确流程中的数据获取职责及数据依赖关系，反过来可以促进流程的制定。

2.数据流图

4.2活动

简化数据和企业架构所面临的复杂问题，解决方式：

1.面向质量。专注与业务和IT开发周期内对数据架构进行不断改进。如果架构没有得到妥善管理，也会慢慢遭到损坏，逐渐变得越复杂和缺乏扩展性，从而给组织带来风险。对数据整合、数据复制以及“意大利面式”接口关系无法控制，使组织效率越来越低，降低数据真实性。

2.面向创新。专注与业务和IT转换，致力于新的期待和机会。用创新性技术和数据使用驱动创新，成为现代企业架构的一种功能。

运用这2种方法有不同的方法论;

面向质量的方法与传统的数据架构工作保持一致，其中架构质量改进是逐步完成的。架构师需要掌握整体架构、将治理、标准化、架构发展作为长期目标进行持续投入。

面向创新的方法通常不用面面俱到，可以应用未经广泛验证的业务逻辑和前沿技术。需要架构师与产品经理和业务设计者进行联系。

4.2.1建立企业数据架构

数据架构应该是企业架构的组成部分。如果没有企业架构，也可以构建数据架构团队，组织应该设计有助于明确目标和驱动数据架构的框架。该框架对数据架构实施路线图中的方法、范围和工作优先级产生影响。

建立企业数据架构通常架构师包括以下工作（可串行或并行执行）：

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

企业数据架构也会影响项目和系统开发的范围边界，如：

1. 定义项目数据需求——通过数据架构为企业提供每个项目数据需求
2. 评审项目数据设计——通过评审来确保概念、逻辑和物理数据模型与架构一致，与企业长期战略一致
3. 确定数据溯源影响——确保数据流在应用中的业务规则一致且可溯源
4. 数据复制控制——复制，能够改善应用和便于获取数据的方法。数据架构治理能保证充分的复制控制（方法和机制）来达到所需的一致性
5. 实施数据架构标准——为企业数据架构生命周期制定和实施标准。标准可以表示为原则、流程、指南和规划蓝图
6. 指导数据技术和更新决策——数据架构与企业架构管理每个应用的数据技术版本、补丁和技术路线策略

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

为了解现有架构，需要识别现有系统的一系列文件，并评估其准确性、完整性和详细程度。如需必要，还需要更新这些文件使其真实反应系统当前状态。

2.开发路线图

如果一个企业是从零开始开发的，那么一个最佳的体系结构将仅仅基于运行该企业所需的数据，优先级将有业务战略确定，决策可以不受过去的阻碍。

企业架构路线图提供了一种管理这些依赖性（数据依赖关系）并做出前瞻性决策的方法。路线图包括（高层次里程碑事件、所需资源、成本评估、业务能力工作流划分）

企业数据架构路线图描述了架构3-5年的发展路径，路线图和业务需求共同将目标架构变为现实。业务数据驱动路线图（P81——图4-7）可以从最独立的业务能力开始，再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力，遵循整体业务数据生成顺序。

在理想中，建议从图中产品管理和客户管理能力开始路线图，然后从上到下解决每一步依赖关系。

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

架构不应该受开发时间的限制。利用数据模型及其有关规范描述的组织数据架构必须足够灵活，并能适应未来需求。构建架构层级的数据模型不仅应有企业全局观，而且要有足够让企业内部完全清楚理解的定义。

对获取、存储、分发数据的开发项目实施解决方案，需要以业务需求和企业数据架构的标准为基础。

在项目级别上，通过数据模型定义需求的过程是从审查业务需求开始的。通常这些需求是特定于项目目标的，不会对企业产生影响。

重要的是，数据架构师必须能够理解需求与其他整体架构的关系，当项目范围完成时，架构师应该决定：

1. 规范中所描述实体是否符合标准
2. 在需求中，哪些实体应该被包括在整体企业数据架构中
3. 规范中的实体和定义是否需要扩大或加深以满足将来的趋势
4. 是否更新数据架构或是否向开发指出了哪些可以重用

企业数据架构项目项相关活动包括：

1. 定义范围。保证范围和接口与企业数据模型一致。理解项目对整体企业数据架构的潜在贡献、项目的建模和设计、哪些现有组件应该或能被重用。
2. 理解业务需求。获取数据相关需求，如实体、资源、可用性、质量和痛点，自己评估满足这些需求的业务价值
3. 设计。形成详细的目标规范。包括：数据生命周期内的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等
4. 实施分为

        ①什么时候购买考虑购买支持逆向工程的软件、逆向数据库中的数据模型（如果可以，让供应商提供其数据模型）

        ②什么时候重用数据。建立应用数据模型与通用数据结构、现有流程和新流程之间的对比映射关系，来理解CRUD操作。

        ③什么时候构建。根据数据结构进行数据存储；根据标准或设计并评审通过的规范进行集成

项目在企业数据架构角色依赖软件开发过程，采用的方式有3种：

1. 瀑布式——作为整个企业设计的一部分，在连续阶段中理解需求和构建系统。但需确保能够从企业视角设计架构和考虑问题，以避免局限性
2. 迭代方式——适合总体需求模糊的原型。这种方式在启动阶段至关重要，最好早期迭代中创建一个全面的数据设计
3. 敏捷方式——敏捷模型能够提供高目标导向的模型，强调用户界面设计、软件设计和系统行为

4.2.2整合其他企业架构

事实上，数据架构可能会影响项目的范围，因此，最好把企业数据架构问题和项目组合管理进行整合 。

企业数据架构师的工作应被包含在企业应用开发和整合计划中，同时将数据架构视图应用于目标应用场景以及该场景的路线图中。

4.3工具

4.3.1数据建模工具

在管理所有层级数据模型的过程中，数据模型工具和模型库都是非常必需的。

4.3.2资产管理软件

资产管理软件用于管理数据资产目录，描述其内容以及跟踪它们之间的关系。

由于通过数据资产管理软件盘点了IT资产，所以包含了关于系统及相关数据的元数据。在创建数据流或研究当前状态时，这些元数据非常有用。

4.3.3图形设计应用

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

4.4方法

4.4.1生命周期预测

架构设计可以是针对当前的、面向未来的、实施完成的及将要退役的产品。

无论哪种情况，其工作成果都应该存档管理。

1. 当前的——当前支持和使用的产品
2. 部署周期的——未来1-2年部署使用的产品
3. 策略周期的——未来2年后使用的产品
4. 退役的——一年内，已经停用或打算停止的产品
5. 优先的——被多数应用优先使用的产品
6. 限制的——在一定应用中限制使用的产品
7. 新兴的——将来可能部署研究和试行的产品
8. 审核的——以评估的产品，评估结果不能用于以上的产品

4.4.2图标使用规范

使用图标来实现视觉转换，以达到提高可读性和便于理解的目的。

具体使用规范如下：

1. 清晰一致的说明
2. 所有图表对象与说明相匹配
3. 清晰一致的线条方向
4. 一致的交叉线显示方法，交叉并非连接点
5. 一致的对象属性，如大小、粗细、颜色等
6. 线性对称

4.5实施指南

实施企业数据架构主要包含内容：

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

实施可以从部分组织中开始，或从某些数据域中开始，如产品数据或消费者数据。认知和工作方式成熟后，可以逐步扩大实施范围。

通常，从非常需要改进的主数据域开始建立企业数据架构，一旦被接受，发展到包括面向业务事件的数据中。

4.5.1就绪评估和风险评估

最明显的风险有：

1. 缺少管理层支持
2. 成功与否缺乏证据
3. 缺乏管理者的信任
4. 管理层不正确的决策
5. 文化冲击
6. 缺乏有经验的项目经理
7. 单一维度视角

4.5.2组织和文化

组织架构实施的速度依赖于适应文化的程度。

以产出为导向，战略一致的组织能更好地适应架构实施。

一个组织接受并实施数据架构的能力依赖于以下几个方面：

1. 对架构方法的接受度（开发架构的友好性）
2. 确认数据属于组织的业务资产，而不仅仅是IT的任务
3. 放弃局部数据视角，接受企业级数据视角的能力
4. 将架构交付成果整合到项目实施中的能力
5. 规范数据治理的接受程度
6. 立足企业全局

4.6数据架构治理

数据架构活动能直接支持数据模型不同层级的映射管理及控制数据。

理想情况下，数据架构师和数据管理员对每个主题域，甚至每个主题域的实体都保持一致。而且，数据监督应该与流程监督保持一致。业务事件主题域应该与流程监督保持一致。每个实体通常与业务流程相对应。

4.6.1数据架构治理活动

1.项目监督，确保符合项目所需的数据架构活动、使用和提高架构资产

2.管理架构设计、生命周期和工具。必须对架构设计进行定义、评估和维护

3.定义标准，制定数据在组织内如何使用的规则、指南和规范

4.创建数据相关构件，支持治理规范的构件

4.6.2度量指标

数据架构的衡量指标反映了架构目标：架构接受度、实施趋势、业务价值

1.架构标准接受率

        可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度，

2.实施趋势，对跟踪架构改善组织实施项目能力的程度，分为：

        1.使用/重用/代替/废弃测量。决定使用新架构构件与重用、代替或废弃构件的比例。

        2.项目执行效率测量。测量交付时间和可重用构件及指导构件的交付改进成本。

3.业务价值度量指标

追踪向期待的业务效果和利益方向的发展过程：

        1.业务敏捷性改进，解释生命周期改进或改变的好处，改进延误成本的测量方法

        2.业务质量，测量业务案例是否按期完成

        3.业务操作质量，测量改进效率的方法

        4.业务环境改进，由数据错误减少而改变客户的保留率和在递交中当局评论的减少率

声明：未经许可，严禁抄袭。