简介TOGAF 9.1 中文电子版面向企业架构师、IT 规划人员及备考 TOGAF 认证的学习者帮助读者系统理解这一由 The Open Group 发布的架构框架。内容围绕架构框架的方法与工具展开涵盖企业架构的认可、构建、使用与维护并基于迭代流程模型与可复用架构资产组织知识体系。资源为单个 PDF 文件压缩包约 50.32MB便于在电脑或平板上随时查阅与检索。文档从核心概念切入讲解 TOGAF 背景下的架构定义、ENTERPRISE 概念以及架构模块功能描述与要求例如用户管理模块 SBB 的架构功能实现与重用思路并延伸至架构原则如何指导架构设计与演进治理。目前已有 1960 人学习适合希望建立完整 TOGAF 知识框架、对照原文梳理概念与原则的读者作为案头参考。1. 拿到 TOGAF9.1 中文电子版之后先别急着从头读到尾很多人第一次接触企业架构都是被一句“考个 TOGAF 认证吧”带进来的。资料到手TOGAF9.1 中文电子版几百页 PDF 往那一放第一章讲架构开发方法第二章讲架构内容框架翻到第三章已经忘了第一章在说什么。真正的问题不是资料不够而是这份文档本身是标准文本不是教程它的组织方式是给评审和裁剪用的不是给线性阅读用的。TOGAF9.1 中文电子版的核心价值在于它把 ADMArchitecture Development Method这套循环方法论、内容框架、参考模型和治理机制完整地摊开了。它解决的是“企业里几十个系统各说各话、业务和 IT 对不上账”这类问题适合架构师、技术负责人、以及需要把业务目标翻译成系统蓝图的人。但如果你把它当小说读大概率会在第二阶段就放弃。合理的用法是先建立 ADM 的骨架认知再按需跳到具体交付物章节最后用治理和裁剪部分收口。下面几章就按这个顺序拆。2. TOGAF9.1 的 ADM 循环与内容框架怎么对应起来看2.1 ADM 八个阶段各自产出什么交付物ADM 是 TOGAF 的主干从预备阶段到变更管理一共八个阶段加一个需求管理贯穿始终。很多人背得下阶段名却说不清每个阶段到底该交出什么东西。下面这张表把阶段和核心交付物对齐看的时候对照中文电子版的目录去翻比顺序读快得多。阶段中文名核心交付物常见误用预备Preliminary架构原则、架构治理框架直接跳过导致后面无约束A架构愿景架构愿景文档、干系人地图写成 PPT 口号没有可度量目标B业务架构业务能力地图、业务流程图只画流程不定义能力C信息系统架构数据实体、应用通信图数据和应用混在一张图D技术架构技术标准、技术参考模型直接抄厂商产品清单E机会与解决方案工作包、过渡架构把项目计划当架构路线图F迁移规划实施迁移计划忽略依赖和回滚G实施治理架构契约、合规评估签完合同就不管了H变更管理变更请求、架构更新变更不回流到需求管理这张表不是让你背而是让你在翻中文电子版时有个锚点。看到某个阶段先问自己“这个阶段的输出物我手上有没有”没有就说明这一步被跳过了。2.2 用需求管理把八个阶段串成闭环需求管理不是第九个阶段它是横跨所有阶段的中心。中文电子版里这部分写得比较散实际落地时我一般会用一个简单的需求追溯表来管。-- 需求追溯表把业务需求映射到架构阶段和交付物 CREATE TABLE requirement_trace ( req_id VARCHAR(32) PRIMARY KEY, -- 需求编号如 REQ-001 req_desc TEXT NOT NULL, -- 需求描述 source_stakeholder VARCHAR(64), -- 提出方 adm_phase VARCHAR(16), -- 归属阶段 A/B/C/D deliverable VARCHAR(128), -- 对应交付物 status VARCHAR(16) DEFAULT open,-- open/approved/implemented change_ref VARCHAR(32) -- 关联的变更请求编号 );这张表的作用是让每个需求都能回答三个问题谁提的、落在哪个阶段、对应哪个交付物。参数上adm_phase用单字母对应 ADM 阶段change_ref在 H 阶段变更时回填形成闭环。没有这张表需求管理就是一句空话架构做完也不知道有没有覆盖业务诉求。提示中文电子版里需求管理章节篇幅不长但它是唯一贯穿全流程的部分建议单独抽出来做一张追溯表而不是等出了问题再补。2.3 内容框架和 ADM 的映射关系内容框架回答的是“架构描述到底包含哪些东西”。它把架构分成业务、数据、应用、技术四个域每个域又分目录、矩阵、图三类表达方式。目录是清单矩阵是关系图是可视化。很多人只画图不建目录和矩阵结果图一多就失控。实际操作时我会先建目录比如应用清单、数据实体清单再用矩阵表达关系应用与数据的 CRUD 矩阵最后才画图。顺序反了图就是装饰品。中文电子版在内容框架部分给了元模型但没给具体模板这部分需要自己按组织情况裁剪。3. 用中文电子版做裁剪从标准到可落地的架构工作流3.1 裁剪的四个维度规模、行业、组织、合规TOGAF 明确说了要裁剪但没说怎么裁。中文电子版在这块偏原则性。我的做法是从四个维度判断企业规模决定阶段是否合并行业决定参考模型选哪个组织成熟度决定治理强度合规要求决定文档留存粒度。比如一个两百人规模的产品公司预备阶段和 A 阶段可以合并B 和 C 可以并行但 D 阶段的技术标准不能省因为技术选型一旦散开后面运维成本会指数上升。而一个受监管行业的企业G 阶段的合规评估必须独立成节不能并进 F 阶段。3.2 把 ADM 阶段映射成团队可执行的任务清单标准里的阶段是方法论语言团队需要的是任务语言。下面这段 Python 把阶段映射成任务清单方便导入项目管理工具。# 将 ADM 阶段裁剪为团队任务清单 adm_phases { Preliminary: [确定架构原则, 建立治理框架, 选定架构工具], A: [识别干系人, 定义架构愿景, 确认业务目标可度量], B: [梳理业务能力, 绘制业务流程图, 定义业务服务], C: [建立数据实体目录, 绘制应用通信图, 输出CRUD矩阵], D: [制定技术标准, 建立技术参考模型, 评估技术债务], E: [识别工作包, 定义过渡架构, 评估方案差距], F: [制定迁移计划, 评估依赖与风险, 确定回滚策略], G: [签订架构契约, 执行合规评估, 记录偏差], H: [收集变更请求, 评估变更影响, 更新架构基线], } # 按团队规模裁剪小团队合并阶段 def tailor(phases, team_size): if team_size 50: # 合并预备与AB与C并行 return {PA: phases[Preliminary] phases[A], B|C: phases[B] phases[C], D: phases[D], E: phases[E], F: phases[F], GH: phases[G] phases[H]} return phases for stage, tasks in tailor(adm_phases, 30).items(): print(f[{stage}]) for t in tasks: print(f - {t})这段代码的逻辑是把标准阶段按团队规模做合并team_size是判断阈值小于 50 人时把预备和 A 合并、B 和 C 并行、G 和 H 合并。参数adm_phases是阶段到任务的映射可以按组织实际情况增删。输出结果直接就是任务清单导入 Jira 或 TAPD 即可。注意合并的是执行节奏不是交付物交付物该有的还得有。3.3 裁剪后如何验证架构覆盖度裁剪最大的风险是漏掉关键域。验证方法是做一次覆盖度检查业务、数据、应用、技术四个域每个域至少有一个目录、一个矩阵、一张图。缺哪个补哪个。域目录矩阵图业务业务能力清单能力与流程矩阵业务流程图数据数据实体清单实体关系矩阵数据分布图应用应用系统清单应用与数据CRUD应用通信图技术技术标准清单标准与组件矩阵技术拓扑图这张表可以直接当检查清单用。裁剪可以合并阶段但不能让某个域只剩一张图。中文电子版的内容框架部分给了元模型这张表是把元模型翻译成可检查的交付物。4. 中文电子版里的参考模型与治理机制怎么用起来4.1 参考模型不是拿来照抄的是拿来对齐的TOGAF9.1 中文电子版里有技术参考模型和基础架构参考模型。很多人看到“参考模型”四个字就想直接套用结果发现和自家技术栈对不上。参考模型的正确用法是对齐不是复制。它提供的是一套分类和分层方式比如把技术组件分成基础设施、中间件、应用平台、交付平台几层你按这个分层去归置自己的组件而不是把模型里的组件名照搬。我一般会做一张对齐表左边是参考模型的分层右边是自家组件中间标注差异。差异大的地方就是技术债务集中的地方。4.2 架构治理的四个抓手原则、契约、评审、度量治理机制在中文电子版里分散在预备阶段和 G 阶段。实际落地时我把它归纳成四个抓手。架构原则是约束架构契约是承诺架构评审是检查架构度量是反馈。四个缺一个治理就变成形式。架构原则要少而硬三到五条足够比如“所有跨系统数据交换必须通过统一数据服务层”。契约要具体到接口和时限。评审要有否决权否则没人当回事。度量要能反映架构健康度比如技术标准符合率、架构偏差数量。4.3 用架构契约模板约束实施阶段架构契约是 G 阶段的核心交付物但中文电子版没给模板。下面是一个可用的最小模板。# 架构契约模板 architecture_contract.yaml contract_id: AC-2024-001 project: 订单中心重构 architect: 张三 phase: G scope: - 订单服务 - 支付网关 constraints: - 必须使用统一认证网关 - 数据写入必须经过数据服务层 - 技术栈限定在技术标准清单内 compliance_check: frequency: 双周 owner: 架构评审委员会 metrics: - 标准符合率 95% - 架构偏差数 2 sign_off: date: 2024-06-01 approver: 李四这份契约的关键字段是constraints和compliance_check。约束要可验证不能写“高性能”这种没法检查的词。检查频率和责任人要明确否则契约签完就进抽屉。metrics里的阈值按组织容忍度调整但必须有量化指标。注意契约不是一次性文件H 阶段变更时要回填contract_id形成变更追溯。中文电子版在变更管理部分强调了这一点但没给具体做法。5. 从中文电子版到认证与实战几个能省时间的技巧5.1 用 ADM 阶段做索引而不是按页码读中文电子版的排版是按章节走的但你的使用场景是按阶段走的。我的做法是在 PDF 里给每个 ADM 阶段建书签把散落在不同章节的相关内容串起来。比如“架构愿景”相关内容可能出现在第二章、第五章和附录建一个书签组比来回翻快得多。阅读顺序建议是先读 ADM 总览再读内容框架然后按你当前项目所处的阶段跳读最后读治理和裁剪。5.2 认证考试里最容易混的几组概念考 TOGAF 认证时有几组概念特别容易混。架构愿景和架构定义的区别在于前者是目标态的高层描述后者是具体蓝图。基线架构和目标架构的区别在于前者是现状后者是未来。过渡架构是两者之间的中间态。交付物和可交付成果的区别在于前者是文档后者是能力。中文电子版在术语部分有定义但分散建议自己整理一张对照表。5.3 把中文电子版当词典用而不是当教材最后一个技巧这份文档最好的用法是当词典。遇到具体问题时去查对应章节而不是从头读到尾。比如要做数据架构直接翻内容框架的数据部分和 C 阶段要写架构原则翻预备阶段。每次只解决一个问题查完就走。这样用几百页的文档反而比精简教程更耐用因为它是标准标准的价值在于覆盖全不在于读得顺。真正需要精读的只有 ADM 总览和需求管理两处其余按需查阅即可。本文还有配套的精品资源点击获取