案例研究：12种保险产品的通用产品模型

在开发基于 COBOL 和分层数据库的旧保险系统的替代品时，决定使用通用产品建模系统。

系统的背景是什么？
背景是一家保险公司，长期开发并运营了一个采用COBOL的32*70终端前端的保险计算、销售和维护系统，取得了巨大成功。由于技术变得越来越过时，公司在 2000 年代初决定重新开发该系统。计划的技术堆栈是基于 Java 和 XSLT 的前端，通过 DB2 数据库调用 COBOL 后端。COBOL 后端应该包含所有决策，原则是“Java 中没有业务逻辑”。由于所有业务逻辑都应基于业务决策，因此 COBOL 后端应为所有决策调用通用保险产品建模系统。

什么是好主意？
所谓的好主意是创建一个通用的前端和数据模型，完全由产品建模系统管理。每一个决策和计算都应该由产品模型来完成，这样业务人员就可以改变产品模型中的一切。如果要发布新一代的保险费率，则所需的一切都将由业务建模，并且新版本的模型将正常工作，因此 IT 不需要更改任何内容。这一原则将始终遵循：甚至文本框是否可见或可编辑的决定也将由业务模型做出。

造成了什么不好的后果，为什么一切都不好？
这个想法引起了很多问题，其中最大的有以下几个：

最大的问题是对于新产品或关税只需要改变商业模式的想法。这个原则根本不成立。例如，当应发布新的关税或产品时，并且需要一个新的复选框（例如，如果狗主人责任保险的新关税需要知道狗是否是斗狗），则不能仅在以下位置生成此复选框：业务模型，但为了使业务模型可见或可编辑，还需要在前端创建复选框。

但它并没有就此停止，还必须在数据库中创建复选框才能存储其值。项目的组织被分成不同的团队，产品建模团队，Java前端团队，COBOL后端团队，一个单独的团队负责COBOL后端和业务模型之间的映射，最后一个团队从事数据库工作。由于每个团队都必须更改其软件以添加一个新的复选框，因此每一项简单的任务都会产生大量的通信开销。

每个业务逻辑都需要由产品模型处理的战略决策使得请求的往返时间变得非常长。如果使用该应用程序的销售人员想要将狗主人责任部分添加到销售对话中的正常责任保险中，Java 前端会将销售对话的完整状态序列化为 XML，只需更改狗责任复选框的值保险。然后，该 XML 结构被发送到 COBOL 后端，进行解析，然后映射到与业务模型对话所需的数据结构。然后，业务模型将评估 COBOL 后端移交的数据结构，然后将“斗狗复选框”的值设置为可见。这将返回到 COBOL 后端，然后 COBOL 后端会将业务模型映射回 XML 并将其发送到 Java 前端，在 Java 前端中解析 XML，然后显示复选框。

发生了什么，有转折点或转折点吗？
经过5年多的开发，该项目最终被取消，计划的12个产品中已经完成了3个。由于往返时间以及 COBOL 后端的高 CPU 需求，使用此技术堆栈运行的应用程序遇到了巨大的性能问题。（大型机 CPU 是租用的，在高峰期，例如在年底，许多人转换保险时，可能会使用比租用更多的 CPU 周期。使用超过租用限制的 CPU 周期会导致非常高的透支成本。）

情况是如何解决的？
项目被取消后，一个新项目开始做同样的事情，但从旧项目中吸取了很多教训。

首先，“所有业务逻辑都必须用COBOL实现”的战略规则被取消。商业模型被缩减，所以只对产品结构和价格计算进行建模。这导致在销售对话中调用产品模型的次数大大减少。选择哪些复选框需要可编辑或显示是在 Java 前端进行的。

Java 前端直接与数据库通信。COBOL 后端仅被调用来与业务模型对话并将销售报价传输到库存系统。

此外，项目团队是一个团队，坐在三个相邻的房间里，成员来自上一个项目的所有“老”团队。

该项目取得了成功。