业务架构 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:05:00 +0800

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

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

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

什么是价值流

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

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

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

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

价值流不是业务流程

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

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

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

怎么做价值流映射

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

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

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

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

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

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

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

一个具体例子

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

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

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

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

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

热力图：找到能力短板

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

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

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

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

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

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

几个实操原则

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

写在最后

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

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

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