ECTIP没有存在必要性

一． ECTIP（企业级电子渠道整合平台）结构分析
渠道交易整合平台要对不同渠道、渠道与客户、产品实行整合管理，定义各类渠道的竞争优势，明晰每个渠道的职责、客户定位和每个渠道重点运营的产品和服务，设计统一的操作流程和服务界面，保证服务质量的一致性和品牌的一致性。实现后的效果是：
 实现了各个渠道系统的数据共享，消除了渠道的信息孤岛及数据冗余，使渠道信息保持了完整性和一致性。
 形成了单一的客户视图，使客户信息能够跨渠道共享，为客户在各渠道间提供一致性的体验和服务。
 实现了渠道间交叉签约，为客户提供个性化的服务。

ECTIP与前后端系统的关系：



       图1-1  注：红色部分为ECTIP系统
最前端的是各个渠道系统，分别是网上银行，呼叫中心，手机银行和其他渠道系统，中间红色的部分是ECTIP，最后端的是EAI，DCC和其他服务。其中ECTIP包括了三个大的功能，分别是：渠道公用功能，交易交互处理，渠道互动；渠道公用功能是将各渠道的通有业务功能集中在一起（比如计费）；交易交互处理时前端渠道通过ECTIP可以访问其他渠道和最后端服务系统，其具备EAI或ESB的交易路由和协议转换的功能；所谓的渠道互动是渠道之间可以相互访问，相互签约。
优势：一个项目兼顾很多功能，可以集中开发（这也是它的劣势），可以做到渠道之间相互签约
劣势：
一个项目拥有太多的职责，在大型企业应用中风险太高，如果这个项目出了问题整个企业都会受到严重的影响，没办法分解风险。
交易交互处理中有EAI（ESB）的作用(协议转换和交易路由)，而其又连接EAI（ESB），导致在整个银行的架构中功能重复，架构混乱和各个项目的职责趋于不明确，也使得ECTIP有些臃肿。
渠道公用功能处理各个渠道中共有的业务逻辑，属于星状结构，一个公有模块出问题会导致前端的各个渠道相应功能瘫痪，如果在实际开发中做不到强有力的扩展性设计，随着ECTIP电子渠道的增多，各个渠道业务需求的变动，用户量的增加，其后续开发，维护和扩展会越来越困难，这些公有模块本来就和业务相关，真正做到开发“通用”很难。

二．升级方案
正如前面所说ECTIP电子渠道的增多，各个渠道业务需求的变动，用户量的增加，使得很多原先的设计，脱离了设计的初衷，比如在ECTIP中交易交互处理在设计出开始仅仅是为了渠道互动，通过EAI（ESB）来访问后端核心业务系统，但是现在开始接入DCC等后端的服务系统，所以其逐渐含有EAI（ESB）特性。
以下提出的是一种改进型的方案，其并不是对ECTIP进行局部调整，而是基于ECTIP现有平台的一种升级方案。


 
图2-1
此方案是将ECTIP中交易交互处理取出来，建立电子渠道的EAI（ESB），剩余的部分命名为渠道后置。
渠道后置的作用实现各渠道的公用模块和渠道互动等功能，电子渠道的EAI（ESB）则是渠道与后端服务系统的中转。
优势：
  使得各个系统的责任单一化，任务明确。
电子渠道EAI（ESB）可以分流部分交易，减轻现有EAI（ESB）的压力，使得电子渠道和现有EAI（ESB）所属前端系统分离。
劣势：
各个渠道同时连接渠道后置和电子渠道EAI（ESB）两个系统，
电子渠道EAI（ESB）和现有EAI（ESB）同时连接后端服务系统。
渠道后置如果在实际开发中不进行严格控制的话，可能逐渐变成现在的ECTIP。
渠道后置也是星状结构。

 

针对于第二条劣势可以将电子渠道EAI（ESB）和现有EAI（ESB）合并，如下图：

（备注：对于后续提出的方案，均在图2-2的基础上（同时适用于图2-1），）

 

 

图2-2

 

三．职责分析后的最终方案

各渠道的公有模块属于渠道后置还是各个渠道？按理说这些公有模块属于各个渠道的，因为其有一定的相似性，所以才提出来进行统一开发，但是各个渠道自己的特色需求导致其又有一定的差异性。如果说这种星状结构有比较高的安全性，强有力伸缩性和扩展性设计，放在一起做还是可以的；如果说没有达到此要求，统一开会存在比较大的风险，而且每个渠道需求的差异性导致了这些公有模块不能真正的做到通用或复用；还要有几个问题考虑的，为什么要将这些相似的模块从各个渠道分解出来，交由另一个项目组来做呢？是否考虑到其中的业务需求到测试要跨项目组，增加项目组之间的沟通成本和相互依赖？如果A渠道和B渠道都有相似的功能，如何确定其属于公有模块？是否交给渠道后置呢？而界限是怎么划分的呢？

    所以最终的答案是每个渠道的业务逻辑由每个渠道去做，而不是将相似的业务逻辑提取出来做成通用模块，这样做的好处保持项目组的完整性，降低项目组之间沟通的成本和相互依赖性，当然这样做也会出现一个问题，是否会引来重复开发？如果对一些通用但是不变的模块开发成通用组件，交给各个渠道调用和扩展，其开发量并不是很大，这个问题也会得到解决。

    说到这里，渠道后置功能就剩下最后一块——渠道互动。公用模块返还给各个渠道，交易交互处理交给EAI（ESB）。渠道互动是各渠道间信息交互，可以建立前端EAI（ESB）如下图3-1

                         图3-1

 

前端EAI（ESB）的作用则是个渠道之间的信息交互，不会访问后端核心业务系统或其他服务系统，EAI（ESB）不参与渠道间的信息交互，直接连接后端服务系统。如果渠道之间的的相互访问不是很多可以将前端EAI（ESB）和EAI（ESB）合并，最后化繁为简，企业中所有的项目和服务的交互都由一条EAI(ESB)完成。