数据架构

架构是对组件要素有组织的设计，目的是优化系统的功能、性能、可行性、成本和体验。数据架构关注组织的数据结构、数据流、数据标准与管控策略，是企业架构的一部分。它的核心目标有两个：有效管理数据，以及有效管理存储和使用数据的系统。

• 数据架构的五项职责：利用技术优势、把业务需求转为数据需求、管理复杂数据、保持业务与 IT 一致、支撑转型
• 主要成果：数据存储与处理需求、满足当前与长期需求的结构和规划
• 架构构件本身是重要元数据，应纳入企业级元数据仓库管理
• 物理数据模型是数据建模的产物，不是数据架构的产物

Zachman 框架是描述企业架构的本体，用 6×6 矩阵组织模型。列是六类问询：是什么、怎么做、在哪里、谁、什么时间、为什么；行是六种视角：高管（业务背景）、业务管理（业务概念）、架构师（业务逻辑）、工程师（业务实体）、技术人员（组件程序集）、用户（操作实例）。矩阵只说明「应该存在哪些模型」，不规定如何建模。

• 数据架构师要在不同抽象层级之间保持可追溯的映射
• 同一实体可以出现在多个主题域模型中，但归属应唯一，跨域通过关系关联
• 选择框架要匹配组织类型与沟通需要，政府、金融等行业常有专用参考框架

企业数据架构由两大部分组成：企业数据模型和企业数据流设计。企业数据模型是整体、企业级、独立于具体实施的概念或逻辑模型，提供通用一致的数据视图；数据流设计描述数据在业务流程、存储位置、角色和技术组件之间的流动。两者都要覆盖当前状态、目标状态和过渡状态。

• 数据流映射应记录：业务流程、存储位置、网段、业务角色、局部差异
• 数据流可以用矩阵或数据流图表达；矩阵擅长呈现多对多的创建与使用关系
• 端到端数据流就是数据血缘：起源、存储、使用、转换，以及在某一点上的状态
• 企业数据模型要由利益相关方评审，才能一致有效地代表企业

架构工作有两条路线：面向质量，持续改进现有架构、控制复杂度；面向创新，支持业务转型和新技术试验。前者需要长期治理与标准化，后者需要与产品经理、业务设计者紧密协作。项目层面的架构活动通常包括定义范围、理解业务需求、设计目标规范、实施四步。

• 瀑布、迭代、敏捷三种交付方式，架构介入的节奏不同，但都不能缺席
• 敏捷项目也要在早期建立整体数据设计，否则技术债会以数据债的形式累积
• DevOps 需要架构师与开发人员共享标准与工具链，而不是各自维护一套模型

1. 01定义范围：对齐企业数据模型，识别接口、依赖、可复用构件与下游影响
2. 02理解业务需求：收集实体、可用性、质量要求和痛点，评估业务价值
3. 03设计：形成目标规范，包含业务规则、验证、时序、扩展性与标准模型
4. 04实施：按购买、重用、构建三种路径落地，并记录模型与规则的差异
5. 05评审与反馈：把项目成果回流到企业模型与架构知识库

数据架构治理包括项目监督、架构设计与生命周期管理、标准制定、构件创建。它与数据治理组织必须保持一致：理想情况下，架构师与数据管理专员按主题域成对协作，流程监督与业务事件主题域对齐。

• 数据复制是常见且合理的性能手段，但必须有复制控制，明确一致性与权威源
• 架构标准要写成原则、流程、指南和蓝图，而不是只有一本文档
• 架构路线图通常覆盖 3～5 年，并与企业架构、业务能力路线图整合