简介TOGAF 9.1 中文电子版面向企业架构师、IT 规划人员及备考 TOGAF 认证的学习者帮助读者系统理解这一由 The Open Group 发布的架构框架。内容围绕架构框架的方法与工具展开涵盖企业架构的认可、构建、使用与维护并基于迭代流程模型与可复用架构资产组织知识体系。资源为单个 PDF 文件压缩包约 50.32MB便于在电脑或平板上随时查阅与检索。文档从核心概念入手讲解 TOGAF 背景下的架构定义、ENTERPRISE 概念以及架构模块功能描述与要求如用户管理模块 SBB 的架构功能实现与重用示例同时阐述架构原则说明如何以组件结构、相互关系及治理指南指导架构设计与演进。目前已有 1960 人学习适合希望建立完整 TOGAF 知识框架、对照标准术语深入研读的读者。1. 为什么架构评审总在扯皮而 TOGAF 9.1 想先解决“语言不通”做过几年企业级项目的人大概都遇到过这种场面业务方说要“中台化”开发团队理解成微服务拆分运维觉得是统一网关安全团队则盯着权限模型不放。会开了三轮PPT 改了五版最后发现大家嘴里的“架构”根本不是同一个东西。TOGAF 9.1 中文电子版要处理的第一个问题恰恰不是画图工具或建模语言而是把“架构”这个词本身钉死在可讨论的定义上。这份文档来自 The Open Group是 TOGAF 9.1 的官方中文版本覆盖引言、核心概念、ADM 方法、架构资产等部分。它把架构定义为“一个系统的基础组织体现在系统组件、组件之间及组件与环境之间的相互关系以及对系统设计和演进进行治理的原则中”同时承认在 TOGAF 语境下架构有两种用法一种是系统的正式描述或组件层级计划另一种是组件结构及其治理原则本身。这个区分看着像文字游戏实际决定了你在项目里是交付一份文档还是维护一套持续演进的治理机制。适合正在做企业架构规划、需要统一团队话语体系的架构师和技术负责人。2. TOGAF 9.1 的核心概念拆解从 ABB、SBB 到架构原则2.1 架构的两种含义与 ISO/IEC 42010 的关系TOGAF 9.1 在术语上做了一个很务实的取舍。它参考 ISO/IEC 42010:2007 对架构的定义但没有严格照搬原因是 ISO 的表述偏学术而 TOGAF 的读者群体里有大量已经习惯了“架构就是那张部署图”的从业者。于是它保留了两层含义并行使用含义典型产出使用场景系统的正式描述架构定义文档、组件层级计划项目立项、方案评审组件结构与治理原则架构原则、演进指南长期治理、变更控制这个表格不是让你二选一而是提醒你在写架构文档时如果只写了组件清单却没有治理原则那在 TOGAF 看来只完成了一半。常见做法是在架构定义文档里单独开一节“架构原则”把每条原则写成“原则陈述 理由 影响”的三段式。2.2 ABB 与 SBB可复用架构资产的分层逻辑TOGAF 9.1 里有一组容易被忽略但极其实用的概念ABBArchitecture Building Block和 SBBSolution Building Block。原文举的例子很直白——用户管理模块的功能描述和要求属于 ABB而“使用 SAP 系统实现的用户管理模块”属于 SBB。理解这两者的关系可以用一个简单的映射来记ABB 回答“需要什么能力”不绑定具体产品SBB 回答“用什么实现”绑定具体产品或技术选型。在实际项目里我一般会这样落地先写 ABB 清单每条包含功能描述、接口要求、质量属性然后在 SBB 层做选型映射标注每个 ABB 由哪个 SBB 满足、是否有替代方案。这样做的好处是当 SAP 换成自研系统时ABB 层不需要动只替换 SBB 映射即可。# ABB 定义示例用户管理能力 abb: id: ABB-USER-MGMT name: 用户管理模块 description: 提供用户生命周期管理、认证、授权能力 interfaces: - 用户创建/查询/禁用 - 统一认证接口 quality: availability: 99.9% latency: 200ms # SBB 映射示例 sbb: - abb_ref: ABB-USER-MGMT implementation: SAP User Management status: active - abb_ref: ABB-USER-MGMT implementation: 自研 IAM 系统 status: candidate这段 YAML 不是 TOGAF 官方格式而是我在项目里常用的简化表达。关键点是abb_ref把两层关联起来status区分当前实现和候选方案。评审时直接看这张映射表比翻几十页文档快得多。2.3 架构原则怎么写才不是口号TOGAF 9.1 强调架构原则要能“指导大家如何做架构”但原文没有给出特别具体的模板。按常见做法一条可执行的架构原则至少包含四部分名称、陈述、理由、影响。比如“数据单一来源原则”陈述所有主数据必须指定唯一权威来源系统理由避免多系统写入导致数据不一致影响新增系统若需主数据必须通过接口从权威源获取不得本地建表。注意如果一条原则写完之后团队无法判断某个具体决策是否违反它那这条原则就还是口号需要继续拆。3. 用 ADM 思路把架构工作拆成可执行的迭代步骤3.1 ADM 的阶段划分与中文版阅读顺序TOGAF 9.1 的核心方法是 ADMArchitecture Development Method中文版在第四部分展开。它把架构工作分成从预备阶段到变更管理的多个阶段形成一个迭代循环。很多人第一次读中文版会从第 1 章顺着往下翻结果翻到 ADM 时已经忘了前面的概念。我一般建议的阅读顺序是第 2 章核心概念 → 第 3 章术语 → 第四部分 ADM 概览 → 再回头细读各阶段。ADM 的阶段不是瀑布式的而是每次迭代都可以从任意阶段切入。比如一个已经上线的系统要做安全加固可能直接从阶段 G实施治理和阶段 H变更管理入手而不是从阶段 A 重新做架构愿景。3.2 阶段 A 到阶段 D从愿景到技术架构的落地路径阶段 A 产出架构愿景阶段 B 做业务架构阶段 C 做信息系统架构数据和应用阶段 D 做技术架构。这条路径在中文版里有详细的输入输出说明但实际使用时容易卡在阶段 B 和阶段 C 的衔接上。一个可操作的检查清单是阶段 A 结束时确认架构愿景文档里有明确的干系人列表和成功标准阶段 B 结束时确认业务架构能回答“哪些业务流程需要哪些业务服务”阶段 C 开始时把业务服务映射到应用组件再映射到数据实体阶段 D 只处理技术选型和部署拓扑不重新讨论业务需求。# 用目录结构管理 ADM 各阶段产出常见做法 architecture/ ├── phase-a-vision/ │ ├── stakeholders.md │ └── success-criteria.md ├── phase-b-business/ │ ├── business-services.md │ └── process-map.md ├── phase-c-information-systems/ │ ├── application-mapping.md │ └──>-- 例外记录表结构示例 CREATE TABLE architecture_exception ( id INT PRIMARY KEY, principle_id INT NOT NULL, project_name VARCHAR(100), reason TEXT, impact TEXT, status VARCHAR(20), -- pending/approved/rejected approved_by VARCHAR(50), expire_date DATE, review_date DATE );这张表的关键字段是expire_date和review_date。例外不能永久有效到期必须复审否则架构原则会逐渐被架空。status字段让治理委员会能快速筛选待处理申请。5. 把 TOGAF 9.1 用成日常工具的几个具体技巧5.1 用阶段检查清单代替通读全文中文电子版篇幅不小通读一遍需要不少时间。更高效的方式是按阶段做检查清单。比如阶段 C 的检查清单可以包括应用组件是否已映射到业务服务、数据实体是否已指定权威来源、接口是否已定义质量属性。每次迭代只翻对应阶段的章节其他部分作为参考。5.2 架构评审会前先对齐 ABB 清单评审会扯皮的根源往往是大家对“要建什么”没有共识。我的做法是会前发一份 ABB 清单每条只写功能描述和接口要求不写产品名。会上先确认 ABB 清单再讨论 SBB 选型。这样能把讨论从“用 A 还是用 B”拉回到“我们到底需要什么能力”。5.3 用版本化目录管理架构资产架构资产不是一次性文档需要版本管理。常见做法是用 Git 仓库管理架构目录每次迭代打 tag。比如v1.0-phase-a表示第一次迭代的阶段 A 产出。这样当有人问“半年前的架构愿景是什么”时可以直接 checkout 对应 tag而不是在聊天记录里翻文件。# 架构资产版本管理示例 git init architecture-repo cd architecture-repo mkdir -p phase-a-vision phase-b-business git add . git commit -m init: phase A vision draft git tag v1.0-phase-a # 后续迭代 git commit -m update: phase B business services git tag v1.1-phase-bgit tag的命名建议包含版本号和阶段名方便检索。git log --oneline可以快速查看架构资产的演进历史比翻邮件附件可靠得多。5.4 中文版检索技巧用术语表反向定位章节中文电子版里同一个概念可能在不同章节用不同措辞出现。如果直接搜“构建块”找不到想要的内容可以试试搜“ABB”或“SBB”。反过来如果搜英文缩写没结果就搜中文全称。我一般会先翻第 3 章术语表找到该术语在中文版里的标准译法再用这个译法去搜正文命中率会高很多。本文还有配套的精品资源点击获取
