DAMA数据管理知识体系（第4章数据架构）

课本内容
- 4.1 引言
  - 概要
    - 数据架构考虑方面
      - 数据架构成果，包括不同层级的模型、定义、数据流，这些通常被称为数据架构的构件
      - 数据架构活动，用于形成、部署和实现数据架构的目标
      - 数据架构行为，包括影响企业数据架构的不同角色之间的协作、思维方式和技能
    - 最为详细的数据架构设计文件是正式的企业数据模型，包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。物理数据模型也属于数据架构文件，但物理数据模型是数据建模和设计的产物，而不是数据架构的产物。
    - 企业数据架构是实现整个企业数据标准一致及数据整合的保证
  - 业务驱动因素
    - 数据架构的目标是在业务战略和技术实现之间建立起一座通畅的桥梁，数据架构是企业架构中的一部分
      - 1）利用新兴技术所带来的业务优势，从战略上帮助组织快速改变产品、服务和数据。2）将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效数据。3）管理复杂数据和信息，并传递至整个企业。4）确保业务和IT技术保持一致。5）为企业改革、转型和提高适应性提供支撑。
  - 数据架构的主要成果包括
    - 1）数据存储和处理需求。2）设计满足企业当前和长期数据需求的结构和规划
    - 数据架构语境关系图
      - 数据架构
    - 数据架构师需要定义和维护的具体事宜如下
      - 1）定义组织中数据的当前状态。2）提供数据和组件的标准业务词汇。3）确保数据架构和企业战略及业务架构保持一致。4）描述组织数据战略需求。5）高阶数据整合概要设计。6）整合企业数据架构蓝图。
  - 基本概念
    - 企业架构类型
      - 企业架构类型
        表4-1 企业架构类型
    - 企业架构框架
      - IEEE计算机协会维护的企业架构框架标准是ISO/IEC/IEEE 42010: 2011
      - 不同视角
        1）高管视角（业务背景）。定义不同模型范围的业务元素目录。 2）业务管理视角（业务概念）。明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系。 3）架构师视角（业务逻辑）。作为模型设计的架构师细化系统需求，设计系统逻辑模型。 4）工程师视角（业务实体）。作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型。 5）技术人员视角（组件程序集）。采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置组件。 6）用户视角（操作类）。参与人员所使用的实际功能实例。该视角没有模型。
    - 企业数据架构
      - 企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。
      - 企业数据架构描述必须包括企业数据模型（如数据结构和数据规范）和数据流设计
        企业数据模型
        企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。
        企业数据模型包括通用的（企业范围的概念和逻辑模型）和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则
        图4-3 企业数据模型
        每个企业数据模型既可以采用自上而下，也可以采用自下而上的方法进行构建。自上而下是从主题域开始，先设计主题，再逐步设计下层模型。而采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成。通常推荐两种方法相结合，即自下而上地从分析现有模型开始，自上而下地设计主题模型，通过两种方法的结合来共同完成企业数据模型的设计工作。
        数据流设计
        定义数据库、应用、平台和网络（组件）之间的需求和主蓝图。这些数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的流动。
        数据流是一种记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动
        数据流映射记录了数据与以下内容的联系：1）业务流程中的应用。2）某个环境中的数据存储或数据库。3）网段（有助于安全映射）。4）业务角色（描述哪些角色有职责创建、更新和删除数据）。5）出现局部差异的位置。
        数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系
        矩阵形式
        图4-5 矩阵形式描述的数据流
        数据流形式
        图4-6 数据流示例
        总结
        这两个模型都需要反映当前状态和目标状态（架构视角）及过渡状态（项目视角）
- 4.2 活动
  - 建立企业数据架构
    - 概要
      - 简化数据和企业架构所面临的复杂问题，基于面向质量和面向创新
    - 企业数据架构也会影响项目和系统开发的范围边界
      - 定义项目数据需求
      - 审评项目数据设计
      - 确定数据溯源影响
      - 数据复制控制
        数据架构治理能保证充分的复制控制（方法和机制）来达到所需的一致性
      - 实施数据架构标准
      - 指导数据技术和更新决策
    - 实施步骤
      - 现有数据架构规范评估
      - 开发路线图
        业务数据驱动路线图可以从最独立的业务能力开始（如对其他业务能力依赖最小），再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力，需要遵循整体业务数据生成顺序。图4-7是一个业务能力数据依赖链的例子，顶部模块依赖最底部模块。产品管理和客户管理不依赖任何模块，因此属于主数据。依赖度最高的模块位于底部，客户发票管理依赖客户管理和销售订单管理，而销售订单管理也依赖另外两个管理模块。
        图4-7 业务能力的数据依赖
      - 在项目中管理企业需求
        架构不应该受开发时间的限制
        数据架构师应该决定
        1）规范中所描述实体是否符合标准。2）在需求中，哪些实体应该被包括在整体企业数据架构中。3）规范中的实体和定义是否需要扩大或加深以满足将来的趋势。4）是否更新了数据架构或者是否向开发人员指出了哪些可以重用。
    - 企业数据架构项目相关的活动包括
      - 定义范围
      - 理解业务需求
      - 设计
      - 实施
        软件开发过程
        瀑布方式
        迭代方式
        敏捷方式
  - 整合其他企业架构
- 4.3 工具
  - 数据建模工具
  - 资产管理软件
    - 资产管理软件用于管理数据资源目录，描述其内容以及跟踪它们之间的关系
  - 图形设计应用
    - 图形设计应用可以用于创建架构设计图形、数据流、数据价值链和其他架构构件
- 4.4 方法
  - 生命周期预测
  - 图标使用规范
- 4.5 实施指南
  - 概要
    - 数据架构包括构件、活动和行为
    - 数据架构的主要工作内容
      - 建立企业数据架构团队和举办问题讨论会
      - 生成数据架构构件的初始版本。例如，企业数据模型、企业范围数据流和路线图
      - 在开发项目中，形成和建立数据架构工作方式
      - 提高组织对数据架构工作价值的认识
  - 就绪评估和风险评估
    - 风险
      - 缺少管理层支持
      - 成功与否缺乏证据
      - 缺乏管理者的信任
      - 管理层不正确的决策
      - 文化冲击
      - 缺乏有经验的项目经理
      - 单一维度视角
  - 组织和文化
    - 一个组织接受并实施数据架构的能力依赖于以下几个方面
      - 1）对架构方法的接受度（开发架构的友好性）。2）确认数据属于组织的业务资产，而不仅仅是IT的任务。3）放弃局部数据视角，接受企业级数据视角的能力。4）将架构交付成果整合到项目实施中的能力。5）规范数据治理的接受程度。6）立足企业全局，而不是仅仅局限于项目交付成果和IT解决问题的能力（Edvinsson，2013）。
- 4.6 数据架构治理
  - 数据架构治理活动
    - 项目监督
    - 管理架构设计、生命周期和工具
    - 定义标准
    - 创建数据相关构件
  - 度量指标
    - 架构标准接受率
    - 实施趋势
      - 使用/重用/代替/废弃测量
      - 项目执行效率测量
    - 业务价值
      - 业务敏捷性改进
      - 业务质量
      - 业务操作质量
      - 业务环境改进
考察分值&知识点
- 考察分值
  - 10分
- 考察知识点
  - 引言
    - 企业架构的基本组成部分
    - 企业数据模型组成部分
    - 企业数据架构的理解
    - 数据架构构件的组成
    - 企业数据模型的理解
    - 数据流映射记录了数据与以下内容的联系
    - 语境关系图-目标
  - 活动
    - 企业数据架构项目相关活动
  - 工具
  - 方法
    - 图标使用规范
  - 实施指南
    - 数据架构的主要工作内容
  - 数据架构治理
    - 数据架构治理活动