金字塔原理写架构文档：结构化思维让 TOGAF 交付物不再被业务方秒关

你写的架构文档，业务方真的看过吗

每个企业架构师都经历过这样的场景：

你花了三周写了一份完整的架构定义文档——参照 TOGAF 的 Architecture Definition Document 模板，涵盖了业务架构、应用架构、数据架构、技术架构四个层面，配图精美、术语精准、足足80页。

发给业务方负责人，对方回了一句：“收到，我先看看。”

一周后你追问，对方说：“最近太忙还没来得及细看，你先讲讲核心结论？”

你讲了半小时，对方说：“所以你建议我们上中台？那预算多少？工期多久？”

你翻开文档第67页的"实施路线图"章节，对方的眼神已经开始飘了。

这不是个别现象。大部分 TOGAF 交付物最终沦为档案柜里的 PDF——评审时过一遍，落地时没人翻。

问题出在哪？不是文档不够专业，恰恰相反——太专业了，专业到业务方看不懂也不想看。

架构文档的核心矛盾

TOGAF 框架本身是面向架构师的方法论。它定义了一套完整的 ADM（Architecture Development Method）流程，从 Phase A（架构愿景）到 Phase H（架构变更管理），每个阶段都有标准交付物模板。

这些模板设计得很完善，但它们有一个默认假设：读者是架构师或技术人员。

现实中，架构文档的核心读者往往不是技术人员，而是：

读者	关注点	阅读时间
CIO / CTO	投资回报、风险、时间线	15分钟
业务线负责人	对我的业务有什么影响	10分钟
项目经理	实施步骤、资源需求、依赖关系	20分钟
技术团队	具体技术方案、接口设计	不限

前三类读者加起来可能只给你30分钟。30分钟看完80页？不可能。

所以架构文档需要两套结构：一套给决策者看，一套给执行者看。

金字塔原理恰好是解决这个问题的最佳工具。

金字塔原理的四个核心原则

先快速回顾一下金字塔原理（Pyramid Principle）。这是 Barbara Minto 提出的一套结构化表达方法，核心四条原则：

1. 结论先行

任何文档的第一句话就应该是结论。不是背景、不是过程、不是"我们先来看看现状"，而是你到底想说什么。

2. 以上统下

每一层论述都是对下一层的概括。顶层是结论，第二层是支撑结论的理由，第三层是支撑理由的证据。

3. 归类分组

同一层级的论点必须属于同一个逻辑范畴。别把技术风险和商业价值混在同一层级。

4. 逻辑递进

同一层级的论点必须按某种逻辑顺序排列——时间顺序、重要性顺序、或者演绎推理。

MECE 原则：相互独立，完全穷尽

金字塔原理还有一个配套原则叫 MECE（Mutually Exclusive, Collectively Exhaustive）——分类时要做到不重叠、不遗漏。

这四个原则加一个 MECE，就是重构架构文档的全部武器。

用金字塔原理重构 TOGAF 交付物

TOGAF 9 标准模板里最核心的交付物是 Architecture Definition Document（架构定义文档）。我们拿它来练手。

传统结构（TOGAF 默认模板）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


1. 引言
   1.1 项目背景
   1.2 文档目的
   1.3 术语表
2. 架构愿景
   2.1 业务目标
   2.2 架构原则
   2.3 利益相关者分析
3. 业务架构
   3.1 业务功能分解
   3.2 组织与角色
   3.3 业务流程
4. 应用架构
   4.1 应用组件清单
   4.2 应用交互矩阵
   4.3 应用部署视图
5. 数据架构
   5.1 数据实体
   5.2 数据流
   5.3 数据治理
6. 技术架构
   6.1 技术组件
   6.2 基础设施
   6.3 网络拓扑
7. 差距分析
8. 实施路线图
9. 风险管理
10. 附录

这个结构有什么问题？

它按架构域分类，不按读者需求分类。 业务方想看的"对我的影响"散落在第3、4、5、7、8章里，需要自己拼接。CIO 想看的"投多少钱、什么时候见效"在第8章和第9章的角落里。

金字塔重构后的结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


0. 执行摘要（1页）
   → 一句话结论 + 三个关键数据

1. 我们建议做什么？（结论层）
   1.1 核心建议
   1.2 预期收益（量化）
   1.3 投资规模与时间线

2. 为什么这么做？（论证层）
   2.1 现状痛点（业务视角）
       2.1.1 痛点一：xxx
       2.1.2 痛点二：xxx
       2.1.3 痛点三：xxx
   2.2 方案对比（MECE：列出所有候选方案）
       2.2.1 方案A：描述 + 优劣
       2.2.2 方案B：描述 + 优劣
       2.2.3 方案C：描述 + 优劣
   2.3 推荐理由

3. 具体怎么做？（方案层）
   3.1 业务架构变更
   3.2 应用架构变更
   3.3 数据架构变更
   3.4 技术架构变更

4. 需要什么资源？（执行层）
   4.1 实施路线图（分阶段）
   4.2 预算明细
   4.3 团队与角色
   4.4 风险与缓解措施

5. 附录（技术细节）
   5.1 完整架构视图
   5.2 术语表
   5.3 参考资料

看出区别了吗？

金字塔结构把决策者需要的信息全部前置：第0章1页纸讲结论，第1章讲做什么，第2章讲为什么，第3-4章讲怎么做和要什么。技术细节全部沉到第5章附录。

CIO 看到第1章就可以做决策了。业务方看到第2章就知道对自己的影响。技术团队翻到第3-5章看具体方案。

同一份文档，不同读者读不同深度，但都在同一个结构里找到自己要的东西。

执行摘要：1页纸定生死

执行摘要是整份文档最重要的部分——很多人可能只看这一页。

好的执行摘要长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


## 执行摘要

### 结论
建议在12个月内完成客户管理中台建设，整合现有3套CRM系统的客户数据，
实现客户360度视图和智能营销能力。

### 关键数据
- 投资规模：850万元（含软件采购、实施服务、内部人力）
- 预期收益：客户转化率提升15%，营销成本降低20%
- 投资回收期：18个月

### 核心风险
1. 数据迁移风险（3套系统数据标准不统一）→ 安排3个月数据治理前置阶段
2. 业务切换风险（新旧系统并行期）→ 分灰度切换，非一刀切上线

1页纸，3个关键数据，2个风险及对策。 这比80页的文档更能推动决策。

第2章「方案对比」的 MECE 实践

架构文档里最容易被质疑的部分是方案选型。业务方会觉得"你是不是早就内定了方案，对比只是走过场？"

MECE 原则可以帮你避免这个质疑。

反面案例

1
2
3
4


方案对比：
- 方案A：自建中台
- 方案B：采购商用中台产品
推荐方案A，因为更灵活。

这不是 MECE。你只列了两个方案，而且"更灵活"这个理由既没有量化也没有对比。

MECE 方案对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


## 候选方案全景（MECE）

按"建设方式"穷尽所有可能性：

| 维度 | 方案A：完全自建 | 方案B：采购+定制 | 方案C：纯采购 | 方案D：云服务(SaaS) |
|------|----------------|-----------------|---------------|---------------------|
| 建设周期 | 18-24个月 | 12-15个月 | 6-9个月 | 3-6个月 |
| 投资规模 | 1200万 | 850万 | 600万/年 | 200万/年 |
| 定制灵活度 | ★★★★★ | ★★★☆ | ★★☆ | ★☆ |
| 运维成本 | 高 | 中 | 中（厂商负责） | 低 |
| 数据安全 | 完全可控 | 基本可控 | 依赖厂商 | 依赖厂商 |
| 技术债务 | 高（自建维护） | 中 | 低 | 无 |

推荐方案B，理由：
1. 满足数据安全合规要求（排除C、D）
2. 建设周期可控在12个月内（排除A）
3. 总拥有成本（3年）最优

四个方案穷尽了"建设方式"的所有可能维度（自建→采购定制→纯采购→云服务），相互之间没有重叠。然后按6个维度打分对比，推荐理由有理有据。

TOGAF 其他交付物的金字塔化

除了 Architecture Definition Document，TOGAF 还有几个核心交付物可以用同样的方法优化：

Architecture Vision（架构愿景）

传统写法是先写5页背景，最后1页写愿景。

金字塔写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 愿景声明（1段话）
   "到2027年，建成以客户为中心的统一数字化平台，
    实现全渠道客户触达和数据驱动的精准运营。"

2. 愿景拆解（MECE 按维度）
   2.1 业务能力愿景
   2.2 技术能力愿景
   2.3 组织能力愿景

3. 现状与差距
4. 实现路径概览

Architecture Roadmap（架构路线图）

传统写法是按 Phase 列出每个阶段的活动。

金字塔写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


0. 路线图摘要（1张甘特图 + 1段话）

1. 三个关键里程碑
   1.1 M1（6个月后）：xxx 上线
   1.2 M2（12个月后）：xxx 上线
   1.3 M3（18个月后）：xxx 上线

2. 各阶段详细计划
   2.1 Phase 1：...
   2.2 Phase 2：...
   2.3 Phase 3：...

3. 依赖关系与约束
4. 资源需求汇总

Statement of Architecture Work（架构工作说明书）

这是给甲方/决策层签批的文档，更需要结论先行：

1
2
3
4
5
6
7
8


1. 请求摘要
   "申请850万预算，12个月工期，用于xxx建设。"

2. 业务价值
3. 技术方案摘要
4. 实施计划
5. 风险与缓解
6. 审批要求

一个实用模板：架构决策记录（ADR）

日常架构决策不需要写80页文档，一个 Architecture Decision Record (ADR) 就够了。用金字塔结构写 ADR：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# ADR-042: 客户数据平台选型决策

## 决策（结论先行）
选择方案B：采购xx产品 + 定制化开发。

## 背景（为什么需要做这个决策）
现有3套CRM系统数据孤岛严重，客户数据重复率约35%，
无法支持跨渠道营销。

## 候选方案（MECE）
- 方案A：自建CDP
- 方案B：采购+定制
- 方案C：纯SaaS方案

## 决策理由
1. 数据安全合规排除方案C
2. 12个月工期约束排除方案A
3. 方案B在成本、周期、灵活度之间最优

## 影响
- 预算增加：采购费用350万
- 新增依赖：需要xx厂商实施团队驻场6个月
- 替代方案A的2名开发人员转岗到定制化模块

## 状态：已批准（2026-06-15）

文档结构对比总结

维度	传统 TOGAF 模板	金字塔重构后
开头	项目背景、术语表	执行摘要（1页结论）
结构逻辑	按架构域分类	按读者决策需求分层
方案对比	列2-3个方案	MECE 穷尽所有可能
技术细节	混在主文档里	沉到附录，按需翻阅
阅读效率	需通读80页	CIO看1页，业务方看5页，技术看全部
被"秒关"概率	很高	显著降低

最后

架构文档不是写给自己看的，是写给需要你帮他做决策的人看的。

金字塔原理不会让你的技术方案更好，但会让你的方案被更多人理解、被更多人接受。技术能力决定你能走多远，表达能力决定有多少人愿意跟你一起走。

下次写架构文档之前，先花10分钟画一个金字塔：顶层是你的结论，第二层是三个理由，第三层是每个理由的证据。结构定了，再往里填内容。

这10分钟可能比你多写10页文档更有价值。