在上周我写了一篇在企业数字化转型过程中数据驱动的文章，提出了数据驱动不是简单的数据反哺业务，而是真正的以数据识别和定义触发，通过数据来反推业务，让业务协同为数据服务，今天就这个话题进一步展开。

我们团队从2007年就开始做中国移动的ERP接口平台项目，也就是我们常说的SOA集成平台和ESB服务总线，在09年又开始承接联通集团的SOA项目，12年开始做联通集团的私有云PaaS平台建设。

现在大家一说到SOA和ESB，第一反应就是已经过时的技术。对于这个问题我也在前面专门整理一篇文章说，虽然技术架构有可能过时，但是SOA架构思想本身不会过时。对于SOA集成平台类项目整体的发展演进，我也做下简单说明。

第一阶段解决系统间的接口集成问题，所以当时平台名字都叫ERP接口平台，解决围绕ERP的一系列外围系统间的接口集成。同时这些集成大部分都是数据集成，即需要在多个业务系统之间进行数据传递，也可以说类似数据交换平台。

第二阶段名字出现变化，一般叫做SOA共享服务平台或SOA集成平台，也就是不仅仅解决系统间的接口集成问题，同时也有意识的开始识别和定义一些粗粒度可复用的共享服务能力。其次就是对于服务本身不仅仅是数据集成类服务，也有了实时调用的业务服务，实时调用业务服务出现是平台第二阶段演进的一个重点。

第三阶段即到了平台+应用的私有云PaaS平台阶段，很多共性技术服务能力，流程平台，4A等全部下沉到了统一的PaaS服务平台。这个时候ESB总线进一步演进为能力开放平台，服务更加强调复用，同时服务调用进一步转为实时调用获取，也就是说共性数据不会在业务系统中存在两份数据拷贝。

第四阶段SOA和私有云PaaS平台思想进一步演进到当前主流的云原生技术平台，中台，微服务等上面。传统比较重的ESB服务总线也演进为API网关或轻量的OpenAPI能力开放平台。微服务间集成去中心化，API网关作用也仅仅是对外统一能力提供和API统一治理。

SOA架构思想-从纵向到横向

去年我在华南CIO大会上做了《平台+应用-传统企业架构的微服务改造》的主题演讲，在这里重新强调了SOA架构思想。

即SOA架构的一个核心是将传统的纵向烟囱式系统构建模式转变为横向分层构建模式。这个横向分层的重点就是首先找到遗留的可复用服务能力，形成共享业务服务层，然后将基于服务的组合，组装和编排来完成新的业务流程。

这个思想在今天谈中台和微服务的时候同样适用，即中台就是共享业务服务能力层，而前台应用就是新的业务流程。

烟囱变短了仍然是烟囱

这句话有点直白，简单来说就是SOA始终在强调业务系统烟囱式的构建，我们也在通过平台+应用的思路来实现共性业务能力下沉。

但是你会发现在新的平台化，微服务架构思想下，仅仅是让烟囱变短，中间部分仍然是纵向的烟囱，你期望的完整的业务流程仍然没有独立出来，还是分散在个各个微服务里面。

也就是说烟囱变短后，各个烟囱仍然存在，你还是得处理各个烟囱之间的集成问题。同时由于传统应用架构已经微服务化，你会发现这个集成问题比传统应用间的集成更加复杂和难以管控。即你期望的灵活性没有出现，反而是治理管控难度增加。

问题出在传统架构分析和应用设计思路

自己从09年开始做信息化规划，企业架构，SOA架构规划等，实际上始终都在沿用一个关键的架构分析思路，这个思路简单总结就是。

基于业务驱动IT的思路，先梳理和分析端到端业务流程，再对流程进行分解，识别核心的业务活动和业务对象数据，然后在基于CRUD分析对业务进行聚合形成业务架构和拆分后的业务组件，对数据进行聚合形成数据架构。同时在基于业务流程协同的目标来分析业务组件之间如何集成，识别关键的服务和接口，完成集成架构。

上面是一个典型的业务驱动IT，架构设计应该分而治之，先分解再集成的思路。这个思路影响了我很多年，实际我也很少去考虑这个方法本身是否存在大的问题。

即使在去年我输出微服务架构规划对传统企业架构规划方法的精简的时候，也仅仅是思考将业务架构和应用架构进一步合并，将共性PaaS技术服务平台构建增加到技术架构规划里面。

当重新回顾这个思路的时候，实际你会发现两个关键问题点。

整体思路仍然是业务驱动，而非数据驱动。

整个架构分析和应用构建很难体现横向分层思想。

在微服务架构实施中，我们一般在技术上会采用前后端分离，即前端UI开发和后端组件和API接口开发是分离的。如果从SOA架构思想来谈前后端分离，我们可以理解为将后台服务能力和前端应用能力分离。

也就是说分层构建核心思想是首先想清楚你有哪些共性能力可以提供，其次再考虑基于这些共性能力如何形成上层应用或业务。

而这个共性能力提供的基础就是你拥有哪些数据。

简单来说就是你可以先去考虑你拥有哪些核心业务对象和数据对象，再考虑考虑这些业务或数据对象能够提供哪些服务能力，最后这些能力如何去组合和编排。

识别数据不一定需要完整的业务流程梳理分析

在业务驱动的思路里面可以看到，通过业务流程分析和梳理，识别出现的业务对象和数据对象。但是要注意到，对于核心数据对象的识别往往并不一定需要完整的业务流程梳理和分析。

比如拿采购业务来讲，你可能并没有做完整的业务流程梳理和流程分析建模，但是基于当前日常工作中的输入和输出单据，你已经可以快速的识别出关键的数据对象，比如采购请购单，询价单，供应商，原材料，采购订单，采购接收单等。

同时你也可以开始分析这些数据对象之间的相互关系。

数据架构先行-对数据域解耦

对于业务对象，我们可以初步分为两个类型

基础数据：其中包括了我们常说的主数据，也包括了数据字典类元数据

业务表单：业务表单类数据，即在业务流程工程中流转的业务表单对象数据

在我们看常见的中台架构图的时候，我们都会注意到中台的各个模板一般都会以中心来命名，比如说用户中心，产品中心，订单中心，商品中心等。而这里面出现的就是各个核心共享业务对象或数据对象。而我们要做的就是把这些关键的数据对象或业务对象识别出来。

如何识别？

我们可以调研企业各个业务部门有哪些常见的业务表单或电子表单，然后对这些表单数据进行定义。即你关注的不是流程，而是最终的结果数据。比如我们说人力资源部门，你会看到存在请假单，用章申请单，工资条，培训需求表，培训考勤表等，这些就是最终的业务表单或数据对象。

我们可能不会去详细地分析培训组织流程，但是我们会关心培训会产生哪些业务对象数据。当然，很多时候你必须仍然要了解业务才能够识别出业务对象，只是不需要对业务流程做详细流程分析。数据域划分-基础主数据-》共享数据-》附属数据

数据架构里面有一个重点就是数据域划分，而数据域的划分往往是我们参考进行拆库的一个重点，因此如何划分数据域成为一个关键点。当然最基本的仍然是数据之间的高内聚和低耦合性。

当核心数据对象全部识别出来后，我们进一步梳理数据对象之间的关系和依赖，形成完整的数据逻辑架构视图。

在数据逻辑架构中，我们很容易找到数据的聚合根节点，而聚合根节点往往是我们进行数据域划分的一个重要参考。当然你也可以参考考供应链，财务，人力资源等核心业务域进一步细划分数据域。

数据域的划分是我们进行底层数据分库的一个关键点，当然底层数据库拆分到一个什么样的粒度，仍然需要基于后续进一步的业务协同耦合性分析来评估。

通过前面的数据架构先行和数据域解耦思路，基本就形成了底层数据服务能力的基座。这个也是后续支撑上层业务的关键。这就是核心的数据驱动的思路，先想清楚你有什么，再考虑考虑这些能力如何支撑上层业务需求。

这个转变很难，但是如果不进行这个转变，那么仍然会走传统业务驱动IT，去划分业务模块，然后到各个业务模块里面实现各个业务功能的老路。

新思路下的阶段演进

再次新的数据驱动思路重点是首先识别底层数据服务能力，然后再考虑考虑上层应用的构建，核心是应用和数据分离，这个是第一个阶段可以做到的点。

其次在整个发展演进的过程中，你会发现上层应用的构建本身来说还可以抽象共性业务服务能力，也就是说共性业务服务能力可以单独抽取出来构建。这个共性业务服务能力是独立的组件，调用了底层数据服务层能力，同时在实现过程中又增加了相应的业务规则和逻辑。

当共性业务层能力逐步积累后，你会发现上层应用构建更加轻量和快捷。当企业自身的业务成熟度和IT管控能力不强的时候，你就可以暂缓下沉共性业务服务能力，给上层业务和应用构建保证足够的灵活度。

再回到本质来说，构建上层应用带来的变化。

比如你原来没有实现采购订单执行跟踪的前端应用功能，你现在要去实现这个功能，那么你会发现这个功能都是来源于底层数据或业务服务能力构建，这个业务功能构建是独立的微服务，不依赖于你已有的采购管理系统，可以独立存在。同时这个功能本身也可以带数据库，但是这个数据库仅仅是做临时单据的暂存，属于你自己的私有数据。

前后端划分方法上的变化

在前面我写过一篇关于领域模型和边界划分的文章，大家可以参考下。

对领域模型和上下文边界分析来划分微服务的再思考

在这篇文章里面重点仍然是在说明如何进行组件边界的划分，微服务的划分等核心内容。而在今天这篇文章，重点是想说明前后端划分方法上出现的一个关键变化。简单总结就是：

应用构建应该前后端分离，后端基于数据域划分为多个独立数据中心或数据库，前端基于业务流程划分为多个独立应用。

这个总结里面最重要的一个点就是前端应用的划分不再是基于业务功能模块的实现来划分的，而是基于流程来划分的。也就是说前端应用是基于完整的业务需求和场景实现了业务流程的贯通，而并不关心你底层数据逻辑，不关心中间要交互多少业务单元。如果真正做到这样，才是打破传统的业务边界和IT系统边界的关键。