注：图片来源于阿里云栖大会相关材料

在谈业务中台前，首先看下对于中台原来我们一般说法是包括了业务中台和数据中台，而现在另外一种说法是包括了业务中台，数据中台，技术中台和AI中台。而实际上对于技术中台不建议划分到中台里面，可以划分到底层的技术支撑平台，属于技术PaaS平台的一部分。而对于AI中台单独划分出来本身也没有必要，AI中台可以划分到数据中台的大范畴里面。

就拿企业来说，中台的构建包括了业务中台和数据中台，按道理应该是先考虑业务中台如何构建，再基于构建好的业务中台来构建数据中台。但是也有企业由于遗留系统很多，并没有参考理想的方法去构建完整的业务中台，而是直接去构建数据中台。数据中台按照全新的方法去构建，替代传统的ODS加数据仓库的构建方法。

对于数据中台的构建，下篇再展开分析，本篇还是重点谈下业务中台的构建。

先看下传统的业务系统规划和构建思路，我们讲过更多的是业务和流程驱动型构建模式。简单来说就是，我们先分析清楚在业务上有哪些流程需要支撑，哪些业务需求需要支撑，然后基于流程逐层分解的方法来分析整个业务架构，基于业务架构再来分析数据架构，最后结合业务+数据架构来分析需要规划建设哪些业务系统或子系统。最后才会去考虑数据如何落地到数据库，应该有哪些数据对象和建立哪些数据库表。

■ 以数据驱动先行的思路来考虑中台模块的识别

而对于业务中台的构建思路，这里给出一种新的构建思路，即数据驱动型的构建思路。对于切入还是可以从端到端流程切入，但是只需要初步分析顶层业务流程即可，不需要进行详细的业务流程分析和分解，并规划业务架构。而是先进行数据架构规划和数据域划分。

即流程并不需要分析的太细，就已经能够完全了解企业核心基础主数据和核心共享数据。这个时候你已经可以梳理出比较粗的数据架构模型，找到核心的业务对象了（基础主数据和核心共享数据）。

同时我们也初步定义了数据域和数据边界。那么数据域和边界的划分是否合理？又得回到端到端流程分析，即还是需要根据端到端的业务流程来进一步试算和演练我们的数据域划分是否合理，即在端到端流程协同的时候是否会出现底层数据域之间的频繁交互和协同，如果存在多个数据对象间频繁交互，那么这些数据对象往往不能进行拆分，否则就可以拆分。

同时我们看到以核心基础数据和共享数据为主体进行数据分域，分域后形成的各个数据域之间满足松耦合的要求，这些分离出来的数据域就是独立的中台各个业务能力提供中心。类似我们常说的订单中心，合同中心，项目中心，产品中心，用户中心，供应商中心，物料中心，客户中心等。

在这个过程中你会发现供应商和物料之间的耦合性很强，那供应商+物料可以规划在中台的一个中心，一个微服微模块里面来实现。类似框架协议和采购订单，也需要放在一个中台中心一个道理。

■ 以对外流程协同，对内数据能力提供两条线来考虑中台模块接口服务识别

如果中台模块已经识别出来，接着就需要去思考每个中台模块究竟需要提供哪些接口服务能力。而这种接口服务的识别，我们考虑两条线相互结合的方式进行。

1. 根据中台模块的核心数据对象来思考应该包括哪些数据接口服务能力

你可以理解为你先不用去思考需要支撑上层哪些业务功能和流程，就是将你已经识别的基础主数据对象和核心共享数据的CRUD能力暴露出现。但是这个暴露和简单的暴露数据库表有差异，这里暴露的应该是核心领域对象和数据对象，这个对象可能是底层多张数据库表。即将底层数据库表，以领域对象模型聚合后的思路将API接口暴露出去。同时我们还需要初步分析哪些能力是不需要对外开放的。比如一些数据对象只需要朝外暴露查询能力接口即可，而有些业务对象则需要暴露CRUD的所有能力，这个也需要分析清楚。

2. 结合端到端交互流程

或者也可以是理解为通过前台需要实现的业务场景和流程，来分析究竟中台模块需要提供哪些能力。要知道通过第一点往往并不能识别出来所有的中台模块应该提供的API接口服务，特别是一些涉及到业务规则和逻辑的接口服务能力，因此在这里还需要继续识别还需要哪些接口服务，这些接口应该确保粗粒度和可重用。

简单的如一个业务对象状态变更的接口服务能力，在第一种方式下我们往往并不会单独将其识别出来定义为一个独立的API接口服务，但是基于业务场景分析后发现有这个需求，那么就需要单独定义接口。

所有中台的构建目的都是为了更好的为前台业务功能实现服务，因此结合前台的业务场景和功能需求来进一步识别需要暴露的接口服务能力是必须的。即我们要意识到前台的构建更多的都是组装中台层各个微服务模块暴露的API接口服务能力，而不是自己去实现这个能力，前台可能有自己独立的数据库，但是这个数据库本身也很轻，只会存储一些临时的或局部使用的数据信息。