寿险核心业务系统设计的问题 - 第2页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
其实是分散处理还是批处理，这些都是指那些无需人员干预的业务，有系统自动完成，但是怎么来完成，什么时间来完成，需要引入任务管理引擎。按照任务的特点进行配置管理。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
冲正一般是指对财务或帐务上进行反向操作，使之总数不变的处理。它是一个正常的财务功能，不是一个错误处理或是容错处理功能。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
我所接触的核心业务系统主要是以提供数据表的方式向营销管理系统和财务系统来提供接口数据。我觉得最好能使用webservice方式，传递XML数据，这样接口可以不变，如果变化只是XML结构的变化。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
对于历史不规范的数据首先要保证它的历史性，然后通过一定的规则把相关重要部分进行抽取与清洗，为现在所应用。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
数据的校验既可以做死，也可以做活，既可以使用程序写死，也可以使用逻辑规则定义。
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
对于保险业财接口，我还是有一年多的体会。我所接触的业财接口有两种方式：一种是业务系统提供业务的帐务数据，提供业务类型给财务系统，有财务系统进行业务类型到财务科目的汇总。另一种就是直接提供财务系统的科目数据，在接口中就把财务数据转换完成。
我认为一个灵活的业务系统这两种方式都应该支持，还有就是业务类型一般是相对于核心系统是不变的，而对应的科目数据是不尽相同的，所以最好能提供一套业务类型对应科目的规则引擎，来兼容不同的财务系统。
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
这就看系统设计的颗粒度是怎么划分的，其实有些业务颗粒都是差不多的，只是流程上变化很大，那其实就是需要很强的业务流程引擎来处理。还有就是核心的业务流程基本是一样的，那些不同的客户化工作也是可以用特殊的手段来定制。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
eastdak@hotmail.com
e365@163.com
最近我在公司碰到的就是各业务模块之间的耦合问题，觉得如果能使用消息队列＋web service的设计方式很多问题就会很好解决了。
由于对SOA不是很了解，因此，也不知道我所想的是不是就是初级的SOA架构
顺便说一句，中科软实在是烂得不行了，快受不了他们了。
1、寿险行业经验11年-15年；
2、从事架构师岗位工作经验6年以上，具备带领15人以上团队的管理经验；
3、出色的沟通能力和清晰敏感的技术方向把控能力，具备面向客户高层（寿险公司CIO或董事长）汇报能力；
4、熟悉当下主流的java框架和设计模式，对寿险行业常见各类开源产品能有较为深入研究；
5、熟悉寿险行业网络、安全、中间件等领域的技术要求和技术实现；
6、熟悉寿险行业任意一款主流核心业务产品，并在该产品上从事过不少于2年的开发和设计工作；
7、熟悉寿险行业核心配套的主流相关系统技术实施，如：工作流、规则引擎等。
猎头Eiven E-mail lietou@suntray.com ,QQ:809578955