转自：http://www.itpub.net/viewthread.php?tid=309192&extra=&page=1
1.
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
其实是分散处理还是批处理，这些都是指那些无需人员干预的业务，有系统自动完成，但是怎么来完成，什么时间来完成，需要引入任务管理引擎。按照任务的特点进行配置管理。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
冲正一般是指对财务或帐务上进行反向操作，使之总数不变的处理。它是一个正常的财务功能，不是一个错误处理或是容错处理功能。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
我所接触的核心业务系统主要是以提供数据表的方式向营销管理系统和财务系统来提供接口数据。我觉得最好能使用webservice方式，传递XML数据，这样接口可以不变，如果变化只是XML结构的变化。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
对于历史不规范的数据首先要保证它的历史性，然后通过一定的规则把相关重要部分进行抽取与清洗，为现在所应用。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
数据的校验既可以做死，也可以做活，既可以使用程序写死，也可以使用逻辑规则定义。
六、如何提供财务接口
业务系统的核心是流程，但是对于一个公司而言，财务永远是至关重要的。
对于保险业财接口，我还是有一年多的体会。我所接触的业财接口有两种方式：一种是业务系统提供业务的帐务数据，提供业务类型给财务系统，有财务系统进行业务类型到财务科目的汇总。另一种就是直接提供财务系统的科目数据，在接口中就把财务数据转换完成。
我认为一个灵活的业务系统这两种方式都应该支持，还有就是业务类型一般是相对于核心系统是不变的，而对应的科目数据是不尽相同的，所以最好能提供一套业务类型对应科目的规则引擎，来兼容不同的财务系统。
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
这就看系统设计的颗粒度是怎么划分的，其实有些业务颗粒都是差不多的，只是流程上变化很大，那其实就是需要很强的业务流程引擎来处理。还有就是核心的业务流程基本是一样的，那些不同的客户化工作也是可以用特殊的手段来定制。
2.
一、分散处理还是批处理
集中处理是基于简化一般交易的原则。但是，如果系统中有大量的批处理，协调这些批处理本身就是一个很复杂的算法。
这两个根本不是一个层面的问题。入单，承保可以分散处理，一些分红交易动作和报表可以批次处理。批次处理要配合合理的业务流程。
二、如何处理冲正
对于系统设计而言，最好的方式是不用冲正，所有的错误通过流程的控制来限制。因为一个反向交易可能比同一个正向交易复杂好多倍。
但是，任何人都不可能不犯错误，复核只能限制错误过多的发生，不能杜绝错误。如果我们不希望总是要在发生错误的时候修改数据，就需要考虑冲正的问题。虽然着比较痛苦。
当然，一个前提条件是一个录入错误不应该导致不可控制的后果，例如一张保单的份数倍扩大了一百倍，随后就发生了退保，然后才发现错误。这种情况可能要考虑人为因素了。
如果系统支持冲正就很简单了，每一步的操作都有严谨的日志记录，和妥善的日志查询机制。
现在主要问题是系统不支持冲正，然后再来改就比较困难。但如果愿意花很大精力和意愿的话还是有可能达到要求的。
三、如何对外围系统提供数据接口
在这方面有很多的尝试，不过感觉上成功的经验不多。最普遍的情况是提供数据的时候必须要在功能和性能之间权衡。
事实上，作为核心系统的设计，以前很少考虑外围系统的需要。如果这种需要在核心系统设计的初期得到重视，情况可能会好很多。
这个是确实存在的问题。太保设计了一IDC项目，就是外围系统集中从IDC取数据。设计思路应该问题不大。但难点是如何做好一个IDC项目。这就涉及到投入的人和资金了。
四、如何处理历史上的不规范数据
可能起步比较早的公司都会遇到类似的问题。
不规范的数据是隐藏在系统中的随时可能爆炸的炸弹。对这些数据清理的工作量会大到不可估量。
同时，这些数据对统计等造成的影响几乎是必然的。
这个问题非常笼统，我的经验是碰到问题一定要提出来，由核心小组讨论解决。非常快速的正确的给出处理方案。假以时日系统会越来越完善。不要惧怕问题。
五、如何校验数据
一个数据是否正确，除了涉及比较可靠的安全级别，使这些数据不会得到不谨慎的修改，在技术上是否还有其他手段校验呢？
这样的校验问题同样存在于基础数据的校验和业务数据的校验。
任何系统在于操作的人（使用者）和系统的限制（开发者），和一种修复机制（数据维护者）这三者一起来保证数据的正确完整性。新人和老手效果大相径庭
七、如何适应个性化的需求
中国是一个幅员辽阔的国家，上海的情况和乌鲁木齐显然有很多不一样的地方。作为系统设计，不能指望全国在业务流程上是完全一样的。
但是这种区别会给系统的设计造成很多的影响。
归纳共性，分析个性，协调业务。开发实施。
总之我觉得LZ的问题都是每家公司都日常遇到的问题。任何问题必然都是有解决的方案。问题老解决不了无非投入的问题尔。