解析保险系统的顶层结构

　字体小大时间：2015-01-17来源：中国社保网编辑：社保网-夏宇

【导读】:在这一篇文章中，我们将介绍在多数现代保险系统中可以看到的、依据保险价值链而存在的顶层子系统。保险系统中一个非常重要的产品部件就是所谓的产品服务器。典型情况下，作为一个产品服务器，它存在一个用于处理产品规则的规则系统。模式1：保险价值链例子你

在这一篇文章中，我们将介绍在多数现代保险系统中可以看到的、依据保险价值链而存在的顶层子系统。保险系统中一个非常重要的产品部件就是所谓的产品服务器。典型情况下，作为一个产品服务器，它存在一个用于处理产品规则的规则系统。

模式1：保险价值链

例子

你被分配去为新的保险办公系统设计结构。在现在的系统中，你找到一个一个根据产品分类的系统分支，如人寿保险，财产保险，汽车保险。你发现，这些现存系统中存在大量交叉重复功能，尤其在申报处理系统和政策处理系统。你也发现要增加一个新的产品需要做的工作十分繁琐冗长，它以每年增加两个新产品的速率进行着。这样低效的原因源自于系统管理政策部分和管理申报处理部分的产品知识混乱，更多其他的产品知识还存在于系统其它部分。

问题

对一个保险办公系统中的大部分商务功能和商务对象来说，什么是一个好的领域构架呢？

约束

系统应该这样来构造，它必须能支持你的竞争战略。我们已经讨论了工作中的市场约束。

方案

根据保险中的价值链构架领域结构。产品－政策－申报处理－销售和市场－客户服务，再加上帮助系统，比如伙伴子系统，保险对象子系统，进出支付系统。

结构

图1 依据保险价值链的保险系统结构图

类似于Porter的价值链模型，这种结构被保险业所采用。

过子系统来进行价值链建模：

· 产品开发和定义子系统：产品为其他子系统所使用前必须给予定义。产品开发和定义子系统负责为其它系统提供产品定义。产品定义由系统其它部分解释。

· 政策参数子系统：负责存储政策参数，支持所有开展商务活动的用例。

· 销售和市场子系统：处理面向客户的产品销售

· 客户服务子系统：有助于向你的客户提供你期望的额外服务，这些服务是在投诉系统所规定的服务之外的。

要建模好所有的商务功能，你需要像下面一样的帮助子系统：

· 伙伴子系统：存储你公司所有合作伙伴的信息。

· 被保对象子系统：存储有关被保和投保对象的信息。

· 支付子系统：处理收入和支出的现金流。

通常你会发现还有好多系统，比如通用名册保持（general bookkeeping），管理信息系统和数据仓库，人力资源系统等等，这些系统不单是针对保险系统，而是普遍存在的，所以我们这里不再进一步讲述。

结论

并非只要采用保险价值链模型就能得到一个灵活柔性的系统和缩短的市场开发时间，你还需要使用更多类似产品服务器、产品实例参数这样的模式来帮助你实现目标。

采用模式你可以建立一个满足所有产品类的系统，但是不能一步到位，多数情况下你需要先从一部分产品类开始，然后逐渐扩充系统以便从遗留系统迁移过来。如果这样，你就避免了重复投资，从而减缩开发费用。

上述结构是为内勤系统设计的。它并不会单独影响你在服务上的态度。

采用上述结构并不意味着能减少通讯的层次，节省开支。要想达到这个目的，你需要启动业务过程重组并采用工作流系统。

实现

保险价值链是一个领域构架模式，要实现一个现实系统你需要一个应用构架。目前，多数领域系统都通过一个树状层次构架来建造。工作流系统也经常用到。通常，你无法在一个地方一下子实现整个系统，或者一下子实现虚拟的单个系统。目前的网络带宽和性能还不如人意，基于这些考虑，你不得不把系统分成内勤和保险销售两个系统。

变种

你常常会发现产品系统和政策参数系统联合工作方式的差异。将要谈到的产品服务器模式与上述两者都不同，而其它像UDP之类的框架，没有提供两子系统之间的子系统边界，但是却把政策参数当着产品实例，并且贴切地耦合了两个系统

相关模式

一般，产品子系统被当作产品服务器来实现。

一个政策参数子系统通常采用用户定义的产品框架来实现，这样可以充分利用组件模式和Type Object模式的优势。通常，你可以把政策参数当成产品实例。

已知应用

上述构架在保险业几个领域构架，比如Phoenix构架，IAA--IBM的保险应用构架或者VAA(VAA95)有更详细的描述。

尽管保险市场巨大，但是有关保险系统的资料还很少，在这一点与其它市场领域相反。有关基于价值链构架的基本概念和原料产品的相关概念可以参阅《Innovative Gestaltung von Versicherungsprodukten》。以上的已知应用有大量的文档，描述了相近的领域构架。来自IBM的IAA也是一个巨大的领域构架，但是它已经注册，不向公众公开。

模式2：产品服务器

假设你想建立一个产品驱动的保险系统，这个系统一般具有一个后勤系统，用以处理提议，管理政策参数，应付投诉。另一方面，你还需要为用于销售的个人电脑，诸如内部供给或者保险经纪人支持等其它系统提供产品定义。

图2 多个系统需要明确的产品定义

问题

何处定义你的产品知识以及怎样发布？

约束

除了上面提到的，还有几个因素也需要考虑：

平台独立性：后勤系统一般运行在OS/390机器上，销售PC一般运行Win95或者其它个人操作系统，互联网上的客户端可能运行Java应用，或者通过嵌入式HTML与某种语言写的服务器端程序组成应用。你的产品定义必须在不同平台都可以访问。

界面设计：宽界面容易导致维护困难和软件结构过于内聚。狭窄界面则适合大量客户在不同平台的情况。

产品知识封装对最佳用户界面设计：一方面你希望封装所有产品知识。这样的好处是，例如所有的对话框只解释一个产品定义，而且能够自动改变适应新的产品定义。缺点是自动化的界面缺少美观。这种方法适合内勤系统对话框，但是不适合销售对话框和销售员笔记本电脑上的多媒体产品展示。

需求差异：尽管内勤系统和销售系统都需要使用相同的产品定义，但是它们对产品定义的视角却有差异。对于存储所有政策参数的内勤系统，你既需要老的产品定义也需要实际的产品定义。对于销售系统你只需要你实际销售的产品程序。一个产品定义知道更多的产品，包括那些正在开发中的和销售程序中尚未出现的，都需要为这些系统提供不同的视图。

方案

在产品服务器中封装产品知识。运行期间，在可移植的产品运行系统中封装它并且使用外观提供视图

结构

你在一个典型的产品服务器中会发现如下组件：

产品编辑器：为定义产品的用户提供易于使用的界面。产品定义可能稳定于产品模型中。

固定的产品定义：代表你的产品的固定商务对象。如何最好地组织这些对象将会在产品树和对象事件赔偿两处予以讨论。

前两个组件也可能被组织在一个普通的面向对象树状层次机构中。

图3 产品服务器的结构

商业对象代表了稳定的产品定义，很少被移植。因此我们需要更多的组件。

发生器：负责从稳定产品定义中产生可移植的代码。

产品运行时系统：可以运行在OS/390上以及Window平台上，负责解释上面产生的代码。有些系统采用ANSI C为产品运行时系统编码以保证系统的可移植性。

如果你想在产品运行时系统中提供一个非常狭窄的界面，但是又不想处理过多的原始界面操作，或许你可以实现：

前端部件：为你的产品定义系统提供不同的视图

图4 销售员膝上电脑

所谓的产品服务器包含所有组件的事实并不说明所有这些组件必须运行在单个机器上，也不意味从客户/服务器系统模式来说产品服务器就是服务器。

要了解这一点请看图4：销售系统的配置。销售对话框通过前端部件使用产品运行时系统。而所谓的产品服务器的剩余部分，产品编辑器，产品商务对象，生成器可能运行在不同的机器不同操作系统和技术架构。

结论

保险系统使用产品服务器来提供优良的灵活性和平台独立性。相对于只使用活动对象模型，使用产品服务器可以在你的销售系统、网站等等为同样的产品定义赋予不同的视图。

缺点在于创建过程。与使用活动对象模型和反射相比，使用产生器具有某些缺点。但是这个缺点可以在一个方面为某种事实所弥补。通常正在编辑的时候，你并不希望你对产品的修改同时为其它地方所见。保险产品就如同代码一样也需要经过测试，发布，版本化。一个系统使用一个简单的活动对象模型，产品开发，测试则笼统模糊，生产没有效率，容易陷入困境。

其它结论是：

平台独立性：通过使用一个可移植的产品运行时系统来达到平台独立性

良好的界面设计：为产品运行系统设计一个非常狭窄的接口或许能取得良好的界面设计

最优界面设计：包含某些产品的专门知识，并涵盖其趋势。这是不凡的设计

需求差异：可以通过在产品运行时系统使用不同前端部件来兼容需求差异

实现

通过在树状层次构架中使用活动对象模型，可以把产品编辑器当作普通面向对象应用来实现。

相关模式

要实现产品编辑器，你应该使用产品树，而产品树用对象事件补偿模式组织。你还需要把表格系统和规则系统集成到其中。运行时系统可以采用实现虚拟机所采用的模式。前端部件用来为产品定义提供不同的产品视图。

要为产品编辑器实现产品商务模型，可以采用活动对象模型和发射。

已知应用

采用产品服务器的这种思想可以在许多保险系统中找到。VP/MS中可以看到部分，如采用CAF的产品定义。EA Generali实现的两个项目也包含了产品服务器的思想：KPS/S，一个正在开发财产保险项目；Phoenix，一个快要完成的人寿保险系统。

模式3：规则系统

举例

假如你实现了一个产品编辑器，这个产品编辑器允许你定义产品结构，那么你需要一种机制来为树的节点元素从一种属性导出另一种属性，比如评估政策参数。

问题

你如何来实现真实性检查或者对产品树进行政策评估这样的功能？

动机

系统管理员的使用：如果你打算让你的系统管理员不编码就定义新产品，你必要提供一种解释语言，这种语言能够把产品属性，性能估计连接起来并且可以实现表格查找。如果你按照这个想法去开始你的工作，你很早就会发现这需要一种全新地编程语言才行。有关这些的进一步讨论可以参看WWW上的《通过编程实现可定制》" (http://c2.com)。那里的讨论与《硬编码对脚本编程语言》相似：一般硬编码（尤其在Smalltalk）比试图在Smalltalk上再建立一种Smalltalk容易。

代价：草率地开发一个规则系统是昂贵的冒险。给一些系统管理员培训Smalltalk一般比为他们开发一种可定制的编程语言代价少。另外我们知，道，像Excel那样，按可以接受的代价来实现像公式解释器那样的功能也常常为系统管理员乐意接受。

追溯机制的完成：如果要建立一个规则系统，最好使之能够完成产品定义需要的所有属性导出，否则，你就得编程实现。

灵活性：对于像C++那样的编译语言，要编辑/编译/链接才能完成，对系统管理员来说一个Excel表单似乎灵活的多。

测试和调试产品：如果你要在你的产品定义中实现脚本语言一样的编码属性追溯机制，你需要一些其它编程语言环境，以及额外的工具，比如可定制调试器。

方案

建立一个类似于解析树中的语义功能的属性追溯机制，或者Excell表单中的单元计算，在运行时解释。

结构

参看图6：保险产品树。如同编译建造，你可以使用某种编程语言（如Lex/Yacc)为语义功能编制程序，或者你也可以用各种不同脚本语言定义一套完整的工具。

注意，这跟基于规则的系统，比如人寿保险中的风险评估系统，没有太大的关系。在基于规则的系统中，你经常可以看到专家系统（如以Prolog实现的）。我们这里谈到的规则系统在一个相当确定并且可预期的基础上实现商务规则。

结论

结论如同实现途径一样多种多样，究竟如何使用取决于你的动机。这些方面跟编程语言设计非常相似。这里给出一些示例，在我所知道的系统中，这些示例将要发生或者已经发生：

不完全规则定义语言：这种情况下，你将需要部分编码来完成属性追溯和定义，这样的结果是，相对它所提供的灵活性和可定制性，你付出了太高的代价。