用 TOGAF把IT系统画成一张图

TOGAF 企业架构引导图

很多公司的 IT 系统，都是"补丁叠补丁"长出来的。

十年前上一个 ERP，五年前上一个 CRM，三年前又上了个数据中台，去年还接了个 SaaS。等老板问一句："我们明年要上 AI 客服，现有系统撑不撑得住？"——会议室里没人答得上来。

业务侧说不清自己到底有哪些能力，技术侧说不清系统之间怎么连，财务更说不清每年几千万 IT 预算到底买了什么。

你缺的不是工具，而是一张能把"业务"和"技术"对齐的架构图。

我是老李。今天不讲虚的，我们直接用 TOGAF 这套业界最主流的企业架构方法论，从零开始，把"一团乱麻"画成"一张能用的架构图"。

本文覆盖三件事：TOGAF 到底是什么、它为什么能治"架构混乱病"、以及——重点——你怎么动手把图画出来，再顺手聊聊业界踩过的坑和最佳实践。

01、为什么你的架构永远画不清理

企业架构的四类典型痛点

先说清楚"病"在哪。绝大多数企业不是没有架构图，而是图太多、太散、太随意。

痛点一：业务和技术两张皮。业务画的是流程图，技术是部署拓扑，两者没有共同语言，对不上号。

痛点二：烟囱林立。每个系统自己一套数据、自己一套接口，A 系统和 B 系统要做个对接，先花三个月搞清楚对方字段含义。

痛点三：没有"现状"也没有"目标"。大家都忙着救火，从没坐下来画过"现在长什么样"（Baseline），更没画过"将来要长什么样"（Target）。

痛点四：图靠个人记忆。架构图在老王脑子、小白文档、还有三年前那份 PPT 里各存一份，谁离职谁就失真。

这些痛点的根，不是画图工具不好，而是缺少一套"统一的方法"——规定画什么、按什么顺序画、用什么语言画、画完放哪。这正是 TOGAF 要解决的。

02、TOGAF 到底是什么

TOGAF 三大支柱：ADM、四大域、内容框架

TOGAF（The Open Group Architecture Framework）是 The Open Group 推出的企业架构框架，最新版是 TOGAF 10（2022 年发布，前身是广泛使用的 9.2）。它不是某个具体软件，而是一套"怎么描述企业架构"的方法论和词汇表。

值得一提的是，TOGAF 10 相比 9.2 做了一个对新手极友好的改动：把原本厚厚一本"大部头"拆成了"基础内容（Fundamental Content）+ 系列指南（Series Guides）"的模块化结构。基础内容只占很小一块，讲透核心方法；数字架构、敏捷架构、安全架构等专题各自独立成册。这意味着你可以只学 20% 的骨架就开干，需要哪个专题再翻哪本——官方自己都在帮你"裁剪"框架。

TOGAF 的核心有三块：

第一，ADM（Architecture Development Method，架构开发方法）。这是 TOGAF 的骨架，一个可以反复迭代的闭环流程，告诉你从哪开始、画到哪结束。

第二，四大架构域。TOGAF 把企业架构切成四个层次，任何一张架构图都得落到某一层：

• 业务架构（Business）：能力、流程、组织、价值流；
• 数据架构（Data）：数据实体、数据流向、主数据；
• 应用架构（Application）：应用系统、服务、接口；
• 技术架构（Technology）：服务器、网络、中间件、部署。

第三，架构内容框架与存储库。TOGAF 规定了"交付物 / 制品 / 构建块"的分层，以及架构存储库（Architecture Repository）来统一存放所有架构资产，避免图散落各处。

一句话总结：TOGAF 给你一套"统一语言 + 统一流程 + 统一仓库"，让业务和技术终于能聊到一块去。

03、为什么非要上 TOGAF，而不是自己画

自画图的三大代价

有人会问：我直接拿 PPT 画不行吗？行，但有三个代价。

代价一：没有共同语言，跨团队必撕。两个架构师各画各的，一个用 UML、一个用脑图，评审会开成翻译课。TOGAF 提供标准化词汇，新人也能看懂老人的图。

代价二：没有流程，容易"一步到位"翻车。很多团队一上来就想画"完美的总架构图"，结果画了三个月还在改第 1 版。ADM 是迭代的，先画愿景、再逐步深入，每轮都有可交付物。

代价三：没有仓库，架构资产会腐化。图一旦画完就进档案，半年后没人信。TOGAF 的存储库 + 变更管理（Phase H）让架构持续保鲜。

当然，TOGAF 也有争议：它常被批评"太重""文档多"。我的建议是——取其骨架，丢其繁文。小团队用 ADM 的 Phase A～D 就够，别被全套交付物吓退。这恰恰是后面"业界最佳实践"要讲的重点。

04、TOGAF 怎么画图：ADM 周期与四大域

TOGAF ADM 迭代周期

这是全文最关键的一节：到底怎么动手画。

4.1 先画 ADM 周期，建立全局观

TOGAF 的 ADM 是一个环形迭代流程，中心是"需求管理"，外圈依次是：

• 预备阶段（Preliminary）：定原则、定范围、定治理；
• A 阶段（架构愿景）：对齐干系人、画出"我们要去哪"；
• B/C/D 阶段（业务 / 数据 / 应用 / 技术架构）：分别画四大域；
• E/F 阶段（机会与方案 / 迁移规划）：从目标架构反推落地路线；
• G/H 阶段（实施治理 / 变更管理）：保证落地不跑偏、架构持续演进。

画图的第一笔，不是画某个系统，而是把这个"环"画出来，让团队对"我们按什么顺序推进"达成一致。

这里有个新手常忽略的点：ADM 的迭代是有"粒度"的。最外层是架构能力迭代（先建立架构团队和治理），中间是架构开发迭代（A～D 画出目标架构），最内层是过渡规划迭代（E～G 分波次落地）。不要指望一圈跑完所有阶段——业界常见的做法是每 6～8 周跑完一个小迭代，每轮都产出能给干系人评审的图。

4.2 再按四大域分层画图

四大域不是四张孤立的图，而是一层层"服务"的关系：技术层支撑应用层，应用层实现数据层，数据层赋能业务层。业界主流做法是用 ArchiMate（同样由 The Open Group 维护）作为建模语言，它天生分 Business / Application / Technology 三层，关系用"服务 serving""实现 realization""分配 assignment"精确表达。

TOGAF 四大架构域分层示意

4.3 画图的三条铁律

铁律一：先 stakeholder，后图。先列出干系人和他们的关注点，再决定画哪种"视点（Viewpoint）"的图。不要为了画图而画图。

铁律二：先 AS-IS，再 TO-BE，最后路线图。先如实画现状（Baseline），再画目标（Target），两者差异就是差距分析，差距驱动迁移 roadmap。

铁律三：一张图只讲一件事。用"视点"把复杂系统切成多张小图（组织视点、服务视点、部署视点），而不是把所有东西塞进一张大图。

05、实战：从业务架构图到 4+1 视图

业务架构实战步骤总览

光说不练假把式。我们用一个真实场景走一遍：假设你要给"订单业务"画一张业务架构图，让产品、研发、老板都能看懂。

第一步：新建业务层视图并放置角色

第一步，打开 Archi（免费开源的 ArchiMate 工具）或 draw.io，新建一个 Business 层的视图（View）。不要一上来就拖系统框，先放"业务参与者（Business Actor）"和"业务角色（Business Role）"，比如"客户""订单专员""风控系统"。

第二步：用业务服务串起流程

第二步，用业务服务（Business Service）和业务流程（Business Process）把角色串起来："客户"触发"下单"流程，"订单专员"执行"审核"，"风控系统"提供"风险校验"服务。注意用 ArchiMate 的"服务"关系，而不是直接画一根普通箭头——这正是和 PPT 图的本质区别：关系有语义。

第三步：补充动机元素并导出

第三步，补上动机元素（Motivation）：在图旁边用"目标（Goal）"和"价值（Value）"标注"为什么要做订单业务"——比如"提升下单转化率"。这张图就不再是冷冰冰的框线，而是能向上汇报的架构资产。

最后导出为 PNG，连同源文件一起存进架构存储库。下次有人问"订单业务长啥样"，你不用翻 PPT，直接发这张带语义的图。

5.4 再进一步：用 4+1 视图把软件架构解剖开

业务架构图对齐了"为什么做、谁参与"，研发紧接着会问："落到系统上，订单服务到底长什么样？"回答这个问题，轮到软件架构领域最经典的视图模型登场——Philippe Kruchten 1995 年提出的 4+1 视图。它的理念和 TOGAF 的视点一脉相承：一张图只回答一类问题，四张视图分别服务四类人。

Kruchten 4+1 视图模型总览

逻辑视图回答"功能对不对"，面向最终用户。把订单领域拆成 Order、OrderItem、Customer、Payment、Inventory 几个类，谁包含谁、谁依赖谁，一张类图讲清楚。它是其他三张图的"功能基准"。

逻辑视图：订单领域对象模型

开发视图回答"代码怎么组织"，面向程序员。同一份逻辑，按 api / app / domain / infra 四层分包，铁律是依赖只许向下、domain 不依赖 infra（依赖倒置）。新人入职看这张图，就知道代码该往哪写。

开发视图：订单服务模块分层

进程视图回答"并发与性能"，面向系统集成者。下单同步链路只到"写库成功"，扣库存、发通知全部走 MQ 异步化。哪步同步、哪步异步、失败怎么重试，这张图说了算。

进程视图：下单链路的同步与异步

物理视图回答"部署与弹性"，面向运维。order-web 三副本加 HPA、order-worker 两副本消费 MQ、RDS 主从、Redis 集群，全落在 K8s 集群里。扩缩容、容灾、资源归属，看这张图就够。

物理视图：订单服务 K8s 部署拓扑

最后的"+1"是场景视图：用"用户下单"这个核心用例，把四张图串起来互相验证——逻辑视图里的 Order.pay()，在进程视图里对应同步写库加异步发事件，在物理视图里跑在 order-web 的 Pod 上，在开发视图里归 order-domain 包管。四张图讲的是同一个系统，场景就是那根线。

一句话分工：ArchiMate 管"业务到技术的对齐"，4+1 管"软件系统内部的解剖"。前者向上汇报，后者向下落地，两者在应用架构域交汇。

06、三个洞见：业界踩坑后的最佳实践

洞见一：把 TOGAF 当迭代而不是瀑布

洞见一：别把 TOGAF 当 waterfall，当迭代。最经典的反面教材是"先花半年写完美架构文档，再交给研发"。正确姿势是 ADM 小步迭代：先出 Phase A 愿景对齐老板，再带着研发画 B/C/D，边画边用。架构是"使能（enablement）"，不是"前置审批"。

这和互联网大厂的治理演进是同一个方向：从事前审批的"架构门禁（gates）"，转向内建于平台的"护栏（guardrails）"——把架构原则做成默认模板、合规检查和自动化流水线，让团队在对的路上自己跑快，而不是在评审会上排队等签字。TOGAF 的 Phase G 实施治理，完全可以落地成这种轻量护栏。

洞见二：ArchiMate 是一种语言不是画图工具

洞见二：ArchiMate 不是"更高级的 PPT"，而是一种语言。很多团队拿 ArchiMate 当画图工具，随便连箭头，结果和 PPT 没区别。它的价值在于关系语义（serving / realization / triggering）和分层约束（不能在业务层直接画服务器）。关系画错，图就失去架构意义。

洞见三：架构价值在仓库不在图本身

洞见三：架构图的价值在"仓库"不在"图本身"。一张图放桌面吃灰，等于零。建立轻量架构存储库（哪怕是 Notion + 统一命名 + 版本），让 AS-IS / TO-BE / Roadmap 可检索、可对比、可复用，架构资产才会越滚越大。

落地时推荐搭配一个轻量实践：ADR（Architecture Decision Record，架构决策记录）。每个关键决策用一页 Markdown 记下"背景—选项—结论—代价"，和架构图一起入库。半年后没人记得"当初为什么这么选"，图会过时，但决策记录不会说谎。很多团队的教训是：不是输在没画图，而是输在图的"为什么"随人离职一起消失了。

07、下一步：四步把 TOGAF 用起来

从零落地 TOGAF 的四步路线

如果你今天就想动，按这个顺序，每次只加一个变量：

第一步，选一个你最熟的域（通常是业务或应用），用 ArchiMate 画一张现状图。别贪多。

第二步，拉上两个干系人（一个业务、一个技术），用这张图对齐"我们说的同一件事"。

第三步，补一张目标图，做差距分析，产出一张迁移路线图。

第四步，把这三张图存进一个共享仓库，定个季度回顾机制。等这个小闭环跑顺，再扩展到其他域和完整 ADM。

记住：TOGAF 的对手从来不是别的框架，而是"永远不开始画"。

08、小结

我们用 TOGAF 把"乱成一锅粥"的 IT，重新梳理成"有方法、有语言、有仓库"的架构资产。

ADM 给出推进顺序，四大域给出分层视角，ArchiMate 给出统一语义，4+1 视图把软件系统解剖给不同角色看，存储库让这一切持续保鲜。

记住一句话：

企业架构不是一次画完的蓝图，而是一张能持续迭代、让业务和技术始终对齐的活地图。

当你能用同一套语言，让老板看懂目标、让研发看懂现状、让两者一起找到差距时，你就已经跨过了企业架构最难的入门门槛。

09、参考链接与概念说明

本文基于 TOGAF 10（The Open Group，2022）与 ArchiMate 3.2 规范整理，框架更新较快，落地细节请以官方文档为准。

• TOGAF 10 官方标准（The Open Group）
• ArchiMate 3.2 规范
• Archi 开源建模工具
• Kruchten 4+1 视图模型原始论文（IEEE Software, 1995）
• TOGAF ADM 概览（Wikipedia）

TOGAF：The Open Group 推出的企业架构框架，核心是 ADM 方法、四大架构域与架构内容框架。

ADM：架构开发方法，TOGAF 的迭代闭环流程，从预备阶段到变更管理，中心是需求管理。

四大架构域：业务、数据、应用、技术四层，自上而下相互支撑。

ArchiMate：The Open Group 维护的企业架构建模语言，分业务 / 应用 / 技术层，关系带语义，是 TOGAF 推荐的画图语言。

AS-IS / TO-BE：现状架构与目标架构；两者差异即差距，驱动迁移路线图。

视点（Viewpoint）：针对特定干系人关注点定义的架构图类型，一张图只回答一类问题。

4+1 视图：Kruchten 提出的软件架构视图模型：逻辑 / 开发 / 进程 / 物理四张视图，加一个把四者串起来验证的核心场景。

全文小结