业务架构不是画流程图：TOGAF 视角下如何用"统一语言"拉齐业务与 IT

Mon, 29 Jun 2026 15:00:00 +0800

提到"业务架构"，很多团队的第一反应是画流程图、写PPT、做汇报。业务部门画一张泳道图，IT 部门画一张系统交互图，两份图在会上对不上，吵完散会，下次继续。这不是业务架构，这是流程文档。

真正的业务架构要回答的问题比流程图深得多：企业靠什么能力创造价值？这些能力哪些强、哪些弱？IT 投资该优先补哪块？如果回答不了这些问题，流程图画得再漂亮也只是在描述"我们怎么干活"，而不是"我们凭什么赢"。

TOGAF 和 BIZBOK 给出的答案是：用价值流和业务能力这两个独立维度，建立一套业务与 IT 都能理解的"统一语言"。

被误读的业务架构

业务架构被矮化成流程图，根源在于视角错位。流程回答的是"怎么做"（How），而业务架构要回答的是"做什么"（What）和"为什么做"（Why）。

一个例子：订单履约是一条价值流，它从客户下单开始，到客户收货结束。这条价值流需要"订单管理"、“库存调度”、“物流配送"等业务能力来支撑。但大多数团队直接跳到了"订单系统怎么改”、“物流接口怎么对接”——这是 IT 架构在做事，业务架构缺位了。

缺位的后果很具体：IT 投入与业务优先级脱节。业务说"我要的是更快的交付"，IT 听到的是"我要一个更快的系统"。中间的翻译层——业务能力——被跳过了。

BIZBOK 的两个核心维度

BIZBOK（Business Architecture Body of Knowledge）把业务架构拆成两个独立的、正交的维度：

价值流（Value Streams）——描述利益相关者如何一步步获得价值。它是外部视角的、端到端的、以客户触发为起点。

业务能力（Business Capabilities）——描述企业"能做什么"，而不是"怎么做"。它是内部视角的、稳定的、与组织架构解耦的。

这两个维度的关系类似于"需求"和"能力"的交叉映射：一条价值流的每个阶段需要调用若干业务能力，一个业务能力可能同时支撑多条价值流。它们不是包含关系，而是关联关系。

关键认知： 价值流会变（客户旅程在变），但业务能力相对稳定（“订单管理"这个能力不会因为换了 ERP 就消失）。这种稳定性让能力模型成为业务与 IT 之间最可靠的"锚点”。

能力分层与热力图

三层分层（Stratification）

BIZBOK 和 TOGAF 都建议将业务能力分为三层：

层级	定位	典型示例（制造业）
战略层（Strategic）	定义企业方向与差异化	战略规划、市场洞察、产品组合管理
核心层（Core）	直接为客户创造价值的主体能力	产品研发、订单履约、制造执行、售后服务
支撑层（Supporting）	为核心能力提供基础保障	人力资源管理、财务管理、IT 基础设施

分层不是画三个框就完事。它的实际用途是决定投资优先级：战略层能力不足意味着方向有问题，核心层能力不足意味着执行力有问题，支撑层能力不足意味着效率有问题。三种问题的解法完全不同。

热力图（Heat Mapping）

热力图是给能力模型"上色"——用红黄绿标注每个能力的成熟度或战略优先级。

红色：能力缺口大，严重制约业务目标
黄色：基本可用但存在明显短板
绿色：成熟度高，无需额外投资

热力图的价值在于可视化差距。当 CIO 和业务 VP 一起看这张图时，他们争论的不再是"要不要上这个系统"，而是"这个能力到底是红还是黄"——这才是业务架构该发生的对话。

TOGAF ADM Phase B：能力差距评估

TOGAF 的架构开发方法（ADM）在 Phase B（业务架构）明确定义了能力差距评估的步骤：

定义基线能力：当前企业具备哪些业务能力，成熟度如何
定义目标能力：战略要求企业达到什么水平
差距分析：逐个能力对比基线与目标，标注差距等级
优先级排序：结合战略影响和实施难度，确定改进顺序
映射到 IT：每个能力差距对应哪些系统、数据、技术需求

这一步的产出物不是又一份 PPT，而是一张能力-系统映射矩阵。它直接告诉架构团队：哪个系统该升级、哪个数据该治理、哪个技术该引入——全部从业务能力差距倒推出来，而不是从技术偏好出发。

案例：某制造企业的统一语言实践

某制造企业（年营收百亿级）在数字化转型初期遇到了典型问题：业务部门提了 47 个 IT 需求，优先级排不出来，IT 部门疲于响应，业务部门觉得 IT 总是拖延。

企业架构团队介入后做了三件事：

第一步：梳理价值流。 从客户视角识别出 6 条核心价值流（从线索到回款、从需求到产品、从订单到交付等），每条拆解为 4-6 个阶段。

第二步：建立能力模型。 定义了 3 层共 85 个业务能力，用"名词+动词"结构命名（如"订单管理"而非"订单系统"），确保业务和 IT 说的是同一件事。

第三步：热力图评估。 业务和 IT 联合对 85 个能力打分，标出 12 个红色能力、23 个黄色能力。47 个 IT 需求被映射到具体能力差距上，其中 15 个需求指向已经绿色的能力（暂缓），8 个需求指向红色能力（优先）。

结果：IT 投资组合从"按需求响应"变成"按能力缺口投资"，业务部门第一次理解了为什么有些需求会被推迟——不是因为 IT 不想做，而是因为那个能力不是当前战略瓶颈。

与 DDD 的衔接：从价值流到限界上下文

如果你同时在做领域驱动设计（DDD），业务架构的统一语言可以自然延伸到系统设计：

1

价值流阶段 → 子域（Subdomain） → 限界上下文（Bounded Context）

一条价值流的每个阶段对应一个或多个子域（核心域、支撑域、通用域），每个子域再映射到一个或多个限界上下文。这样，DDD 的上下文边界就不是架构师拍脑袋定的，而是从业务价值链条上推导出来的。

这个衔接解决了一个长期痛点：微服务拆分的依据是什么？ 答案不是"按数据库拆"或"按团队拆"，而是按业务能力拆——每个限界上下文承载一个或一组业务能力，服务边界与能力边界对齐。

实操工具箱

工具/方法	用途	适用阶段	产出物
价值流映射	从客户视角定义端到端价值交付	战略对齐	价值流图 + 阶段定义
业务能力建模	定义企业"能做什么"	能力盘点	分层能力模型
能力-价值流交叉映射	发现能力冗余与缺口	差距分析	交叉矩阵
热力图	可视化能力成熟度	投资决策	红黄绿能力地图
能力差距评估（ADM Phase B）	基线 vs 目标对比	路线图规划	差距清单 + 优先级
能力-组织映射	发现职责重叠或空白	组织优化	职责矩阵
价值流→子域→限界上下文	业务架构到系统架构的桥接	系统设计	上下文映射图

业务架构的本质不是画图，而是建立一套业务与 IT 共享的语义体系。价值流定义了"为谁创造什么价值"，业务能力定义了"靠什么创造价值"，两者交叉映射形成了从战略到执行的完整链路。当业务和 IT 终于在用同一套语言对话时，那些排不完的需求优先级、对不齐的系统边界，才有了解决的基础。

能力建模 on 文艺技术笔记