**架构：**对组件要素有组织的设计，旨在优化整合结构或系统的功能、性能、可行性、成本和用户体验。系统的基本结构，具体体现在架构构成的组件、组件之间的相互关系以及管理其设计和演变的原则。在组织不同范围、不同层级开展。负责将难以理解的东西定义明确清晰。
**企业架构包含业务架构、数据架构、应用架构和技术架构等。**好的架构能帮助组织了解系统状态、加速转好，实现守规提效的目标。
**数据架构是数据管理的基础，**需要在不同层级上描述，以便更好的了解和帮助决策。
**数据架构的构件：**当前状态的描述、数据需求的定义、数据整合的指引、数据资产管理规范；
**数据架构的目标：**在业务战略和技术实现之间建立起一座通畅的桥梁，数据架构是企业架构中的一部分。
**业务驱动因素：**在业务战略和技术实现之间建立一座通畅的桥梁，是企业架构的一部分。主要职责：
- 利用新兴技术所带来的优势，从战略上帮助组织快速改变产品、服务和数据；
- 将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效数据；
- 管理复杂数据和信息，并传递至整个企业；
- 确保业务和IT技术保持一致；
- 为企业改革、转型和提高适应性提供支撑；
数据架构的主要成果：
- 数据存储和处理需求；
- 设计满足当前和长期数据需求的结构和规划；
数据架构师的主要工作：
- 定义数据当前状态；
- 提供数据和组件的标准业务词汇；
- 确保数据架构和企业战略、业务架构一致性;
- 描述数据战略需求；
- 高阶数据整合概要设计；
- 整合企业数据架构蓝图。
总体数据架构实施：
- 使用数据构架构建（主蓝图）来定义数据需求、指导数据整合、管控数据资产，确保数据项目投入与企业战略保持一致。
- 在参与改进业务或IT系统开发的利益相关方合作，学习并影响他们；
- 通过数据架构及通用的数据词汇，搭建企业数据语言。
**数据架构定义：**识别企业的数据需求（无论数据结构如何），设计和维护总蓝图以满足这些需求，使用总蓝图来指导数据集成、控制数据资产，并使数据投资与业务战略保持一致。
数据架构目标：
- 识别数据存储和处理需求；
- 设计结构、计划以满足企业当前和长期的数据需求；
- 战略性的为组织做好准备，快速发展其产品、服务和数据，并使数据投资与业务战略保持一致。【识别需求、设计结构、战略准备】
数据架构活动：
- 建立企业数据构架（评估现有数据架构规范、制定路线图、管理项目中的企业需求）；
- 与其他企业架构集成。
**数据架构输入：**企业架构、业务架构、IT标准和目标；
**数据架构交付成果：**数据架构设计、数据流、数据价值链、企业数据模型、实施路线图；
架构师需求一种能为组织带来价值的方式对组织的数据架构进行设计，这种价值主要通过合适的技术应用、有效运营、项目效率提升及数据应用能力加强来体现。
**企业架构类型：**业务架构、数据架构、应用架构、技术架构。
|--------|------------------------|----------------------------------|----------------|----------------------|
| 类型 | 业务架构 | 数据架构 | 应用架构 | 技术架构 |
| 目的 | 识别组织如何为消费者和其他利益相关方创造价值 | 描述数据应如何组织和管理 | 描述企业应用的结构和功能 | 描述能使系统发挥功能和传递价值的实体技术 |
| 元素 | 业务模型、流程、功能、服务、事件、策略、词汇 | 数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口 | 业务系统、软件包、数据库 | 技术平台、网络、安全、整合工具 |
| 依赖项 | 制定其他架构的需求 | 管理业务架构、创建和需要的数据 | 依赖业务需求来处理指定的数据 | 承载并执行应用架构 |
| 角色 | 业务架构师和分析师、业务数据管理员 | 数据架构师、建模师、数据管理员 | 应用架构师 | 基础设施架构师 |
**架构框架：**架构的架构、思考和理解架构的方式；
**Zachman框架：**6*6矩阵，问询沟通和重新定义转换两个维度；
Zachman框架：问询沟通：
- 什么What:目录列，构建架构的实体；
- 怎么How:流程列，表示执行的活动；
- 在哪里Where:分布列，业务位置和技术位置；
- 谁Who:职责列，角色和组织；
- 时间When：时间列，表示间隔、事件、周期和时间表；
- 为什么Why:动机列，表目标、策略和手段。
|----------|---------|---------|----------|----------|----------|-----------|-----------|
| | 是什么 | 怎么做 | 在哪里 | 是谁 | 什么时间 | 为什么 | |
| 管理层 | 库存标识 | 过程识别 | 分发识别 | 责任认定 | 时间识别 | 动机识别 | 上下文范围 |
| 业务管理 | 库存定义 | 流程定义 | 分布定义 | 责任定义 | 时间定义 | 动机定义 | 业务概念 |
| 架构师 | 库存表示 | 过程表示 | 分布表示 | 责任表示 | 时间表示 | 动机表示 | 系统逻辑 |
| 工程师 | 库存规格 | 过程规范 | 分布规范 | 责任规范 | 时间规范 | 动机规范 | 实施部署 |
| 技术员 | 库存配置 | 流程配置 | 分发配置 | 责任配置 | 时间配置 | 动机配置 | 工具组件 |
| 操作员 | 库存实例 | 流程实例 | 分发实例 | 责任实例 | 时间实例 | 动机实例 | 操作实例 |
| | 库存集 | 过程流 | 分销网络 | 责任分配 | 时间周期 | 动机的意图 | |
**Zachman框架-重新定义转换：**是将抽象的概念转变为具体的实体（实例化）的必经步骤；
- 高管视角：定义不同模型范围的业务流程目录；
- 业务管理视角：明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系；
- 架构师视角：作为模型设计的架构师细化系统需求，设计系统逻辑模型；
- 工程师视角：作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型；
- 技术人员视角：采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置的组件；
- 用户视角：参与人员所使用的实际功能实例，该视角没有模型。
**企业数据架构：**定义对组织非常重要元素的标准术语和设计。企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。具体如下：企业数据模型（数据结构、数据规范）、数据流设计。
**数据：**需要安全、集成、存储、记录、分类、共享的报表和分析，最终交付使用。过程中数据可能会被：验证、增强、链接、认证、整合、脱敏处理以及用于分析，直到数据被归档或清除。
**企业数据模型：**是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。简化抽象的。包括：数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性。
**数据流设计：**定义数据库、应用、平台和网络（组件）之间的需求和主蓝图，展示数据在业务流程、不同存储位置、业务角色和技术组件间的流动。
**企业数据模型：**采用行业标准模型能快速提升企业模型应用的效率，随着企业需求变人，企业数据模型中的范围和各层级内容也会扩张，可以用不同层级增量和迭代方式来构建，每个企业数据模型中的实体应仅属于一个主题域，但可和任何企业主题域相关联。企业概念数据模型是主题域模型相结合构建，可自上而下，也可自下而上。
主题域的识别准则必须在整个企业模型中保持一致，常见的主题域识别准则：使用规范化规则，从系统组合中分离主题域，基于顶级流程（业务价值链）或者基于业务能力(企业架构)从数据治理结构和数据所有权（或组织）中形成主题领域，如果主题域结构是使用规范化规则形成的，那么它对于数据架构的工作通常是最有效的，规范化过程将建立承载/构成每个主题域的主要实体。
**数据流:**记录数据学院的数据加工过程，用于描述数据如何在业务流程和系统中流动，源于哪，在哪存，如何转化，数据血缘分析有助于分析解释数据流中某一点的数据状态。数据流映射记录了：业务流程中的应用、某个环境中的数据存储和数据库、网段、业务角色、出现局部差异的位置；
数据流可以用于描述不同层级模型的映射关系：主题域、业务实体、乃至属性层面的映射关系、用二维矩阵和数据流图呈现。
**两种方法论：**面向质量（与传统一致）、面向创新（不用面面俱到）
建立企业数据架构要做的工作：
- 战略。选择框架，制定方法，开发路线图；
- 沟通和文化；
- 组织，明确责任和职责；
- 工作方法，与企业架构保持一致；
- 结果，在总体路线图中产出。
数据架构会影响：
- 定义项目数据需求；
- 评审项目数据设计；
- 确定数据溯源影响；
- 数据复制控制；
- 实施数据架构标准；
- 指导数据技术和更新决策。
企业数据架构路线图：
描述了3-5年的发展路径。包括高层级里程碑事件、所需资源、成本评估、业务能力工作流划分，路线图应以数据管理成熟度评估为指导，业务数据驱动路线图可以从最独立的业务能力开展，再处理相互依赖程度较高的业务能力。
在项目级别上，通过数据模型定义需求的过程是从审查业务需求开始的。通常，这些需求是特定于项目目标的，不会对企业产生影响，该过程还应包括开发术语定义和智慧数据使用的其他活动。
企业数据架构项目相关的活动：
- **定义范围，**保证范围和接口与企业数据模型一致；
- **理解业务需求，**获取数据相关的需求，如实体，资源，可用性，质量和痛点，业务价值；
- **设计，**形成详细的目标规范；
- 实施，（什么时候购买，什么时候重用数据，什么时候构建）。
**架构活动嵌入到项目过程采用的方式：**瀑布、迭代、敏捷；
**数据架构工具：**数据建模工具、资产管理软件、图形设计应用。
**数据架构方法：**1.生命周期预测；2.图标使用规范；
**生命周期预测：**1.当前的；2.部署周期的；3.策略周期的；4.退役的；4.优先的；6.限制的；7.新兴的；8.审核的。
**图标使用规范：**1.清晰一致的说明；2.所有图表对象与说明相匹配；3.清晰一致的线条方向；4.一致的交叉线显示方法；5.一致的对象属性；6.线性对称。
数据架构包括构件、活动、行为。数据架构实施工作内容：
- 建立企业数据架构团队和举办问题讨论会；
- 生成数据架构版本；
- 在开发项目中，形成和建立数据架构工作方式；
- 提供组织对数据架构工作价值认识。
就绪评估和风险评估：
- 缺少管理层的支持；
- 成功与否缺乏证据；
- 缺乏管理者的信任；
- 管理层不正确的决策；
- 文化冲击；
- 缺乏有经验的项目经理；
- 单一维度视角。
组织和文化依赖：
- 对架构方法的接受度；
- 确认数据属于组织的业务资产，而不是IT的任务；
- 放弃局部数据视角，接受企业级数据视角的能力；
- 将架构交付成果整合到项目实施的能力；
- 规范数据治理的接受程度；
- 立足企业布局，而不局限于项目交付成果和IT解决方案的能力；
数据架构治理活动：
- 项目监督；
- 管理架构设计、生命周期和工具；
- 定义标准；
- 创建数据相关构件。
数据架构度量指标：
- 架构标准接受率；
- 实现趋势；
- 业务价值度量指标。
架构标准接受率：测量项目与已建立的数据构架的紧密程度及项目与企业架构参与流程的遵循度；
实现趋势：使用/重用/代替/废弃测量，项目执行效率测量；
业务价值度量指标：1.业务敏捷性改进；2.业务质量；3.业务操作质量；4.业务环境改进。