TOGAF架构成熟度模型精读：用标准化评估框架衡量企业架构能力

Wed, 29 Jul 2026 12:00:00 +0800

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 的流程规范化是否已经满足当前需要？

陷阱三：只评不管，评估与改进脱节

某企业每年花大价钱做成熟度评估，出了漂亮的报告，但报告写完就锁进抽屉。下一年再评估，问题还是那些问题。

问题本质：评估和改进之间缺少闭环机制。没有专人负责改进计划的执行和跟踪。

应对建议：评估报告必须附带改进计划，改进计划必须有明确的负责人、时间表和验收标准。把改进执行情况纳入架构治理委员会的定期议程。

架构成熟度评估的真正价值，不在于那个分数本身，而在于评估过程中暴露的问题、引发的讨论、推动的改进。

分数只是一个快照，改进才是持续的视频。

如果你的企业正在考虑引入架构成熟度评估，不妨从一次坦诚的自评开始。不需要完美的问卷，不需要外部的顾问，只需要架构团队坐在一起，诚实地回答一个问题：我们到底做得怎么样？哪里可以更好？

这个问题的答案，就是成熟度提升的起点。

架构成熟度 on 文艺技术笔记

TOGAF架构成熟度模型精读：用标准化评估框架衡量企业架构能力

TOGAF 架构成熟度模型精读：用标准化评估框架衡量企业架构演进水平

成熟度模型：从混沌到优化的五级演进

Level 0：未建立（Initial / Absent）

Level 1：初步建立（Initial / Ad-hoc）

Level 2：可重复（Repeatable / Managed）

Level 3：已定义（Defined）

Level 4：量化管理（Quantitatively Managed）

Level 5：持续优化（Optimizing）

评估维度：五大支柱撑起架构能力

1. 架构治理（Governance）

2. 架构流程（Process）

3. 工具与技术（Tools & Technology）

4. 人员与能力（People & Competency）

5. 绩效与价值（Performance & Value）

量化指标：把"好不好"变成"多少分"

流程成熟度指标

工具成熟度指标

绩效成熟度指标

指标体系的落地建议

落地步骤：从自评到持续改进

第一步：组织自评（1-2 周）

第二步：外部评估（2-4 周）

第三步：差距分析（1-2 周）

第四步：制定改进计划（1-2 周）

第五步：执行与回顾（持续）

常见陷阱：三个典型失败案例

陷阱一：把评估变成考试

陷阱二：追求高级别，忽视实用性

陷阱三：只评不管，评估与改进脱节