TOGAF on 文艺技术笔记

企业架构四大视图：业务、应用、数据、技术怎么串成一个整体

Thu, 18 Jun 2026 21:20:00 +0800

企业是一个复杂的系统。几百个业务流程、几十个应用系统、上千张数据表、成堆的服务器和中间件——如果不做拆分，没有人能一次性把它看清楚。

TOGAF 的做法是把它拆成四个视图，每个视图回答一个不同的问题：

视图	核心问题	关键词
业务架构	企业靠什么流程创造价值？	流程
应用架构	系统之间怎么交互协作？	交互
数据架构	数据怎么统一定义和管控？	统一
技术架构	基础设施怎么共享复用？	共享

四个视图不是孤立的四份文档，而是一条从上到下的设计链路。下面逐个展开。

一、业务架构：一切皆流程

TOGAF 对业务架构有一个很直白的判断：万般业务皆流程。不管你是制造企业还是金融机构，最终创造价值的载体就是流程。业务无止境，流程出效益——流程决定了业务的价值目标，也决定了组织机构怎么设置。

很多人把业务架构等同于"画流程图"，这是最大的误解。流程图只是表达工具，业务架构真正要做的是回答三个问题：有哪些业务？每个业务怎么运转？谁来执行？

IPOGR 模型

每个业务流程都可以用 IPOGR 来拆解：

I（Input）：流程的输入是什么
P（Process）：处理逻辑是什么
O（Output）：输出是什么
G（Goal）：这个流程要实现的价值目标
R（Role）：谁来做，对应什么组织结构

举个例子——“客户贷款审批"这个流程：

要素	内容
I	客户提交的贷款申请材料
P	风控审核 → 额度计算 → 审批决策
O	审批结果（通过/拒绝/补件）
G	控制坏账率、提升审批效率
R	风控岗、审批岗、合规岗

流程本身就是 IPO，G 决定了这个流程存在的理由，R 决定了谁来执行。

三步设计法

业务架构的设计有一套总体法则：

一步定清单：梳理多级流程清单，从 L1 价值链到 L2 业务域再到 L3 具体流程
二步定流程：对每个流程用 IPO 模型做详细建模
三步定组件：把流程活动定义成可复用的业务组件

❌ 常见错误：直接从组织结构出发画流程图——组织会变，流程的价值链不会轻易变。

✅ 正确做法：先识别价值流，再映射到流程，最后才落到岗位和组织。

二、应用架构：开放互联标准化

业务架构定义了"做什么”，应用架构回答"用什么系统来做、系统之间怎么配合"。

TOGAF 对应用架构的核心原则是两句话：

开放互联标准化——系统之间的接口要走公开标准，不搞私有协议
协同访问总线化——系统间的通信走统一的服务总线，不搞点对点网状调用

三步设计法

一步汇总做分割：把所有业务功能需求汇总，按功能域做逻辑分割
二步分划定应用：根据分割结果划定每个应用系统的边界
三步组件做归约：识别可复用的服务组件，合并同类项

❌ 常见错误：一个部门建一个系统，系统边界跟着组织走，结果是烟囱林立。

✅ 正确做法：先按业务能力做功能归集，再划定应用边界，最后抽象共享服务。

举个例子：CRM 系统、订单系统、财务系统都可能涉及"客户信息管理"功能。应用架构的任务就是把这个共性功能抽出来做成共享的客户主数据服务，而不是让三个系统各自维护一份。

实际操作中，“协同访问总线化"这一点经常被忽视。很多企业的系统对接方式是 A 系统直接调 B 系统的数据库、B 系统再反向调 C 的接口，最后形成一张蜘蛛网。上了企业服务总线（ESB）或 API 网关之后，所有调用走统一通道，监控、限流、鉴权都有了抓手。

三、数据架构：统一管控

应用架构解决了系统怎么交互，数据架构解决的是另一个层面的问题：不同系统对同一个业务实体的描述必须统一，管控必须集中。

两个统一

数据描述统一化：同一个概念（比如"客户”、“订单”）在所有系统里有统一的定义、统一的编码、统一的口径
数据管控统一化：数据的质量、安全、生命周期由统一的治理体系来管

四个质量维度

数据统一管控具体体现在四个维度：

维度	含义	反面例子
完整性	该有的数据不能缺	客户手机号字段 30% 为空
保密性	敏感数据要分级管控	员工薪资表存在共享盘上
一致性	同一数据在各处要一致	CRM 和财务系统的客户地址对不上
可用性	数据要能被及时获取	报表取数要等三天批处理

元模型设计三步法

一看异构找同构：梳理各系统的数据现状，找出不同实现背后的共同语义
二看本质定模型：抽象出企业级概念模型（主题域 → 实体 → 属性）
三看将来找支持：评估模型是否能支撑未来业务扩展

❌ 常见错误：直接抄某个系统的数据库表结构当企业数据模型。

✅ 正确做法：跨系统做语义对齐，建立独立于具体系统实现的企业概念模型。

举个实际的例子：某零售企业有 POS 系统、电商系统、会员系统三个地方都存了"商品"信息，但字段名不同、编码规则不同、品类分类也不同。数据架构的第一步就是把这三个"异构"的商品定义对齐，找到共同的语义——商品编码、商品名称、品类、规格、价格这些本质属性，然后建立统一的商品主数据模型。

四、技术架构：建平台、定标准、成体系

技术架构的核心思路是找共性、做共享。具体来说：

共性业务能力沉淀为业务平台（如统一用户中心、统一审批引擎）
共性应用能力沉淀为应用平台（如 API 网关、消息中间件）
共性数据能力沉淀为数据平台（如数据湖、主数据管理系统）

设计四步走

识别技术组件：梳理当前和未来的技术需求，列出需要的技术组件清单
技术组件分类：按基础设施、中间件、开发框架、运维工具等维度归类
平台设计：把同类组件整合成技术平台，确定部署架构
标准设计：制定技术标准（协议、接口规范、安全基线等）

三个面向

面向	要求
面向应用	按应用的分割划分来提供技术支撑
面向业务	弹性可扩展，业务量翻倍时不用推翻重来
面向数据	管理体系化，存储、计算、治理有统一方案

统筹规划找共性，集约建设找集中，低成本靠云平台。总结成一句话就是：建平台、定标准、上应用、成体系。

这里有一个容易踩的坑：技术架构不是"选技术"，而是"定标准"。选什么数据库、用什么框架，这些是项目层面的决策；技术架构要回答的是——企业级的技术栈怎么收敛、标准怎么统一、平台怎么共享。十个项目用十种消息中间件，运维成本会把人拖死。

五、四个视图怎么串起来

四个视图不是并列关系，而是一条逐层落地的设计链路：

业务架构（流程决定需要什么能力）
    ↓ 驱动
应用架构（能力拆成系统和服务）
    ↓ 承载
数据架构（系统交互的数据统一定义和管控）
    ↓ 落地
技术架构（为上层提供共享的基础设施平台）

一张表总结四个视图的设计要点：

视图	设计原则	设计步骤	核心交付物
业务架构	一切皆流程	定清单 → 定流程 → 定组件	流程清单、IPO 模型、业务组件
应用架构	开放互联标准化	汇总分割 → 划定应用 → 组件归约	应用地图、接口规范、服务目录
数据架构	数据统一管控	异构找同构 → 定模型 → 看将来	概念模型、数据标准、治理规则
技术架构	共享复用	识别组件 → 分类 → 平台设计 → 标准设计	技术平台、技术标准、部署架构

六、常见的脱节问题和修复思路

实践中四个视图经常脱节，几种典型情况：

❌ 业务架构和 IT 两张皮 业务部门画的流程图，IT 部门根本没法用。原因：流程没有定义到可执行的活动粒度。 ✅ 修复：业务架构做到 L3 级，每个活动都要能回答"由哪个系统/角色来执行"。

❌ 应用架构脱离业务 系统建了一堆，但业务流程跑不通。原因：应用边界是按部门划的而不是按业务能力划的。 ✅ 修复：用业务能力地图（而非组织架构图）来指导应用分割。

❌ 数据架构事后补做 系统上线了才开始做数据治理，到处打补丁。原因：数据架构没有和应用架构同步设计。 ✅ 修复：在应用架构阶段就同步定义数据模型和数据流向，数据架构前置。

❌ 技术架构过度设计 建了一个庞大的技术平台，但没几个应用用得上。原因：技术架构没有从上层需求倒推。 ✅ 修复：技术组件的选择必须由业务、应用、数据三个视图的需求来驱动，不是技术团队自己拍脑袋。

七、写在最后

做好企业架构设计，对架构师的要求可以归结为一个公式：

架构设计能力 = 懂战略 + 懂流程 + 懂 IT + 面向未来

懂战略，才能知道业务架构要往哪个方向走；懂流程，才能把战略分解成可执行的业务活动；懂 IT，才能让应用、数据、技术三个视图真正落地；面向未来，才能让架构有足够的弹性承接变化。

四个视图不是写四份文档交差，而是一个连贯的思考过程——从"企业要怎么赚钱"一直想到"服务器要怎么配"。能把这条链路走通的架构师，才算真正入门了。

架构治理不是走审批流程：TOGAF 治理机制怎么真正落地

Thu, 18 Jun 2026 21:15:00 +0800

你公司的架构治理，是不是就是开会签字？

每个搞企业架构的人大概都经历过这种场景：一个项目上线前，拉一堆人开个评审会，PPT 放了四十分钟，架构委员会的人点头说"可以"，签个字，散会。至于后面开发团队是不是按评审的方案做的——没人管，也没人查。

❌ 有标准，但没人对着标准逐项检查。 ❌ 评审完就扔，问题没人跟踪闭环。 ❌ 变更靠领导拍脑袋，没有真正的业务动机驱动。

这不叫架构治理，这叫走审批流程。

TOGAF 对架构治理的定义其实很明确：一个主体（治理委员会）、一个目的（找偏差）、一个行为（合规检查）、一个依据（检查单）。四要素缺一不可，缺了任何一个，治理就变成形式主义。

治理六步法：一识、二度、三量、四称、五术、六循环

TOGAF 把治理行为拆成了六个递进的动作，我称之为"治理六步法"：

步骤	名称	做什么
一	识	识别偏差——实施结果和架构设计之间哪里对不上
二	度	筛选偏差——哪些偏差值得管，哪些可以放过
三	量	量化影响——这个偏差会造成多大范围的后果
四	称	权衡利弊——修正的成本 vs 放任的风险
五	术	给出改进建议——不是光说"不行"，要给出可行方案
六	循环	定期复查——治理不是一次性的，是周期性行为

很多公司死在第一步和第六步：从来不主动找偏差，找到了也不回头复查。

举个例子：一个微服务拆分方案评审通过后，开发团队为了赶进度，把两个本该独立的域合并部署了。如果治理专员在"识"这一步就去看部署拓扑图，偏差当场就能抓住。但大多数公司等到上线后出了耦合问题才发现——这时候修正成本已经翻了好几倍。

治理的三条线：前端、中间、后端

架构治理不是只在项目快上线时才介入。按治理行为发生的位置，分三段：

阶段	治理行为	关注点
前端	专题架构设计评审	方案本身是否合理，是否符合企业架构原则
中间	项目需求分析与设计阶段介入	需求拆解有没有偏离架构意图
后端	项目验收交付	交付物是否与架构设计一致

❌ 大多数公司只做后端验收（而且验收也很敷衍）。 ✅ 真正有效的治理是从设计阶段就开始介入，全程跟踪。

前端治理的核心问题是：你的架构方案有没有违反企业级的架构原则？比如明明规定了所有对外接口必须走统一网关，你的方案里是不是又搞了一套自建鉴权？这种问题在设计阶段发现，改一张图的事；到了上线前才发现，就是改一套系统的事。

中间治理容易被忽略，但它恰恰是偏差产生的高发区。需求拆到开发任务的时候，开发团队往往会"简化"架构设计——把异步改成同步、把事件驱动改成 RPC 调用、把共享服务改成独立实现。如果没有人在这个阶段盯着，架构设计就变成了一纸空文。

架构治理专员：这个角色的日常工作是什么？

“架构治理专员"不是挂名头衔，这个角色有五个具体动作：

选定治理对象——哪些系统、哪些项目纳入治理范围
撰写架构契约——把架构约束写成明确的契约条款
与责任者达成契约——跟项目负责人确认并签署
跟踪验证——对象产生时（代码提交、部署上线），对照契约逐项检查
发起变更并给出建议——发现偏差时，不只是报告问题，要提出改进路径

另外，这个角色需要的能力模型叫四通：

一通：业务战略与流程——你得知道公司要往哪走
二通：IT 技术判断——能判断技术选型是否合理
三通：迁移优先级——知道什么先做什么后做
四通：治理流程——熟悉合规检查的方法论

说白了，这个人得既懂业务又懂技术，还得会写契约、会跟踪、会推动。不好找，但这个角色一旦缺位，治理就是空转。

一个常见的误区是把架构治理专员等同于 QA。QA 关注的是功能和缺陷，治理专员关注的是架构意图是否被正确实现。两者的检查对象、检查依据、产出物完全不同。如果你的公司让 QA 兼任架构治理，基本等于没人做治理。

架构评审：三种形式，你是哪一种？

评审会上有三种角色：总体组（组织者）、架构设计师（设计与修改架构）、架构委员会（评审与反馈）。评审的四个步骤是：疑则问、问则议、议则果、果则行——有疑问就提出来，提出来就讨论，讨论完要有结论，结论要落地执行。一个目标：求改进。一个依据：检查单。

但现实中，评审会的质量差异巨大。按形式分三种：

形式	特征	效果
签字型	走流程、签个字、存档	❌ 零价值
问题型	能发现问题，但没人跟进	⚠️ 发现但不闭环
改进型	发现问题、跟踪整改、复查验证	✅ 真正有效

你的评审会是哪种？如果是签字型，建议直接取消，省下的时间让团队多写几行代码。

中后期验证：各层架构到底看什么？

项目做到中后期，治理验证的重点因架构层而异：

架构层	验证重点
业务架构	需求实现是否选择了业务构件化模式
应用架构	是否实现了产品级复用，而非项目级烟囱
数据架构	异构系统的集成策略和数据管理是否到位
技术架构	平台推广情况、技术标准是否落实

这些不是抽象的原则，每一条都可以拆成检查单上的具体条目。比如应用架构验证，你可以直接问：这个模块有没有调用已有的公共服务？还是又自己造了一个轮子？数据架构验证，直接查：跨系统的数据同步用的什么方案？有没有统一的数据治理策略？

架构变更：主动预测 vs 被动救火

架构变更有两个来源：

主动变更：治理过程中预测到的变化，提前规划
被动变更：出了事故之后被迫请求的变更

❌ 多数公司的变更管理 = 领导决策制，没有真正的业务动机分析，出了问题才改。 ✅ 好的治理应该在巡检阶段就能识别出架构腐化的趋势，主动发起变更。

举个实际场景：你发现某个核心服务的响应时间在过去三个月持续上升，虽然还没触发告警阈值，但趋势明显。主动变更的做法是现在就启动优化或重构计划；被动变更的做法是等到某天凌晨被 oncall 电话叫醒，然后紧急 patch。

主动变更的驱动力来自治理过程中的持续观测，被动变更的驱动力来自生产事故。两者的修复成本差一个数量级。

常见反模式与修复方案

反模式	表现	修复方案
有标准无检查	写了一堆规范文档，从没人对着检查	建立检查单机制，每次评审逐条过
变更靠拍脑袋	领导说改就改，没有影响分析	变更前必须做"量"和"称"两步
评审缺专家	评审委员会的人不懂具体技术	引入外部专家或培养内部架构师梯队
信息不对称	项目组懂细节，评审的人只看到表面	评审前做架构走查，不只看 PPT
问题不闭环	评审提了一堆问题，没人跟踪	指定治理专员负责跟踪验证
项目组信息壁垒	项目组内部清楚，外部评审者看不到真相	评审前安排架构走查，深入代码和配置，不只看汇报材料

写在最后

架构治理的本质不是合规检查打勾，而是持续改进。

一识二度三量四称五术六循环——这个框架的核心词是循环。治理不是一次性的动作，是嵌入到项目生命周期里的持续行为。每轮循环都应该比上一轮更高效，因为你在不断积累经验、优化检查单、提升团队能力。

如果你的架构治理目前还停留在"开会签字存档"的阶段，不用急着一口气推翻重来。先做一件事：给每次评审加一张检查单，指定一个人负责跟踪问题整改。从这一步开始，治理就从形式主义变成了真正有用的东西。

检查单不需要一开始就完美。先列出你团队最常犯的五个架构偏差，每次评审对着这五条过一遍。跑几轮之后，你自然知道该往检查单里加什么。治理能力的建设本身也是一个循环——先跑起来，再迭代优化。

TOGAF 价值流映射：用客户视角重新审视你的业务架构

Thu, 18 Jun 2026 21:05:00 +0800

大多数企业架构工作都是从内部开始的。我们梳理系统、画流程图、定义服务边界，本质上都是在回答"我们怎么干活"。架构评审会上讨论最多的问题也是"这个系统的边界在哪"、“这个服务该归哪个团队”。这些都对，但有一个盲区：客户不关心你怎么干活，他只关心你给他交付了什么。

一个典型的场景：业务部门提了一个新需求，架构师的第一反应是"哪个系统来承接"、“数据怎么流转”、“接口怎么设计”。这些都是执行层面的问题。但在回答这些之前，有一个更根本的问题被跳过了——这个需求在客户的价值链条上处于什么位置？它是在帮客户完成一个完整的价值交付，还是只是内部视角下的一个功能点？

TOGAF 里的价值流（Value Stream）就是用来补这个盲区的。它强制你从客户视角出发，倒推企业需要哪些能力来交付价值。方向反过来：不是"我有什么能力就用什么"，而是"客户需要什么价值，我就得有什么能力"。

什么是价值流

价值流是一组端到端的增值活动，最终为客户或利益相关者交付一个完整的、可感知的结果。注意关键词：端到端和可感知。一个孤立的内部操作不算价值流，它必须从客户触发开始，到客户获得价值结束。

TOGAF 定义了价值流的四个标准元素：

元素	说明
名称	动词+名词结构，如"采购商品"、“招聘员工”
描述	这条价值流做什么，边界在哪
利益相关者	谁触发了它，谁从中获益
价值	交付了什么具体结果，用什么衡量

每条价值流可以拆解为多个阶段。每个阶段除了名称和描述，还包含进入条件（什么情况下启动这个阶段）、退出条件（什么情况算完成）、以及该阶段贡献的具体价值项。这些条件很重要——它们是判断流程是否真正衔接的标准，而不是画完箭头就完事。

价值流不是业务流程

这两个概念经常被混用，但方向完全不同：

维度	价值流	业务流程
视角	自外向内（客户视角）	自内向外（运营视角）
关注点	交付了什么价值	怎么完成任务
粒度	粗，面向战略层	细，面向执行层
稳定性	相对稳定，随商业模式变化	频繁调整，随运营优化变化
典型用途	识别能力缺口、对齐战略	流程自动化、效率优化

还有一个容易混淆的概念是价值链（Value Chain）。价值链来自波特，是经济学视角，把企业活动分为主要活动和支持活动。价值网络则从参与者角度描述价值交换关系。精益价值流专注制造业中的浪费消除。它们各有适用场景，不要混着用。

怎么做价值流映射

步骤不复杂，但需要克制——别一上来就画二十个阶段。

第一步：识别外部价值流。 从客户和利益相关者出发，列出企业对外交付的核心价值流。一般 5-10 条足够覆盖主要业务。零售企业可能有"采购商品"、“获取客户”、“处理退货”；服务企业可能有"签约客户"、“交付服务”、“续约管理”。

第二步：分解阶段。 每条价值流拆成 4-7 个阶段。每个阶段有清晰的进入和退出条件。以电商"采购商品"为例：

`1`	`发现商品 → 比较选择 → 下单支付 → 等待交付 → 使用评价`

每个阶段不是内部的操作步骤，而是客户经历的一个状态转换。“等待交付"对客户来说是一个真实的阶段，虽然内部可能涉及物流、仓储、配送等多个流程。

第三步：映射能力到阶段。 把你已经梳理好的业务能力（Business Capability）挂到对应的价值流阶段上。这一步的目的是回答：为了完成这个阶段，企业需要哪些能力？

比如"比较选择"阶段可能需要：商品推荐能力、价格比较能力、用户评价管理能力。“下单支付"阶段需要：订单处理能力、支付网关能力、库存实时查询能力。

一个具体例子

假设你在做一家在线教育平台的业务架构。核心外部价值流之一是"学习课程”：

阶段	进入条件	退出条件	阶段价值
发现课程	用户有学习意图	用户找到目标课程	匹配需求
评估课程	用户进入课程详情	用户做出购买决策	降低决策成本
购买课程	用户决定购买	订单完成、权限开通	获得访问权
学习课程	用户开始学习	用户完成课程内容	获得知识/技能
获得认证	用户完成考核要求	证书发放	可验证的成果

然后把业务能力映射上去。“学习课程"阶段可能需要：内容分发能力、进度追踪能力、互动答疑能力、离线缓存能力。“获得认证"阶段需要：考核评估能力、证书生成能力、第三方验证能力。

注意这里的映射是多对多的。“用户身份管理能力"可能同时出现在"购买课程"和"获得认证"两个阶段，而"学习课程"阶段可能需要五六个能力的协同支撑。这很正常——能力是组织级的，价值流阶段是场景级的，它们之间不存在一一对应关系。

映射过程中你会自然发现一些问题：某个阶段挂了七八个能力，说明这个阶段复杂度很高，值得单独拆解；某个能力挂了所有阶段，说明它可能是平台级能力，应该下沉到共享服务层。

热力图：找到能力短板

映射完成后，画一张价值流×能力的交叉矩阵，就是热力图。行是价值流阶段，列是业务能力，交叉点标注能力的成熟度：

🟢 成熟：能力完备，能支撑该阶段
🟡 发展中：有能力但不完善
🔴 缺失或薄弱：关键缺口

这张图的价值在于：它能直接告诉你，哪些能力投资能产生最大的客户价值回报。如果"学习课程"阶段的离线缓存能力是红色，而你们有 40% 用户在移动端学习，那这个缺口就直接影响了核心价值的交付。

反过来，热力图也能暴露冗余——某个能力被标记为绿色但没有挂在任何价值流阶段上，说明它可能不直接创造客户价值。不是说要砍掉，而是需要重新审视它的定位：它可能在支撑内部价值流（如"管理合规”、“优化运营”），只是不在外部客户视角内。

实操中热力图最大的价值不是那张图本身，而是画它的过程。你需要和业务方一起逐个讨论每个交叉点的成熟度，这个过程本身就是对齐——技术团队认为"已经做得很好"的能力，业务方可能觉得完全不够用。分歧暴露出来，优先级就清楚了。

一个建议：别试图一次性把所有价值流和能力都放进热力图。挑一条最核心的外部价值流，聚焦在它的关键阶段上，做深做透，再逐步扩展。

几个实操原则

从外部价值流开始，别从内部流程倒推。先想客户要什么，再想你需要什么能力。
保持简洁。 价值流阶段不是工作流步骤，4-7 个阶段足够。如果你画了 15 个阶段，那你在画流程图，不是价值流。
价值流不等于能力。 价值流是"做什么”，能力是"能做什么”。一个是活动序列，一个是组织具备的本领。它们是多对多关系。
别追求完美覆盖。 先把核心价值链画出来，识别出最明显的能力缺口，这比一张面面俱到但没人看得懂的图有用得多。

写在最后

价值流映射不是一个独立的架构活动，它是连接战略和执行的桥梁。战略规划告诉你"我们要进入什么市场、服务什么客户”，价值流把这个战略翻译成"我们需要交付什么价值"，能力映射再把它翻译成"我们需要建设什么能力"。

三层对齐之后，技术架构的决策就有了锚点。你知道为什么要投某个系统、为什么某个服务要优先重构、为什么某个能力的数字化比另一个更紧迫。不是因为技术团队觉得它酷，而是因为客户价值链条上的某个阶段在等着它。

这才是业务架构该有的样子：不是为了画图而画图，而是让每一行代码都知道自己在为谁创造价值。

TOGAF ADM 方法精要：8个阶段串起企业架构全景

Thu, 18 Jun 2026 21:00:00 +0800

做企业架构绕不开一个方法——ADM（Architecture Development Method）。它是 TOGAF 框架里真正"能落地"的部分，也是全球使用最广泛的企业架构方法论。不管你是考 TOGAF 认证，还是在公司里推架构治理，ADM 都是绑在腰带上的基础工具。

很多人把 ADM 当成考试知识点背完就扔，这是最大的浪费。它的设计初衷是给架构师一套可重复、可裁剪的工作流——从愿景到变更，每个阶段该干什么、交付什么、怎么衔接，都有明确的锚点。

一张图看懂 ADM 全貌

ADM 的核心结构可以用一句话概括：一备、一中心、八步一方法。

组成部分	内容	定位
预备阶段（Preliminary）	定支持、定接受，搞定组织和治理前提	地基
需求管理（中心）	需求登记 + 能力验证，贯穿全程	心脏
A 愿景	定方向、定范围	起点
B 业务架构	看流程	骨架
C 信息系统架构	数据架构看统一 + 应用架构看交互	血管
D 技术架构	看共享	基础设施
E 机会与方案	紧迫性 × 方案成熟度	选项池
F 迁移规划	排序 + 发布节奏	路线图
G 实施治理	合规与偏差管控	护栏
H 架构变更	变更评估、触发新一轮	闭环

注意 A-D 阶段定义架构本身（“是什么”），E-H 阶段定义如何落地（“怎么做”）。前四个阶段产出基线架构和目标架构，后四个阶段把差距转化为可执行的项目。

四个架构域：各看什么？

架构域	核心关注	一句话
业务架构	流程	业务怎么跑
应用架构	交互	系统之间怎么对话
数据架构	统一	数据怎么一致
技术架构	共享	基础设施怎么复用

这四个域不是孤立的。业务架构驱动应用架构，应用架构依赖数据架构，数据架构跑在技术架构之上。自顶向下设计，自底向上验证。

逐阶段拆解

预备阶段（Preliminary）

核心任务：确认组织具备架构能力——人、流程、工具到位，治理层认可。

关键交付物：架构能力框架、架构原则、组织承诺。

❌ 跳过预备直接画架构图 ✅ 先拿到管理层签字和资源承诺，确定架构治理的边界和权责

需求管理（中心）

这不是某个阶段，而是贯穿始终的脉搏。需求为准做登记，能力导向做验证。每一轮 ADM 循环都从需求出发，以需求校验收尾。

❌ 把需求管理当成 A 阶段的子任务，做完就丢 ✅ 每个阶段都要回到需求中心做校准，确保架构演进不偏离业务诉求

阶段 A：架构愿景

核心任务：定范围、定利益相关方、拿批准。

关键交付物：架构工作请求、愿景文档、利益相关方地图、架构工作说明书。

❌ 范围太宽，想一次搞定整个集团数字化转型 ✅ 划定边界，明确"这次做什么、不做什么"，拿到关键干系人的正式签字

阶段 B：业务架构

核心任务：梳理业务流程，建立基线（当前状态）和目标（未来状态），做差距分析。

关键交付物：业务流程模型、基线/目标架构、差距分析。

差距分析 = 目标架构 − 基线架构。这是 B/C/D 三个阶段共同的输出逻辑。基线架构是现在架构的状态与内容总称，目标架构是未来架构的状态与内容总称。

❌ 只做目标架构，不画基线 ✅ 基线不清，差距就是空中楼阁；必须两条线都画清楚才能看到真实距离

阶段 C：信息系统架构

拆成两个子域：

数据架构：数据实体、数据组件、数据治理——核心是"统一"
应用架构：应用系统、交互关系——核心是"交互"

关键交付物：数据模型、应用组合目录、接口清单、数据-应用映射矩阵。

❌ 数据和应用混在一起画，分不清哪些是数据问题哪些是系统问题 ✅ 先定数据归属和数据标准，再定系统边界和集成方式

阶段 D：技术架构

核心任务：定义技术平台、共享服务、部署拓扑。

关键交付物：技术参考模型、平台服务目录、技术标准与规范。

❌ 技术选型脱离业务需求，追新不追对 ✅ 技术为业务服务，共享是关键指标；能复用的不重建，能标准化的不定制

阶段 E：机会与解决方案

核心任务：根据需求紧迫性 × 方案成熟度两个维度，筛选可行方案组合。

这是一个发散阶段。目的是产生足够多的选项，形成可比的解决方案包供后续排序。不是挑一个"最好的"，而是把牌摊开让决策者选。

❌ 只给一个"最佳方案"，没有 Plan B ✅ 至少给出 2-3 个可比的方案包，标注各自的约束和前置条件

阶段 F：迁移规划

核心任务：给定问题是排序，给定依据是发布。

优先级公式：VCR = 价值% / (成本% × Wc + 风险% × Wr)

VCR 越高，优先级越高。Wc 和 Wr 是成本和风险的权重，由组织战略决定。这个公式的价值不在于精确计算，而在于把"拍脑袋排优先级"变成"可讨论的量化框架"。

关键交付物：实施与迁移计划、优先级排序矩阵、里程碑与发布节奏。

❌ 所有项目都是"高优先级"，等于没有优先级 ✅ 用 VCR 公式量化排序，让数据说话，减少利益相关方之间的扯皮

阶段 G：实施治理

核心任务：确保实施不偏离架构设计，管控合规与偏差。

❌ 架构团队交付完文档就撤，实施团队自由发挥 ✅ 持续参与，做架构合规评审，发现偏差及时纠正或记录为架构变更

阶段 H：架构变更管理

核心任务：评估变更影响，决定是否触发新一轮 ADM。

❌ 任何变更都走完整 ADM，流程太重 ✅ 判断变更级别：小改走变更控制流程，大改才重新跑完整轮次

迭代的本质：找爹原则

ADM 不是瀑布。每个阶段的输出都可以触发回溯——发现目标架构不可行，回到 A 调整愿景；发现技术架构支撑不了业务需求，回到 B 重新审视流程。

这叫"找爹原则"：当前阶段解决不了的问题，往上游阶段去找根因。不是推倒重来，而是带着新信息回到能解决问题的层级。

场景	回溯方向	触发原因
技术方案落地不了	D → B 或 C	需求理解有误或架构过度设计
迁移成本超出预算	F → E	方案选型需要重新评估
利益相关方不买账	任意阶段 → A	愿景和范围需要重新对齐
数据标准打架	C → B	业务流程定义不清导致数据归属模糊

小组织怎么用 ADM？

不是每家公司都有百人架构团队。中小组织可以这样裁剪：

做法	说明
合并阶段	B/C/D 合为一个"解决方案架构"阶段
轻量化交付物	用一页纸架构视图替代 50 页文档
缩短轮次	一个 ADM 周期从 12 个月压缩到 3 个月甚至更短
聚焦痛点	不做全域，只针对当前最痛的问题跑一轮
重用优先	框架为通用，定制为应用，迭代为完善，重用为质保

企业架构（IT）的本质是 IT 战略减去 IT 项目之间的 gap。ADM 帮你把这个 gap 显性化、可管理。小团队不需要做全套，但需要理解这个 gap 在哪里、有多大。

ADM 是思维框架，不是流水线

把 ADM 当 checklist 逐条打勾，大概率会做出一堆没人看的文档。真正有用的做法是：用 ADM 的阶段逻辑来组织你的思考，用差距分析来对齐利益相关方的认知，用迭代机制来应对不确定性。

阶段顺序是建议，不是法律。交付物是手段，不是目的。能把架构意图传达清楚、让项目和战略对齐、让变更可控可追溯，就算把 ADM 用明白了。别迷信流程的完整性，关注架构决策的质量和沟通的有效性。