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

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

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 网关、消息中间件）
共性数据能力沉淀为数据平台（如数据湖、主数据管理系统）

设计四步走

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

三个面向

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

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

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

五、四个视图怎么串起来

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

1
2
3
4
5
6
7


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

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

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

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

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

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

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

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

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

七、写在最后

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

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

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

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