对于厚服务层这个概念我在很早以前的博客文章中就已经提到过，由于我前面一直在谈将ESB服务总线重归回技术平台这个概念，但是更这个相对的恰好就是厚服务层和ESB服务平台打造为提供完整的服务资产库的业务平台的解决思路。

　　SOA技术平台到业务平台

　　谈这个概念的核心就在于对于一个商用化的ESB平台，如果定位为技术平台，那么在SOA集成商将相关的技术标准，规范，管控治理和运维体系流程制定清楚后，后面所有的服务都按标准的接入流程进行接入，消费者按标准的服务订购流程进行服务开通和消费，那么对于SOA集成商不再会提供额外的其它价值，只需要保证ESB平台本身的运行可靠和高性能。而对于ESB平台上究竟应该注册和接入哪些服务？这些服务本身的复用性，服务的粒度如何并不需要SOA集成商去关心。那么如果按照这个思路去实施ESB服务总线，虽然整个实施过程更加简单和快捷，但是并不能形成真正有价值的，高复用的，开箱即用的服务资产库。那么对于我们经常谈的SOA咨询规划，服务架构规划方法论的内容也就很难落地了。

　　在13年我谈私有云PaaS平台，谈及用SOA+云计算思想下企业内部平台+应用的全新构建模式和思路，这里面也一直在强调厚PaaS平台的概念，对于厚PaaS平台也是同样强调了共性能力的下沉，在下沉后再提供统一的服务能力开放，而这些共性能力同样既包括了技术能力也包括了业务能力。

　　这里我们拿SAP ERP举例，最近几年也做了多个围绕SAP ERP系统的ESB总线和集成平台，对于SAP ERP传统存在通过PI，SFC，IDOC，ABAP定制程序等多种方式进行接口的开放和集成。这里面不仅仅是接口发布的协议标准，更加重要的是接口实现和处理逻辑，特别是SAP ERP系统本身数据是偏对象存储，你连传统的DB适配这种简单方法都没法应用，包括我们经常谈到的对于增量数据的数据集成和同步，往往也很难实现。而通过我们实施，我们逐渐将所有接口全部转换为标准的WS服务接口，统一接入到ESB服务总线，在这里面采用多种适配器完成服务的接入，协议的转换。

　　如果WS是SAP系统提供，那么ESB服务总线实施就很简单，仅仅是服务代理接入。而如果SAP本身原来就没有即可，也没有开发定制的各种接口程序，那么可以看到如果ESB集成商能够将这块内容完全理解和掌握，并基于SAP标准的接口程序和接口表，发布一套对外交互和协同的WS服务接口。在WS服务接口中可能还涉及到接口数据规则和逻辑校验。如果这些都做到，同时又能够确保服务目录库本身的可复用性和完整性，那么最终围绕SAP发布出来的这套WS服务目录就是一个完整的服务资产库。

　　经过多个SAP系统的接口实施，ESB集成商可以逐渐去形成这套完整的服务资产库，并将这些作为ESB实施能够提供的关键资产的一部分，那么这个时候可以看到ESB实施厂商就不再是一个单纯的技术厂商，而是能够真正解决企业系统间集成的咨询+实施整体方案提供商，同时这种方案包括了技术平台+可用的服务资产清单，以确保服务实施过程中的标准化和快速上线。

　　我们可以试想，如果一个ESB集成厂商将主流的ERP，CRM，SCM，财务，HR，MES，PLM，4A，流程平台系统提供厂商都形成这么一套服务目录和资产库，并形成一套表中的集成方案和服务集成实施方法，那么这种ESB总线的实施完全由ESB厂商就能够完成大部分，而不是需要任何一个接口的改动都需要协同原业务系统开发商才能够完成。同时基于这种完整的服务目录库，ESB集成商将完全有能力做更上层的端到端流程监控和应用层的功能整合提供。

　　ESB总线实施往往会和BI产品实施类似，即单纯的ESB技术平台，BI工具和报表本身价值并不会太大，然而能够提供服务目录库，能够提供BI的指标库的实施商往往更加会被企业选型时重视。

　　SOA厚服务层即业务中台

　　简单来说，如果一个企业已经构建了围绕ERP为核心的多个IT业务系统，而当前又在做数字化转型或者类似消费互联，产业互联的转型。

　　那么传统的ERP为核心的系统可以沉淀为后台系统。

　　通过ERP和后台系统的能力以可复用的API接口的方式注册和接入到SOA总线或能力开放平台，这个提供各类共享业务接口服务能力的平台可以理解为传统遗留IT平滑迁移过程中构建的一个业务中台。

　　这个业务中台不是对传统IT系统全部推倒重建，而是将已有遗留IT系统的服务能力通过适配，组合，重构整合厚接入并开放出来，供前台类似应用使用，类似各种需要快速面对C端客户的数字化营销系统，电商平台等。

　　所以在这种模式下，业务中台自身并不提供业务能力，而是对后台IT系统具备的各种业务能力进行了聚合和组合等，然后再提供出来。这往往才是最大化保留当前企业IT和业务资产的方式，也方便遗留IT系统逐步迁移到新IT架构上。