数据架构项目手册

1. 业务驱动与目标

数据架构在业务、应用、技术架构之间组织数据及其关系，目标包括：

• 识别当前和长期的数据存储、处理、共享和消费需求；
• 用主蓝图指导集成、控制复制、管理数据资产并协调投资；
• 建立共同业务语义，使项目实现能追溯到企业数据需求；
• 降低点对点“接口意大利面”、重复数据、不一致和技术僵化；
• 既改善架构质量，也支持新产品、分析、AI 和外部数据机会；
• 通过可演进的过渡架构平衡目标状态、遗留约束、风险、成本和交付速度。

成功不是完成一张图，而是项目反复使用架构工件、减少无控复制与重复建设、提高互操作和交付效率，并能说明架构选择产生的业务价值。

2. 原则与关键概念

• 业务能力驱动： 业务架构定义所需能力、过程、事件和信息；数据架构组织支持它们的数据。
• 整体与分层： 同时考虑企业、领域和项目；概念主题域、逻辑语义与物理实现可纵向追溯。
• 现状—目标—过渡： 目标描述方向，过渡状态管理依赖、风险和临时共存，现状以证据为基准。
• 需求与实现分离： 先表达需要什么和为何需要，再选择平台、模式和产品。
• 共享语义： 共同词汇、定义、主数据、参考数据和模型是互操作的基础。
• 生命周期与血缘： 从创建/获取、存储维护、使用增强到处置，记录来源、移动、转换和责任。
• 有意复制： 复制服务性能和可用性，但必须规定权威来源、同步、延迟、质量和退役。
• 标准化与例外： 原则、蓝图、标准和评审控制长期一致；例外有理由、风险、到期和补救。
• 迭代维护： 架构随战略、能力、技术和证据演进，不能成为一次性文档。

核心架构域及关系：业务架构提出能力/过程/事件与价值需求；数据架构定义数据组织、流向和管理；应用架构规定处理数据的功能；技术架构提供平台、网络、安全和运行环境。

3. Plan / Control / Develop / Operate

Plan

1. 建立数据架构实践：范围、框架、角色、工作方法、工件、工具和与企业架构的接口。
2. 将战略拆成业务能力、信息需求、数据原则、质量/风险目标和外部约束。
3. 评估现有规范、模型、数据流、系统清单和技术路线是否准确、完整和仍被使用。
4. 规划当前、目标、过渡视图和 3–5 年或适当周期路线图；按能力与数据依赖排序。

Control

1. 发布架构原则、模式、接口、复制、位置、生命周期、元数据、安全和质量标准。
2. 在项目立项、方案、模型、采购、发布和退役门检查符合性。
3. 管理架构决策、例外、技术版本/更新、资产复用与淘汰。
4. 与治理和数据管家对齐主题域、实体、术语、所有权和过程监督。

Develop

1. 从业务能力、过程、事件和消费者导出数据需求与概念主题域。
2. 描述当前数据生态：权威源、系统、存储、流向、复制、依赖、质量、风险和成本。
3. 比较目标方案，形成数据组织、交换、处理、存储、消费、元数据和控制视图。
4. 定义过渡状态、迁移/共存/退役路径、项目工作包和架构决定。
5. 为项目提供企业数据要求并审查概念、逻辑、物理模型与架构一致性。

Operate

1. 维护架构仓库、视图、决定、标准和技术生命周期，使其反映生产事实。
2. 监控项目符合、例外、复制、接口增长、资产复用、交付效率和业务满意。
3. 将运行事件、性能/成本、数据质量和变更影响反馈到路线图。
4. 定期复核目标状态和路线；复用、替换、退役或新增工件并记录理由。

4. 上下文与角色

每个主题域至少明确业务数据管家和数据架构责任；业务事件主题应与业务过程监督对齐。

5. 交付物与验收证据

架构任务书

- 业务结果、能力、事件和消费者：
- 架构范围与非范围：
- 当前问题和证据：
- 时间视野与过渡限制：
- 功能/数据需求：
- 质量、服务、安全、隐私、地域、保留、成本要求：
- 已选技术与不可改变约束（含批准来源）：
- 必须做出的架构决定：
- 视图、批准人、阶段门和验收证据：

视图目录

架构决策记录（ADR）

# ADR-<编号>：<决定>
- 状态/日期/决策人：
- 业务和数据背景：
- 驱动、约束与质量属性：
- 候选方案（含维持现状）：
- 比较证据与权衡：
- 决定及理由：
- 影响、风险、补偿与后续：
- 何时重新评估：

目标与过渡路线

符合性记录

快速架构与可复用评估模板

四周快速路径的最小集：第 1 周批准任务书并核实关键现状；第 2 周完成能力—数据、主题域、系统责任和关键流向；第 3 周比较目标/过渡方案并形成关键 ADR；第 4 周批准依赖路线、首个工作包和符合性门。只制作能回答当前决定的视图，未使用的视图写明省略理由与后续触发条件。

对跨境或敏感约束未决项按影响和紧迫度分级，记录决策 owner、升级时限和阻断门。临时例外至少包含最小化字段/记录范围、隔离位置、访问名单、加密/脱敏、禁止下游用途、删除期限、补偿监控、批准人与到期复核；高影响且无充分补偿时不得放行。

架构图的验收必须验证视图之间名称和关系一致、可追溯到需求/证据、被目标受众理解，并能支持一个真实决定；美观不是验收标准。

6. 工具与技术

• 能力—数据矩阵/CRUD： 识别数据产生、使用和依赖，帮助确定权威来源与路线顺序。
• 主题域/企业数据模型： 建立共同语义和高层边界；详细模型交由 modeling-data。
• 数据流与血缘： 结合设计图和生产配置/日志，揭示点对点依赖、复制与跨境。
• 生命周期投影： 对关键数据逐阶段检查存储、处理、保留、质量、安全与责任。
• 场景/质量属性分析： 用峰值、故障、并发、延迟、地域、审计、变更等场景比较架构。
• 适配—差距与权衡矩阵： 将已选技术和候选模式对照需求；记录不适配、补偿、成本和风险接受。
• 依赖网络与过渡规划： 从相对独立的主/参考能力开始，再推进依赖它们的交易、分析和产品能力。
• 图示清晰性： 每图声明目的、范围、时间状态、图例、责任人和版本；同一概念保持一致标识。

建模和资产管理工具用于维护关系与追溯；绘图工具只负责表达。架构仓库的价值取决于更新责任、版本、生产证据和使用流程。

7. 指标、风险与实施

指标组合：

• 符合与采用： 适用项目参与评审率、标准符合率、例外数量/逾期/重复原因；
• 复用与生命周期： 复用、替换、退役、新建资产比例，重复数据集/接口/技术减少；
• 交付效率： 设计/集成交付周期、返工、缺陷、项目成本与可复用工件带来的变化；
• 运行结果： 数据新鲜度、可靠性、质量、互操作、恢复、成本和安全事件趋势；
• 业务价值： 能力上线、决策速度、产品/分析采用和利益相关者满意度。

主要风险：以厂商图代替架构；只描述目标不处理遗留；现状文档不可信；视图互相矛盾；过度中心化造成瓶颈；项目例外长期化；无控复制；架构脱离运行；路线按系统而非能力依赖排序。用来源证据、视图一致性检查、过渡状态、ADR、例外到期和运行反馈控制。

阶段门：任务书/需求获批 → 现状与未知项核实 → 原则/方案/权衡批准 → 目标和过渡视图一致 → 首个工作包验证 → 项目符合与运营反馈。关键跨境、安全、权威源或生命周期要求未决时，不批准物理落地。

8. 依赖与协同

• establishing-data-governance：批准原则、所有权、标准和例外，监督项目符合。
• modeling-data：把主题域和语义细化为概念、逻辑和物理模型，并维持纵向追溯。
• integrating-data：把数据流视图实现为接口、映射、编排、对账与监控。
• operating-data-storage：把技术部署/服务要求实现为数据库、存储、备份、恢复、容量和运行控制。
• managing-metadata：维护架构资产、术语、血缘、所有权、版本和影响分析。
• improving-data-quality：定义适用质量、基线、规则和持续控制。
• securing-data、handling-data-ethically：定义数据位置、用途、访问、保护和高风险约束。
• assessing-data-management-maturity：当路线优先级取决于组织能力时提供证据；不把成熟度模型当目标架构。
• 企业、业务、应用和技术架构：共同解析跨域依赖，避免数据架构在孤立状态优化。