信息化孤岛探讨及解决思路（六）业务应用孤岛问题的解决
问题
前面我们分析了信息化孤岛 明确了整体方案需要解决的几种孤岛类型 包括交付、数据、业务（应用）和资源孤岛。又深入一点的讨论了交付和数据融合，这次，我们谈谈业务（应用）孤岛的融合。
这是之前关于业务孤岛解决方案的总结：再回到应用（业务）孤岛，我们之前已经将应用的功能分成两类，一类是业务本身的功能，一类是标准功能。标准功能部分，完全可以按照数据库中间件的做法，以使用提供的paas层的服务来实现、建设，除了节省投入外、还起到规范功能、规范共同数据的作用（比如用户id），可以帮助数据的融合，通过这些方式，将业务孤岛的范围缩小到业务本身，尽可能的减少复杂度。
对于业务本身，相关联的业务有两种可能性，紧耦合和松耦合两种。紧耦合的业务，相关的几个应用只能通过统一设计、或者服务总线这些传统方式，来达到业务融合的目的。对于松耦合的，通过串接的方式，确实比较容易实现业务的关联使用（比如购物、下单、出库、快递、签收、评价这个流程，各环节独立、相互不干扰不嵌套的）
还有一种新的方案，类似于松耦合的方案：基于数据的融合，根据业务的需求，重新设计面向业务的新的应用，与原有专业的应用配合使用，达到业务融合的效果。新的应用（我们也称之为智能专项应用）提供给普通的使用者、领导等，针对的提供他们所需要的信息和操作、尽量的简化，既减少投入又符合使用习惯。而原有的应用保留提供给专业分工人士，比如OA、财务、仓管、快递员（举例）等。可以理解为原应用+衍生轻应用等模式，是不是可以解决业务融合的问题了？至少是一种不错的解决方案，而可以看到智慧应用也在这种模式下产生出来了。
接下来我们讨论上述方案是否可行？如何操作？有没有不同的方案？
讨论
针对这些问题，小伙伴们循例进行了如下，有些发散但有益的讨论：
对于解决数据孤岛，那么肯定是建设一个数据融合平台了，也就是所谓数据池，兼顾到以后未来的应用，那么还需要考虑到现有的应用可能还会存在传统数据库，既然这么做的话，那就还得考虑把传统数据库的数据慢慢的，逐渐的向迁移大数据平台，类型通常就是半结构化非结构化的数据类型。可是传统数据库改造成大数据的那些方式其实可能会有一些问题，有两个问题吧。第一应用本身他有自己的运转，他是有自己的方式的，可能需要的还是传统型数据库，像那种事务型的比如银行的转账业务，他是有关联动作的，而大数据类型的目前支持不了的，所以还是需要传统型的数据库。第二呢，在藕合上，低耦合设计，应用本身是要能够自成一体的，所以呢，不能够直接改造。
比较好的方式应该还是区分各种数据，按各种数据对时间要求的需要，尽量减少实时准实时的数据的需要，缩小那个处理的范围，对那些数据，需要实时、准实时的就提供接口我的浅见：业务孤岛产生的一个重要原因是数据孤岛，数据隔离了，那么把数据融合了，同时结合标准化中间层服务，自然就更加方便的实现业务融合，解决业务孤岛。
延伸问题：那么对于用户来说，还是那些系统，他看不到什么变化，数据融合了，但是业务上会有什么变化？能不能再深入说一下？
我比较倾向于第二种方案，重新设计业务流程。以新的界面、逻辑展现给用户，这样可以清晰告诉用户，这是一套全新的东西，更加直观。跟用户说再多的数据融合，可能还不如一套新界面来的直观。虽然重新设计应用，短期内成本较高，但能更好的梳理流程。紧耦合的方式，看起来会简单，但是，很容易陷入之前旧的逻辑当中去，到最后，发现，改了，并没有优化多少。
我也比较倾向于第二种方案，客户多数心理预期是：我花了很多钱，我要看到大的改变。那么最直观的就是新的UI、新的操作逻辑了。当然，数据融合，要体现在新的东西里，很重要的一点也是统一中间件，方便数据在不同的应用中使用。
延伸问题：那旧的系统怎么办？还用吗？如果还用，用法如何？新的系统功能会包含所有的旧系统功能吗？工作量会不会太大？对于决策者来说，他可能会理解为所有系统全部重做，他需要知道怎么样才能够在他可以承受的范围内完成这个解决方案，所以这个是必须说清楚的。
这就是前期梳理流程的工作了，需要跟用户沟通清楚，从一个大而全的系统中，找出符合自己实际工作的应用。重新排列组合。至于旧的系统，需要要有一段长时间的并行阶段，其实，可以两种方案综合一起。
其实数据整合共享、推动数据开放，很多情况下和原有的业务系统是不冲突的。我说的重点是使用上，往往还是关联紧密的。原有业务使用方式可以不变，但是可以做到应用的快速迭代开发、可以做到之前想着但是却很难实现的新的业务需求，我们经常说的重新设计面向业务的新的应用，其实大部分是客户新的需求。
用原有业务可以满足的，肯定就是使用原有的了，新需求产生的业务如果和原有业务有冲突，一般说明原有业务满足不了，后续慢慢会被取代，或者补充。
我觉得适当优化交互，简化操作流程好一点。因为用户在使用旧系统的过程中已经习惯了其中的逻辑交互，如果我们突然换掉可能会需要用户重新去适应新系统。我们可以在保证原功能都可以正常使用的情况下，让用户减少操作步骤，交互感提升。
要对现有业务系统进行梳理分析了，能改造的改造，不能改造的保持，不能为业务融合而融合。
业务是基于需求，融合也是基于需求，不会为融合而去产生一个新业务，只会因为有业务需求才有融合需求。
延伸问题：以新的需求为目标进行新系统的建设，对应的系统按需要进行有限改造或者不改造，不需要用新功能的用户完全可以使用旧系统？
是的
是的
我也这样想，不应该急于一时。
我也觉得是，有新需求才能催生新业务系统。
我个人倾向第二种方案，原应用+衍生轻应用；这种方案，一方面能解决实际的问题，原应用也未丢弃可继续使用，不会觉得前期投入浪费了，也可免去使用者学习熟悉全新应用这一过程；另外，这种改变相对较小，投入的成本也相应会低。这种方案更容易让用户接受。
观点
1、在实现数据融合的基础上，进行业务（应用）融合的更加顺畅；
2、不为了业务融合而融合，而是因为有业务（应用）融合的需要而进行融合；
3、融合的时候，为融合的业务（按需分析）进行重新设计和开发建设，是一个比较可行、高效、相对低成本的方式；
4、基于数据融合，实现新的融合业务（应用），原有应用按需进行必要的改造（一般这个改造也是依照数据融合所需进行即可）；
5、原有应用一般情况下保留使用，该系统的专业用户（如财务、人力、具体业务人员等）沿用，而且也是数据融合数据产生的最大来源；随着业务需要进行对应的改造升级、甚至被替换，但仍需要考虑它作为数据来源这一环；
6、对融合业务有需求的使用者，一般是中、高层用户，主要改为使用新的融合业务（应用）；
7、尽可能使用H5、小程序、轻应用等方式设计和发布新的融合业务（应用），以适应多种终端和统一发布的需要；
如下图，进行了数据融合后，用户还不能看到变化，体会不到数据融合的意义：

开发、建设新的融合业务（应用）后，有融合业务需求的使用者，将使用新的应用以代替原有使用方式，可以得到新的体验，如下图：
对于耦合度很高的业务的融合，还需要考虑采用传统方式进行改造，紧耦合的业务，相关的几个应用只能通过统一设计、或者服务总线这些传统方式，来达到业务融合的目的。
涉及到流程的，对于松耦合的，就算进行了数据的融合，业务流程方面，仍然需要通过串接的方式，在宏观层面实现业务的关联使用（比如购物、下单、出库、快递、签收、评价这个流程，各环节独立、相互不干扰不嵌套的），这种情况下，仍然需要原有业务系统进行相应的接口改造，如果原有系统是按前后端分离的架构进行设计的，那么这个改造成本比较可控，否则，不排除必要的情况下，需要相关原有业务系统进行升级和整体改造。上述松耦合的、业务层面的宏观串接，也是新的融合应用，可以适当优化交互，简化操作流程、让用户减少操作步骤，提升交互感受。
一切都应该有需求促发，有融合的需求才进行融合的建设，才进行相应的设计和改造，进行业务（应用）的融合和数据的融合，流程的融合，才会使用到以上的方式方法，才会有价值、活力。
后续章节我们将继续进行深入探讨。