架构治理：让系统别白建，让决策别白做
本系列为虚构教学案例，全文完。上一篇：《36 个月路线图：不是项目排期表，是决策的时间化表达》
这是《宏远智造的出海架构史》最后一篇。前四篇是"打仗"------能力地图、病灶解剖、目标架构、路线图，每篇都有明确的敌人和胜利。治理篇最难写，因为它要处理的是一个没有敌人的战场：系统建完之后，如何防止一切慢慢变坏。
先回收上一篇的思考题：M12，老板看完 OMS 的漂亮数据，要把 BI 数据平台提前到 M13 启动。你接不接？------这道题没有标准答案，但有标准动作。我们用这道题开场，看治理是怎么运转的。
一、治理的第一课：不接需求，接的是"决策流程"
那位架构师的正确回应不是"接"也不是"不接"，而是启动一次影响分析 ：BI 平台提前 6 个月，意味着从 ERP 切换团队抽 3 个人、TD-003 桥接债的偿还延期、M15 切换窗口的风险上升。分析结果写成 ADR-003：驳回 BI 提前，给出替代方案------现有 OMS 数据上做三张只读报表（两周工作量），满足老板"看数据"的真实诉求，不动平台建设计划。
注意这个处理的结构：需求本身被认真对待，但需求的实现路径进入了决策流程。 老板得到了数据（业务诉求满足），路线图保住了（架构约束守住），替代方案的成本被记录（两周 vs 三个月）。这就是治理和所有"审批流"的区别------治理不是说不，治理是让每一个"是"和"不"都留下推理的痕迹。
二、治理三件套：评审会、技术雷达、ADR 常态化
1. 架构评审会（每月一次，45 分钟）
宏远评审会的准入清单只有四条，每条都对着一个历史病灶：
| 准入问题 | 对应病灶 |
|---|---|
| 新系统进来，是否走了 iPaaS 而不是点对点？ | 11 个接口 7 个没人认领 |
| 新系统读写的核心实体，Owner 是谁？ | 一物多码率 23% |
| 客户数据进哪个系统，谁在管？ | GDPR 裸奔 |
| 有没有现成的能力可以复用，而不是新建？ | 影子 IT |
第一次评审会就逮到了大鱼：市场部要上一个自购的邮件营销 SaaS------历史重演。这次没有被否决，而是被收编：走 iPaaS 接入，客户数据字段对齐 MDM，评审通过。影子 IT 的解药从来不是禁止，而是让"绕过"变成"没有必要"。
2. 技术雷达（每年两轮，四个环）
借型 ThoughtWorks 雷达，四个环：采用 / 试验 / 评估 / 暂缓。宏远第一轮雷达的三个真实决策：
- 试验：越南工单系统的"扫码报工"轻方案（一个二维码 + 手机表单，替代完整 MES）------先小步验证工人使用率，再决定要不要上重系统。病灶四的过渡方案就是这么落地的。
- 评估：低代码平台------业务侧呼声很高，但 iPaaS 刚立规矩，低代码的"绕开 IT 生产力"属性和治理目标冲突，进评估环继续观察。
- 暂缓：微服务改造------有人提议把 OMS 拆了，被一句问倒："你现在有几个开发人员需要独立发布？"------架构决策的敌人经常是过度设计，雷达的"暂缓"环就是给过度设计一个体面的坟场。
3. ADR 常态化：让决策可以被打脸
第 4 篇说过，ADR 的副作用是"会被打脸"。M15 复盘 ADR-001：桥接债 TD-003 如期还清，OMS 错单率 0.3% 达标------但 ADR-002 有一个判断错了 ：当时认定"客户主数据随 ERP 切换一并清洗"，结果 ERP 切换窗口比预期紧张，客户主数据清洗被迫延后一个月，连带 CRM 延期。这个偏差被如实记录进 ADR-002 的补充条款，教训沉淀为一条新评审规则： "依赖别人里程碑的清洗任务，自己必须有 Plan B。"
敢写"我们错了"的治理体系，才有资格说"我们学到了"。
三、治理的日常节奏表（可以直接抄）
| 机制 | 频率 | 参与人 | 产出物 |
|---|---|---|---|
| 架构评审会 | 每月 45 分钟 | 架构组 + 需求方 | 准入决定 + ADR 编号 |
| 技术雷达 | 每年两轮 | 架构组 + 技术骨干 | 四环清单 + 暂缓项备忘 |
| ADR 评审 | 随事随记，季度集中复盘 | 决策相关人 | 新 ADR + 旧 ADR 状态更新 |
| 数据 Owner 例会 | 每月 30 分钟 | 各实体 Owner | 口径变更记录 |
总成本：架构组每月约 3 小时。买的是：所有系统有人认领、所有决策可以追溯、所有技术债有格子。这个性价比表，建议出现在你下次争取治理预算的汇报里。
四、36 个月后，回扣第 1 篇
系列结尾，把第 1 篇那颗埋了六篇的雷拆了。
2025 年 10 月的经营会上，老板问"越南到底赚不赚钱"，财务答不出来。2028 年的同一张会议桌上：越南工厂的单台成本实时可查，双法人一套账月结 5 天，全公司一个 GMV------老板那个问题的答案，就是这张架构图存在过的证据。
但别误会是童话结局。36 个月后的宏远面临新的威胁：组织壮大后的流程官僚化、第二个海外基地的复制难题、以及一个永恒的问题------新系统在建成后第 4 年开始的第二次缓慢腐烂 。架构转型没有终点，只有下一轮的诊断。这就是为什么治理是收官篇而不是附录：打仗的能力让你赢得转型，治理的能力让你不用每三年重来一次。
架构师思考问题（系列最后一问） ：回看你自己经历过的项目，有没有一个系统、一份文档、一个决策，是"没人认领、没人敢动"的？那就是你经历过的治理真空。试着用今天的四问准入清单问它一遍------新系统走 iPaaS 了吗？实体有 Owner 吗？客户数据谁在管？有没有重复建设？把你的诊断写在评论区。系列完结，但案例留下的方法属于你们每一个人。