1.4 保险企业的技术债
保险信息化自诞生起就开始了快速发展。一方面，随着业务的快速发展，信息化建设必须及时跟进；另一方面，保险信息化与国内软件产业的发展几乎同步，可直接借鉴的经验和获得的帮助较少。就像保险在复业后快速增长留下了“后遗症”一样，保险信息化在快速发展的同时也积累了大量问题，主要体现在“技术债”上。
“技术债”一词是Wiki创始人沃德·坎宁安在1992年提出的。为了解决短期的资金压力，企业向银行借款产生债务，代价是要为债务支付额外的利息。软件开发也是如此，为了加速开发、尽快上线，在应该采用最佳方案时进行了妥协，改用短期内能加快进度的方法，从而在未来给自己带来了额外的开发负担，就像欠债还利息一样。
1.技术债的积累原因
保险企业积累技术债有多方面的原因，包括系统设计、编码、测试等微观层面的原因，以及规划、管理等宏观层面的原因。前者可以通过人员培训、技术规范和工具应用等方法避免，而后者则较为复杂，这里进行重点介绍。
1）业务缺少统筹和规划。在企业中，技术必须跟随业务，服务于业务。如果业务横向割裂、统筹不足，系统就会形成一个个孤岛。如果业务缺少长期规划，技术也很难长远布局，为系统做出前瞻性设计。当业务需要调整时，技术只能迭代。
2）企业IT团队定位偏差。大部分保险企业的技术团队规模较小，系统建设以结果为导向，自己只做项目管理和需求衔接，系统设计、开发、测试等工作外包给技术服务商。这样做会造成两个问题：一是宏观的架构设计不足，系统间往往不能以最优的方式组合衔接；二是微观的技术把控缺失，系统设计、编码和测试的质量完全依赖于服务商的责任感与人员素质。
3）以采购为主的建设模式。保险企业信息系统建设以采购为主，供应商在自有产品的基础上根据需求进行二次开发。这些产品多数经历了多家企业的开发沉淀，除了积累经验还聚集了许多企业的技术债。这些债务通过系统采购和实施在企业间流转、积累。国内主要保险软件供应商都有自己独立的技术体系和产品体系，不能完全兼容。如果使用多个供应商的产品，则会面临维护异构系统和多套技术体系的问题。
2.技术债的表现形式
保险企业的技术债主要有以下3种表现形式。
1）烟囱式信息系统。保险企业信息系统采用垂直的业务条线结构和以业务为导向的系统建设模式，在渐进式的建设过程中形成了典型的烟囱式结构。每个系统都是一个垂直的体系，拥有独立的服务器和数据库，以及相似的技术底层和基础功能。由于系统间无法共享资源或相互访问，每个系统都成为一个信息孤岛和资源孤岛。
2）繁杂的技术体系。许多企业需要同时维护多个技术体系。虽然后端开发主要使用Java语言，但是一些企业仍在使用VB、VF或C语言。前端开发使用的技术包括JSP、VUE等。软件架构既有CS也有BS，既有单体式也有分布式。不同的技术团队，甚至不同的项目组都可能有自己独立的技术栈和构件集合。
3）失控的代码和缺失的文档。保险企业IT项目的普遍情况是：只有需求规格说明书和系统操作手册这两种文档受到重视，但也无法保证对它们及时更新。软件设计、开发和测试文档的编写视项目情况而定，如果时间充裕就详细一些，如果时间紧张就简单处理或直接忽略。虽然项目都有编码规范，但能够做得详尽且严格执行的较少。
3.技术债的影响
技术债与其他债务一样，是一种透支行为，以牺牲未来来满足当前的一些需求。与其他债务一样，技术债也有利息，并随着时间“利滚利”。技术债的显性影响是不断降低开发效率，从而影响业务进度和市场反馈。隐性影响是系统开发和运维成本不断增加，企业的IT投入和运营成本也增加。
1）IT性价比越来越低。许多保险企业的管理者会有这样的感受：IT投入逐年增多，但好像做的事情并没有增加；系统初建时成本并不高，但上线后迭代需求成本却越来越高。其实，这里有技术债的因素。随着时间的推移，系统积累的技术债越来越多，开发一个需求时需要偿还的债务利息也就越来越多。
以某保险公司为例，根据监管要求，该公司需要调整一些业务规则。该公司有多套核心系统和多套前端营销服务系统，这些系统是烟囱式的，业务规则散落其中，因此调整必须在多个系统中同时进行。其中一个系统是20世纪引进，架构非常古老，不仅开发效率低，而且只有少数资深技术人员能够处理。有几个系统文档缺失，代码也很混乱。技术团队经历了几轮更替，大家对调整可能产生的影响都心有余悸。为了确保调整不出问题，只好在调整前花费大量时间来评估，调整后也要花费大量时间进行回归测试。
2）导致业务逐渐僵化。保险业务与信息系统密不可分，任何业务调整和创新都需要进行系统开发。然而，由于系统技术债的积累，新需求的开发变得越来越缓慢、成本越来越高。逐渐地，业务就开始僵化。当必须进行调整时，才发现不仅需要偿还技术债，还要偿还一堆业务债。
3）技术债绑架企业。技术债大量积累之后，系统开发和运维效率越来越低。但是，业务不能没有系统，重新建设短期成本太高且有风险。对于企业来说，即使投入低效、成本越来越高，也只能继续下去。某些系统债务缠身，里面充满了地雷和陷阱，只有特定的厂商能够进行二次开发，只有特定的人员能够维持系统运转。因此，企业只能选择依赖这些厂商和人员。