# 数据架构
# 架构及数据架构基本概念
架构是构建一个系统的艺术与科学，以及在构建过程中的成果。通俗点讲，架构是对组件要素有组织的设计，旨在优化整个结构或系统功能、性能、可行性、成本和用户体验。
术语“架构”已经被广泛接受，并用于描述信息系统的重要设计部分。在国际标准ISO/IEEE 42010中，将架构定义为“系统的基本结构，具体体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则”。从全局来理解“架构”一词，可以指对系统当前状态的描述、一组系统的组件、系统设计的准则、一个系统或一组系统的意向性设计、描述系统的构建或执行设计工作的团队等。
架构设计工作通常在组织的不同范围（企业、业务线、项目等）内，在信息系统的不同层级（企业架构、应用架构、数据架构）来开展。架构师的工作，就是要通过自身的专业技能，将这些容易被非专业架构人员难以理解或迷惑的内容定义清晰，以便浅显易懂。
企业架构包含多种不同类型，如业务架构、数据架构、应用架构和技术架构等。良好的企业架构管理有助于组织了解系统的当前状态，加速向期待状态改变，实现遵守规范，提高效率的目标。我们可以从如下几个角度来考虑数据架构：
- 数据架构成果，包括不同层级的模型、定义、数据流，这些通常被称为数据架构的构件。
- 数据架构活动，用户形成、部署和实现数据架构的目标。
- 数据架构行为，包括影响企业数据架构的不同角色之间的协作、思维方式和技能。
以上三个方面是数据架构的基本组成部分，数据架构是数据管理的基础，由于大多数组织拥有的数据超过了个人可理解的范围，因此有必要在不同层级上描述组织的数据，以便更好的了解数据，帮助管理层做出决策。
数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控中要求的数据资产管理规范。组织的数据架构是指不同抽象层级主要设计的集合，其中包括数据的收集、存储、规划、使用和删除等标准。这是按照数据的生命周期来对数据架构中包括的内容进行定义和范围界定，同时也可以按照数据在组织系统中所存储的容器和路径来进行定义和确定范围。
数据架构设计文件是正式的企业数据模型，包含数据名称、数据属性、元数据定义、概念和逻辑实体、关系及业务规则。物理数据模型也属于数据架构文件，但物理数据模型是数据建模和设计的产物，不是数据架构的产物。在理想的情况下，数据架构构件应该在企业级元知识库中被集成和统一管理。
# 企业架构框架
企业架构框架是用于开发广泛的相关架构的基础结构，架构框架提供了思考和理解架构的方式。他们代表了一个总体的“架构的架构”。
比较经典的企业架构框架有TOGAF和Zachman框架。我们这次重点描述一下Zachman，Zachman是一个本体，即6*6矩阵构成一组模型，这组模型可以完整的描述一个企业以及相互之间的关系。它并不定义如何创建模型，只是显示哪些模型应该存在。
矩阵框架的两个维度为：问询沟通（是什么、怎样做、在哪里、是谁在做、什么时间做、为什么要做）在列中显示，重新定义转换（如识别、定义、描述、规范、配置和实例）在行中显示。框架分类按照单元格呈现（问询和转换之间的交叉）。框架的每个单元格代表一个独特的设计组件。
在问询沟通时，可以询问关于任何一个实体的基本问题，将其转换成企业架构，每个列可以按如下方式理解：
- 是什么（what）。目录列，表示构建架构的实体。
- 怎样做？（how）。流程列，表示执行的活动。
- 在哪里做？（where）。分布列，表示业务位置和技术位置。
- 谁做？（who）。职责列，表示角色和组织。
- 什么时间？（when）。时间列，表示间隔、事件、周期和时间表。
- 为什么做？（why）。动机列，表示目标、策略和手段。
矩阵中的每一行代表不同的角色，具体的角色包括策划者、所有者、设计师、建造者、实施者和用户。每个角色对整个过程和不同问题的解决均有不同的视角。这些不同的视角对应的内容在每行中进行显示。具体说明如下：
- 高管视角（业务背景）。定义不同模型范围的业务元素目录。
- 业务管理视角（业务概念）。明确管理层在定义的业务模型中所涉及的不同业务概念之间的关系。
- 架构师视角（业务逻辑）。作为模型设计的架构师细化系统需求，设计系统逻辑模型。
- 工程师视角（业务实体）。作为具体模型建造者的工程师，在特定技术、人员、成本和时间限制内，优化和实施为具体应用设计的物理模型。
- 技术人员视角（组件程序集）。采用特定技术、脱离上下文语境的视角，来解释配置模型的技术人员如何使用、组装和实施配置组件。
- 用户视角（操作类）。参与人员所使用的实际功能实例。
# 企业数据架构
数据架构定义了对组织非常重要元素的标准术语和设计。企业数据架构的设计中包括业务数据描述，如数据的收集、存储、整合、移动和分布。
当数据在组织中通过源或接口流动时，需要安全、集成、存储、记录、分类、共享的报表和分析，最终交付给利益相关方使用。在这个过程中，数据可能会被验证、增强、链接、认证、整合、脱敏处理以及用于分析，直到数据被归档或者清除。因此，企业数据架构描述必须包含企业数据模型（数据结构和数据规范）和数据流设计。
# 企业数据模型
企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型，为企业提供通用的、一致的数据视图。通常用于表示高层级简化的数据模型，也表示了不同的抽象层级。企业数据模型包括数据实体（如业务概念）、数据实体间关系、关键业务规则和一些关键属性，它为所有数据和数据相关的项目奠定了基础。任何项目级的数据模型必须基于企业数据模型进行设计，企业数据模型应该由利益相关方审核，以便它能一致有效的代表企业。
有些组织将企业数据模型创建为单独的构件，还有些组织认为数据模型是由不同角度不同层级的细节组成，这些细节一致的描述了企业内数据的实体、数据属性和它们之间关系的理解。企业数据模型包括通用的（企业范围的概念和逻辑模型）和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则。采用行业标准模型能够加快开发企业数据模型的效率，设计企业数据模型的组织，也必须决定投入多少时间和精力到构建和维护企业数据模型上。大多数的企业业务数据模型会利用不同层级的增量金额迭代的方式来构建。
企业概念数据模型是由主题域模型相结合构建的。每个企业数据模型既可以采用自上而下，也可以采用自下而上的方法进行构建。自上而下是从主题域开始，先设计主题，在逐步设计下层模型。采用自下而上的方法时，主题域结构则是基于现有逻辑数据向上提炼抽象而成。
主题域的识别准则必须在整个企业模型中保持一致。常用的主题域识别规则包括：使用规范化规则，从系统组合中分离主题域，基于顶级流程或者基于业务能力，从数据治理结构和数据所有权中形成主题领域。
# 数据流设计
数据流是一种记录数据血缘的数据加工过程，用于描述数据如何在业务流程和系统中流动。端到端的数据流包含了数据起源于哪里，在哪里存储和使用，在不同流程和系统内或系统之间如何转化。数据血缘分析有助于解释数据流中某一点上的数据状态。
数据流映射记录了数据与一下内容的联系：
- 业务流程中的应用。
- 某个环境中数据存储或数据库。
- 网段（有助于安全映射）。
- 业务角色（描述哪些角色有职责创建、更新和删除数据）。
- 出现局部差异的位置。
数据流可以用于描述不同层级模型的映射关系：主题域、业务实体，乃至属性层面的映射关系。系统可以通过网络、平台、常用应用集或独立服务器呈现。数据流也可以通过二维矩阵或数据流图来实现。
# 建立企业数据架构
在理想情况下，数据架构应该是企业架构的组成部分，但是如果没有企业架构，依然可以构建数据架构团队。在这种情况下，组织应该设计有助于明确目标和驱动数据架构的框架。该框架将对数据架构实施路线图中的方法、范围和工作优先级产生影响。
建立企业数据架构通常包括以下工作：
- 战略。选择框架，制定方法，开发路线图。
- 沟通与文化。建立沟通机制，激励积极参与者。
- 组织。通过明确责任和职责来组织数据框架中的工作。
- 工作方法。与企业架构保持一致，在开发项目中定义最佳实践并执行数据架构工作。
- 结果。在中体线路图中产出数据架构产品。
企业数据架构也会影响项目和系统开发的范围边界，如：
- 定义项目数据需求。通过数据架构为企业提供每个项目的数据需求。
- 审评项目数据设计。通过设计审评来确保概念、逻辑和物理数据模型与架构一致，与组织的长期策略一致。
- 确定数据溯源影响。确保数据流在应用中的业务规则一致并且可追溯。
- 数据复制控制。复制是一种常见的，能够提供改善应用性能和便于获取数据的方法，但是也有可能导致数据的不一致。数据架构治理能保证充分的复制控制（方法和机制）来达到所需的一致性。
- 实施数据架构标准。为企业数据架构生命周期制定和实施标准。标准可以表示为原则、流程、指南和规划蓝图。
- 指导数据技术更新和决策。数据架构与企业架构一起管理每个应用的数据技术版本、补丁和我数据路线图策略。
# 数据架构成果和实施
数据架构的目标是在业务战略和技术实现之间建立起一座通畅的桥梁，数据架构是企业架构中的一部分，其主要职责是：
- 利用新兴技术所带来的技术优势，从战略上帮助组织快速改变产品、服务和数据。
- 将业务需求转换为数据和应用需求，以确保能够为业务流程处理提供有效依据。
- 管理复杂数据和信息，并传递至整个企业。
- 确保业务和IT技术，在数据理解层面保持一致。
- 为企业改革、转型金额提高适应性提供支撑。
数据架构师创建和维护企业相关数据及其系统的知识，这些知识可以使得企业将数据作为资产进行管理，以及研究更多数据在业务应用、降低成本、风险防控等方面的场景，以提升企业在数据价值变现方面的能力。
架构师需要提供一种能够为组织带来价值的方式对组织数据架构进行设计。这种价值主要通过合适的技术应用、有效运营、项目效率提升以及数据应用能力加强来体现。为了实现该目标，要求组织具有良好的设计和计划以及确保计划能够被执行的能力。为了达到该目的，数据架构师需要定义和维护具体事宜如下：
- 定义组织中数据的当前状态。
- 提供数据和组件的标准业务词汇。
- 确保数据架构和企业战略及业务架构保持一致。
- 描述组织数据战略需求。
- 高阶数据整合概要设计。
- 整合企业数据架构蓝图。
总体数据架构实施包括：
- 使用数据架构构件（主蓝图）来定义数据需求、指导数据整合、管控数据资产，确保数据项目投入与企业战略保持一致。
- 与参与改进业务或IT系统开发的利益相关方合作，学习并影响他们。
- 通过数据架构及通用的数据词汇，搭建企业数据语言。
# 现有架构规范评估
每个组织都保存着现有系统的一系列文档。为了了解当前数据架构，需要识别这些文件，并评估其准确性、完整性和详细程度。如有必要，还需要更新这些文件使其真实反应系统的当前状态。
# 开发线路图
如果一个企业是从零开始开发数据架构，那么一个最佳体系结构将仅仅基于运行该企业所需数据，优先级将由业务战略确定，决策可以不受过去的阻碍。路线图有助于组织权衡并定制夯实的项目计划，使其与业务需求和机会、外部需求、可用资源保持一致。
企业数据架构路线图描述了3-5年的发展路径，考虑到实际情况和技术评估，路线图和业务需求共同将目标架构变成现实。企业数据架构路线图必须与企业架构路线图相整合，企业架构路线图包括：高层次里程碑事件、所需资源、成本评估、业务能力工作流划分。
业务数据驱动路线图可以从最独立的业务开始，在处理想依赖程度较高的业务能力。按照顺序处理每个业务能力，需要遵循整体业务数据生成顺序。
# 管理企业需求
架构不应该受开发时间的限制。利用数据模型及其有关规范描述的组织数据架构必须足够灵活，并能适应未来需求。构建架构层次的数据模型不仅应有企业全局观，而且要有能够让企业内部完全清楚理解的定义。
企业数据架构相关的工作包括：
- 定义范围。保证范围和接口与企业数据模型一致。理解项目对整体企业数据架构的潜在贡献、项目的建模和设计。对项目应该确定项目范围外的利益相关方的依赖性，确定项目共享重要的数据构件，把它们整合到企业逻辑数据模型和指定的存储库中。
- 理解业务需求。获取数据相关的需求，如实体、资源、可用性、质量和痛点，以及评估满足这些需求的业务价值。
- 设计。形成详细的目标规范，包括：数据生命周期的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等。企业逻辑数据模型和企业架构知识库可为企业内可重用数据结构共享提供良好的支撑。同时，审核和使用数据技术标准。
# 实施指南
数据架构包括构件、活动和行为。因此，实施企业数据架构主要包含的工作内容为：
- 建立企业数据架构团队和举办问题讨论会。
- 生成数据架构构件的初始版本。例如。企业数据模型、企业范围数据流和线路图。
- 在开放项目中，形成和建立数据架构的工作方式。
- 提高组织对数据架构工作价值的认识。
一个组织接受并实施数据架构的能力依赖于以下几个方面：
- 对架构方法的接受度（开发架构的友好性）。
- 确认数据属于组织的业务资产，而不仅仅是IT的任务。
- 放弃局部视角，接受企业级数据视角的能力。
- 将架构交付成果整合到项目实施中的能力。
- 规范数据治理的接受程度。
- 立足企业全局，而不仅仅局限于项目交付成果和IT解决问题的能力。