信息化孤岛探讨及解决思路（六）业务应用孤岛问题的解决

问题

前面我们分析了信息化孤岛 明确了整体方案需要解决的几种孤岛类型 包括交付、数据、业务（应用）和资源孤岛。又深入一点的讨论了交付和数据融合，这次，我们谈谈业务（应用）孤岛的融合。
这是之前关于业务孤岛解决方案的总结：再回到应用（业务）孤岛，我们之前已经将应用的功能分成两类，一类是业务本身的功能，一类是标准功能。标准功能部分，完全可以按照数据库中间件的做法，以使用提供的paas层的服务来实现、建设，除了节省投入外、还起到规范功能、规范共同数据的作用（比如用户id），可以帮助数据的融合，通过这些方式，将业务孤岛的范围缩小到业务本身，尽可能的减少复杂度。

对于业务本身，相关联的业务有两种可能性，紧耦合和松耦合两种。紧耦合的业务，相关的几个应用只能通过统一设计、或者服务总线这些传统方式，来达到业务融合的目的。对于松耦合的，通过串接的方式，确实比较容易实现业务的关联使用（比如购物、下单、出库、快递、签收、评价这个流程，各环节独立、相互不干扰不嵌套的）

还有一种新的方案，类似于松耦合的方案：基于数据的融合，根据业务的需求，重新设计面向业务的新的应用，与原有专业的应用配合使用，达到业务融合的效果。新的应用（我们也称之为智能专项应用）提供给普通的使用者、领导等，针对的提供他们所需要的信息和操作、尽量的简化，既减少投入又符合使用习惯。而原有的应用保留提供给专业分工人士，比如OA、财务、仓管、快递员（举例）等。可以理解为原应用+衍生轻应用等模式，是不是可以解决业务融合的问题了？至少是一种不错的解决方案，而可以看到智慧应用也在这种模式下产生出来了。

接下来我们讨论上述方案是否可行？如何操作？有没有不同的方案？

讨论

针对这些问题，小伙伴们循例进行了如下，有些发散但有益的讨论：

对于解决数据孤岛，那么肯定是建设一个数据融合平台了，也就是所谓数据池，兼顾到以后未来的应用，那么还需要考虑到现有的应用可能还会存在传统数据库，既然这么做的话，那就还得考虑把传统数据库的数据慢慢的，逐渐的向迁移大数据平台，类型通常就是半结构化非结构化的数据类型。可是传统数据库改