案例研究：12种保险产品的通用产品模型
内容提要
该文章讨论了保险公司决定使用通用产品建模系统替代旧保险系统的背景和结果。决策导致了通信开销和性能问题，最终项目被取消。新项目取消了COBOL实现的战略规则，并对商业模型进行了缩减。改进后的项目团队最终取得了成功。
延伸解读
“业务人员自改模型”的理想与现实
文章的核心设想是让业务人员通过通用产品模型自行修改一切，包括界面元素是否可见。但实际中，新增一个复选框仍需前端、数据库、映射等多个团队配合修改，说明业务模型无法独立于技术栈存在。这提醒读者：产品建模系统的边界应明确，不能假设业务模型能覆盖所有变更。
过度集中决策带来的性能代价
所有业务逻辑都交由COBOL后端调用产品模型处理，导致每次简单操作（如勾选复选框）都要经历XML序列化、解析、映射和往返调用。这种设计在销售对话中频繁触发，造成高CPU需求和长响应时间，甚至因租用CPU超限产生高额成本。文章表明，将决策权过度集中到单一模型会显著增加系统开销。
组织拆分放大通信开销
项目按产品建模、Java前端、COBOL后端、映射、数据库等拆分成多个团队，每个简单任务都需要跨团队协调。文章指出，这种组织方式使每一项变更都产生大量通信开销，拖慢开发进度。这提示读者：技术架构的集中化若与团队拆分不匹配，会进一步加剧协作成本。
新项目的务实调整与成功关键
新项目取消了“所有业务逻辑必须用COBOL实现”的规则，将产品模型缩减为只处理产品结构和价格计算，界面控制改由Java前端直接与数据库交互。同时，团队合并为一个、成员来自旧项目且坐在一起，协作更紧密。文章认为这些调整使项目最终成功，说明缩小模型范围与组织整合是扭转局面的关键。
Q&A
为什么保险公司决定重新开发旧的COBOL保险系统？
旧系统虽然长期成功运营，但技术变得越来越过时，因此公司在2000年代初决定重新开发该系统。
新系统最初计划的技术架构是什么样的？
计划采用基于Java和XSLT的前端，通过DB2数据库调用COBOL后端，且COBOL后端包含所有业务逻辑，原则是“Java中没有业务逻辑”。
通用产品建模系统的核心设计理念是什么？
创建一个通用的前端和数据模型，完全由产品建模系统管理，每一个决策和计算都由产品模型完成，以便业务人员可以自行修改产品模型中的一切，甚至包括文本框是否可见或可编辑。
为什么“只需改变业务模型”的想法在实践中行不通？
因为当需要新增一个复选框时（例如狗主人责任保险需要知道狗是否是斗狗），不能仅在业务模型中生成，还需要在前端创建复选框，并在数据库中创建字段来存储其值，涉及多个团队的修改。
项目团队的组织方式导致了什么问题？
项目被分成产品建模团队、Java前端团队、COBOL后端团队、映射团队和数据库团队，每个团队都必须修改自己的软件来添加一个新复选框，导致每一项简单任务都产生大量的通信开销。
这个项目最终的结果如何？
经过5年多的开发，项目最终被取消，计划的12个产品中只完成了3个，并且由于往返时间长和COBOL后端的高CPU需求，应用程序遇到了巨大的性能问题。
新项目是如何吸取教训并取得成功的？
新项目取消了“所有业务逻辑必须用COBOL实现”的规则，缩减了商业模型（只对产品结构和价格计算建模），减少了调用产品模型的次数，前端直接与数据库通信，COBOL后端仅用于与业务模型对话和传输销售报价，并且团队整合为一个团队，成员来自旧项目，协作更紧密，最终取得成功。
