Appearance
Baseline、Target 与 Gap：把愿景变成可执行差距
零售企业画出一张目标图：统一会员中心、商品中心、订单中心、库存平台和履约系统，各系统边界清晰、数据统一。现状材料却只有一份系统清单，写着 POS、商城、WMS、CRM 和财务系统。目标按业务责任描述，现状按应用名称描述，两者无法逐项比较，Gap 最后只能写成“建设五大中心”。
Baseline、Target 和 Gap 不是三个文档章节，而是一套比较模型。只有使用相同范围、对象和粒度描述现状与目标，差距才能落到能力、数据、应用、技术、组织和迁移任务。
Baseline 是可验证的当前状态
Baseline 不等于历史设计文档，也不等于应用资产清单。它描述在架构工作约定的时间点和范围内，企业实际上如何运行。
可靠的 Baseline 需要组合多类证据：
| 证据 | 可以说明什么 | 局限 |
|---|---|---|
| 业务流程和操作手册 | 正式流程、角色和规则 | 可能与实际操作不一致 |
| 应用与接口目录 | 系统、Owner、依赖和生命周期 | 不一定反映真实流量 |
| 数据库与 Schema | 当前存储和约束 | 不能完整表达业务语义 |
| 日志、追踪和指标 | 实际调用、错误和流量 | 只能看到已观测部分 |
| 权限与审计 | 谁实际可以操作什么 | 权限存在不代表被使用 |
| 对账与工单 | 数据差异、人工补偿和异常 | 常常缺少统一分类 |
| 访谈与现场观察 | 隐性流程、例外和绕行 | 需要多方交叉验证 |
如果文档写着商城通过库存服务查询，但调用链显示商城仍直接读取旧库存表，Baseline 应记录实际状态和偏差，而不是复制理想设计。
Target 描述可验证的未来条件
Target 不是“引入微服务、湖仓和云原生”，也不是一张没有度量的目标图。它应描述目标能力和约束成立时，企业能够观察到什么状态。
| 维度 | 弱目标 | 可验证目标 |
|---|---|---|
| 业务 | 实现全渠道 | 客户可以跨渠道查单和售后，门店自提有完整异常流程 |
| 数据 | 统一库存数据 | 库存事实语义、Owner、时效和权威修改方明确 |
| 应用 | 建设库存中心 | 指定渠道预占只经过库存平台，旧写入口无新增记录 |
| 技术 | 提高系统稳定性 | 峰值场景满足 SLO，支付和库存可以按既定 RPO/RTO 恢复 |
| 组织 | 加强治理 | 能力、数据、应用和运行责任有人承担，例外按期退出 |
Target 应允许多个实现方案。目标如果直接绑定某个产品或部署拓扑，就可能把手段误当成结果。
使用相同维度和粒度比较
Baseline 与 Target 必须在相同的抽象层级比较：
| 比较对象 | Baseline | Target | 可识别 Gap |
|---|---|---|---|
| 业务能力 | 渠道独立承诺库存 | 企业级库存承诺 | 统一规则、Owner 和异常流程 |
| 核心事实 | 多套商品标识和库存口径 | 企业 SKU、地点和库存语义 | 映射、清洗、数据责任与质量 |
| 应用责任 | 商城、POS、订单都能锁定库存 | 库存平台成为预占权威方 | 接口、权限、状态和旧逻辑退出 |
| 技术能力 | 批量同步、缺少幂等和对账 | 实时预占、事件传播、可恢复 | Outbox、重放、观测和容量 |
| 组织责任 | 多团队共同修改规则 | 能力和数据 Owner 明确 | 职责、流程、值班和治理 |
如果 Target 细化到接口级，而 Baseline 只到系统级，Gap 会混入大量猜测。可以先在能力和责任层比较，再对高风险差距逐步展开数据、应用和技术细节。
Gap 不是“缺少一个系统”
Gap 描述从现状到目标必须改变、增加、保留或退出的内容。可以分为：
- Missing：目标需要但现状不存在，例如统一库存承诺能力。
- Changed：现有对象需要改变，例如订单状态模型和接口契约。
- Retained：现状仍满足目标，需要明确保留，例如财务核心账务。
- Removed：目标中不再需要，例如商城本地库存锁定逻辑。
- Consolidated：多个对象合并，例如多套商品映射服务。
- Transitional：只在迁移期间存在，例如事件桥接和双轨对账。
“Retained”同样重要。没有明确保留项，项目可能为了目标架构重写本来稳定且不在问题范围内的能力。
写出可执行 Gap
一个 Gap 至少应包含：
yaml
id: GAP-INV-03
domain: data-application
baseline: 商城与 POS 在各自范围内维护库存锁定
target: 已迁移渠道的库存预占只由库存平台裁决
change: 改造调用、迁移锁定状态、收回旧写权限并停用旧任务
depends_on:
- DATA-SKU-MAPPING
- CAP-INVENTORY-COMMITMENT
owner: 交易与库存联合团队
risk: 切换期重复锁定或遗漏释放
exit_criteria:
- 迁移范围 100% 请求进入库存平台
- 连续四周旧入口无新增锁定
- 对账差异低于阈值且均可解释
evidence:
- 调用链流量
- 数据库写入来源
- 对账报告
- 故障演练只有标题“建设库存平台”无法进入依赖排序、验收和治理；上面的 Gap 可以被分配、验证和关闭。
先找重复、冲突和隐含 Gap
不同架构域会识别出看似独立但实际重复的差距：
- 业务架构发现没有库存承诺 Owner。
- 数据架构发现锁定库存没有统一语义。
- 应用架构发现三个系统都能修改锁定。
- 技术架构发现没有并发裁决和重放机制。
- 治理发现旧写入口没有退出规则。
这些不是五个独立项目，而是同一能力差距的不同方面。Gap 合并时应保留跨域关系，形成能够产生业务结果的工作包。
也要识别冲突 Gap。例如业务希望门店断网继续销售，数据目标要求库存平台唯一写入。真正的 Gap 还包括离线额度、凭证同步、冲突裁决和例外治理，而不是简单选择其中一个目标。
差距分析按影响而非数量排序
Gap 数量不能直接代表工作量和优先级。可以从以下方面评估：
| 维度 | 评估问题 |
|---|---|
| 业务价值 | 关闭后改善哪个结果，影响多少客户或交易 |
| 风险降低 | 是否减少合规、资金、数据或运行风险 |
| 基础依赖 | 其他多少变化依赖它，例如企业 SKU 映射 |
| 时间紧迫 | 是否受法规、合同、活动或系统退役日期约束 |
| 实施规模 | 组织、数据、应用和技术改造范围多大 |
| 可逆性 | 失败后能否回退，是否会产生难以恢复的数据状态 |
评分方法可以不同，但假设和依赖必须可见。高业务价值但依赖未满足的 Gap，不能仅凭分数排到最前面。
未知状态也是 Baseline 的一部分
复杂企业不可能在开始时完全掌握现状。可以明确记录：
- 已验证：有多源证据支持。
- 已声明：由 Owner 确认，但尚未用运行数据验证。
- 推测：根据代码、配置或访谈推断。
- 未知：范围存在但缺少可靠信息。
未知项要有验证计划和截止点。把未知隐藏起来，会让路线图看起来确定，风险却在迁移时集中爆发。
Baseline 不需要无限详细
现状分析容易陷入“先把企业全部盘清楚”。可以按决策需要控制深度：
- 先定义架构工作范围和目标结果。
- 只收集影响这些结果的能力、数据、应用和技术现状。
- 对高风险和高依赖区域增加证据深度。
- 对准备保留且稳定的区域记录接口和约束即可。
- 把无法在当前时间解决的未知登记为风险。
Baseline 的目标是支撑决策，不是完成企业百科全书。
从 Gap 到工作包
工作包围绕业务结果组合差距，而不是围绕某一层技术对象：
| 工作包 | 组合的 Gap | 可验证结果 |
|---|---|---|
| 身份与语义基础 | 商品映射、客户标识、地点编码、Owner | 跨系统事实可以准确关联 |
| 库存可视 | 来源采集、时效、差异分类、读模型 | 运营能够解释库存差异 |
| 库存承诺 | 规则、权威写入、并发裁决、补偿 | 新渠道不再独立实现锁定 |
| 订单状态统一 | 企业订单 ID、状态机、历史查询 | 客户和客服跨渠道查单 |
| 遗留退出 | 旧入口、权限、任务、归档 | 双轨成本和重复责任下降 |
一个 Gap 可以被多个工作包分阶段处理，但必须明确哪个工作包最终关闭它，避免长期处于“部分完成”。
Gap 的关闭必须有证据
代码合并或服务上线不是 Gap 关闭条件。不同 Gap 需要不同证据：
- 能力 Gap：业务流程可执行，Owner 和指标生效。
- 数据 Gap：语义、责任、质量和对账达到目标。
- 应用 Gap：目标调用和写入关系成立，旧入口退出。
- 技术 Gap：压测、故障和恢复场景通过。
- 组织 Gap：角色、值班、预算和治理机制实际运转。
如果目标是“旧系统停止修改库存”，证据必须包含旧系统写入来源归零，而不是新库存接口已经上线。
最小交付物
- 架构工作范围、时间点和证据可信度。
- 使用相同对象和粒度描述的 Baseline 与 Target。
- Missing、Changed、Retained、Removed 和 Transitional 分类。
- Gap 的 Owner、依赖、风险、退出条件和证据。
- 跨域重复与冲突 Gap 的合并关系。
- Gap 到工作包、过渡架构和收益指标的追踪。
常见失效方式
- Baseline 抄旧设计文档，没有验证实际运行状态。
- Target 直接写产品和系统名称，没有可验证条件。
- 现状与目标使用不同粒度，Gap 无法比较。
- 只记录新增内容，不记录保留、删除和迁移临时项。
- Gap 被拆成技术任务，业务、数据和组织变化遗漏。
- 以服务上线关闭 Gap，没有验证旧责任退出和业务结果。
- 追求完整盘点，耗尽时间却没有支持关键决策。
能力验证
- 能用运行证据而不是历史文档建立 Baseline。
- 能把 Target 写成可验证的业务、数据、应用和技术条件。
- 能在相同粒度上比较现状与目标。
- 能写出包含 Owner、依赖、风险和退出证据的 Gap。
- 能合并跨域 Gap，并识别目标之间的冲突。
- 能把 Gap 连接到工作包、过渡架构和运行指标。
总结
Baseline、Target 和 Gap 的核心是可比较性。Baseline 说明企业实际如何运行，Target 说明未来哪些条件必须成立，Gap 则把两者之间的变化写成能够被负责、排序和验证的对象。差距分析做得好，目标架构才能进入迁移规划；做得差，路线图只会变成一组预先想好的项目名称。