目录
4.1引言
架构是构建一个系统（如可居住性建筑）的艺术和科学，以及在此过程中形成的成果-系统本身。
通俗讲，架构是对组件要素有组织的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。
国际标准中，将架构定义为“系统的基本机构，体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则。”
架构设计工作在信息系统的不同层级（企业架构包括：基础架构、应用架构、业务架构、数据架构等）来开展。
架构师就是通过自身专业技能，将难以理解或迷惑的内容定义和设计清晰，以便浅显易懂，这是架构师的价值之所在。
数据架构主要目标①是有效地管理数据，以及有效地管理存储和使用数据的系统。
本章主要从以下3个方面考虑数据架构(基本组成部分)：
为什么需要数据架构：数据架构是数据管理的基础。大多数组织的数据超出了个人可理解的范围，因此有必要爱不同抽象层级上描述组织的数据，以便更好地了解数据，帮助管理层做出决策。
数据架构的作用：良好的企业架构管理有助于组织了解系统的当前状态，加速向期待状态的转变。实现遵守规范，提高效率的目标。
数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控策略中要求的数据资产管理范围。
组织中的数据架构是指不同抽象层级主要设计文档的集合，主要包括数据的收集、存储、规划、使用和删除等标准。
详细的数据架构设计文件是正式的企业数据模型，它包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。物理数据模型也属于数据架构文件，但物理数据模型是数据建模和设计的产物，而不是数据架构的产物。
数据架构能完全支持整个企业的需求，它才是最有价值的。
架构师设计的数据架构构件是非常有价值的元数据的重要组成部分。数据架构构件应该在企业级元知识库中被集中存储和管理。
4.1.1业务驱动因素
数据架构主要目标②是在业务战略和技术实现之间建立起一座通畅的桥梁。
数据架构在企业架构中主要职责是：
4.1.2数据架构成果和实施
主要成果包括（P71——图4-1）：
架构师寻求一种能为组织带来价值的方式对组织的数据架构进行设计。这种价值主要通过合适的技术应用、有效运营、项目效率提升以及数据应用能力加强来体现。
为了实现该目标，组织要求具有良好的设计和计划以及确保设计和计划能够被执行的能力。
为了达到该目的，架构师需要定义和维护的具体事宜如下:
总体实施包括：
4.1.3基本概念
1.企业架构类型（P72——表4-1）
企业业务架构：
目的：识别企业如何为消费者和其他利益相关方创造价值
元素：业务模型、流程、功能、服务、事件、策略、词汇
依赖项：制定其他架构的需求
角色：业务架构师和分析师、业务数据管理员
企业数据架构：
目的：描述数据应该如何组织和管理
元素：数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口
依赖项：管理业务架构创建和需要的数据
角色：数据架构师、建模师、数据管理员
企业应用架构：
目的：描述企业应用的结构和功能
元素：业务系统、软件包、数据库
依赖项：依赖业务需求来处理指定的数据
角色：应用架构师
企业技术架构：
目的：描述能使系统发挥功能和传递价值的实体技术
元素：技术平台、网络、安全、整合工具
依赖项：承载并执行应用架构
角色：基础设施架构师
2.企业架构框架（P73——图4-2）
主要讲述了Zahman的6*6矩阵模型，可以完整的描述一个企业以及相互之间的关系。
矩阵框架的两个维度是：问询沟通和重新定义转换
列中显示的是问询沟通（可以寻问任何实体的基本问题，将其转换成企业架构对应每个列的理解）：
每个对应列下行中的值显示其重新定义转换（是将抽象概念转变为具体的实例的必经步骤，如识别、定义、描述、规范、配置和实例[注：每一列中都对应自己的这些步骤，识别→实例]）。
矩阵中的每一行代表不同的角色，包括规划者、所有者、设计师、建造者、实施者和用户。
每个角色对不同问题解决持有不同的视角。例如每个视角与“什么”列交叉。
具体如下：
3.企业数据架构
数据架构定义了对组织非常难重要元素的标准术语和设计。设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。
当数据在组织中通过源或接口流动时，需要安全、集成、存储、记录、分类、共享的报表和分析，最终交付给利益相关方使用。在这个过程中数据可能被验证、增强、链接、认证、整合、脱敏处理及用于分析，直到数据被归档或清除。
因此企业数据架构必须包括企业数据模型和数据流设计。
1.企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。
企业数据模型包括数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性，它为所有数据和数据相关项目奠定了基础。
2.数据流设计，定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的移动。
（1）企业数据模型
企业数据模型包括通用的（企业范围的概念和逻辑模型）和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则。
P75——图4-3显示了不同模型是如何关联的，以及概念模型如何最终与物理应用数据模型关联，其明显特征为：
各层级的模型是企业数据模型的组成部分。模型链接定义和管理了模型的纵向从上到下以及横向间的关联路径。
纵向：不同层级模型间的映射
横向：同一个实体和关系可能出现在同一层级的多个模型中（用于关联关系的，主外键）
企业数据模型是由主题域模型相结合构建的。构建方法为自上而下，或自下而上：
自上而下是从主题域开始的：概念模型→主题域模型→逻辑模型→逻辑数据模型——物理数据模型
自下而上是现有逻辑数据模型向上提炼抽象而成。
通常推荐2种方法相结合共同完成企业数据模型的设计工作。
主题域识别的准则必须在整个企业模型中保持一致。通常常用准则包括：
使用规范化，从系统组合中分离主题域，基于顶级流程（业务价值链）或基于业务能力（企业架构）从数据治理结构和数据所有权（或组织）中形成主题领域。
(2)数据流设计
数据流是一种记录数据血缘的数据加工过程。
数据流映射记录了数据与以下内容的联系：
数据流用于描述主题域、业务实体，乃至属性层面的映射关系。
数据流呈现方式有：
1.二维矩阵（P78-图4-5）（横向是业务流程和纵向是主要实体）——通过矩阵图形能清晰地展现创建和使用数据的过程。
采用矩阵的优势是可以清楚看出数据不是只在一个方向上流动的。通过矩阵可以明确流程中的数据获取职责及数据依赖关系，反过来可以促进流程的制定。
2.数据流图
4.2活动
简化数据和企业架构所面临的复杂问题，解决方式：
1.面向质量。专注与业务和IT开发周期内对数据架构进行不断改进。如果架构没有得到妥善管理，也会慢慢遭到损坏，逐渐变得越复杂和缺乏扩展性，从而给组织带来风险。对数据整合、数据复制以及“意大利面式”接口关系无法控制，使组织效率越来越低，降低数据真实性。
2.面向创新。专注与业务和IT转换，致力于新的期待和机会。用创新性技术和数据使用驱动创新，成为现代企业架构的一种功能。
运用这2种方法有不同的方法论;
面向质量的方法与传统的数据架构工作保持一致，其中架构质量改进是逐步完成的。架构师需要掌握整体架构、将治理、标准化、架构发展作为长期目标进行持续投入。
面向创新的方法通常不用面面俱到，可以应用未经广泛验证的业务逻辑和前沿技术。需要架构师与产品经理和业务设计者进行联系。
4.2.1建立企业数据架构
数据架构应该是企业架构的组成部分。如果没有企业架构，也可以构建数据架构团队，组织应该设计有助于明确目标和驱动数据架构的框架。该框架对数据架构实施路线图中的方法、范围和工作优先级产生影响。
建立企业数据架构通常架构师包括以下工作（可串行或并行执行）：
企业数据架构也会影响项目和系统开发的范围边界，如：
1.现有数据架构规范评估
为了解现有架构，需要识别现有系统的一系列文件，并评估其准确性、完整性和详细程度。如需必要，还需要更新这些文件使其真实反应系统当前状态。
2.开发路线图
如果一个企业是从零开始开发的，那么一个最佳的体系结构将仅仅基于运行该企业所需的数据，优先级将有业务战略确定，决策可以不受过去的阻碍。
企业架构路线图提供了一种管理这些依赖性（数据依赖关系）并做出前瞻性决策的方法。路线图包括（高层次里程碑事件、所需资源、成本评估、业务能力工作流划分）
企业数据架构路线图描述了架构3-5年的发展路径，路线图和业务需求共同将目标架构变为现实。业务数据驱动路线图（P81——图4-7）可以从最独立的业务能力开始，再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力，遵循整体业务数据生成顺序。
在理想中，建议从图中产品管理和客户管理能力开始路线图，然后从上到下解决每一步依赖关系。
3.在项目中管理企业需求
架构不应该受开发时间的限制。利用数据模型及其有关规范描述的组织数据架构必须足够灵活，并能适应未来需求。构建架构层级的数据模型不仅应有企业全局观，而且要有足够让企业内部完全清楚理解的定义。
对获取、存储、分发数据的开发项目实施解决方案，需要以业务需求和企业数据架构的标准为基础。
在项目级别上，通过数据模型定义需求的过程是从审查业务需求开始的。通常这些需求是特定于项目目标的，不会对企业产生影响。
重要的是，数据架构师必须能够理解需求与其他整体架构的关系，当项目范围完成时，架构师应该决定：
企业数据架构项目项相关活动包括：
项目在企业数据架构角色依赖软件开发过程，采用的方式有3种：
4.2.2整合其他企业架构
事实上，数据架构可能会影响项目的范围，因此，最好把企业数据架构问题和项目组合管理进行整合 。
企业数据架构师的工作应被包含在企业应用开发和整合计划中，同时将数据架构视图应用于目标应用场景以及该场景的路线图中。
4.3工具
4.3.1数据建模工具
在管理所有层级数据模型的过程中，数据模型工具和模型库都是非常必需的。
4.3.2资产管理软件
资产管理软件用于管理数据资产目录，描述其内容以及跟踪它们之间的关系。
由于通过数据资产管理软件盘点了IT资产，所以包含了关于系统及相关数据的元数据。在创建数据流或研究当前状态时，这些元数据非常有用。
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度量指标
数据架构的衡量指标反映了架构目标：架构接受度、实施趋势、业务价值
1.架构标准接受率
可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度，
2.实施趋势，对跟踪架构改善组织实施项目能力的程度，分为：
1.使用/重用/代替/废弃测量。决定使用新架构构件与重用、代替或废弃构件的比例。
2.项目执行效率测量。测量交付时间和可重用构件及指导构件的交付改进成本。
3.业务价值度量指标
追踪向期待的业务效果和利益方向的发展过程：
1.业务敏捷性改进，解释生命周期改进或改变的好处，改进延误成本的测量方法
2.业务质量，测量业务案例是否按期完成
3.业务操作质量，测量改进效率的方法
4.业务环境改进，由数据错误减少而改变客户的保留率和在递交中当局评论的减少率
