思维导图

        架构是构建一个系统（如可居住型建筑）的艺术和科学，以及在此过程中形成的成果——系统本身。用通俗的话说，架构是对组件要素有组织的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。
将架构定义为“系统的基本结构，具体体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则”。然而，从全局来理解，“架构”一词可以指对系统当前状态的描述、一组系统的组件、系统设计的准则(架构实践)、 一个系统或一组系统的意向性设计(未来状态或计划的架构)、描述系统的构件(架构文档)或执行设计工作的团队(架构师或架构团队) 等。
企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。
其中数据架构的主要目标是有效地管理数据，以及有效地管理存储和使用数据的系统。 

数据架构是数据管理的基础。

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

4.1 引言

数据架构的基本组成部分

1）数据架构成果，包括不同层级的模型、定义、数据流，这些通 常被称为数据架构的构件。

2）数据架构活动，用于形成、部署和实现数据架构的目标。

3）数据架构行为，包括影响企业数据架构的不同角色之间的协 作、思维方式和技能。

数据架构的构件

1. 当前状态的描述
2. 数据需求的定义
3. 数据整合的指引
4. 数据管控策略中要求的数据资产管理规范。

4.1.1 业务驱动因素

数据架构的目标是在业务战略和技术实现之间建立起一座通畅的桥梁，数据架构是企业架构中的一部分，其主要职责为：

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

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

4.1.2 数据架构成果和实施

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

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

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

总体数据架构实施包括：

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

交付成果：

• 数据架构设计
• 数据流
• 数据价值链
• 企业数据模型
• 实施路线图

4.1.3 基本概念

1、企业架构类型

类型	企业业务架构	企业数据架构	企业应用架构	企业技术架构
目的	识别企业如何为消费者和其他利益相关方创造价值	描述数据应该如何组织和管理	描述企业应用的结构和功能	描述能使系统发挥功能和传递价值的实体技术
元素	业务模型、流程、功能、服务、事件、策略、词汇	数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口	业务系统、软件包、数据库	技术平台、网络、安全、整合工具
依赖项	制定其他架构的需求	管理业务架构创建和需要的数据	依据业务需求来处理指定的数据	承载并执行应用架构
角色	业务架构师和分析师、业务数据管理员	数据架构师、建筑师、数据管理员	应用架构师	基础设施架构师

2、企业架构框架

3、企业数据架构

企业数据模型：

        企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。通常用于表示高层级简化的数据模型，也表示了不同抽象层级。企业数据模型包括数据实体（如业务概念）、数据实体间关系、关键业务规则和 一些关键属性，它为所有数据和数据相关的项目奠定了基础。任何项目级的数据模型必须基于企业数据模型设计。企业数据模型应该由利益相关方审核，以便它能一致有效地代表企业。

        自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成。

数据流设计

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

        

数据血缘分析有 助于解释数据流中某一点上的数据状态。 数据流映射记录了数据与以下内容的联系：

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

数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系。

4.2 活动

简化数据和企业架构所面临的复杂问题，基于以下两种方式解决：
1)面向质量。专注于业务和IT开发周期内对数据架构进行不断改进。如果架构没有得到妥善管理，也会慢慢遭到破坏，系统逐渐变得越来越复杂和缺乏扩展性，因而给组织带来风险。对数据整合、数据复制以及“意大利面”式接又关系无法控制，这会使组织效率越来越低，并降低数据的真实性。 

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

4.2.1 建立企业数据架构

建立企业数据架构通常包括以下工作，这些工作可以串行或并行执行。

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

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

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

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

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

2、开发路线图

        考虑到实际 情况和技术评估，路线图和业务需求共同将目标架构变为现实。企业数据架构路线图必须与企业架构路线图相整合，企业架构路线图包括:高层次里程碑事件、所需资源、成本评估、业务能力工作流划分。路线图应以数据管理成熟度评估为指导 

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

数据架构师应该决定：

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

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

1. 定义范围。
2. 理解业务需求。
3. 设计。
4. 实施。（瀑布方式、迭代方式、敏捷方式）

4.2.2 整合其他企业架构

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

4.3 工具

4.3.1 数据建模工具

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

4.3.2 资产管理软件

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

4.3.3 图形设计应用

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

4.4 方法

4.4.1 生命周期预测

        架构设计可以是针对当前的，也可以是面向未来的，还可以是已实施并完成的，甚至是准备退役的产品。无论哪种情况，其工作成果都应该存档管理。

1. 当前的。当前支持和使用的产品。
2. 部署周期的。未来1～2年内部署使用的产品。
3. 策略周期的。未来两年后期待使用的产品。
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. 立足企业全局，而不是仅仅局限于项目交付成果和IT解决问题的能力（Edvinsson，2013）。

4.6 数据架构治理

4.6.1 数据架构治理活动

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

4.6.2 度量指标

企业数据架构衡量指标反映了架构目标：架构接受度、实施趋势、 业务价值。数据架构衡量工作通常作为项目总体业务客户满意度的一部 分，每年开展一次。

（1）架构标准接受率

        可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度。追踪项目预期的衡量指标也有助于理解和采纳执行过程中出现的问题。

（2）实施趋势

        对跟踪企业架构改善组织实施项目能力的程度，至少沿两个方向进 行改善：

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

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

（3）业务价值度量指标

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

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

2）业务质量。测量业务案例是否按期完成；基于新创建或集成的 数据导致业务发生的改变，测量项目是否实际交付了这些变更。

3）业务操作质量。测量改进效率的方法。实例包括准确性改进、 时间减少，由于数据错误而导致的纠错费。

4）业务环境改进。实例包括由于数据错误减少而改变的客户保留 率和在递交报告中当局评论的减少率。