关于业务平台架构的思考

业务平台是连接业务战略与技术实现的桥梁。好的业务平台架构，不仅要沉淀可复用的基础设施以降低成本，更要通过开放的架构能力支持业务的快速创新与差异化经营。本文从"业务是什么"这一基本问题出发，逐步展开对业务平台架构定位、能力建模、域划分以及架构构建方法的系统性思考。

从我们最熟悉的说起——业务是什么？

不同来源对"业务"有着不同层次的解读：

职业上的事务，统称为「业务」——辞海
"业务"更白话一些来说，就是各行业中需要处理的事务，但通常偏向指销售的事务，因为任何公司单位最终仍然是以销售产品、销售服务、销售技术等等为主。"业务"最终的目的是"售出产品，换取利润"。——百度
"Anything that relates to organizing the exchange of goods and services by a business, a governmental institution, or an agency."——OpenGroup TOGAF Business Architecture

业务的定义

业务：企业接受客户订购，并将商品或服务交付给客户的一系列活动的总和，称之为一个业务。

业务的基本特征是产品+组织。当产品交付给客户时，面向不同客户、市场、行业，如何解决业务的差异性？答案是业务身份。

业务身份是现实业务在系统中给予的唯一编码标识，是基于"业务"差异性划分而形成的系统 ID。业务身份的本质不是为了区分逻辑判断，而是区分需求来源以及规则的适用范围。因此，业务身份应该有全局的一致性。

业务平台架构的定位

从业务内部看，要解决的主要问题

维度	目标
创新	不断适应市场的业务策略
低成本	实施成本低
快速响应	能快速推进，快速试错
外部资源	易于获得生态内足够的外部资源，如流量、供给、渠道

从全局看，怎样支持业务快速发展？

维度	目标
基础强大	有强大的基础平台支撑，通用能力得到保证
组装灵活	可以快速选择部分能力，构建适合自身需要的支撑体系
易于变化	变化牵涉面小，可以快速定制
自主投入	不受基础平台资源瓶颈限制

从技术与业务两个角度看，需要的能力

功能丰富：靠积累
易于复用：粒度合适，易于集成（技术兼容）
开放定制：平台开放（架构开放），运行解耦（部署灵活）、研发过程解耦
信息共享：概念一致、场景链接
沟通顺畅：共同的术语、对业务整体的一致认识

被复用或信息共享的前提

从业务角度看，能够被复用或信息共享需要满足以下前提：

核心管理对象的一致性
- 概念一致：对象+关系
- 数据描述一致：主数据
存在一定层次的流程一致性
- 关键活动
- 基本规则

软件复用的四种形式

从技术的角度，软件怎样被复用？

复用形式	说明
功能复用	一段功能被完整使用
接口复用	输入输出定义复用，实现逻辑重写
流程复用	一段控制结构被复用，控制逻辑加上节点
规则复用	一段判断逻辑被复用

复用的前提是业务实质的相似性。如果管理的核心对象存在较大差异，绝大部分情况下，以上复用都没可能。

业务平台的能力取决于什么？

是否存在基础的具有共性的关键业务环节
是否存在需要全局共享的关键资源
是否存在需要广泛连接的关键应用
是否存在需要大范围执行的管控规则
是否需要稳定性 SLA

业务平台的价值

降低成本：通过沉淀可复用的软件基础设施
支持创新：通过提供开放的基础架构能力，支持创新和差异化经营
全局管控：通过管理基础数据和基本流程节点，提供全局管控的手段和稳定性保障

业务架构模型分析

业界对业务架构的描述方式有多种参考模型：

模型	来源
Business Process	TMF、APQC
Business Capability	Open Group、Gartner
Value Stream	Open Group
Business Service	FEA

描述业务的三个视角

Business Capability（What）：业务为实现特定目的或结果而可能拥有或交互的特定能力或产能

A particular ability or capacity that a business may process or exchange to achieve a specific purpose.
Business Process（How）：一组有逻辑行为的结构化活动或任务，产生特定的结果、服务或产品

A set of structured activities or tasks with logical behaviors that produce a specific outcome, service or product.
Business Value Stream（Why）：表示一组端到端增值活动集合，这些活动为客户、干系人或者最终用户获得一个总体结果

A sequence of activities an enterprise undertakes to deliver on a customer request.

参考模型的共性

在推动企业 IT 服务能力的持续演进方面，业界已经有丰富的参考。分析前述参考模型可以看到：

顶层视图一致：不论哪种描述方式，都是先从企业的管理范围做大的划分——基于价值链的分析形成顶级视图，以是否直接服务客户为基准划分不同分类
内容逻辑趋同：大多讨论都涉及组织、能力、过程的关系
目标一致：虽然在不同的时期、不同的视角强调的重点不同，但都是希望建立更易于为业务理解的视图，并成为构建 IT 系统的桥梁

业务架构的现状与挑战

通常，企业架构包括业务架构、技术架构、应用架构、数据/信息架构，而业务平台最薄弱的环节往往在于业务架构：

已经形成框架，但缺乏对关键概念的确切定义
已经形成平台，但缺乏长期演进的规划指引
已经形成对业务的基础性支撑，但基础能力没有明确的定义
平台团队缺乏对业务的结构化思考框架指引，容易造成团队能力的瓶颈

因此，我们首先需要健全业务架构体系。业务架构体系的构建关键在于先要建立业务视角。

什么是业务视角？

用业务发生的方式描述业务：围绕能力、流程与场景描述
将业务现象背后的逻辑进行结构化呈现
强调结果而非方法实现，屏蔽技术细节

如何建立业务视角？

首先要明确业务目标，理解业务含义，知道结构划分的依据
要建立端到端的全流程视角，业务需求能够对应到系统功能
在业务沟通中，统一使用达成共识的业务语言而非技术术语
系统被业务感知的部分要有明确的业务语义以及清晰的边界

业务平台架构的层次结构

业务平台架构是一个以流程为基础，以能力为表达的层次结构：

层次	目标
第一层	明确语义和范围
第二层	构建完备、正交的业务模型
第三层	与交付形态相结合，提供服务 SLA

无论从能力角度，还是从流程角度，都是对企业行为的一种描述方式。我们既可以通过满足的客户需求出发，构建能力的集合，也可以根据流程到企业能力的对应，建立起整体的能力框架或过程框架。

关于域（Domain）的思考

域是一个广泛被使用的词，但定义也很宽泛。领域建模这个词很熟悉，但具体"领域"是什么，在实践中并没有可以判定的简单标准。域常常被理解为不同的场景：功能域、过程域、数据域。

如果从 OO（面向对象）的核心思想出发，则可以将域做一个统一认知：

功能是对象行为的外部表现，但作为域的聚合依据是对象
对象的行为和数据是不可分开的，过程是对象行为的执行过程

基于以上认知，域的概念可以统一为**「信息域」**——数据是信息的载体，信息是对数据的语义解释。因此，领域建模就是找出问题范围内的对象及其关系，根据对象间关系的紧密程度，来确定是否属于一个域。

价值链视角下的能力划分

价值链把企业的能力划分为核心能力以及辅助能力，实质是以客户为中心，区分客户与企业两个角色。根据 TMF-eTOM 的划分方式，在核心流程进一步细分基础设施和战略、运营，和生产不直接相关的活动都定义为企业管理。

能力的语义分析——5W1H 的逻辑

对能力进行语义分析，可以借助经典的 5W1H 框架：

维度	关注点	层次
Why	价值	高层次
What	目标	高层次
When	时间	细节层次
Where	地点	细节层次
Who	参与人	细节层次
How	方式方法	细节层次

当我们在较高层次谈能力，往往是在谈 Why 和 What；在较低或细节的层次谈能力，则往往强调的是 3W1H（When、Where、Who、How）——即做的程度和特性。

能力的两种描述形式

能力的描述通常有两种形式：

形式一：按照目标描述——做什么以及达到的目标。

形式二：按照特性描述——特性往往体现为两类：

对象属性值的组合：值的组合往往体现为场景。例如"担保交易"是一个能力描述，"担保"本身是交易的分类特性，描述的是交易具有的特点。
过程执行的非功能特性：如时间、空间等。例如"秒杀"描述的是交易的时间特性；"店铺红包"描述的是红包使用的范围（空间特性）。

能力与场景的结合

能力的特性描述实际是场景切分的方式。一旦进入场景，就是离散的结构；而按照流程的能力划分方式，则可以是逐步细化的方式，会形成树状的结构。

如果我们把二者结合并加以规范，就能形成既满足 MECE（Mutually Exclusive, Collectively Exhaustive）原则，又能把两种特点有效体现的描述方式：

按照端到端流程完成初始能力描述
找到流程的各个环节，分解成不同的能力
在流程各个环节里，找出关键参数，描述业务的适应能力
找出关键的非功能性的特性
把流程各个环节较为固定的组合找出来

能力分析 vs 流程分析

能力：要达到一个目的，得到一个结果。如果是服务于客户，从客户的角度看，就是"我"帮客户完成了一件什么事情。
流程：我要干一件什么样的事情，其步骤是什么，体现的是做的过程。

从划分的结果来看，能力划分和流程划分是一致的，但从思考的角度看是不同的。从划分的确定性看，因为角色有限，能力从结果和目标的角度出发，避开路径的复杂性，有更强的确定性。

业务建模 vs 业务架构

在独立讲述流程建模或者能力建模的论述中，都强调用业务的语言，构建符合业务习惯的成果。业务建模只强调逻辑的完整性，但是在以 IT 实现为目标的前提下，业务建模和 IT 实现之间必须建立简单的对应关系。

无论是能力建模或者过程建模，最终要与信息模型建立映射关系。在业务分散而平台支撑要统一的情况下，也可以看作是 IT 在寻找和业务的共同语言。

商业能力的划分

划分的核心原则

能力划分的核心是围绕客户，以是否与客户诉求直接相关作为基准。在顶层视图中，划分能力和流程的视角是一致的——无论流程视角还是能力视角，都要找出我们能为客户做什么。

因此，我们可以区分三类能力：

客户销售与服务能力——直接面向客户
支撑能力——为前端能力提供基础保障
企业管理能力——支撑组织自身运转

能力划分的逻辑

能力划分是自顶向下的逻辑分解过程。其出发点首先是角色分析，以满足角色的诉求为目的。因此，顶层的划分都是以角色的诉求为基础，本质是场景（或流程）的划分。

能力类型	划分逻辑	说明
前端能力	按消费逻辑划分	直接服务于客户需求，按客户消费场景进行顶层划分
后端支撑能力	按资源/角色分类	服务于经营者，因内部角色分散，形成面向资源的分散流程

场景的细分本身可以构成能力细分的逻辑基础，但仍需要找到场景细分的逻辑。后端支撑能力本质是服务于经营者，可以从经营者的诉求进行划分。但因为内部角色的分散，难以在顶层形成贯穿全局的流程主线，就会形成面向资源的分散流程。这里的资源，本质就是我们所说的域。

这代表了一类细分的思路：在场景细分的基础上，通过资源的分类完成下一级的细分。即便到了资源的分类层次，仍有可能进一步细分，这又会回到场景划分的逻辑。所以，业务能力建模的过程也是在不断寻找不同层次的能力切分逻辑的过程。

从全局看，核心是以客户为中心进行能力的划分。实际上，每一部分能力都服务于生态中的某个特定角色，所以在能力的描述上，直接满足的是当前角色的价值要求，间接地通过以客户为中心的视角进行原则性校验。

企业能力生态闭环

企业的能力围绕"客户、企业自身、合作伙伴"的生态形成闭环
前端围绕满足客户需求
后端分为满足生产要素管理和满足企业自身管理
企业管理暂不涉及

能力划分全景图

后端支撑能力与企业管理能力

后端支撑能力：

客户管理
产品管理（PLM）
合作伙伴管理
营销活动管理
账单与收入管理
资源管理

企业管理能力：

人力资源
财务
技术发展
基础建设
法务
……

从概念性的能力到软件实现的层次

能力到软件实现的映射

能力的表现形式：

高层的能力：应该是逻辑的表达，对应于软件的整体或可独立交付的部分
低层的能力：应该和软件的外在存在形式关联，如分布式环境中的服务接口、SDK 中定义的接口

能力的划分原则：

能力是围绕以完成客户诉求为目标来划分的，完成一个能力可能需要多个领域对象的协作。能力的细分有横向和纵向的划分方式，未必代表软件实现的粒度细分，所以要建立能力和软件实现的映射关系。但在能力粒度上，一定需要和软件的交付物有一致并且明确的边界。

能力、流程、域的关系

三者的划分依据各有不同，但最终需要建立映射：

概念	划分依据	特点
能力	按照完成目标划分	面向结果
流程	按照执行过程划分	面向步骤
域	按照实体聚合切分	面向对象

业务流程是业务感知结果的流程，系统流程是执行步骤的划分。域内可以有流程，域的多项能力可能对应细分流程的多个步骤，不一定有必然的先后顺序，也可能是离散的能力组合。

域和能力之间也需要在一定的粒度上建立映射关系，否则会造成在域和能力都有很多层次，并在多个层次间建立复杂的映射。

商业能力层的设计

商业能力层和域内的关系

商业能力是客户可直接感知的能力。越是面向客户直接交互的层次，在技术上越难以限制其差异性，可能会与需求直接映射；越是趋近技术实现的层次，越是需要更高的抽象，以间接满足需求。

商业能力层提供流程性的封装，在顶层按照与客户的交互场景划分，并结合域的划分进行分解：

商业能力层：以提高交互场景的合理性和对外的灵活性为目标，关注面向客户体验的逻辑实现
域内：以实现领域内的接口复用为目的，提供合适粒度的接口，与商业能力层确认概念模型

商业能力团队应该首先是一个设计团队，其次才是一个实现团队。设计应该是和各域一起探讨的过程，商业能力要限制向下层过度延伸，也要迫使下层更注重域内抽象。

在设计过程中，逻辑分解应该尽量形成在各域的独立逻辑，然后组合成对外的交互逻辑。最外层交互所依赖的服务都在商业能力层实现封装，应该以业务设计结果为准，而不是技术设计。对外的扩展点，都在商业能力层定义和体现。

商业能力在软件结构上的分层

如果对外提供的就是商业能力，那么域和商业能力的边界到底在哪里？

所有在 SDK、RPC 接口中对外提供调用或者是 SPI 提供实现的，都在商业能力层定义
需要提供给外部使用或扩展的（这里不包含界面层对后端的调用，界面是软件的一部分）

如何界定"内"和"外"？

"内"与"外"的界定取决于商业能力的服务对象和组织边界：

视角	"内"	"外"
业务平台 vs 业务方	业务平台	业务方
整个中台	所有中台能力	中台以外
企业内外	企业	客户

如果考虑放大到所有提供中台能力的都和业务平台同等的地位，那么整个中台就是内——但这样就要有整个中台的统一对外组织和架构标准。

商业能力和域的分层及域间关系

域间是否允许调用？调用规则如下：

调用类型	是否允许	说明
依赖另一个域的实体对象信息的查询调用	允许	不限制下层的信息查询
依赖另一个域的判断的调用	禁止	交给上层去集成
嵌入另一个域的处理环节的调用	禁止	限制下层的逻辑蔓延

核心原则是：上层进行逻辑和控制结构的组装，不限制下层的信息查询，但限制下层的逻辑蔓延。

对于下层能够独立完成的判断逻辑或处理环节，鼓励下层去做。但对象必须有属主域，判断应该是本域的关键对象的行为判断，而不能是跨越边界。只有直接被认为是对象的直接属性的内容，才被认为是查询，所以对于一个域要有基本的概念模型。

商业能力的表达

对组织边界外的外部系统服务，都是商业能力封装；对于和客户直接交互的、提供给界面的，都是商业能力。

商业能力本身可以分成两类：

领域内服务：单域完成的能力
跨域服务：可以作为独立的分类

从上下级关系看，上级的逻辑必然覆盖下层的逻辑，建立能力树，是给用户导航的方式。

基于企业架构，构建业务架构

要想构建业务平台架构，我们需要有一套行之有效的构建方法论。方法论的构成包括：原理过程 + 表示法 + 工具。

能力地图代表业务架构，概念模型代表信息架构。对于多数业务平台，技术架构一般已经有较为明确的选择。所以，业务平台亟需构建的是除技术架构之外的泛"业务架构"。

从企业管理维度上看，企业架构在业务平台通常可以解决的问题包括：

研发投资的价值识别
架构演进的组织方法
组织的职责划分

构建架构体系：战略-模式-能力-过程

业务架构的边界来源于战略输入。从能力的角度，产品目录是业务架构的延续；从实现的角度，产品目录是应用架构的延续。在交互层面，通过合适的集成手段，实现应用功能面向用户的有效整合。

应用架构的边界和域的边界有内在的关联，可以通过自顶向下的讨论以及循环迭代完成演进。

构建能力地图

确定架构定义及结构描述
- 分层划分的规则确定
现状描述
- 能力地图的草稿初建
搜集关键场景，确定目标架构
- 补充关键演进场景
Gap 分析
演进计划
构建一个基础的完备正交集合
构建不同场景的视图
- 外部客户交付关键能力视图
- 内部业务的热点关键能力视图

构建概念模型

现状搜集：

已经被广泛引用的概念、实体
已经被广泛使用的术语
已经被相对固化的流程节点
已经广泛使用的场景

未来场景搜集：

战略输入
业务规划

建模：

域划分
模型定义
耦合验证

演进计划

总结

业务平台架构的构建是一个系统性工程，其核心在于找到业务与技术之间的共同语言。回顾全文，可以提炼出以下关键认知：

业务身份是差异性管理的基础——通过全局一致的业务身份，区分需求来源和规则适用范围
能力、流程、域三位一体——能力面向结果，流程面向过程，域面向对象，三者需要在合适的粒度上建立映射
以客户为中心的划分逻辑——无论前端能力还是后端支撑，最终都服务于客户价值的交付
商业能力层是关键的架构抽象——它既要限制向下层的过度延伸，又要迫使下层注重域内抽象
域间调用的原则——允许信息查询，禁止逻辑蔓延，上层负责编排
业务架构需要持续演进——通过能力地图和概念模型的迭代构建，逐步完善架构体系

好的业务平台架构不是一蹴而就的，它需要在实践中不断验证和演进。关键是始终保持以业务视角为出发点，用结构化的方法将业务逻辑转化为可落地的技术架构。