"数智化"的三大支柱，分别是：数字管理、数字引擎、智慧营销。任何产业中的企业想要往数字化和智能化方向转型，都离不开这三个维度，它们是构成一个「企业数智化转型」的核心元素。
企业存在的本质是为了提供服务，那服务具体到某一个领域下就会形成业务。如今，很多企业往往已不局限于一个业务领域， 例如阿里巴巴这家企业，从早些年的金融、新零售到如今的物流、大文娱等等，其覆盖的业务边界十分庞大繁杂。为了持续高效地开展更多业务，一套科学、先进的数字管理机制就尤为重要，这也是支撑企业数智化转型的基础。 今天，我们就来聊一聊能将一切业务数据化的数字管理机制：业务中台。

一、为什么会有业务中台?

小编从事软件技术研发多年，一直认为：技术本身不会创造商业价值，只有将技术应用在业务中，才能让企业因为使用技术而创造商业价值。但往往，市场环境瞬息万变，企业业务的开展与技术能力的积淀经常存在诸多时间矛盾点，快速建设和集成可复用的技术能力成为了提高企业展业效率的头等大事。

即：真正能大幅提升业务诉求响应和业务创新的关键是有多少业务层面的能力（技术，模式，经验）是可以复用的。

业务中台便是一个能将 通用 技术能力和需要此能力的业务进行深度整合的载体，其以业务领域划分边界，形成高内聚、低耦合的面向业务领域的能力中心，成为可持续演进业务能力的共享服务平台。

如上图钱包支付类业务场景所示，其直观呈现是各能力中心的抽象实现：

用户中心：登录凭证、岗位权限、用户资料的整体抽象
交易中心：支付渠道、订单类型的整体抽象
商品中心：商品信息、品类垂类的整体抽象
库存中心：库存量、库存变动的整体抽象
充值中心：账户状态、资金充结算的整体抽象
...

其核心职能是需要尽可能做到：

场景覆盖全面
业务处理迅捷
用户触点汇集
数据高效生产

其最终效果和目的是尽可能地将一切业务高效地实现数据化。

例如：当项目初期，钱包支付业务仅提供APP访问，此时需要提供一个小程序端的支持，只需基于当前已有的生活服务管理、会员管理（产品共享服务层）、用户、交易、营销、商品（中台层）等中心的服务，在一个月内就能构建出一个稳定的小程序端钱包并上线。
这相比传统建设模式，其需求响应速度提升了几倍。同时，来自不同前台（Web浏览器\APP\小程序端等）业务的用户数据和日志，也能通过统一的中台服务进行数据的标准化采集、上报、入库、加工、分析、计算。大大降低了技术运维的成本，且为后续数据中台所要完成的任务打下了良好的基础。

二、如何搭建业务中台？

业务中台的建设核心是进行通用业务机制的建模与设计。其本质是如何用一套科学的方去寻找让所建模型更加易复用，易共享的办法。

这套方法，小编已将其流程化，如下图所示：

2.1 调研规划

业务的调研与规划目标是为了从发展的角度去看企业当下的业务运营情况和未来的规划。

这一步非常重要，其决定了业务中台的高度和更加有的放矢的详细设计。这里列举一个金融业务的例子：

从上图的业务规划中，能明确看到企业中台建设的总体需求与目标规划，在不同阶段对会员、营销、交易、风控等方面的诉求，那接下来就是对这些诉求进行更加详尽的需求分析，梳理核心流程。

2.2 需求分析

调研规划之后就是需求分析阶段，其目标是从业务规划的各种场景触发，梳理粗粒度下（并不需要关心业务层面具体的用户交互和功能细节）的核心业务流程。这个过程是边梳理业务流程边识别业务实体，同步进行，相辅相成。

业务对象
业务能力
业务规则
已存在的业务系统边界
依赖外部系统的服务边界

2.3 业务运行机制拆解

需求分析只是梳理粗粒度下的核心业务流程，再之后，我们需要进行细粒度的业务运行机制拆解，从中提炼出业务中台所需要的通用机制和系统开放机制。

如上图，我们将业务运行机制拆解为业务五要素：

1.业务对象：
- 实体对象（例如：会员、组织结构）。
- 过程对象（例如：支付、订单、审批）。
2.业务能力：业务能力是同类业务功能的抽象，是对业务对象的具体操作。能力的基础是结构和算法，一个能力可以支持多个功能。（例如：商家入驻能力可支持商家自助注册功能，也可支持后台主动开通商家账号的功能）
3.业务规则：本质就是业务逻辑，是用来控制或影响业务能力的定义。业务规则影响了各能力中心所提供的能力和业务数据的聚合、转换、变化。（例如：“支付单创建能力”搭配“支付需要二次确认交易密码”的业务规则，就会产生“支付单产生后进入待支付状态，待用户完成交易确认才会结算的业务流程“）
4.业务配置：业务配置是内嵌在中台业务逻辑中的一些控制点和扩展点。通过可视化的Web配置，用户可以动态控制中台的执行逻辑，让业务柔性运行。（例如：用户身份认证扩展点，是选用滑块认证\人脸认证还是其他认证方式，从而动态控制认证该场景下的业务执行规则）
5.业务流程：业务流程规定了业务中台系列业务动作执行的顺序，用以完成特定的业务目的。
- 中台针对不同业务需要设计不同的业务引擎。（例如：交易引擎处理交易相关的逻辑，促销引擎负责促销活动相关的自动化，审批流引擎负责业务单据的审批）
- 业务引擎和流程定义决定了能力中心内部以及能力中心之间如何自动化执行。（例如：通过可自定义的交易流程，业务系统既可实现先付款后发货，又可实现先发货后付款）

2.4 中台设计

我们将业务运行机制拆解完成后，就可以基于这些细粒度的机制进行中台核心架构的设计。从两个维度来进行切分：在纵向维度上进行领域划分，形成中台的能力中心，同时在横向维度上根据业务领域与上层应用的关联性，将业务中台领域进行分层。

2.4.1 纵向切分

纵向切分是指：中台将企业的业务内容，按照能否独立运营为标准，进行切割形成各个系统。切分之后的各个系统，我们一般称为中台的能力中心（例如：用户会员中心，营销中心，交易中心，审批中心...）。

这时，我们就会常遇到企业客户经常提出的问题：我们的公司到底需要几个能力中心？这些中心怎么出来的？这些中心是什么样子？

这一步一定要从企业核心业务场景和流程用例出发，接下来，我们试着通过分析系统时序，找出业务域的触点，从而聚合出我们需要建设的能力中心面貌，如下图所示：

以分析金融业务场景为例，我们可以产出一个大致的基于中台业务域架构的调用关系，再把这些系统时序按照业务域进行分类归集。时序图中和业务域的每一次交互算一次触点，按业务域把所有触点进行聚合，通过触点数我们可以直观地看出这些“业务域”的活跃程度以及与业务场景的依赖程度。这时就可以结合团队的资源和战略规划，定义出第一批可以升级到"能力中心"的业务域了。

2.4.2 横向分层

横向分层需要建立在纵向切分的基础上。对于不同的业务领域，中台会根据其管理对象的不同性质，从下向上拆分为业务活动层（BAL）、业务协作层（BCL）、业务实体层BEL。

业务实体层（BEL）：由管理企业静态资源的能力中心构成，居于三层模型的底部，比如用户中心。

业务协作层（BCL）：由对企业资源使用策略进行管理的能力中心构成，居于三层模型的中间，起到承上启下的作用，比如营销中心。

业务活动层（BAL）：由管理或实现企业核心业务活动的能力中心构成，居于三层模型的顶部，可实时调用下方两层的业务能力，完成业务活动的执行，比如交易中心，审计中心等。

2.5 开发实现

软件开发是一项复杂的系统工程，需要经历系统设计、数据库模型设计、应用代码结构设计、核心时序设计、接口设计、编码调试、持续集成、测试部署等环节。

而中台型软件是基于云原生，大数据，人工智能等新一代技术打造的共享服务平台。它的建设带来了更高的架构设计要求，更高的技能要求和更全面的系统特性要求。我们在建设中台时往往并不会直接从0开始编码工作，而是用与之相匹配的技术平台为开发底座，来支持中台后续更好的发展和迭代。

往往，技术平台的选型由技术团队的核心骨干们所决定，随着项目深入而不断演进，其将为我们提供代码脚手架、大前端、网关、多云适配、混合云管理、云中间件、开放平台、DevOps流水线工具等多个领域的技术能力和工具集。

关于企业技术平台的搭建，后续有必要我会再开一章进行详细的描述。

2.5.1 技术架构

基于上述的技术平台能力，我们可以在开发前进行一个技术架构的简易设计，以搭建金融业务中台为例：

我们将中台的各能力中心以微服务的方式拆分，并将公共组件，配置中心，服务治理，开放服务等公共能力进行独立建设，按照前台业务对能力中心的实际用量进行不同程度的集群资源部署。以网关的形式进行流量资源的弹性管理。例如：交易中心的TPS常年较高，需要分配较大的集群计算资源。营销中心具备偶尔的流量峰值，需要具备一定时间段内的快速扩容的能力。

底层的PaaS和IaaS设施可以根据每家公司各自熟悉信赖的供应商进行选型。

除此之外，上述的技术架构，还可以有效的支撑起中台的三个重要技术特性，即：

业务隔离
集成策略
高并发与高可用

2.5.2 业务隔离

业务中台作为共享服务，需支撑多个前台应用。在共享的基础上，需要隔离前台应用，让前台应用既可执行个性化的逻辑，又避免互相干扰，各自独立运营发展。

例如：当任何一个前台应用增加功能或者修改执行逻辑时，我们只需要对该前台应用进行整体回归测试，而不需要对其他前台应用进行回归测试。

2.5.4 集成策略

业务中台需要提供合适的集成策略，以衔接内外部\上下游的其他业务系统。

业务驱动集成

1. 外部平台服务

很多专业领域的厂商会以API的方式提供待接入的服务，比如支付、物流、认证、以及商品、订单等平台服务能力。这些服务一版可称为API as Service。将专业能力开放给企业，可减少小企业建设IT系统的难度。而平台厂商则希望通过开放服务建设其自由的生态。

业务中台集成的常见外部服务如下：

第三方支付：通过对接支付宝\微信\PayPal等成熟的第三方支付系统，实现业务的在线支付。
物流：对接顺丰\菜鸟等第三方物流系统，实现物品物流信息的跟踪等服务。
认证：通过对接微信\QQ\OPPO等常用的第三方认证平台实现免注册登录。
短信：通过对接第三方短信服务商或电信运营商，实现短信的下发。
社交分享：通过各大网站的社交分享功能，实现人与人的信息传递。
电子合同：对接e签宝这样的第三方系统，实现电子合同的在线签署和管理。
电子发票：对接e发票，51发票这样的第三方系统，实现发票的在线化。

2. 企业内部系统

以往企业在信息化阶段会建设众多的内部系统，比如：

ERP：通过与ERP对接，实现业务从前端营销到企业内部的管理流转。
WMS：通过与WMS对接，实现订单发货与仓库智能管理的联动。
OA：通过与OA对接，实现前端营销和企业管理的一体化协同。

集成连接器

综上，为了保证中台的独立性，降低对外部系统的依赖，提高集成的效率和系统的容错性，我们需要设计一个中台连接器，来统一实现和管控与第三方系统的对接。

连接器一端连接业务中台，对接业务中台的标准接口，另一端根据所集成系统的对接方式进行适配对接，如下图所示：

常见的集成方式有：

方式	备注	优点	缺点	使用场景
接口调用	通过常见的RESTful/RPC等接口协议进行调用	以接口形式实时调用，时效高，接口协议规范。	不适用于大数据量的数据传输	适用于对实时要求高、数据传输量不大的实时请求
消息队列	业务中台和其他系统既可以是消息队列的生产者也可以是消费者，通过这种方式可实现与其他系统的解耦式集成	基于发布订阅模型，对分布式应用进行异步解耦，增加应用的水平扩展能力。削峰填谷，当大促等流量洪峰来袭时，缓存突发流量避免下游崩溃。可提供点对点消息推送，一对多广播室推送。	非实时调用，时效比不上接口调用，方案受中间件的性能和可靠性等因素影响	解耦的场景：比如交易核心系统只需要与消息队列交互，不需要与下游系统交互异步的场景：一是交易核心流程可以先完成，不需要等待后续流程。二是多个消息订阅方可独立并发处理。
文件传输	业务中台与其他系统可分别作为文件的生产者和消费者，生产者把变化的数据通过文件的方式推到文件服务器上，消费者基于双方约定的规范化名称获取并解析文件	系统通过文件的方式实现系统与系统间的解耦，通过文件能传输大量的数据	需要文件接收方定期主动扫描和解析文件，效率低	适用于网络隔离的情况，比如由于企业管理的需要，网络与网络之间不允许服务的调用，只允许文件传输以及大量数据批量传输场景。
共享数据库	数据可以从已有的数据库中直接共享出来，也可以新建一个中间库，或者实时同步一个只读库供其他系统读写数据。	无须改造现有系统	需要设计数据更新标识并识别更新数据的机制	适用于老旧系统，系统无法改造、改造代价大或没有接口的情形

集成收益

通过上述内容，我们不难发现，通过引入中台集成连接器，可以为我们带来如下收益：

连接器能够隔离业务中台与外部系统，避免外部系统的复杂影响业务中台本身的纯粹性。
由连接器进行数据统一适配转换，解决各系统数据不一致问题，降低数据维护成本。
当数据有错漏时，连接器可以进行数据重试。连接器提供默认重试机制，并且可以手动批量调整数据状态进行重放。
当中台和各系统对接数据场景不一致时，连接器备有预留扩展。如果遇到不满足的业务场景，重新开发新的适配方式即可。

2.5.5 高并发、高可用

如今，互联网的后端应用基本都是分布式架构，对于天生就需要依赖/服务多方租户的业务中台，高并发与高可用是开发实现环节必须要考虑的因素。

由于此块内容知识体系庞大，本文并不进行过多的展开介绍。未来会在公共号单独开设相关的专题文章。

同时也为大家推荐一本此领域相关的高质量读物：

《亿级流量网站架构核心技术》2017,电子工业出版社出版,张开涛

2.6 业务数据统一生产

业务中台不仅仅是一个能将 通用 技术能力和需要此能力的业务进行深度整合的载体，更是有着将一切业务数据化的使命。

为此，我们可以基于各个能力中心进行业务数据字典的统一构建，统一口径，为进入到后续数仓中统一生产加工而奠定良好的基础。

2.7 业务能力持续沉淀

业务&能力全景可视化

基于中台是实现组织内部数据信息开放共享的重要形式，对于沉淀到中台的服务能力应该以公共、透明的方式开放给组织的其他业务部门，只有将这些信息做到足够的开放和细致，前台业务才能更容易地了解中台目前提供的服务能力，能更清晰地知道满足当前业务需求需要得到中台哪些方面的支持，哪些需要自己去实现，哪些需求可以提出来与中台团队一起探讨最佳实现方式。

为此，我们需要构建起一个清晰的业务&能力全景地图，让需要使用这些能力的应用方对于中台的服务能力有一个清晰的了解。

这里以欢太数科的金融业务能力全景图为例：

能力自助接入

仅仅提供能力地图将中台的服务能力展现出来，给企业带来的价值是有局限的。

如果给服务使用者提供自服务接入，将比之前需要跟多个服务中心的团队进行线下沟通和讨论高效得多。

例如：微信小程序就是能力自助接入的典型案例。

它为服务接入方提供了：

全局能力地图
业务应用的开发创建指引
业务应用的设计风格参考
业务应用的数据统计
业务应用管理的后台
基于流程的运营指引

流程驱动的能力沉淀

中台不是通过一次项目的建设一蹴而就的，而是在企业业务不断发展的过程中持续演变和发展的，这意味着中台内各服务中心的服务能力随着业务需求的变化\新增等也会有修改、增加甚至淘汰，这样将持续保持中台服务能力的不断沉淀。

为了能做到这一点，对于应用方提出的能力需求，不管是对现有能力提出的更新需求还是新增能力的需求，都可以采用流程化的方法将需求沉淀到中台并对过程信息进行跟踪：

通过这样的流程，我们可以将中台对前台应用的支撑以及业务的沉淀做到有迹可循，将所有协同的信息、处理效率都做到完全数据化，更直观地体现出中台价值，且人员的工作效率可量化。

解决方案中心

中台刚开始提供的是相对 细粒度的服务能力，随着前台业务的不断接入，我们会发现有更多的某种业务场景需要 粗粒度的共性服务，需要聚合多个中台服务中心提供的原子化服务能力。当这种需求场景增多时，我们就会形成一个强大的解决方案中心。当有新的前台业务接进来时，可以首先推荐该前台从解决方案中心去寻找是否有同样的或类似场景的解决方案，以便加快前台业务的开发。

三、如何利用业务中台？

3.1 为前台输送弹药

如果把业务发展看作是一场战役，那一个个前台团队就像是一个个地面快速反应部队（接近一线），业务中台的战略身份则就是我军的炮火支援（集中打击），数据中台则需要提供雷达监测，为指挥中心提供决策依据。

这些"弹药"具体体现在：

可以让前台团队更加集中精力关注市场变化，享受一定程度的可复用红利。
最大程度地驱动团队力量，促进内部协作，减少决策风险。
实现了后端业务资源到前台易用能力的转化。

3.2 集成外部系统

在如何用好业务中台这个问题上，我们先要明白业务中台有可能会对企业应用带来哪些变化？

1.在业务中台上新建应用，即用新建应用替换原有应用。
2.部分改造原有应用，从原有应用中剥离出可由业务中台提供服务的部分。
3.借助已有应用的功能和数据，反向建设业务中台。

以上前三点的详细集成策略在本文的2.5.4章节已有详细介绍。

4.与数据中台形成联动，构成数据“生产-消费-再生”的闭环。

我们将在3.3中重点介绍。

3.3 与数据形成联动

业务中台与数据中台各自独立，却又相辅相成。业务中台支撑实时在线业务，并产生业务数据，数据中台则通过汇聚整合、提纯加工、建模处理、算法学习，将数据转为数据资产，并以共享服务的方式提供给业务使用，从而与业务联动，并再次产生新的数据。

3.3.1 从数据角度看

业务中台通过能力的输出，获取业务数据。这些实时的业务数据是数据中台非常重要的数据来源之一，可以减少日志采集、埋点上报等离线数据加工的时间延迟。与此同时，数据中台通过模型加工出来的数据结果，可直接推给业务中台，丰富业务中台的业务内容。

比如，数据中台加工产生的用户标签，推送给业务中台后，业务中台就可以展现综合的客户画像，为营销和服务提供高效率和高质量的服务。

3.3.2 从业务协作角度看

业务中台在支撑业务时，需要数据中台提供的数据服务来对业务能力进行调整。数据中台提供的在线数据服务可以帮助业务能力更有针对性和精准性的执行。比如，产品信息和精选专区展示场景下，业务中台的广告中心可以结合数据中台的人群画像服务，完成千人千面的差异化推荐。

3.3.3 从系统管理角度看

业务中台在建设统一业务中心的同时，也起到了统一数字化管理的作用。这为数据中台的数据源治理打下了业务、数据统一的基础，为其提供了高质量的数据元信息，减少了数据中台中元数据对象重复定义、重复管理这些环节的工作量。

总结

业务中台所提供的数字管理和共享业务能力为前台业务提供了强有力的炮火支撑，但想要了解战场的情况、指挥炮火打向哪里，就需要数据中台通过数据分析、产生智能，形成决策。

业务与数据不断交融，构建数据"生成-消费-再生"的闭环，才能更好地推动企业进行数智化转型，我们将在下一章节《【企业数智化转型】第三章：如何为企业搭建属于自己的数字引擎？》中重点介绍数据中台这一角色。

【企业数智化转型】第二章：如何构建业务中台实现企业数字管理