# 数据架构项目手册

## 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. 交付物与验收证据

### 架构任务书

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

### 视图目录

| 视图 | 回答的问题 | 元素/关系 | 主要受众 | 来源证据 | 负责人 | 验收 |
|---|---|---|---|---|---|---|
| 能力—数据 | 哪些能力产生/使用哪些数据，依赖顺序是什么 | 能力、事件、主题域、CRUD/流向 | 业务/企业架构 | 能力图、过程、访谈 | | |
| 概念主题域 | 企业讨论哪些数据及边界 | 主题域、核心实体和高层关系 | 业务/治理/项目 | 术语、模型、数据清单 | | |
| 数据流/血缘 | 数据从哪里来、如何变、到哪里去 | 源、接口、转换、存储、消费 | 架构/集成/风险 | 配置、作业、日志 | | |
| 系统/应用 | 哪个系统承担何种数据责任 | 权威源、记录系统、消费、复制 | 应用/项目 | 系统清单、契约 | | |
| 技术部署 | 数据放在哪里、如何处理和保护 | 平台、区域、网络、服务、环境 | 技术/安全/运行 | 云/基础设施配置 | | |
| 生命周期/控制 | 各阶段的所有权、质量、安全和处置 | 阶段、角色、控制、证据 | 治理/审计/运行 | 政策、控制、日志 | | |

### 架构决策记录（ADR）

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

### 目标与过渡路线

| 能力/数据依赖 | 现状证据 | 目标状态 | 过渡状态/共存 | 工作包 | 前置依赖 | 复用/替换/退役 | 出口证据 |
|---|---|---|---|---|---|---|---|

### 符合性记录

| 项目/变更 | 适用原则/标准 | 证据 | 符合/例外 | 风险与补偿 | 批准人 | 到期/复核 |
|---|---|---|---|---|---|---|

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

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

| 场景 | 峰值/规模 | 延迟/新鲜度 | 故障/恢复 | 地域/敏感性 | 审计/血缘 | 预期变化 | 验证证据 |
|---|---|---|---|---|---|---|---|

| 产品/能力 | 数据类型/规模 | 批/流延迟 | 地域/安全适配 | RTO/RPO | 成本边界 | 锁定/退出 | 运行责任 | 结论/差距 |
|---|---|---|---|---|---|---|---|---|

| 指标 | 基线 | 目标/阈值 | 数据源 | 频率 | Owner | 升级条件 |
|---|---|---|---|---|---|---|

对跨境或敏感约束未决项按影响和紧迫度分级，记录决策 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`：当路线优先级取决于组织能力时提供证据；不把成熟度模型当目标架构。
- 企业、业务、应用和技术架构：共同解析跨域依赖，避免数据架构在孤立状态优化。
