企业官网建设流程全解析

简介：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 中文电子版的核心价值在于它把 ADM（Architecture Development Method）这套循环方法论、内容框架、参考模型和治理机制完整地摊开了。它解决的是“企业里几十个系统各说各话、业务和 IT 对不上账”这类问题，适合架构师、技术负责人、以及需要把业务目标翻译成系统蓝图的人。但如果你把它当小说读，大概率会在第二阶段就放弃。合理的用法是：先建立 ADM 的骨架认知，再按需跳到具体交付物章节，最后用治理和裁剪部分收口。下面几章就按这个顺序拆。

2. TOGAF9.1 的 ADM 循环与内容框架怎么对应起来看

2.1 ADM 八个阶段各自产出什么交付物

ADM 是 TOGAF 的主干，从预备阶段到变更管理，一共八个阶段加一个需求管理贯穿始终。很多人背得下阶段名，却说不清每个阶段到底该交出什么东西。下面这张表把阶段和核心交付物对齐，看的时候对照中文电子版的目录去翻，比顺序读快得多。

这张表不是让你背，而是让你在翻中文电子版时有个锚点。看到某个阶段，先问自己“这个阶段的输出物我手上有没有”，没有就说明这一步被跳过了。

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: # 合并预备与A，B与C并行 return {"P+A": phases["Preliminary"] + phases["A"], "B|C": phases["B"] + phases["C"], "D": phases["D"], "E": phases["E"], "F": phases["F"], "G+H": 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 裁剪后如何验证架构覆盖度

裁剪最大的风险是漏掉关键域。验证方法是做一次覆盖度检查：业务、数据、应用、技术四个域，每个域至少有一个目录、一个矩阵、一张图。缺哪个补哪个。

这张表可以直接当检查清单用。裁剪可以合并阶段，但不能让某个域只剩一张图。中文电子版的内容框架部分给了元模型，这张表是把元模型翻译成可检查的交付物。

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 总览和需求管理两处，其余按需查阅即可。

本文还有配套的精品资源，点击获取