企业官网建设流程全解析

简介：面向企业架构师及TOGAF实践者，这份基于TOGAF 9.1的制品模板合集，系统梳理了需求管理、业务架构、数据架构、应用架构与技术架构各阶段的核心交付物，涵盖目录、矩阵和图示三类典型制品。通过标准化架构输出的结构与语言，能够帮助团队在规划、设计、实施和治理环节保持一致性与可复用性，适用于正在落地企业架构方法论或需要快速搭建架构资产库的读者。压缩包内为单个pptx演示文稿，体积约15.4MB，模板包含各阶段制品示例、使用说明及改编方式，便于架构师结合实际工具和场景进行剪裁。目前已有410人学习下载，对于希望提升架构文档质量与协作效率的团队而言，是一份兼具参考价值和实操意义的配套资源。

1. 别再抱着一摞 TOGAF 书啃：一份制品模板才是项目里真正能用的东西

很多架构师第一次接触 TOGAF 9.1，第一反应是去读规范原文，读完 ADM 的十个阶段，合上书仍然不知道明天开会该先画哪张图、先写哪份文档。我见过太多团队在架构项目里花一半时间争论「这个阶段要产什么制品」，而不是讨论架构本身。TOGAF-V91-制品模板-v3.pptx这类文件解决的就是这个问题：它把 ADM 各阶段要输出的制品，提前整理成了可填写、可评审、可裁剪的演示文稿模板。你不需要从零发明交付物结构，只需要按模板填内容、按项目裁剪范围。这篇文章想讲清楚三件事：模板里装的到底是什么、怎么把它用进真实项目、以及用的时候最容易在哪些地方翻车。

2. 制品、交付物与模板结构：先把 9.1 的内容框架对齐

2.1 制品不是文档：Artifact、Deliverable 和 View 的关系

TOGAF 9.1 的内容框架里有一套容易混淆的概念，模板用不好，根源往往在这里。制品（Artifact）是架构内容的描述单元，它可以是一个目录（Catalog）、一张矩阵（Matrix）或一张图（Diagram）；交付物（Deliverable）是架构项目对外承诺的产出物，是评审、签约和验收的对象。一个交付物可以由多个制品组成，同一个制品也可以被多个交付物复用。视图（View）则是从某个利益相关者的视角出发对架构内容的呈现，它承载的是「给谁看、解决谁的什么关注点」。

我见过不少团队把「制品」和「文档」划等号，结果模板里的每一页都被当成一份独立文档去写，页与页之间内容大量重复，评审时说不清哪份是权威版本。正确理解是：制品是内容单元，文档是打包方式。一份架构说明书可以是交付物，但它内部应该包含若干个可独立维护的制品，比如组织分解图、业务服务目录、接口矩阵。模板的价值就在于，它把「制品 → 交付物 → 视图」的嵌套关系用每一页幻灯片固定下来了，你填的是制品内容，组合起来自然形成交付物。

这里还有一个关键点：视图是选出来的，不是画出来的。TOGAF 9.1 强调先识别利益相关者的关注点（Concern），再选择对应的视点（Viewpoint），最后才生成视图。模板里如果只是堆了一堆漂亮的架构图，而没有标注每张图服务于哪个关注点，那它对你项目评审的帮助非常有限。

2.2 v3 模板里通常装了什么：按 ADM 阶段组织的制品清单

一份成熟的 TOGAF 9.1 制品模板，通常不是按「公司介绍、现状描述、目标架构」这种文档逻辑组织的，而是按 ADM 阶段来组织。因为制品天然依附于 ADM 各阶段的产出要求，按阶段分页，架构师在推进到某个阶段时，直接打开对应分区开始填即可。一个 v3 版本的模板，大概率包含以下几个分区，它们的名称和内容顺序一般遵循 ADM 的推进节奏。

表格里这些制品名字，是 TOGAF 9.1 内容框架里比较常见的类型，实际模板可能命名略有差异，但骨架基本一致。v3 版本相比 v1、v2 的典型进步，在于页面上的引导信息更完整：每一页通常带「用途说明」「输入」「输出」「填写提示」四个区域。这也是判断一份模板是不是「能用的版本」的标志——如果每一页只有标题和空白文本框，那只是样式稿，不是工作模板。

2.3 为什么很多团队压在 9.1：版本差异与选型判断

现在 TOGAF 已经更新到了 9.2，甚至更晚的版本，但大量存量企业和咨询项目仍然以 9.1 为基线。这背后不完全是惰性，而是理性选择。9.2 在内容元模型上做了重组和精简，部分术语有调整，但 ADM 阶段流程和制品大类并没有颠覆性变化。已经按 9.1 建好架构资产库（术语表、模板、检查单、评审基线）的团队，升级到 9.2 意味着要重写一批模板和元模型映射，ROI 不如把精力花在项目交付上。

所以选型逻辑不复杂：如果你所在组织已经有 9.1 的存量资产和评审习惯，直接沿用 9.1 模板，不要为了「追新版本」而迁移；如果你是刚起步、没有任何存量，可以评估最新版本。这里的判断重点是「你的团队能用一套体系把架构项目跑完」，而不是追求版本号本身。模板的 v3 迭代，恰恰说明使用者已经过了「要不要用模板」的阶段，进入了「模板怎么改才好用」的深水区。

3. 把 v3 模板搬进真实项目：裁剪、起步与视图参数怎么调

3.1 动手前先裁一刀：哪些制品必须产出，哪些合并处理

TOGAF 明确支持对 ADM 进行裁剪（Tailoring），这是一个常被忽略但极其重要的能力。把整本模板原封不动搬进每个项目，结果就是项目组花了大量时间填无关紧要的页，核心决策反而没时间讨论。我的习惯是，拿到模板后先做一次「三分类」：必须产出、按需裁剪、明确删除。

判断标准主要看项目类型。比如做一个核心业务系统替换项目，业务架构阶段（阶段 B）的业务服务目录和业务场景是必须的，因为它是后续数据、应用架构的输入；而阶段 E 的机会与解决方案里的详细项目分组，如果项目边界已经明确，就可以简化成两页。再比如做一个技术平台整合项目，阶段 D 的技术架构制品就是重头戏，阶段 B 的业务架构可以压缩成一张上下文图加上一份业务服务目录，不必展开完整的企业业务流程分解。

这一步落地的操作方式，是在模板文件里直接删除或隐藏不需要的页面。我建议用「隐藏幻灯片」而不是物理删除，因为 v3 模板的元信息（比如备注里的填写指引）后面项目可能还用得上。裁剪完以后，在模板封面页或备注区记录一句裁剪说明：「本版本基于项目 X 裁剪，删除了阶段 F 的详细分册，保留到阶段 E。」这样下一轮评审时，别人不会质疑为什么少了某些标准页。

3.2 从复制文件到基线交付：五个可照做的起步步骤

把模板投入真实项目，我一般按下面五个步骤走，每一步都有明确的完成标志，避免「从第一天就陷入填 Word 式细节」的泥潭。

第一步，复制模板并按项目重命名。重命名的格式建议包含项目代号和版本，例如「客户名-项目名-架构制品-v1-日期.pptx」。不要把模板原文件直接拿来编辑，保证模板本身永远是干净基线。第二步，设置统一的术语与编号规则。打开模板的术语表页，把每个制品页的标题前缀改成「阶段号-制品类型-名称」，例如「C-矩阵-数据实体与业务服务映射」。这一步决定了后面所有页面的引用是否对得上。

第三步，建立制品的填写优先级。按 ADM 依赖关系排顺序：先做上下文和原则，再做业务架构，再数据、应用、技术。我把每个制品页的备注里都写了「前置制品编号」，比如阶段 C 的数据实体目录前置是阶段 B 的业务服务目录。第四步，每一页先填结论，再补过程。具体来说，每一页顶部先写一句话的结论，比如这张图画的是「库存域采用集中式数据模型」，再填充图和表。这样评审时快速翻页就能抓住关键判断。

第五步，生成第一版基线。所有必填制品页至少填到「有结论、有依据、待评审」状态，导出 PDF 存档，并在项目协作空间里建一个只读目录。第一次基线不需要完美，它的价值是把讨论从「该画什么」推进到「画得对不对」。

3.3 视图筛选参数：让每个利益相关者只看该看的东西

模板页面多了以后，很容易出现一种典型问题：一份上百页的架构文件发给所有人，业务负责人和技术负责人接收到的信息完全相同，评审会上各看各的，讨论失焦。TOGAF 9.1 的处理方式是用视图矩阵解决关注点差异。我在模板里固定放了一页「视图矩阵」，用一张表描述每个利益相关者对应哪些制品页。

这个矩阵不是给人看的装饰页，而是一个参数配置表。每次评审会前，按参会人身份筛选模板页，生成不同的评审子版本。比如给业务负责人的版本只保留架构愿景和业务场景，给技术团队保留数据、应用、技术三章全文。这个习惯能有效减少评审会上的「跑题式提问」，因为这些提问大多来自看了不该看的页面后的信息错位。

3.4 模板里最容易提前踩到的细节：备注区和封面元信息

这部分不是高阶理论，但实战中翻车概率最高。pptx 模板和 Word 文档最大的差别，是每一页的备注区域最适合放填写指引。很多架构团队把填写说明写在文本框里，结果影响版面布局，导出 PDF 后又显得很啰嗦。正确做法是把「这个制品描述什么、输入来自哪一页、输出给谁用」写进备注栏，正文只放内容框架和图表。配合演示文稿软件的分屏演示模式，填写者可以一边看指引一边填正文。

封面页的元信息也不要放过。我习惯在封面页加一个表格，记录：项目名称、架构师、基线日期、版本号、裁剪说明。很多模板的 v3 迭代失败，不是模板结构不好，而是封面元信息缺失，三个月后翻查文件根本不知道这是哪个项目的版本、基于什么裁剪、评审到哪一轮。

4. 模板套用中的五个高发踩坑场景与排查办法

4.1 模板成了改名游戏：内容还是旧的 SOP 和方案书

现象：项目组把模板文件复制进去，每一页标题都按模板改了，但正文内容却直接从上一份项目文档里复制粘贴，页面上充满了「因此」「综上所述」这类方案书语言，没有任何架构图和数据表。评审时评审人翻了几页就问：「这些页面到底是不是按模板要求重新组织的？」

原因：团队没有理解「制品」是结构化内容单元，以为模板页只是换了排版格式的文档封面。本质上是把模板当成格式皮肤，而不是内容框架。

解决：治理手段比培训更有效。在评审检查表里加两条硬门槛：一是所有目录类制品必须用表格呈现，禁止大段叙述文字；二是每个制品页必须标注输入来源页编号，找不到来源的制品视为无效。这两个约束一落地，改名游戏基本就停了。

4.2 视图与制品混着写：一张图里塞了三个视角

现象：某份业务架构图里，既画了业务流程，又标了系统部署节点，还写上了项目阶段里程碑。画的人觉得一张图信息全，看起来高效。评审时不同角色的关注点互相干扰，业务说看不懂技术标记，技术说业务流程挤占了部署信息。

原因：没有区分视图与制品。视图是面向关注点的投影，一个制品页应该只回答一个关注点。把多个关注点塞进一张图，本质上是偷懒，想把讨论推迟到评审现场。

解决：遇到想画「大而全」的图，先停一下，回到视图矩阵，确认这张图服务于哪个利益相关者的哪个关注点。如果确实有三个关注点，就拆成三张图，哪怕内容有重叠也没关系，这是视图的合法性所在。模板里预设的页面不够用就复制页面，不要在原有页面上叠加信息。

4.3 产出物和 ADM 阶段对不上：业务阶段画了技术图

现象：项目推进到阶段 B 业务架构时，交付内容里出现了完整的网络拓扑图和服务器集群规划。追问之下，团队说反正是要给甲方看的，提前把后面的图画了。结果阶段 D 真正启动时，业务约束变了，之前画的拓扑图全部返工。

原因：把 ADM 阶段当成「必须完整体验一遍的流程」，而不是依赖严格的阶段治理。跨阶段产出本身不一定错，但没有任何机制约束「按当前阶段基线的输入来画」，导致后续阶段的制品被建立在尚未定稿的前置制品上。

解决：在每个制品页备注里写上「本页的前置基线版本」。技术架构图的前置基线应该是定稿的应用通信图，如果应用架构还没评审通过，拓扑图只能标注「草稿-依赖未定稿输入」。评审时优先检查这种跨阶段依赖是否有基线支撑，没有的一律打回。

4.4 版本号彻底失控：v3 被改成了「v3_真_最终版」

现象：模板文件名从 v3 变成 v3 改、v3 改 2、v3 最终、v3 最终真，目录里躺着七八个相似文件。等到项目中期，谁也说不清当前基线是哪一份，最后只能按文件修改时间猜，猜错后全部返工重来。

原因：版本管理没有规则，或者有规则没执行。模板文件是项目资产的载体，但团队没把它当代码管理，而当成普通文档用「另存为新文件名」的方式管理。

解决：把模板文件纳入和代码一样的基线管理习惯。每次基线变更必须满足三个条件：有评审意见记录、有变更内容说明、有新的版本号。文件命名只允许「项目名-制品-版本号-日期」的格式，任何人要改内容，先从当前基线复制出工作副本，完成后由指定人合并回基线。这一条一开始执行会有点痛苦，坚持两轮评审就顺了。

4.5 只有模板没有元模型：项目一结束，模板就从资产变库存

现象：项目交付后，模板被束之高阁。下一个项目来了，又要重新拉团队理解模板每一页的用法。模板里的术语在不同项目里含义漂移，比如「服务」有时候指业务服务，有时候指接口服务，评审争论半天。

原因：模板是内容框架的载体，但团队没有把模板背后的元模型（术语定义、实体关系、属性）抽出来。没有元模型，模板就是一堆孤立的页面，换项目换人后无法形成一致语言。

解决：在模板里固定放一页「术语表」和「制品关系图」。术语表每新增一个术语必须同步更新；制品关系图示出每个制品的输入输出依赖，例如「应用通信图 ← 数据实体目录 + 业务服务目录」。这一页不需要画得多专业，它的作用是让模板每个项目都能从同一套语言逻辑开始，而不是每次重新发明。

5. 让模板长成架构资产库：三个见效快的进阶习惯

第一个习惯：用脚本对模板做定期体检，而不是靠肉眼翻页检查。引入熟悉办公文档处理的脚本库，写一段不复杂的程序，遍历模板所有页面，读取备注区内容和表格标题，自动标记「空白页」「无备注指引页」「标题重复页」。这个体检每周跑一次，能把「翻车在评审现场」变成「翻车在电脑桌面」，成本很低，收益立竿见影。脚本本身不要追求复杂，能输出一份缺失清单就够了，重点是把体检变成固定动作。

第二个习惯：把每次项目的裁剪决定记录回模板里。项目评审时删除、合并、新增的页面，全部在模板封面页的裁剪说明中留痕。积累两三个项目后，你会得到一份「哪些制品页在哪些场景下被裁剪」的经验表，这比任何外部咨询都更有价值。下次接到同类项目，启动阶段就能直接给出建议范围，而不需要重新讨论。这个习惯也让模板从「标准模板」逐渐演化成组织的「架构资产库」。

第三个习惯：从常用制品反推最小元模型。不用追求覆盖 TOGAF 全部元模型实体，只挑项目里反复用到的那批制品，比如业务服务目录、数据实体目录、应用通信图，把它们的命名规则和引用关系固定下来。哪怕只写了十几条术语定义，也会让跨项目沟通顺畅很多。最怕的是术语表一百多条但没人用，那比没有还难维护。

最后说一个我自己的教训：早年在某公司做架构项目时，我们拿到模板先做的第一件事不是填内容，而是请了一位同事把所有页面都填满了占位文字，让文件看起来「完成度很高」。结果第一次评审，评审人随机点开一页问视图来源，那位同事答不上来，整个团队花了两周重做。从那以后我定了一条规矩：模板可以留白，但不能造假；页面可以不美，但每个制品必须说得出它的输入和消费者。希望这份模板相关的经验，能帮你在下一个架构项目里少走一段弯路。

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