TOGAF 的技术架构到底包含什么：从 Phase D 到一份能落地的 13 章文档

「技术架构应该包含哪些内容？」

在企业里问这句话，通常会收到三种回答：第一种是甩一张网络拓扑图，说「这就是技术架构」；第二种是打开采购系统，导出一份服务器和中间件清单；第三种最诚实——「看你怎么定义」。

三种回答都指向同一个困惑：大家想找一份固定的内容清单，但 TOGAF 从来没有给过。

一个容易被误解的前提 链接到标题

TOGAF 给的不是清单，而是三样东西：一套阶段划分（ADM 的 Phase D）、一组制品（Artifacts）、一个架构内容框架（Architecture Content Framework）。所以「技术架构包含什么」这个问题，必须拆成四层来回答：

定位 → 输入输出 → 内容域 → 制品。

先把定位讲清楚，否则后面全是空中楼阁。

第一层：技术架构是 ADM 的 Phase D 链接到标题

TOGAF 把企业架构切成四个域，技术架构是其中唯一一个「不自带业务语义」的域：

TOGAF 对它的定义大意是：

技术架构是 IT 基础设施与技术组件的根本组织方式，包括它们相互之间以及与环境之间的关系，以及指导其设计与演进的原则。

这句话里有三个词值得单独拎出来：组织方式、关系、原则。它们决定了技术架构不是「有什么」，而是「怎么摆、为什么这么摆、以后往哪摆」。

Phase D 的目标也因此很明确：定义目标技术架构，让架构愿景、目标业务/数据/应用构建块能够通过技术组件和技术服务真正落地，同时回应架构工作说明书和利益相关者的关切。

三条边界，比内容清单更重要 链接到标题

• 不负责业务功能建模，也不负责应用逻辑设计——那是 B 和 C 的事；
• 必须承接应用架构提出的部署、集成、性能、可用性、安全需求——应用怎么部署，是技术架构的关键输入；
• 输出的是平台、基础设施、技术标准、部署形态、演进路线，而不是一份软硬件采购清单。

第三条最容易被违反。很多所谓的「技术架构文档」，本质是采购清单加一张拓扑图——它回答了「买了什么」，却没回答「为什么这么组织、出了事怎么演进」。

第二层：Phase D 怎么走 链接到标题

Phase D 的输入输出可以画成一条很朴素的流水线：

主要输入：架构原则、架构愿景与工作说明书、业务/数据/应用架构成果、架构仓库与可复用构建块（ABB/SBB）、含非功能需求的架构需求规格、参考模型与现有技术组合。

主要输出：架构定义文档（ADD）中的技术架构部分（基线 + 目标）、架构需求规格、架构路线图、技术标准目录与技术组合目录等制品，以及对 Phase E/F 的候选解决方案与迁移规划输入。

九个步骤 链接到标题

TOGAF 9.2 和 10 在这一点上基本一致：

1. 选择参考模型、视点和工具
2. 开发基线技术架构描述
3. 开发目标技术架构描述
4. 做差距分析（Gap Analysis）
5. 定义候选路线图组件
6. 解决跨架构景观的影响
7. 开展正式的利益相关者评审
8. 最终确定技术架构
9. 创建或更新架构定义文档

注意第 6 步——「跨架构景观的影响」。这是 TOGAF 里最容易被跳过的步骤，也是大型企业翻车最多的地方：集团在做目标架构，某个板块正在上线一套不兼容的中间件，两边各自都「符合架构」，合起来却是新的技术债。

第三层：九个内容域 链接到标题

把 TOGAF 的制品和实务经验合起来，技术架构通常覆盖九块内容。先看全景：

技术参考模型（TRM）：最常用的骨架 链接到标题

TRM 严格说不是强制交付物，但它是组织 Phase D 内容、做差距分析时最好用的分类学：

另外还有 III-RM（集成信息基础设施参考模型），用于「无边界信息流」场景。

TRM 的真正价值在于统一语言：当业务说「要一个中台」、运维说「要一套消息队列」、开发说「要一个服务网格」时，TRM 能把它们放到同一张图上，暴露出「其实是同一层在重复建设」。

NFR：技术架构最容易被写虚的部分 链接到标题

非功能需求必须显式承载，而且要可度量、可验证：

• 可用性、可靠性、容灾（RTO/RPO）
• 性能、吞吐、时延、并发
• 可扩展性、弹性
• 安全性、合规性、数据主权
• 可运维性、可观测性（日志、监控、告警、链路追踪）
• 成本（TCO）、能耗与可持续性
• 可移植性、避免厂商锁定

判断一段 NFR 写得好不好，有个简单测试：能不能直接变成一条验收标准或一个监控指标？ 「系统要高性能」不是 NFR，「核心交易接口 P99 < 300ms，峰值 2000 TPS」才是。

第四层：TOGAF 规定的制品清单 链接到标题

Phase D 的制品分三类，这个分类本身就是个好用的检查表。

目录（Catalogs） 链接到标题

矩阵（Matrices） 链接到标题

图（Diagrams） 链接到标题

不同 TOGAF 版本对「核心/扩展」制品的归类略有差异；TRM、III-RM 属于参考模型，不是必须交付的制品，但在 Phase D 中被广泛使用。

三类制品的分工很清楚：图用于沟通，目录用于盘点，矩阵用于追溯。只有图没有目录和矩阵的文档，三个月后就没人敢改了。

从「标准」到「可交付」：大型企业的 13 章骨架 链接到标题

到这里，TOGAF 的部分讲完了。但如果你是一家大型公司的技术架构师，真正要交出去的是一份文档——而这份文档最容易出的问题不是「写少了」，是写成产品手册、现状流水账，或者一份没有约束力的愿景。

比较稳妥的主线是：

总纲 → 现状 → 目标 → 专项 → 标准 → 演进 → 治理

按这条主线展开，就是 13 章：

每章一张自检卡 链接到标题

章节目录本身不稀奇，值钱的是「写完这章，怎么知道它合格」。下面这张表是整份文档的验收清单：

集团级做参考架构，板块级做实例化 链接到标题

大型集团最常犯的错，是拿一份集团文档去覆盖所有业务线的细节——结果要么厚到没人读，要么空到没人用。

更现实的做法是两层体系：

• 集团级出「参考技术架构」：原则、标准、平台目录、总体蓝图、治理规则；
• 板块/领域级出「实例化技术架构」：具体部署、选型、参数、地域与合规差异。

集团文档的职责是约束与复用，不是代替设计。

主线永远是「基线—目标—差距—路线」 链接到标题

不管文档分几章，真正撑起它的是一条四段式主线：

一旦写成「现状介绍 + 技术展望」两段式，这份文档就失去了约束力——因为没有差距，就没有优先级；没有路线，就没有预算；没有治理，就没有人负责。

写作时的八个建议 链接到标题

1. 先定「架构契约」，再写细节。明确哪些是强制、哪些是推荐、哪些是领域自决，否则文档会退化成「建议集」。
2. 主线始终是「基线—目标—差距—路线」，不要写成两段式。
3. 每个关键决策配一条 ADR（背景、选项、决定、理由、影响），比大段描述更有说服力。
4. 集团级做参考架构，领域级做实例化，各司其职。
5. 图表与目录/矩阵并重。图负责沟通，目录和矩阵负责可维护、可审计。
6. 让安全、运维、财务、采购共同签署。落地的瓶颈往往不在技术，而在预算、合规和供应链。
7. 控制篇幅。正文 40–80 页，清单和图表放附录；超过 100 页的文档通常没人读完。
8. 版本化与年度刷新。技术架构是活文档，至少每年一次，重大技术变化时增量更新。

五个常见误区 链接到标题

如果只能先做一个最小可行版本 链接到标题

现实里很少有企业能一次写完 13 章。如果你想先交出一版能用的东西，优先做这七块，就足以支撑第一轮评审和次年预算：

1. 技术原则与政策
2. 技术参考模型与能力地图
3. 基线技术组合盘点
4. 目标架构蓝图与平台服务目录
5. 技术标准目录（含技术雷达）
6. 差距分析与 12–18 个月路线图
7. 治理流程与评审门禁

这七块覆盖了「定规则、看清现状、说清目标、给出路径、保证执行」的闭环。剩下的章节，可以在后续版本里逐步补齐——先有能用的 40 页，好过永远写不完的 200 页。

写在最后 链接到标题

回到开头那个问题。TOGAF 中的技术架构，核心内容可以压缩成一句话：

以技术原则与标准为约束，以 TRM 等参考模型为骨架，描述基线与目标的技术组件、平台、基础设施、网络与环境，建立应用—技术映射，承载非功能与安全需求，并给出技术演进路线图与治理机制。

它的交付物落在三个地方：架构定义文档的技术架构部分、架构需求规格、架构路线图；配以技术标准目录、技术组合目录、应用/技术矩阵，以及各类技术架构图。

至于那份文档本身——它不是一次性的答卷，而是一份需要每年续写的契约。