提到"业务架构"，很多团队的第一反应是画流程图、写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），业务架构的统一语言可以自然延伸到系统设计：
| |
一条价值流的每个阶段对应一个或多个子域（核心域、支撑域、通用域），每个子域再映射到一个或多个限界上下文。这样，DDD 的上下文边界就不是架构师拍脑袋定的，而是从业务价值链条上推导出来的。
这个衔接解决了一个长期痛点：微服务拆分的依据是什么？ 答案不是"按数据库拆"或"按团队拆"，而是按业务能力拆——每个限界上下文承载一个或一组业务能力，服务边界与能力边界对齐。
实操工具箱
| 工具/方法 | 用途 | 适用阶段 | 产出物 |
|---|---|---|---|
| 价值流映射 | 从客户视角定义端到端价值交付 | 战略对齐 | 价值流图 + 阶段定义 |
| 业务能力建模 | 定义企业"能做什么" | 能力盘点 | 分层能力模型 |
| 能力-价值流交叉映射 | 发现能力冗余与缺口 | 差距分析 | 交叉矩阵 |
| 热力图 | 可视化能力成熟度 | 投资决策 | 红黄绿能力地图 |
| 能力差距评估（ADM Phase B） | 基线 vs 目标对比 | 路线图规划 | 差距清单 + 优先级 |
| 能力-组织映射 | 发现职责重叠或空白 | 组织优化 | 职责矩阵 |
| 价值流→子域→限界上下文 | 业务架构到系统架构的桥接 | 系统设计 | 上下文映射图 |
业务架构的本质不是画图，而是建立一套业务与 IT 共享的语义体系。价值流定义了"为谁创造什么价值"，业务能力定义了"靠什么创造价值"，两者交叉映射形成了从战略到执行的完整链路。当业务和 IT 终于在用同一套语言对话时，那些排不完的需求优先级、对不齐的系统边界，才有了解决的基础。
