信息化现状

信息化现状

1、基于数据库的信息化管理系统已渗透到企业运营的各个方面

2、信息化系统需快速适应企业业务发展的变化，否则逐渐成为企业发展的障碍

3、Excel表格数据在企业中大量使用

4、单一系统难以支撑企业的全部业务需求，分布式的独立小系统成为企业信息化的现实

通用问题

1、需求是目前信息技术面临的最大问题

—需求沟通不畅。客户、管理人员、开发人员、测试人员理解可能不一致，容易误解。

—需求变更反应缓慢。客户理解上的小的需求变更，技术实现上可能影响巨大。

—对技术开发人员依赖过大。最详细的、精确的需求最终在程序员脑中或者在代码中。

—技术寄希望于限制需求或者预先封装变化点，但却总是对需求变化力不从心。

2、通用问题-困惑及抱怨

—业务人员

—技术人员很难沟通

—技术老容易出问题

—需求变动总是被拒绝、或者被推迟

—技术人员

—需求总是要变动

—需求总是要求很急

—需求变动工作量

当业务系统正式上线后，当业务需求变化时，业务部门总是希望技术可以马上实现业务需求的变化点，如果技术事先已经设计好并预留这种变化点，则可以很快对应。否则技术人员的工作量非常大，而且

也容易出错

通用突破-原因及探索

. 业务需求

. 业务逻辑描述容易想当然

. 采用Excel进行数据处理操作简单

. 业务需求逻辑描述不够严谨

. 技术实现

. 程序语言与业务语言的差距太大

. 技术需要多人分工处理数据层、逻辑层和界面层的实现

. 技术人员容易误解业务

采用尽可能和业务语言接近的方式来实现业务逻辑，采用技术人员、业务人员、管理人员都可以看得懂工具来定义规则。

将数据层、逻辑层基础框架、界面层的实现自动化，技术人员只需要关注业务逻辑的实现，使得技术人员实现业务逻辑的工作量接近业务人员描述业务逻辑的工作量。

让业务人员、管理人员也可以参与或负责业务逻辑的实现

让技术人员可以减少做重复、琐碎、技术含量低的工作

. 通用突破-优秀框架解决方法

. 优点

. 利用复用技术，重用了很多代码和组件。减轻了大量开发工作。

. 充分利用设计模式中封装变化点的技巧，能快速适应预想的需求变化

. 采用优秀的框架能制作出非常好的效果。

. 业务组件的设计并实现，可以简化大量的工作

. 不足

. 对框架的依赖大，框架的设计影响其适用面

. 对架构师要求高，需要全面了解框架才能进行优秀的设计

. 对业务熟悉要求高，需要预先设计并封装变化点

设计模式的目的是为将来世界的模型提供变化点、处理变化的需求。好的系统设计必须考虑可扩展性、灵活性和可插入性。……

. 通用突破-工作流解决方法

. 优点

. 实现业务上对工作流程的控制和管理。

. 简化了流程控制逻辑的实现。

. 简化了表单的设计和制作。

用xxx开发应用软件，会具有前所未有的高效率、高质量、高适应性。其目标是让每个应用软件开发人员成为优秀的系统分析员，而不是代码的奴隶。不用写代码便能生成各种各样的应用程序。……

. 不足

. 粗粒度的流程图难以定义复杂的逻辑处理

. 对于流程节点的逻辑处理，仍然需要编写代码实现

. 通用突破-传统规则引擎解决方法

. 优点

. 实现业务逻辑的可视化定义，增强了业务逻辑实现的可读性。

. 实现了业务规则的独立管理，真正实现业务逻辑的分析。

. 实现了业务逻辑的快速变更，与Office的配合使得业务人员可以参与业务逻辑的变更。

. 不足

. Rete算法的复杂性决定了配置规则的学习曲线很高

. 需要优秀的系统分析师规划设计实现规则的结构

. 需要优秀的架构师来优化并考虑规则执行性能

. 对数据结构的变化无能为力

CDG现存问题

. 客户

. 对需求变更响应速度慢

. IT系统不稳定, 差错率很高(尤其是新产品上线时)；

. 对客户业务或规则不够了解

. 测试的时间长、联测的效率低。

. CDG

. 没有规范全面的业务规则文档、文档和程序不同步

. 人员变动频繁（IT、运营服务都存在这样的情况），新的人员在短时间内很难对规则进行详细的了解。

. 每个客户的规则差异大，需求变更技术改动工作量大

. 没有统一业务规则处理流程文档，运营、开发、测试部门理解的客户业务规则不一定一致CDG尝试突破

.尝试突破

.从Delphi转到C#语言

.用设计模式思想采用新的系统结构

.采用新的分布式架构设计

.采用开源规则引擎来处理理赔规则

.采用新的工作流引擎

.仍需改进

.业务规则实现仍然不够透明

.业务规则的规范化、标准化工作仍需强化

.保险行业数据结构和规则的共性分析仍需加强

.基于开源规则引擎和工作流引擎的性能仍成问题

.开源规则引擎实施工作量大，适用范围小

旗正解决方案

—旗正解决方案--实现目的

—业务

—将业务逻辑的实现白盒化，采用业务语言来展现业务逻辑的实现

—实现业务规则的完全配置化（无编码）实现

—增强对系统中应用的业务规则的控制和管理

—业务人员可以清晰了解已实现的规则，并且清楚变更规则所需要的时间和工作量

—技术

—实现业务逻辑和数据结构描述与实现一一对应。实现业务逻辑变更和实现变更基本同步。

—强制分离业务逻辑、数据存储、界面表单、流程控制

—简化琐碎的处理业务逻辑开发工作，减少沟通时间

—可以将精力集中在架构设计、数据结构设计、算法设计、高层业务分析等更有技术含量的工作

业务和技术分管更加明确。将程序员从琐碎的业务逻辑编码中解放出来。

业务人员可以掌控全面完整的业务规则、技术人员可以专心于提高技术水平

—旗正解决方案--改良规则引擎

—支持变化

—不光支持业务规则处理逻辑的动态变化

—支持调用接口数据结构的变化。

—支持数据库源结构变化

—支持XML结构变化

—支持Excel源结构变化

—适用面

—支持批量数据处理和传递

—支持数据字典等定义

—支持常量结构定义

—支持子规则、循环类规则