做了多年的SOA项目咨询和实施，可以看到企业内部业务系统间的集成主要还是三个阶段，在传统EAI和ESB总线阶段，更多解决的是从点对点蜘蛛网集成到总线式集成的转变;而到了当前微服务架构阶段，更多的则是从总线集成到能力开放的思想过渡。
当谈集成的时候往往涉及到数据的交换和数据在多个业务系统中落地，这虽然降低了业务系统之间的耦合性，但是由于数据多点落地也带来数据实时性和一致性方面的问题。而到了微服务阶段，更加强调按需通过能力接口实时使用数据，而不是将数据通过接口同步到自己系统中。
因此集成的发展本身就是从接口集成到能力开放的一个发展过程。同时集成的思路也是从中心化总线式集成逐步到去中心化集成方式过渡。
企业应用集成可以分为如下三个阶段，下面分别进行说明。
第一阶段：完全的点对点集成
业务系统之间完成通过点到点的方式进行集成，形成蜘蛛网式的集成架构。在这个阶段本身又存在几个发展过程，最初级的时候就是接口完全不标准，各种实现技术，各种规格定义都存在，同时对于安全，日志等管控也很弱，导致最多的问题就是后续问题排查很麻烦。
再好点就是定义了接口标准，比如全部走标准的WS服务接口进行集成，或者根据不同的场景定义了2到3种可选的集成方式。在这种情况下接口本身做到标准化和规范化，但是存在的主要问题还是接口本身的管控和治理，即没有一个统一的管控和治理中心，能够实现对企业内部所有的接口统一的接入，开通，授权，日志监控，问题排查等统一的监控和管控。
点对点集成下，接口很难复用，完全是有一个接口需求就做一个接口，造成大量重复开发和联调工作量。
同时点对点集成商，本身技术也导致难以复用，比如一个JMS消息集成，一个大文件传输集成等，往往都需要各个业务系统去准备实现相同的技术组件。这块本身也是无谓的工作量增加和技术投入。
第二阶段：类似接口平台或集成平台
发展到第二阶段，当前谈论比较多的就是接口平台或集成平台。在这个阶段一个最大的转变就是原来的点对点集成模式转变为了基于接口平台的总线Hub式集成模式。所有的业务系统间接口都不直接交互，而是都直接注册和接入到集成平台，然后再由集成平台发布一个统一的接口服务地址供外部业务系统调用。
一个集成平台基本会支撑传统消息，数据，文件，WS服务等各种模式的集成能力。
集成平台的建设和实施一般就会进一步地约定接口技术标准和规范，约定接口开发标准，接口服务的接入标准和消费标准，同时对于注册接入的接口在安全，日志，异常监控，路由，消息发布订阅等多方面给予更强的能力支撑。这些都在统一的集成平台完成，真正提升了SOA治理和管控能力。
在集成平台阶段往往又分两种场景，一种是传统的数据交换平台，重点是数据交换，所有数据全部落地;一种是服务共享平台，提倡的是服务接口实时消费和使用，数据尽量不落地。当前更多的是服务共享平台模式，但是同时存在接口服务数据落地和不落地两种消费场景。
第三阶段：能力开放和OpenAPI平台
能力开放和OpenAPI平台在互联网谈的比较多，但是这也将是企业内部集成发展的一个必然趋势，不仅仅是企业内部业务系统能力超对外的开放，比如电商，B2B等。其次也是企业内部业务系统间的能力开放。
第二阶段往往是A超B提交接口需求，B系统考虑实现一个接口服务。而真正到了能力开放阶段，更多的是以B系统为主去考虑究竟需要暴露和开放哪些能力出去。这是一个关键顺序的变化。
集成平台阶段可以看到服务的注册接入和服务的消费两个过程往往是高度耦合在一起的，有接口需求B系统才会做接口服务，A系统马上就去消费。而到了OpenAPI平台阶段服务接入和服务消费两个过程是松耦合的，即能力即使在没有消费方的情况下也可以先接入并发布到能力库，而各业务系统随时也可查看服务目录库和服务市场发起服务订购请求和消费。
在OpenAPI平台阶段更加强调了以业务系统为主的能力开放。同时也更加强调了各个业务系统基于OpenAPI平台的自服务流程，即整个过程里面并不需要太多的集成商工作参与，所有需要的标准和规约也都全部固化到了类似服务接入，服务订购，服务开通等自服务流程中。
传统集成平台更多的是SOAP WS，Rest，JMS消息各种方式并存，而到了OpenAPI平台由于是以能力开放和发布为主，基本可以全部统一为轻量的Rest服务接口服务模式。
