你公司的架构治理，是不是就是开会签字？
每个搞企业架构的人大概都经历过这种场景：一个项目上线前，拉一堆人开个评审会，PPT 放了四十分钟，架构委员会的人点头说"可以"，签个字，散会。至于后面开发团队是不是按评审的方案做的——没人管，也没人查。
❌ 有标准，但没人对着标准逐项检查。 ❌ 评审完就扔，问题没人跟踪闭环。 ❌ 变更靠领导拍脑袋，没有真正的业务动机驱动。
这不叫架构治理，这叫走审批流程。
TOGAF 对架构治理的定义其实很明确：一个主体（治理委员会）、一个目的（找偏差）、一个行为（合规检查）、一个依据（检查单）。四要素缺一不可，缺了任何一个，治理就变成形式主义。
治理六步法：一识、二度、三量、四称、五术、六循环
TOGAF 把治理行为拆成了六个递进的动作，我称之为"治理六步法"：
| 步骤 | 名称 | 做什么 |
|---|---|---|
| 一 | 识 | 识别偏差——实施结果和架构设计之间哪里对不上 |
| 二 | 度 | 筛选偏差——哪些偏差值得管，哪些可以放过 |
| 三 | 量 | 量化影响——这个偏差会造成多大范围的后果 |
| 四 | 称 | 权衡利弊——修正的成本 vs 放任的风险 |
| 五 | 术 | 给出改进建议——不是光说"不行"，要给出可行方案 |
| 六 | 循环 | 定期复查——治理不是一次性的，是周期性行为 |
很多公司死在第一步和第六步：从来不主动找偏差，找到了也不回头复查。
举个例子：一个微服务拆分方案评审通过后，开发团队为了赶进度，把两个本该独立的域合并部署了。如果治理专员在"识"这一步就去看部署拓扑图，偏差当场就能抓住。但大多数公司等到上线后出了耦合问题才发现——这时候修正成本已经翻了好几倍。
治理的三条线：前端、中间、后端
架构治理不是只在项目快上线时才介入。按治理行为发生的位置，分三段：
| 阶段 | 治理行为 | 关注点 |
|---|---|---|
| 前端 | 专题架构设计评审 | 方案本身是否合理，是否符合企业架构原则 |
| 中间 | 项目需求分析与设计阶段介入 | 需求拆解有没有偏离架构意图 |
| 后端 | 项目验收交付 | 交付物是否与架构设计一致 |
❌ 大多数公司只做后端验收（而且验收也很敷衍）。 ✅ 真正有效的治理是从设计阶段就开始介入，全程跟踪。
前端治理的核心问题是：你的架构方案有没有违反企业级的架构原则？比如明明规定了所有对外接口必须走统一网关，你的方案里是不是又搞了一套自建鉴权？这种问题在设计阶段发现，改一张图的事；到了上线前才发现，就是改一套系统的事。
中间治理容易被忽略，但它恰恰是偏差产生的高发区。需求拆到开发任务的时候，开发团队往往会"简化"架构设计——把异步改成同步、把事件驱动改成 RPC 调用、把共享服务改成独立实现。如果没有人在这个阶段盯着，架构设计就变成了一纸空文。
架构治理专员：这个角色的日常工作是什么？
“架构治理专员"不是挂名头衔，这个角色有五个具体动作：
- 选定治理对象——哪些系统、哪些项目纳入治理范围
- 撰写架构契约——把架构约束写成明确的契约条款
- 与责任者达成契约——跟项目负责人确认并签署
- 跟踪验证——对象产生时（代码提交、部署上线），对照契约逐项检查
- 发起变更并给出建议——发现偏差时，不只是报告问题，要提出改进路径
另外，这个角色需要的能力模型叫四通：
- 一通：业务战略与流程——你得知道公司要往哪走
- 二通：IT 技术判断——能判断技术选型是否合理
- 三通：迁移优先级——知道什么先做什么后做
- 四通：治理流程——熟悉合规检查的方法论
说白了，这个人得既懂业务又懂技术，还得会写契约、会跟踪、会推动。不好找，但这个角色一旦缺位，治理就是空转。
一个常见的误区是把架构治理专员等同于 QA。QA 关注的是功能和缺陷，治理专员关注的是架构意图是否被正确实现。两者的检查对象、检查依据、产出物完全不同。如果你的公司让 QA 兼任架构治理，基本等于没人做治理。
架构评审：三种形式，你是哪一种？
评审会上有三种角色：总体组（组织者）、架构设计师（设计与修改架构）、架构委员会（评审与反馈）。评审的四个步骤是：疑则问、问则议、议则果、果则行——有疑问就提出来，提出来就讨论，讨论完要有结论，结论要落地执行。一个目标：求改进。一个依据：检查单。
但现实中，评审会的质量差异巨大。按形式分三种：
| 形式 | 特征 | 效果 |
|---|---|---|
| 签字型 | 走流程、签个字、存档 | ❌ 零价值 |
| 问题型 | 能发现问题，但没人跟进 | ⚠️ 发现但不闭环 |
| 改进型 | 发现问题、跟踪整改、复查验证 | ✅ 真正有效 |
你的评审会是哪种？如果是签字型，建议直接取消，省下的时间让团队多写几行代码。
中后期验证：各层架构到底看什么？
项目做到中后期，治理验证的重点因架构层而异：
| 架构层 | 验证重点 |
|---|---|
| 业务架构 | 需求实现是否选择了业务构件化模式 |
| 应用架构 | 是否实现了产品级复用，而非项目级烟囱 |
| 数据架构 | 异构系统的集成策略和数据管理是否到位 |
| 技术架构 | 平台推广情况、技术标准是否落实 |
这些不是抽象的原则，每一条都可以拆成检查单上的具体条目。比如应用架构验证，你可以直接问：这个模块有没有调用已有的公共服务？还是又自己造了一个轮子？数据架构验证，直接查：跨系统的数据同步用的什么方案？有没有统一的数据治理策略？
架构变更：主动预测 vs 被动救火
架构变更有两个来源：
- 主动变更：治理过程中预测到的变化，提前规划
- 被动变更：出了事故之后被迫请求的变更
❌ 多数公司的变更管理 = 领导决策制，没有真正的业务动机分析，出了问题才改。 ✅ 好的治理应该在巡检阶段就能识别出架构腐化的趋势，主动发起变更。
举个实际场景：你发现某个核心服务的响应时间在过去三个月持续上升，虽然还没触发告警阈值，但趋势明显。主动变更的做法是现在就启动优化或重构计划；被动变更的做法是等到某天凌晨被 oncall 电话叫醒，然后紧急 patch。
主动变更的驱动力来自治理过程中的持续观测，被动变更的驱动力来自生产事故。两者的修复成本差一个数量级。
常见反模式与修复方案
| 反模式 | 表现 | 修复方案 |
|---|---|---|
| 有标准无检查 | 写了一堆规范文档，从没人对着检查 | 建立检查单机制，每次评审逐条过 |
| 变更靠拍脑袋 | 领导说改就改，没有影响分析 | 变更前必须做"量"和"称"两步 |
| 评审缺专家 | 评审委员会的人不懂具体技术 | 引入外部专家或培养内部架构师梯队 |
| 信息不对称 | 项目组懂细节，评审的人只看到表面 | 评审前做架构走查，不只看 PPT |
| 问题不闭环 | 评审提了一堆问题，没人跟踪 | 指定治理专员负责跟踪验证 |
| 项目组信息壁垒 | 项目组内部清楚，外部评审者看不到真相 | 评审前安排架构走查，深入代码和配置，不只看汇报材料 |
写在最后
架构治理的本质不是合规检查打勾，而是持续改进。
一识二度三量四称五术六循环——这个框架的核心词是循环。治理不是一次性的动作，是嵌入到项目生命周期里的持续行为。每轮循环都应该比上一轮更高效，因为你在不断积累经验、优化检查单、提升团队能力。
如果你的架构治理目前还停留在"开会签字存档"的阶段，不用急着一口气推翻重来。先做一件事：给每次评审加一张检查单，指定一个人负责跟踪问题整改。从这一步开始，治理就从形式主义变成了真正有用的东西。
检查单不需要一开始就完美。先列出你团队最常犯的五个架构偏差，每次评审对着这五条过一遍。跑几轮之后，你自然知道该往检查单里加什么。治理能力的建设本身也是一个循环——先跑起来，再迭代优化。