DAMA学习笔记(三)-数据架构

1.引言

  架构是构建一个系统（如可居住型建筑）的艺术和科学，以及在此过程中形成的成果——系统本身。用通俗的话说，架构是对组件要素有组织的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。

对于架构的理解:

• 在国际标准ISO/IEC/IEEE 42010: 2011中，将架构定义为“系统的基本结构，具体体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则”。
• 从全局来理解，“架构”一词可以指对系统当前状态的描述、一组系统的组件、系统设计的准则（架构实践）、 一个系统或一组系统的意向性设计（未来状态或计划的架构）、描述系统的构件（架构文档）或执行设计工作的团队（架构师或架构团队） 等。
• 架构设计工作通常在组织的不同范围（企业、业务条线、项目等）内，在信息系统的不同层级（基础架构、应用架构和数据架构等）来开展。
• 企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等。

本文将从以下三个方面阐述数据架构:

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

数据架构是数据管理的基础。数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控策略中要求的数据资产管理规范。 组织的数据架构是指不同抽象层级主要设计文档的集合，其中主要包括数据的收集、存储、规划、使用和删除等标准。这是按照数据的生命周期来对数据架构中包括的内容进行定义和范围界定，同时也可以按照数据在组织系统中所存储的容器和路径来进行定义和确定范围。

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

1.1 业务驱动因素

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

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

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

1.2 数据架构成果和实施

  数据架构的主要成果包括：

• 1）数据存储和处理需求。
• 2）设计满足企业当前和长期数据需求的结构和规划

数据架构语境关系图如图4-1所示。

图4-1语境关系图：数据架构

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

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

总体数据架构实施包括：

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

1.3 基本概念

1.3.1 企业架构类型

  企业架构包括业务架构、数据架构、应用架构和技术架构。该四类架构的具体描述和比较，见表4-1。不同类型的架构师除了致力于自己所属的架构设计和实施工作外，还必须了解与其紧密关联的架构需求, 了解不同架构之间的关系和影响。

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

1.3.2 企业架构框架

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

图4-2 简化的Zachman框架

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

  在问询沟通时，可以询问关于任何一个实体的基本问题，将其转换成企业架构，每个列可以按照如下理解：

• 1）什么（What）。目录列，表示构建架构的实体。
• 2）怎样（How）。流程列，表示执行的活动。
• 3）在哪里（Where）。分布列，表示业务位置和技术位置。
• 4）谁（Who）。职责列，表示角色和组织。
• 5）什么时间（When）。时间列，表示间隔、事件、周期和时间表。
• 6）为什么（Why）。动机列，表示目标、策略和手段。

  重新定义转换是将抽象的概念转变为具体的实例 (实例化) 的必经步骤。矩阵中的每一行代表不同的角色，具体的角色包括规划者、所有者、设计师、建造者、实施者和用户。每个角色对整个过程和不同问题的解决均持有不同的视角。这些不同的视角对应的内容在每行中进行显示。例如，每个视角与“什么”列（目录或数据）均有交叉，说明相互之间具有不同关联关系。具体说明如下：

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

  如前面提到，Zachman框架的每个单元格代表设计组件的独特类型，在行列的交叉中进行定义。每个组件代表每个具体视角如何回答具体问题。

1.3.3 企业数据架构

  数据架构定义了对组织非常重要元素的标准术语和设计。企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。 当数据在组织中通过源或接口流动时，需要安全、集成、存储、记 录、分类、共享的报表和分析，最终交付给利益相关方使用。在这个过程中，数据可能会被验证、增强、链接、认证、整合、脱敏处理以及用 于分析，直到数据被归档或清除。因此，企业数据架构描述必须包括企业数据模型（如数据结构和数据规范）和数据流设计。关于这两个方面的具体定义如下：

• 1）企业数据模型。
  • 企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。
  • 通常用于表示高层级简化的数据模型，也表示了不同抽象层级。
  • 企业数据模型包括数据实体 (如业务概念) 、数据实体间关系、关键业务规则和一些关键属性，它为所有数据和数据相关的项目奠定了基础。
  • 任何项目级的数据模型必须基于企业数据模型设计。
  • 企业数据模型包括通用的 (企业范围的概念和逻辑模型) 和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则。

  通过企业数据模型可以构建不同的层级，资源的可用性将影响其构建范围。随着时间的推移，企业需求会发生变化，随之带来企业数据模型中的范围和各层级中内容通常会扩张。对大多数成功的企业数据模型会利用不同层级增量和迭代的方式来构建。图 4-3显示了不同的模型是如何关联的，以及概念模型如何最终与物理应用数据模型关联。其明显特征为：

图4-3 企业数据模型

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

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

• 1）纵向。不同层级模型之间的映射。 例如，项目的物理模型中定义的“移动设备”存储的数据表/数据文件，可以和项目的逻辑模型中的移动设备实体对应，可以和企业逻辑模型中的产品主题域中的移动设备实体、产品主题域模型中的概念实体以及企业概念模型中的产品实体相关联。

• 2）横向。同一个实体和关系可能出现在同一层级的多个模型中。 同一个实体和关系可能出现在同一层级的多个模型中。 位于一个主题域中的逻辑模型中的实体可以和其他主题域中的实体相关联，在模型图中标记为其他主题域的外键。例如，一个产品的部分实体可以出现在产品主题域模型中，也可以以外部关联的形式出现在销售订单、库存和营销主题域中。 图4-4是一个包含了三个主题域的模型示意图（简单例子），每个主题域中包含一个概念数据模型和一套实体。横向实体间的关联可以超出主题域边界；每个企业数据模型中的实体应该仅属于一个主题域，但是可以和任何其他主题域相关联。
  

  图4-4 主题域模型图例

    企业概念数据模型是由主题域模型相结合构建的。每个企业数据模型既可以采用自上而下，也可以采用自下而上的方法进行构建。 自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成。通常推荐两种方法相结合，即自下而上地从分析现有模型开 始，自上而下地设计主题模型，通过两种方法的结合来共同完成企业数据模型的设计工作。

    主题域的识别准则必须在整个企业模型中保持一致。常用的主题域识别准则包括：使用规范化规则，从系统组合中分离主题域，基于顶级流程（业务价值链）或者基于业务能力（企业架构）从数据治理结构和 数据所有权（或组织）中形成主题领域。如果主题域结构是使用规范化 规则形成的，那么它对于数据架构工作通常是最有效的。规范化过程将建立承载/构成每个主题域的主要实体。

• 2）数据流设计。

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

  • 数据流是一种记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动。端到端的数据流包含了数据起源于哪里，在哪里存储和使用，在不同流程和系统内或之间如何转化。数据血缘分析有助于解释数据流中某一点上的数据状态。

  • 数据流映射记录了数据与以下内容的联系：1）业务流程中的应用。 2）某个环境中的数据存储或数据库。 3）网段（有助于安全映射）。 4）业务角色（描述哪些角色有职责创建、更新和删除数据）。5）出现局部差异的位置。数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系。

  • 数据流的呈现方式: 二维矩阵或者数据流图。
    

    图4-5 矩阵形式描述的数据流
    • 通过矩阵可以清晰地展现创建和使用数据的过程。
    • 采用矩阵方法显示数据需求的优势是可以清晰看出数据不是只在一个方向上流动。
    • 在企业模型中构建这些矩阵是一个长期的过程。

    

    图4-6 数据流示例

    传统系统级的数据流图，其中描述了系统之间的数据流类型。通过这种图可以以较为直观的方式，进一步扩展更细层级的数 据流图。

两个模型都需要反映当前状态和目标状态（架构视角）及过渡状态（项目视角）。

2.活动

  简化数据和企业架构所面临的复杂问题，基于以下两种方式解决：

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

面向质量的方法与传统的数据架构工作保持一致，其中架构质量改进是逐步完成的(架构师把控)。面向创新的方法通常不用面面俱到的考虑，可以应用未经广泛验证的业务逻辑和前沿技术(架构师与产品与业务多联系)。

2.1 建立企业数据架构

  在理想情况下，数据架构应该是企业架构的组成部分。但如果没有企业架构，则依然可以构建数据构架团队。在这种情况下，组织应该设 计有助于明确目标和驱动数据架构的框架。该框架将对数据架构实施路线图中的方法、范围和工作优先级产生影响。建立企业数据架构通常包括以下工作，这些工作可以串行或并行执行。

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

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

• 1）定义项目数据需求。
• 2）审评项目数据设计。(确保概念、逻辑和物理数据模型与架构一致,与组织长期策略一致)
• 3）确定数据溯源影响。(与业务规则一致)
• 4）数据复制控制。
• 5）实施数据架构标准。
• 6）指导数据技术和更新决策。

2.1.1 现有数据架构规范评估

  通过现有系统的一系列文档去评估数据架构的准确性、完整性和详细程度。

2.1.2 开发路线图

  路线图提供了一种管理这些依赖性并做出前瞻性决策的方法。路线图有助于组织权衡并制订夯实的项目计划，使其与业务需求和机会、外部需求、可用资源保持一致。企业数据架构路线图描述了架构3～5年的发展路径。考虑到实际情况和技术评估，路线图和业务需求共同将目标架构变为现实。企业数据架构路线图必须与企业架构路线图相整合，企业架构路线图包括：高层次里程碑事件、所需资源、成本评估、业务能力工作流划分。路线图应以数据管理成熟度评估为指导。业务数据驱动路线图可以从最独立的业务能力开始（如对其他业务能力依赖最小），再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力，需要遵循整体业务数据生成顺序。

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

  图4-7是一个业务能力数据依赖链的例子，顶部模块依赖最底部模块。产品管理和客户管理不依赖任何模块，因此属于主数据。依赖度最高的模块位于底部，客户发票管理依赖客户管理和销售订单管理，而销售订单管理也依赖另外两个管理模块。因此，在理想中，建议从产品管理和客户管理能力开始路线图，然后从上到下解决每一步依赖关系。

2.1.3 在项目中管理企业需求

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

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

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

• 1. 定义范围。保证范围和接口与企业数据模型一致。
• 2）理解业务需求。获取数据相关的需求，如实体、资源、可用性、质量和痛点，以及评估满足这些需求的业务价值。
• 3）设计。形成详细的目标规范，包括：数据生命周期内的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等。
• 4. 实施
  • ① 什么时候购买。考虑购买支持逆向工程的软件（商用产品）、逆向数据库中的数据模型，对比项目建设期提供的设计文档或模型，识别并记录数据模型、定义、规则等方面的差异和不同。
  • ② 什么时候重用数据。通过建立应用数据模型与通用数据结构、现有流程和新流程之间的对比映射关系，来理解CRUD操作。强制使用管理该结果的系统记录或其他权威数据，以便识别和存储差异。
  • ③ 什么时候构建。根据数据结构进行数据存储；根据标准或设计并评审通过的规范进行集成。

项目中的企业数据架构角色依赖软件开发过程。因采用的方法不同，将架构活动嵌入到项目中的过程也不同，具体采用的方式有以下三种：

• 1）瀑布方式。
  • 作为整个企业设计的一部分，在连续阶段中理解需求和构建系统。
  • 用于控制变化的关口。
• 2）迭代方式。
  • 逐步学习和构建（如小型瀑布模型）。
  • 适合总体需求模糊的原型。
• 3）敏捷方式。
  • 在离散的交付包中学习，构建并测试 （称为“sprints”冲刺）
  • 敏捷模型（Scrum，快速开发，统一流程）能提高目标导向的模型，强调用户界面设计、软件设计和系统行为。

2.2 整合其他企业架构

  数据架构可能会影响项目的范围。因此，最好把企业数据架构问题和项目组合管理进行整合。这样做能促进路线图的实施，有助于获得更好的项目效果。

3.工具

3.1 数据建模工具

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

3.2 资产管理软件

  资产管理软件用于管理数据资源目录，描述其内容以及跟踪它们之间的关系。另外，利用这些工具还可以确保组织遵循软件许可相关的合同义务，并收集资产相关的数据，最小化成本，优化IT流程。

3.3 图形设计应用

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

4.方法

4.1 生命周期预测

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

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

4.2 图标使用规范

  运用模型和图标呈现信息是指以已定义好的且达成共识的一套图标来表达待说明内容的一种方式。该方式是通过使用图标来实现视觉转换，以达到提高可读性和便于理解的目的。对图标的使用需要遵从干扰最小化、有用信息最大化的原则。具体使用规范如下所示:

• 1）清晰一致的说明。应该清晰标识并说明所有对象和线条及图标所代表的内容。在所有图表中，应该在统一的位置描述说明。
• 2）所有图表对象与说明相匹配。在使用的说明模板中，并不是所有的说明对象都会在图标中出现，但是所有的图标对象都应该有与之相匹配的说明。
• 3）清晰一致的线条方向。所有线条的流向都应该从某一侧或角（通常为左侧）开始，尽可能流向对侧或对角。有可能会出现循环或者环，但仍然要确保回流和循环的线条方向清楚可见。
• 4）一致的交叉线显示方法。要清楚交叉点并非连接点，在无法避免交叉的情况下允许线交叉；对同一个方向上的所有线使用跨线；不要将线与线直接连接；尽可能减少线交叉现象出现的次数。
• 5）一致的对象属性。对任何大小、颜色、线条粗细等不同的图标均要求表示不同的内容，否则会因此增加读者的理解难度，容易造成混淆。
• 6）线性对称。行和列排放整齐的图标比随机摆放的图标易读性更好，更容易理解。虽然几乎不可能使所有对象都能够保持一致，且能够实现行和列排放整齐，但至少在某一个方向上（水平或垂直）排列整齐，这也将在很大程度上提高图标的可读性。

5.实施指南

  数据架构包括构件、活动和行为。因此，实施企业数据架构主要包含的工作内容为：

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

数据架构实施应该至少包括其中两项工作内容，因为这样可以实现互补，以获得相对较好的效果。

5.1 就绪评估和风险评估

  架构类项目可能相比其他项目，特别是在组织中第一次尝试时，容易暴露出更多的风险。最明显的风险有：

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

5.2 组织和文化

  组织架构实施的速度依赖于适应文化的程度。以产出为导向，战略一致的组织能更好地适应架构实施。一个组织接受并实施数据架构的能力依赖于以下几个方面：

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

6.数据架构治理

• 数据架构师通常充当数据治理活动的业务联络人。
• 企业数据架构和数据治理组织必须保持一致。
• 在理想情况下，数据架构师和数据管理员对每个主题域，甚至每个主题域的实体都保持一致。
• 数据监督应该与流程监督保持一致。
• 业务事件主题域应该与流程监督保持一致，因为每个事件实体通常与业务流程相对应。

6.1 数据架构治理活动

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

6.2 度量指标

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

• （1）架构标准接受率
• （2）实施趋势: 对跟踪企业架构改善组织实施项目能力的程度，至少沿两个方向进行改善:
  • 1）使用/重用/代替/废弃测量。
  • 2）项目执行效率测量。
• （3）业务价值度量指标 : 追踪向期待的业务效果和利益方向的发展过程
  • 1）业务敏捷性改进。
  • 2）业务质量。
  • 3）业务操作质量。
  • 4）业务环境改进。

7.总结

• 架构: 对组织要素有组织的设计, 旨在优化整个结构或者系统的功能、性能、可行性、成本和用户体验。在组织不同范围、不同层级展开, 负责将难以理解的东西定义明确清晰。
• 企业架构: 业务架构、数据架构、应用架构以及技术架构等。
• 数据架构的主要目标: 有效地管理数据以及有效管理存储和使用数据的系统。
• 数据架构的基本组成部分:
  • 1) 数据架构成果 不同层级的模型、定义、数据流(数据架构构件)。
  • 2) 数据架构活动 用于形成、部署和实现数据架构的目标。
  • 3) 数据架构行为 影响数据企业数据架构不同角色之间的协作、思维方式和技能。
• 数据架构是数据管理的基础。
• 数据架构构件: 当前状态的描述、 数据需求的定义、数据整合的指引、 数据资产管理规范。
• 详细的数据架构设计文件是正式的企业数据模型: 数据名称、数据属性、元数据定义、概念和逻辑实体、关系以及业务规则。
• 物理数据模型也属于数据架构文件, 物理数据模型是数据建模和设计的产物。
• 数据架构的目标: 在业务战略和技术实现之间建立一座通畅的桥梁。
• 业务驱动因素: 在业务战略和技术实现之间建立一座通畅的桥梁, 是企业架构的一部分。主要职责:
  • 1. 利用新兴技术所带来的业务优势, 从战略上帮助组织快速改变产品、服务和数据。
  • 2. 将业务需求转换为数据和应用需求, 以确保能为业务流程处理提供有效数据。
  • 3. 管理复杂数据和信息, 并传递至整个企业。
  • 4. 确保业务和IT技术保持一致。
  • 5. 为企业改革、转型和提高适应性提供支撑。
• 数据架构的主要成果: 1) 数据存储和处理需求。2) 设计满足当前和长期数据需求的结构和规划。
• 数据架构师的主要工作: 1 定义数据当前状态。2 提供数据和组件的标准业务词汇。3 确保数据架构和企业战略、业务架构一致性。4 描述数据战略需求。5 高阶数据整合概要设计。6 整合企业数据架构蓝图。
• 总体数据架构实施: 1) 使用数据架构构件(主蓝图)来定义数据需求、指导数据整合、管控数据资产, 确保数据项目投入与企业战略保持一致 2) 与参与改进业务或者IT系统开发的利益相关方合作 3) 通过数据架构与通用的数据词汇, 搭建企业数据语言。
• 数据架构定义: 识别企业的数据需求(无论数据结构如何)，设计和维护总蓝图以满足这些需求。使用总蓝图来指导数据集成、控制数据资产，并使数据投资与业务战略保持一致。
• 数据架构目标: 1 识别数据存储和处理需求。2 设计结构、计划以满足企业当前和长期的数据需求。3 战略性的为组织做好准备，快速发展其产品、服务和数据，并使数据投资与业务战略保持一致。【识别需求、设计结构、战略准备】
• 数据架构活动: 1 建立企业数据构架（A 评估现有数据架构规范。B 制定路线图。C 管理项目中的企业需求）2 与其他企业架构集成。
• 数据架构输入: 企业架构、业务架构、IT 标准和目标、数据策略。
• 数据架构交付成果: 数据架构设计、数据流、数据价值链、企业数据模型、实施路线图。
• 架构师通过合适的技术应用、有效运营、项目效率提升及数据应用能力为组织带来价值。
• 企业架构类型：业务构架、数据架构、应用架构、技术架构。
• 架构框架：架构的架构。思考和理解架构的方式。
• Zachman 框架，6X6 矩阵。问询沟通和重新定义转换两个维度。
• Zachman 框架——问询沟通：
  • 1 什么 What：目录列，构建架构的实体。
  • 2 怎么 HOW：流程列，表示执行的活动。
  • 3 在哪里 WHERE，分布列，业务位置和技术位置。
  • 4 谁 WHO：职责列，角色 和组织。
  • 5 时间 WHEN：时间列，表示间隔、事件、周期和时间表。
  • 6 为什么 WHY：动机列，表目标、策略和手段。
• Zachman 框架——重新定义转换是将抽象的概念转变为具体的实体（实例化）的必经步骤。
  • 1） 高管视角（业务背景）：定义不同模型范围的业务元素目录。
  • 2）业务管理视角（业务概念）： 明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系。
  • 3）架构师视角（业务逻辑）： 作为模型设计的架构师细化系统需求，设计系统逻辑模型。
  • 4）工程师视角（业务实体）： 作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型。
  • 5）技术人员视角（组件程序集）： 采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置组件。
  • 6）用户视角（操作类）： 参与人员所使用的实际功能实例。该视角没有模型。
• 企业数据架构：定义对组织非常重要元素的标准术语和设计。企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。企业数据架构包括两个方面的设计：
  • 1）企业数据模型(数据结构 、数据规范)
    • 企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。
    • 企业数据模型包括：数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性。
  • 2）数据流设计
    • 定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。
    • 展示数据在业务流程、不同存储位置、业务角色和技术组件间的流动。
• 常用的主题域识别准则：使用规范化规则，从系统组合中分离主题域，基于顶级流程（业务价值链）或者基于业务能力（企业架构）从数据治理结构和数据所有权（或组织）中形成主题领域。
• 数据流：记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动。源于哪，在哪存，如何转化，数据血缘分析有助于分析解释数据流中某一点上的数据状态。
• 数据流映射记录了：1 业务流程中的应用。2 某个环境中的数据存储或数据库。3 网段。4 业务角色 。5 出现局部差异的位置。
• 数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系。用 二维矩阵 或 数据流图 呈现。
• 两种方法论： 面向质量(与传统一致)、面向创新
• 【活动1】建立企业数据架构。
  • 【活动 1-1】建立企业数据架构-现有数据架构规范评估。
  • 【活动 1-2】建立企业数据架构-开发路线图
  • 【活动 1-3】建立企业数据架构-在项目中管理企业需求。
• 【活动 2】整合其他企业架构
• 数据架构工具：1 数据建模工具 2 资产管理软件 3 图形设计应用
• 数据架构方法： 1. 生命周期预测 2. 图标使用规范
• 数据架构包括构件、活动、行为。数据架构实施工作内容
• 数据构架度量指标：1.架构标准接受率 2.实现趋势 3.业务价值度量指标