TOGAF 架构成熟度模型精读：用标准化评估框架衡量企业架构演进水平
很多企业做架构管理，做了好几年，却始终说不清自己"做到了什么水平"。
有人拿通过了几次评审来衡量，有人拿画了多少张图来证明，还有人拿采购了什么工具来标榜。这些都是表面指标，跟架构能力的真实成熟度没有直接关系。
真正的问题在于：缺少一个标准化的评估框架，把"架构做得好不好"从主观判断变成可量化、可比较、可改进的体系。
TOGAF 的 Architecture Capability Framework 正是为解决这个问题而设计的。它提供了一套从 Level 0 到 Level 5 的成熟度模型，覆盖了治理、流程、工具、人员、绩效五大维度，让企业能够系统性地评估自身架构能力的现状，并找到改进路径。
成熟度模型：从混沌到优化的五级演进
TOGAF 借鉴了 CMMI 的能力成熟度思想，将企业架构能力划分为六个递进级别。每一级都建立在前一级的基础之上，不可跳跃。
Level 0：未建立（Initial / Absent）
企业没有正式的企业架构职能。架构决策完全依赖个人经验，没有文档、没有流程、没有治理。
典型特征：
- 项目各自为战，技术选型全凭团队偏好
- 重复建设严重，同一个功能在不同系统中实现了三四次
- 没有人能回答"我们的系统全景是什么"
Level 1：初步建立（Initial / Ad-hoc）
开始有零散的架构活动，但缺乏制度化。偶尔会有人画架构图，偶尔会做技术评审，但全靠个人推动，没有组织保障。
典型特征：
- 有少数架构师角色，但职责模糊
- 架构文档存在，但散落在各处，没有统一管理
- 架构决策没有记录，事后无法追溯
Level 2：可重复（Repeatable / Managed）
架构流程开始制度化。关键的架构活动有了明确的步骤和交付物，能够在不同项目中重复执行。
典型特征：
- 建立了架构评审流程，关键项目必须经过评审
- 有了统一的架构文档模板和存储库
- 开始制定架构原则，并在项目中推广
Level 3：已定义（Defined）
架构管理体系全面建立。流程、角色、工具、交付物都有明确定义，形成了组织级的标准实践。
典型特征：
- 架构治理委员会正式运作，有明确的决策权限
- 架构开发方法（如 ADM）在组织内全面推行
- 架构仓库结构化运作，资产可复用
Level 4：量化管理（Quantitatively Managed）
架构活动有了可量化的度量指标。不仅"做了"，还能说清楚"做得怎么样"，用数据驱动改进。
典型特征：
- 建立了架构 KPI 体系，定期度量和报告
- 能够量化架构对业务价值的贡献
- 架构决策有数据支撑，不再是拍脑袋
Level 5：持续优化（Optimizing）
架构能力进入自我进化阶段。基于度量数据和反馈，持续优化架构流程、工具和方法。
典型特征：
- 架构改进成为组织文化的组成部分
- 能够主动识别架构瓶颈并提前优化
- 架构创新成为业务创新的驱动力
有句话说得好：成熟度不是终点，而是旅程。 Level 5 不代表完美，而是代表你有了持续变好的能力。
评估维度：五大支柱撑起架构能力
TOGAF 的 Architecture Capability Framework 将架构能力分解为五个核心维度，每个维度都有从 Level 0 到 Level 5 的成熟度描述。
1. 架构治理（Governance）
架构治理决定了"谁来决策、如何决策、决策如何执行"。
| 级别 | 治理表现 |
|---|---|
| L0 | 无治理，决策随意 |
| L1 | 少数人非正式决策 |
| L2 | 有评审流程，但执行不一致 |
| L3 | 治理委员会正式运作，决策透明 |
| L4 | 治理效果可度量，偏差可追踪 |
| L5 | 治理流程持续优化，自适应调整 |
2. 架构流程（Process）
架构流程定义了"怎么做架构"——从需求分析到架构设计、评审、实施、运维的全生命周期。
关键流程包括：
- 架构开发流程：如何从业务需求推导出目标架构
- 架构评审流程：如何确保架构方案的合理性
- 合规检查流程：如何确保项目遵循架构标准
- 变更管理流程：如何管理架构的演进
3. 工具与技术（Tools & Technology）
工具是架构能力的"乘法器"。没有工具支撑的架构管理，效率极低且难以持续。
工具成熟度的关键问题：
- 有没有统一的架构建模工具？
- 架构资产有没有集中管理的仓库？
- 工具之间能不能互通（比如建模工具和配置管理工具）？
- 工具的使用率和覆盖率如何？
某架构师曾吐槽：“我们用 Excel 管架构，用 PPT 做评审，用邮件发通知，然后问为什么架构管理推不动。” 这话说到了痛处。
4. 人员与能力（People & Competency）
架构能力的核心载体是人。这个维度评估的是架构团队的专业水平、组织架构的支撑力度。
评估要点：
- 架构师角色是否有明确的技能要求和认证体系？
- 是否有架构培训中心或知识社区？
- 架构师在组织中的汇报关系和影响力如何？
- 架构能力是否在组织层面有系统性的培养计划？
5. 绩效与价值（Performance & Value）
这是最容易被忽视、却最关键的维度。架构不能只"做"，还要"有用"。
绩效评估的核心问题：
- 架构活动是否减少了重复建设？
- 架构标准化是否降低了集成成本？
- 架构决策是否加速了项目交付？
- 架构资产复用率是否在提升？
量化指标：把"好不好"变成"多少分"
成熟度评估最难的部分不是"定性判断"，而是"定量度量"。以下是 TOGAF 推荐的几类量化指标设计思路。
流程成熟度指标
| 指标名称 | 计算方式 | 目标值示例 |
|---|---|---|
| 架构评审覆盖率 | 经过架构评审的项目数 / 应评审项目总数 | ≥ 90% |
| 架构合规率 | 符合架构标准的项目数 / 总项目数 | ≥ 85% |
| 架构原则采纳率 | 引用架构原则的决策数 / 总决策数 | ≥ 70% |
| 架构文档完整率 | 有完整架构文档的系统数 / 系统总数 | ≥ 80% |
工具成熟度指标
| 指标名称 | 计算方式 | 目标值示例 |
|---|---|---|
| 工具覆盖率 | 使用标准架构工具的项目数 / 总项目数 | ≥ 75% |
| 仓库资产数 | 架构仓库中可复用资产的数量 | 逐年增长 |
| 资产复用率 | 被复用的架构资产数 / 总架构资产数 | ≥ 30% |
绩效成熟度指标
| 指标名称 | 计算方式 | 目标值示例 |
|---|---|---|
| 重复建设减少率 | (去年重复模块数 - 今年) / 去年重复模块数 | ≥ 20% |
| 集成成本降低率 | (去年集成成本 - 今年) / 去年集成成本 | ≥ 15% |
| 架构决策周期 | 从提出到决策的平均天数 | ≤ 10天 |
量化指标的设计原则：可采集、可比较、可改进。 如果一个指标无法定期采集数据，那就不要用它。
指标体系的落地建议
- 不要贪多。初期选 5-8 个核心指标即可，覆盖治理、流程、绩效三个维度
- 先有基线，再设目标。第一年的重点是采集基线数据，不要急着定 KPI
- 指标要分层。组织级指标（如合规率）和项目级指标（如评审通过率）分开管理
- 定期回顾。每季度回顾指标趋势，识别异常并分析根因
落地步骤：从自评到持续改进
成熟度评估不是一次性活动，而是一个持续循环。以下是推荐的落地路径。
第一步：组织自评（1-2 周）
由架构团队内部完成初步评估。使用 TOGAF 的成熟度评估问卷，对五个维度逐一打分。
自评的关键：
- 诚实。自评不是表演，打低分不丢人，打高分骗自己才丢人
- 证据导向。每个评分都要有支撑证据（文档、数据、案例）
- 全员参与。不能只由架构负责人一个人打分，要让团队成员都参与
第二步：外部评估（2-4 周）
引入外部视角——可以是集团内部的架构专家组，也可以是外部咨询机构。
外部评估的价值：
- 打破"自评偏见"（人们倾向于高估自己的成熟度）
- 引入行业对标数据（你的 Level 3 在行业中算什么水平？）
- 发现自评中遗漏的盲区
第三步：差距分析（1-2 周）
将当前成熟度与目标成熟度进行对比，识别关键差距。
差距分析的输出：
- 各维度的当前级别 vs 目标级别
- 每个差距的优先级（P0/P1/P2）
- 每个差距的改进方向和所需资源
第四步：制定改进计划（1-2 周）
基于差距分析，制定 12 个月的架构能力提升计划。
计划的核心要素：
- 短期快赢（0-3 个月）：选择 2-3 个容易改进的点，快速见效
- 中期建设（3-6 个月）：流程制度化、工具部署、培训推广
- 长期优化（6-12 个月）：度量体系建立、持续改进机制
第五步：执行与回顾（持续）
按计划执行改进，每季度回顾进展，每年重新评估成熟度。
回顾的关键问题：
- 计划中的改进项完成了多少？
- 成熟度级别有没有实际提升？
- 有没有新的差距出现？
- 下一年的改进重点是什么？
常见陷阱：三个典型失败案例
陷阱一：把评估变成考试
某企业引入成熟度评估后，各团队为了"过关"，开始突击补文档、造记录。评估时看起来什么都有，评估完一切照旧。
问题本质：把成熟度评估当成了合规检查，而不是改进工具。
应对建议：评估的目的不是打分，而是发现问题。降低评估的"考试感"，增加"诊断感"。让团队知道：打低分不惩罚，但不改进要问责。
陷阱二：追求高级别，忽视实用性
某企业一上来就定了"三年内达到 Level 4"的目标，投入大量资源建设度量体系，结果基础流程都没跑通，度量数据全是假的。
问题本质：成熟度不是越高越好，而是越匹配越好。Level 3 对大多数企业已经足够，强行冲 Level 4/5 是资源浪费。
应对建议：目标成熟度应该由业务需求驱动，而不是由"面子"驱动。问自己：我们真的需要量化管理吗？Level 3 的流程规范化是否已经满足当前需要？
陷阱三：只评不管，评估与改进脱节
某企业每年花大价钱做成熟度评估，出了漂亮的报告，但报告写完就锁进抽屉。下一年再评估，问题还是那些问题。
问题本质：评估和改进之间缺少闭环机制。没有专人负责改进计划的执行和跟踪。
应对建议：评估报告必须附带改进计划，改进计划必须有明确的负责人、时间表和验收标准。把改进执行情况纳入架构治理委员会的定期议程。
架构成熟度评估的真正价值，不在于那个分数本身，而在于评估过程中暴露的问题、引发的讨论、推动的改进。
分数只是一个快照，改进才是持续的视频。
如果你的企业正在考虑引入架构成熟度评估，不妨从一次坦诚的自评开始。不需要完美的问卷，不需要外部的顾问，只需要架构团队坐在一起，诚实地回答一个问题：我们到底做得怎么样？哪里可以更好？
这个问题的答案，就是成熟度提升的起点。
