目标应用架构怎么画，以及一份真实格式的 ADR：为什么 OMS 先于 ERP
本系列为虚构教学案例。上一篇：《解剖一家公司的烂 IT：四个病灶，没有一个是技术问题》
第 3 篇把宏远的四个病灶切完了。这一篇给手术方案画一张总图------目标应用架构，然后把它背后最核心的一次取舍写成一份完整的 ADR（Architecture Decision Record，架构决策记录） 。这篇是全套系列的技术重心，建议收藏慢读。
一、先纠正一个画图的姿势
我见过的大多数"应用架构图"，本质是系统清单的花式排版：方框写上系统名，箭头连起来，看上去信息丰富，实际上什么都没决策。一张合格的应用架构图必须能回答三个问题：
- 分层：每层解决哪一类问题？层与层之间允许怎么说话？
- 取舍：同样的能力为什么用 A 方案不用 B 方案？
- 时序：先建什么后建什么，依据是什么？
带着这三问看宏远的目标架构。
二、宏远的目标应用地图（文字版）
从外到内六层，每层一句话说清它的职责：
| 层 | 系统 | 职责 | 关键约束 |
|---|---|---|---|
| 渠道触达层 | Shopify 独立站、Amazon、国内电商、线下 | 获客与交易发生地 | 不承载内部逻辑，全部对外 |
| 履约中台 | OMS 订单中台 | 全渠道订单归集、路由、状态回传 | 渠道的脏不进来，内部的不出去乱 |
| 商品与客户中台 | PIM 商品主数据、CRM | 一物一码的唯一真相源、客户 360° | 谁不产生主数据，谁只读 |
| 核心交易层 | 多组织多币种 ERP 、海外仓/工厂 WMS | 核算与执行的系统真相 | 双法人双账套，多币种原生 |
| 数据层 | MDM 、BI | 口径的统一与呈现 | MDM 是所有系统的前置 |
| 横向底座 | iPaaS 集成平台、IAM 统一身份 | 系统之间的语言、人的权限 | 禁新增点对点接口 |
这张图里藏着三个值得说的设计决策，我逐个展开，其中第一个写成完整 ADR。
三、ADR-001：订单履约先行建设 OMS，而非先替换 ERP
markdown
# ADR-001：先建 OMS 订单中台，ERP 切换推迟到 Phase 2
状态：已接受（2025-11）
决策人：架构组（虚线汇报至 CFO 与供应链 VP）
## 背景
2025 年 6 月 DTC 上线后，日均订单从约 40 单（OEM 大单）
增至 1,200 单（DTC 小单），Excel 导单错单率 1.8%，
库存状态延迟约 24 小时，已引发 Amazon 超卖与平台绩效告警。
越南工厂产能处于爬坡期，规划承接 30% 总量。
同时，单组织 U8+ 无法支撑双法人核算，多组织多币种 ERP
切换被财务评估为 12--15 个月项目。
## 决策
Phase 1（0--6 月）先行建设 OMS 订单中台，
多币种 ERP 切换推迟至 Phase 2。
## 备选方案
方案 B：先切 ERP。
能解决核算问题，但订单问题是每天都在流血的大出血：
按方案 B 的排期，OMS 上线要到第 18 个月，
意味着 18 个月的 1.8% 错单率 + 超卖罚分，Amazon 账号
权重可能撑不到那天。
方案 C：各渠道后台直接对接 U8+。
省去 OMS。但每新增一个渠道就要重写一次集成，
渠道侧接口一变更就要返工------这正是宏远历史上
接口无人认领、无人敢动的原因，此方案会把它制度化。
## 后果
正面：
- 错单率目标降至 0.3% 以下；渠道接入与 ERP 解耦，
新渠道接入周期从"月"降到"周"
- OMS 沉淀订单全链路数据，为 Phase 3 数据平台供料
负面（如实记录）：
- 未来 12--15 个月，OMS 与旧 U8+ 之间需建桥接接口
（已登记技术债 TD-003，责任人到人）
- 过渡期库存仍靠对账弥合，超卖风险降级而非消除
- 双系统集成期间，口径问题需 MDM 与 ADR-002 兜底
## 关联
ADR-002（MDM 与商品主数据先行）是本决策的前置依赖；
路线图第 5 篇 Phase 1/Phase 2 边界由此划定。注意几个细节，这些才是 ADR 的精髓：后果一节必须写负面------不敢记录代价的决策记录等于没写；"双方案被否"要写清被否的理由而不是只写名字；技术债要登记编号和责任人。面试时如果让你"讲一次你做的技术决策"，能按这个结构讲，就已经赢了一半。
四、ADR-002（摘要版）：MDM 是所有系统的前置条件
背景不再重复（第 3 篇的病灶三）。决策一句话：Phase 1 第一个开工的不是任何业务系统，而是 MDM + 商品主数据（PIM）。
被否的关键方案是"MDM 跟着新 ERP 一起上"------这看起来省事，实际意味着 OMS、WMS 先吃一年脏数据，而它们输出的订单和库存又会污染未来的 ERP。主数据是河流上游，上游脏，下游每个系统都是净水器------净水器会堵，河不会自己变清。
这条 ADR 还有一个行政后果：主数据的"数据 Owner"制度在宏远第一次被写进流程------每个核心实体（商品、客户、供应商）有且只有一个部门对口径负责。这是组织动作，不是技术动作，但它往往比系统更难落地。
五、图上另外三个"为什么"
为什么渠道层不留任何内部逻辑？ 上一篇说过，业务曾绕开 IT 自购 SaaS（影子 IT）。目标架构给渠道层的定位是"纯粹的对客触点"------它只调 OMS 的 API，不直接碰 ERP。规则简单，才守得住。
为什么是 iPaaS 而不是继续点对点？ 宏远历史上有 11 个接口，7 个没人认领、没人敢改。点对点集成的死亡率不是技术问题，是组织问题：没有平台，就没有"接口的户口"。iPaaS 的本质是给集成发身份证。
CRM 为什么排在 Phase 2 而不是更晚？ DTC 的复购和私域运营 2026 年才成为主要矛盾，但它依赖客户主数据------又在 MDM 后面。顺序链：MDM → OMS → CRM，一环扣一环，路线图会把这个链条时间化。
六、这张图还没画完
细心的你可能发现了：目标架构图画了系统，却没画数据怎么流、没画 IAM 的权限模型、没画合规水位线。这是刻意的------应用架构一张图画全会变成墙纸。剩下的部分会在第 5 篇（路线图：这些系统按什么顺序落地）和第 6 篇（治理：画完的图怎么不跑偏）里逐块补齐。
架构师思考问题：ADR-001 里我否掉了"先切 ERP"，理由是"大出血等不了大手术"。但如果换一个前提------Amazon 账号没有被罚风险、错单率只有 0.3%------这个决策还成立吗？把你的推演写在评论区：同一个架构决策，换一组约束，结论会不会翻转？会翻转的决策和不会翻转的决策，哪一个更能体现架构师的水平？