架构治理不是走审批流程：TOGAF 治理机制怎么真正落地

Thu, 18 Jun 2026 21:15:00 +0800

你公司的架构治理，是不是就是开会签字？

每个搞企业架构的人大概都经历过这种场景：一个项目上线前，拉一堆人开个评审会，PPT 放了四十分钟，架构委员会的人点头说"可以"，签个字，散会。至于后面开发团队是不是按评审的方案做的——没人管，也没人查。

❌ 有标准，但没人对着标准逐项检查。 ❌ 评审完就扔，问题没人跟踪闭环。 ❌ 变更靠领导拍脑袋，没有真正的业务动机驱动。

这不叫架构治理，这叫走审批流程。

TOGAF 对架构治理的定义其实很明确：一个主体（治理委员会）、一个目的（找偏差）、一个行为（合规检查）、一个依据（检查单）。四要素缺一不可，缺了任何一个，治理就变成形式主义。

治理六步法：一识、二度、三量、四称、五术、六循环

TOGAF 把治理行为拆成了六个递进的动作，我称之为"治理六步法"：

步骤	名称	做什么
一	识	识别偏差——实施结果和架构设计之间哪里对不上
二	度	筛选偏差——哪些偏差值得管，哪些可以放过
三	量	量化影响——这个偏差会造成多大范围的后果
四	称	权衡利弊——修正的成本 vs 放任的风险
五	术	给出改进建议——不是光说"不行"，要给出可行方案
六	循环	定期复查——治理不是一次性的，是周期性行为

很多公司死在第一步和第六步：从来不主动找偏差，找到了也不回头复查。

举个例子：一个微服务拆分方案评审通过后，开发团队为了赶进度，把两个本该独立的域合并部署了。如果治理专员在"识"这一步就去看部署拓扑图，偏差当场就能抓住。但大多数公司等到上线后出了耦合问题才发现——这时候修正成本已经翻了好几倍。

治理的三条线：前端、中间、后端

架构治理不是只在项目快上线时才介入。按治理行为发生的位置，分三段：

阶段	治理行为	关注点
前端	专题架构设计评审	方案本身是否合理，是否符合企业架构原则
中间	项目需求分析与设计阶段介入	需求拆解有没有偏离架构意图
后端	项目验收交付	交付物是否与架构设计一致

❌ 大多数公司只做后端验收（而且验收也很敷衍）。 ✅ 真正有效的治理是从设计阶段就开始介入，全程跟踪。

前端治理的核心问题是：你的架构方案有没有违反企业级的架构原则？比如明明规定了所有对外接口必须走统一网关，你的方案里是不是又搞了一套自建鉴权？这种问题在设计阶段发现，改一张图的事；到了上线前才发现，就是改一套系统的事。

中间治理容易被忽略，但它恰恰是偏差产生的高发区。需求拆到开发任务的时候，开发团队往往会"简化"架构设计——把异步改成同步、把事件驱动改成 RPC 调用、把共享服务改成独立实现。如果没有人在这个阶段盯着，架构设计就变成了一纸空文。

架构治理专员：这个角色的日常工作是什么？

“架构治理专员"不是挂名头衔，这个角色有五个具体动作：

选定治理对象——哪些系统、哪些项目纳入治理范围
撰写架构契约——把架构约束写成明确的契约条款
与责任者达成契约——跟项目负责人确认并签署
跟踪验证——对象产生时（代码提交、部署上线），对照契约逐项检查
发起变更并给出建议——发现偏差时，不只是报告问题，要提出改进路径

另外，这个角色需要的能力模型叫四通：

一通：业务战略与流程——你得知道公司要往哪走
二通：IT 技术判断——能判断技术选型是否合理
三通：迁移优先级——知道什么先做什么后做
四通：治理流程——熟悉合规检查的方法论

说白了，这个人得既懂业务又懂技术，还得会写契约、会跟踪、会推动。不好找，但这个角色一旦缺位，治理就是空转。

一个常见的误区是把架构治理专员等同于 QA。QA 关注的是功能和缺陷，治理专员关注的是架构意图是否被正确实现。两者的检查对象、检查依据、产出物完全不同。如果你的公司让 QA 兼任架构治理，基本等于没人做治理。

架构评审：三种形式，你是哪一种？

评审会上有三种角色：总体组（组织者）、架构设计师（设计与修改架构）、架构委员会（评审与反馈）。评审的四个步骤是：疑则问、问则议、议则果、果则行——有疑问就提出来，提出来就讨论，讨论完要有结论，结论要落地执行。一个目标：求改进。一个依据：检查单。

但现实中，评审会的质量差异巨大。按形式分三种：

形式	特征	效果
签字型	走流程、签个字、存档	❌ 零价值
问题型	能发现问题，但没人跟进	⚠️ 发现但不闭环
改进型	发现问题、跟踪整改、复查验证	✅ 真正有效

你的评审会是哪种？如果是签字型，建议直接取消，省下的时间让团队多写几行代码。

中后期验证：各层架构到底看什么？

项目做到中后期，治理验证的重点因架构层而异：

架构层	验证重点
业务架构	需求实现是否选择了业务构件化模式
应用架构	是否实现了产品级复用，而非项目级烟囱
数据架构	异构系统的集成策略和数据管理是否到位
技术架构	平台推广情况、技术标准是否落实

这些不是抽象的原则，每一条都可以拆成检查单上的具体条目。比如应用架构验证，你可以直接问：这个模块有没有调用已有的公共服务？还是又自己造了一个轮子？数据架构验证，直接查：跨系统的数据同步用的什么方案？有没有统一的数据治理策略？

架构变更：主动预测 vs 被动救火

架构变更有两个来源：

主动变更：治理过程中预测到的变化，提前规划
被动变更：出了事故之后被迫请求的变更

❌ 多数公司的变更管理 = 领导决策制，没有真正的业务动机分析，出了问题才改。 ✅ 好的治理应该在巡检阶段就能识别出架构腐化的趋势，主动发起变更。

举个实际场景：你发现某个核心服务的响应时间在过去三个月持续上升，虽然还没触发告警阈值，但趋势明显。主动变更的做法是现在就启动优化或重构计划；被动变更的做法是等到某天凌晨被 oncall 电话叫醒，然后紧急 patch。

主动变更的驱动力来自治理过程中的持续观测，被动变更的驱动力来自生产事故。两者的修复成本差一个数量级。

常见反模式与修复方案

反模式	表现	修复方案
有标准无检查	写了一堆规范文档，从没人对着检查	建立检查单机制，每次评审逐条过
变更靠拍脑袋	领导说改就改，没有影响分析	变更前必须做"量"和"称"两步
评审缺专家	评审委员会的人不懂具体技术	引入外部专家或培养内部架构师梯队
信息不对称	项目组懂细节，评审的人只看到表面	评审前做架构走查，不只看 PPT
问题不闭环	评审提了一堆问题，没人跟踪	指定治理专员负责跟踪验证
项目组信息壁垒	项目组内部清楚，外部评审者看不到真相	评审前安排架构走查，深入代码和配置，不只看汇报材料

写在最后

架构治理的本质不是合规检查打勾，而是持续改进。

一识二度三量四称五术六循环——这个框架的核心词是循环。治理不是一次性的动作，是嵌入到项目生命周期里的持续行为。每轮循环都应该比上一轮更高效，因为你在不断积累经验、优化检查单、提升团队能力。

如果你的架构治理目前还停留在"开会签字存档"的阶段，不用急着一口气推翻重来。先做一件事：给每次评审加一张检查单，指定一个人负责跟踪问题整改。从这一步开始，治理就从形式主义变成了真正有用的东西。

检查单不需要一开始就完美。先列出你团队最常犯的五个架构偏差，每次评审对着这五条过一遍。跑几轮之后，你自然知道该往检查单里加什么。治理能力的建设本身也是一个循环——先跑起来，再迭代优化。

架构治理 on 文艺技术笔记