1.1. 第一波浪潮是银行和金融交易
1.2. 第二波浪潮是各种数字服务交互
1.3. 在第三波浪潮中，传统行业像汽车、医疗保健设备和工具等也正在进行数字化转型
1.3.1. 物联网和远程信息处理推动了第三波浪潮
2. 数据架构2.1. 架构是构建一个系统的艺术和科学，以及在此过程中形成的成果——系统本身
2.1.1. 架构是对组件要素有组织的设计，旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验
2.1.2. 架构定义为“系统的基本结构，具体体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则
2.1.3. 从全局来理解，“架构”一词可以指对系统当前状态的描述、一组系统的组件、系统设计的准则（架构实践）、一个系统或一组系统的意向性设计（未来状态或计划的架构）、描述系统的构件（架构文档）或执行设计工作的团队（架构师或架构团队）等
2.2. 架构设计工作通常在组织的不同范围（企业、业务条线、项目等）内，在信息系统的不同层级（基础架构、应用架构和数据架构等）来开展
2.3. 企业架构包括多种不同类型，如包括业务架构、数据架构、应用架构和技术架构等
2.3.1. 数据架构是数据管理的基础
2.3.1.1. 数据架构如果能够完全支持整个企业的需求，它才是最有价值的
2.3.1.2. 企业数据架构是实现整个企业数据标准一致及数据整合的保证
2.4. 数据架构成果，包括不同层级的模型、定义、数据流，这些通常被称为数据架构的构件
2.4.1. 数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控策略中要求的数据资产管理规范
2.4.2. 组织的数据架构是指不同抽象层级主要设计文档的集合，其中主要包括数据的收集、存储、规划、使用和删除等标准
2.4.3. 架构师设计的数据架构构件是非常有价值的元数据的重要组成部分
2.4.4. 在理想情况下，数据架构构件应该在企业级元知识库中被集成存储和管理
2.5. 数据架构活动，用于形成、部署和实现数据架构的目标
2.6. 数据架构行为，包括影响企业数据架构的不同角色之间的协作、思维方式和技能
2.7. 最为详细的数据架构设计文件是正式的企业数据模型，包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则
2.7.1. 物理数据模型也属于数据架构文件，但物理数据模型是数据建模和设计的产物，而不是数据架构的产物
2.8. 许多企业，在基于数据提供服务的业务模式上几乎没有什么经验，因为在此之前这些服务都是由零售商或售后服务提供商负责
2.8.1. 架构师就是要通过自身的专业技能，将这些容易被非专业架构人员难以理解或迷惑的内容定义和设计清晰，以便浅显易懂
2.8.2. 具有前瞻性的组织在设计新产品时，设计团体应该包括数据管理专业人员（如企业数据架构师或战略数据管理员），因为现在新产品的设计需要以数据为基础，而数据通常需要涉及捕获数据的硬件、软件和服务以及依赖数据访问服务等
3. 业务驱动因素3.1. 主要职责
3.1.1. 利用新兴技术所带来的业务优势，从战略上帮助组织快速改变产品、服务和数据
3.1.2. 将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效数据
3.1.3. 管理复杂数据和信息，并传递至整个企业
3.1.4. 确保业务和IT技术保持一致
3.1.5. 为企业改革、转型和提高适应性提供支撑
3.2. 数据架构师创建和维护企业相关数据及其系统的知识
3.2.1. 这些知识可以使得企业将数据作为资产进行管理，以及研究更多数据在业务应用、降低成本、风险防控等方面的场景，以提升企业在数据价值变现方面的能力
4. 数据架构成果和实施4.1. 主要成果
4.1.1. 数据存储和处理需求
4.1.2. 设计满足企业当前和长期数据需求的结构和规划
4.2. 架构师寻求一种能够为组织带来价值的方式对组织的数据架构进行设计
4.2.1. 定义组织中数据的当前状态
4.2.2. 提供数据和组件的标准业务词汇
4.2.3. 确保数据架构和企业战略及业务架构保持一致
4.2.4. 描述组织数据战略需求
4.2.5. 高阶数据整合概要设计
4.2.6. 整合企业数据架构蓝图
4.3. 总体数据架构实施
4.3.1. 使用数据架构构件（主蓝图）来定义数据需求、指导数据整合、管控数据资产，确保数据项目投入与企业战略保持一致
4.3.2. 与参与改进业务或IT系统开发的利益相关方合作，学习并影响他们
4.3.3. 通过数据架构及通用的数据词汇，搭建企业数据语言
5. Zachman框架5.1. 什么(What)
5.1.1. 目录列，表示构建架构的实体
5.2. 怎样(How)
5.2.1. 流程列，表示执行的活动
5.3. 在哪里(Where)
5.3.1. 分布列，表示业务位置和技术位置
5.4. 谁(Who)
5.4.1. 职责列，表示角色和组织
5.5. 什么时间(When)
5.5.1. 时间列，表示间隔、事件、周期和时间表
5.6. 为什么(Why)
5.6.1. 动机列，表示目标、策略和手段
5.7. 重新定义转换是将抽象的概念转变为具体的实例（实例化）的必经步骤
5.8. 高管视角（业务背景）
5.8.1. 定义不同模型范围的业务元素目录
5.9. 业务管理视角（业务概念）
5.9.1. 明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系
5.10. 架构师视角（业务逻辑）
5.10.1. 作为模型设计的架构师细化系统需求，设计系统逻辑模型
5.11. 工程师视角（业务实体）
5.11.1. 作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型
5.12. 技术人员视角（组件程序集）
5.12.1. 采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置组件
5.13. 用户视角（操作类）
5.13.1. 参与人员所使用的实际功能实例。该视角没有模型
6. 企业数据架构6.1. 数据架构定义了对组织非常重要元素的标准术语和设计
6.2. 企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布
6.3. 企业数据模型
6.3.1. 企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图
6.3.2. 通常用于表示高层级简化的数据模型，也表示了不同抽象层级
6.3.3. 企业数据模型包括通用的（企业范围的概念和逻辑模型）和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则
6.3.4. 需要设计企业数据模型的组织，必须决定投入多少时间和精力到构建和维护企业数据模型上
6.3.5. 企业主题域的概念概述
6.3.6. 各主题域的实体和关系概述
6.3.7. 归属于同一主题域的详细逻辑概述
6.3.8. 具体到应用或项目的逻辑和物理模型
6.3.9. 各层级的模型是企业数据模型的组成部分，模型链接定义和管理了模型的纵向从上到下以及横向之间的关联路径
6.3.9.1. 纵向：不同层级模型之间的映射
6.3.9.2. 横向：同一个实体和关系可能出现在同一层级的多个模型中
6.3.10. 每个企业数据模型既可以采用自上而下，也可以采用自下而上的方法进行构建
6.3.10.1. 自上而下是从主题域开始，先设计主题，再逐步设计下层模型
6.3.10.2. 采用自下而上的方法时，主题域结构则是基于现有逻辑数据模型向上提炼抽象而成
6.3.10.3. 通常推荐两种方法相结合，即自下而上地从分析现有模型开始，自上而下地设计主题模型，通过两种方法的结合来共同完成企业数据模型的设计工作
6.3.11. 常用的主题域识别准则
6.3.11.1. 使用规范化规则，从系统组合中分离主题域，基于顶级流程（业务价值链）或者基于业务能力（企业架构）从数据治理结构和数据所有权（或组织）中形成主题领域
6.3.11.2. 如果主题域结构是使用规范化规则形成的，那么它对于数据架构工作通常是最有效的
6.3.11.3. 规范化过程将建立承载/构成每个主题域的主要实体
6.4. 数据流设计
6.4.1. 定义数据库、应用、平台和网络（组件）之间的需求和主蓝图
6.4.2. 这些数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的流动
6.4.3. 数据流是一种记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动
6.4.4. 端到端的数据流包含了数据起源于哪里，在哪里存储和使用，在不同流程和系统内或之间如何转化
6.4.5. 数据血缘分析有助于解释数据流中某一点上的数据状态
6.4.6. 业务流程中的应用
6.4.7. 某个环境中的数据存储或数据库
6.4.8. 网段（有助于安全映射）
6.4.9. 业务角色（描述哪些角色有职责创建、更新和删除数据）
6.4.10. 出现局部差异的位置
6.4.11. 数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系
