讨论：银行IT蓝图（2）- 综合前置
上回书说到渠道，似乎没什么参与讨论，这回书着落在业务从渠道接入后到达之地 - 综合前置综合前置也有叫大前置的，顾名思义前置是放在后台主机前面做一些预处理或一些主机不好做、不适合作的事情。例如，与多个协作方通信，报文格式转换和组装等等。综合前置之前，前置大多是分散的，比如ATMP，POSP，证券，中间业务可能都是各自一套。不同厂商开发，不同程序语言，不同平台...。后来逐渐整合到一起，成为综合前置：一个体系架构，一种开发语言，甚至一个系统。慢慢地综合前置也出现很多变种，有些做渠道整合平台，有些作中间业务平台，甚至有些发展为企业整合平台/企业总线...
无论叫什么名字，就是渠道与后台业务主机之间那部分，按以前的叫法，中台，渠道叫前台。：）
中台这一块现在在SOA的喧嚣下越发被重视，只是要从以前大前置转上SOA轨道，还是需要很多努力。中台主要的功能是和不同的系统、第三方互联，报文的格式化，组合多方交易实现新的业务逻辑。从我个人的设想看，前台，就是渠道这块，应该只负责展示，不应该含有任何处理逻辑；而中台，这里要分两部分，一部分负责通信和报文格式适配，姑且叫综合前置，另一部分是业务逻辑实现，其实这部分也和后台性质上也很相似了，只是没有后台业务内聚那里完备，在SOA的架构模式下，两者的界限已经分不太清。后台这一块，应该以合适的粒度封装业务逻辑成为一个个服务。后台最重要就是对业务的提炼，而现在大多后台系统是个打包系统，前中后都管的。可能一些用大机的行会分的清一点。
综合前置的要求，最重要的是灵活，能够容易地增加新的渠道接入，第三方通信，新的报文格式转换。曾经考虑用OSGi的模式来实现一个，未完成。而在后台系统还不太可能大幅度改造的情况下，应该再有一个业务运行平台，处理业务逻辑。市面上有一些这样和二为一的产品。综合前置部分做的还过得去，但业务运行平台还是差强人意，老外在这部分作的不错，软件比较成型。
写这么多！ 写的不错，能否具体说说“综合前置的要求，最重要的是灵活，能够容易地增加新的渠道接入”——应该如何达成？ 原帖由 SeeaMonster 于 2007-8-14 10:41 发表 http://bbs.chinaunix.net/images/common/back.gif
写的不错，能否具体说说“综合前置的要求，最重要的是灵活，能够容易地增加新的渠道接入”——应该如何达成？
在交易方面，尽量做到模块化，将公共部分子交易化。
在通讯方面尽量做到互不相干。
这个帖子不错，欢迎大家踊跃讨论:em10: 原帖由 dlms 于 2007-8-14 11:12 发表 http://bbs.chinaunix.net/images/common/back.gif
在交易方面，尽量做到模块化，将公共部分子交易化。
在通讯方面尽量做到互不相干。
这个帖子不错，欢迎大家踊跃讨论:em10:
感觉也是个知易行难的事啊，要做到交易定制化，感觉难度很大啊。 原帖由 SeeaMonster 于 2007-8-14 13:44 发表 http://bbs.chinaunix.net/images/common/back.gif
感觉也是个知易行难的事啊，要做到交易定制化，感觉难度很大啊。
呵呵这个不难，国内很多前置开发商已经做到这一点了。
1.首先公司产品环境允许你这样作，这点尤其重要，产品都没有模块化从何谈应用模块化呢。
项目周期就那点，费用就那么多，如果产品没有模块化，项目实施这个层次就很难做了。
有些小的商行早些年不太重视前置业务，他们的前置产品都是核心业务开发商捎带送的东西，类似这样的东西很难模块化的。
2.要有良好的项目实施规范，和版本控制观念。
一个前置产品，到各地实施因为客户的需求不同，到处改产品，造成一个产品多个版本，这样的现象也是很普遍的。
所以一定要做好产品版本控制。这里所说的事前置产品的版本控制，最后由产品部门统一维护，源码不下放到现场实施组里。
3.应用模块化
前置的业务大体相同，业务逻辑没有核心帐务那么复杂，如果在某行的一个分行实施过了，只要稍加改造到另外一个分行就可以直接使用。
直接使用的前提是必须作到交易模块化，比如我在某行分行实施过移动代收费项目，在另外一个分行也有这样的子业务，那么上主机的部分就是公共的了。
这样就可以大大缩短项目周期，从而降低项目成本，提升人月费用。
说是这样说，但是真正做好这样的公司不太多，但是还是有公司一直在坚持这样作的。 其实很蛇足，既增加了应用结构的复杂性，增加了出错的环节，也为系统引进了一个性能瓶颈，除了一个理由，真的没有存在的必要。特别是中小系统，要慎重考虑。
几个回答
1、关于二楼同学对灵活性的问题，版主作了很好的回答。我在这里再具体一点：主要要提炼的有三个方面：a、架构方面，比如如何把通信、拆组报文、加密等分好层次和耦合；b、在通信方面，总结出如TCP/IP，HTTP，CICS，TUXEDO，UDP...然后通过设定参数就能实现一个接入；c、在报文方面如定长、分割符、8583、XML...等等也是可通过配置来控制拆分组装。至于交易逻辑的提炼，这和后台应用的做法类似，我将在下一个讨论专题讨论。2、关于YG对于前置系统有画蛇添足的嫌疑，不可否认，众多前置系统让整个IT看起来复杂了，但存在还是合理的。局域网内的通信效率如今很高了，高内聚松耦合的理论不仅仅在一个程序里，可以扩大到架构层次，让各个层面专注于自己的工作，会为更高效率的开发和改变提供便利。现今SOA的概念无非把内聚松耦的想法发展到了极致，在企业内、企业外都可组合。 在通信方面，总结出如TCP/IP，HTTP，CICS，TUXEDO，UDP...然后通过设定参数就能实现一个接入；c、在报文方面如定长、分割符、8583、XML...等等也是可通过配置来控制拆分组装
不知道有哪个银行的系统是把所谓的“综合前置”直接开放给渠道的。如果这些都给综合前置做，那渠道前置又做些什么呢
“综合前置”就象A片，看着爽，做的未必爽啊 原帖由 yg 于 2007-8-15 08:55 发表 http://bbs.chinaunix.net/images/common/back.gif
不知道有哪个银行的系统是把所谓的“综合前置”直接开放给渠道的。如果这些都给综合前置做，那渠道前置又做些什么呢
“综合前置”就象A片，看着爽，做的未必爽啊
综合前置是个大概念。
就拿四大银行中的一家说说吧，综合前置有总行前置，和分行前置之分。
实际上在很多分行，渠道业务是走前置上总行的。
但是也有很多行对于渠道业务，是先到总行渠道前置，前置拆分后根据分行代码，在跟分行发生通讯，分行处理交易后返回总行的前置，然后给业务发起方。
呵呵实现方式多种多样。:em10: 看来所谓的“综合前置”连内涵都没法界定，讨论也没什么意义。
每增加一个环节，对网络事务都是很棘手的，特别是牵扯第三方的交易，为了保证逐层提交的可靠性，付出的代价是很大的。
套用数学的原则，“简单的就是最美的”。
所以，不要为了“综合前置”，而“综合前置”，能简单就简单点吧。