保险企业IT架构转型系列（一）：烟囱式保险系统

什么是烟囱式系统

烟囱系统是指一种由相互关联的元素紧密结合在一起的集合，其中单个元素无法区分、升级或重构。烟囱系统会一直维持存在，直到有新的系统将其完全取代。[百度百科]

企业发展过程中，刚开始都是以独立的业务为切入点进入市场，形成地位以后，为了扩大规模，开始涉及其他潜力业务。为了不影响原有业务发展，IT系统是独立建设的。

这些系统有典型的“烟囱式”结构，每个系统都是一个垂直的体系，有自己的服务器等IT设备，独立的管理工具和数据库。不同的系统不能共享资源，不能相互访问，每个系统都是一个资源孤岛和信息孤岛。

这些系统在业务架构、流程、规则上基本都是独立的，大部分系统都包含类似的基础支撑功能，对于支持相似业务的系统，可能大部分业务功能都是相似的。

烟囱式架构的弊端

很多企业的IT系统都是烟囱式，这种模式有很多弊端。

重复建设和重复维护。重复功能建设不仅消耗的是人力、财力，更重要的是时间！建设后要持续运维，重复建设导致重复运维，增加运维成本。甚至，重复建设的系统或功能可能采用不同的技术体系，还需要储备不同技术体系的支持人员。

系统间集成、交互和协作成本高昂。“烟囱”系统连接需要不同技术团队间的协作，有很大的协调、沟通成本。不同系统架构、技术各异，还会导致五花八门的对接方式，治理成本巨大。

不利于业务沉淀和持续发展。这种模式下，企业系统平均生命周期只有6-8年。6、7年后原先的系统常规升级改造已经很难满足当下的业务发展诉求，必须大规模升级，而对企业来讲，大规模升级往往不如重新建设一个“烟囱”省时省力。这样往复，历史系统的业务沉淀不断流失。

除了这些直接的弊端，烟囱系统模式还深远的影响企业发展。

业务变化难，企业僵化。烟囱模式下，一个业务变化可能会涉及多个系统重复修改，系统间接口重新调整。随着各系统不断积累，逻辑越来越复杂，系统修改和接口调整会越来越难、代价越来越大。业务变化难，企业的灵活性就会差。

抑制企业创新。每次创新都面临大量重复建设，使得企业在新开业务和创新项目尝试时，不得不面临较大的前期投入。一旦方向出错，损失巨大！反过来看，就会抑制创新。

保险IT系统是典型的烟囱式架构

保险信息化独特的发展历程、建设模式和管理方法，使保险企业IT系统形成了典型的烟囱式架构。

保险企业大部分系统是分阶段、渐进式建设的。随着企业发展，不断建设系统支持新的业务。面对新的需求，若改造已有系统支持，一方面可能原系统建设时并没有考虑此类扩展，硬改造成本巨大；另一方面改造正在运行的系统，必然有影响其已支持业务的风险。因此，大部分情况下，都会选择新建一个“烟囱”支持新的业务。

保险企业系统建设多是业务部门主导。业务部门提出需求，IT部门组织采购和实施，上线后，系统“归属”提出需求的业务部门。在IT是公共资源的保险企业，业务部门获得独立IT支持的最佳方法是建设独享的IT系统。因此，大部分业务部门都有动力推进建设独立的“烟囱”系统。

保险企业系统建设主要依靠采购成熟的产品，或基于采购的产品做二次开发。国内市场上为保险企业提供IT系统的厂商中，每家都有独立的技术体系和产品体系。对于保险企业而言，又不能将鸡蛋放在一个篮子里，会同时采购多家厂商的产品。这就导致企业的各IT系统内部自成体系，系统间异构性明显，形成“烟囱式”架构。

保险企业系统建设多采用传统的项目制。组建专门的项目团队，走立项、采购、实施、上线、验收流程。由于思维惯性，在传统险企的IT项目观念中：立一次项若不产出一个新的系统，似乎干系各方都难以接受；没有以完整系统为标的的体系化项目文档，验收似乎也没有抓手；新项目就该配置专门的资源，也应该有单独的成果物。项目制和这样的项目观念也催生了大量“烟囱式”系统。

核心业务系统和互联网系统是保险企业IT系统“烟囱式”架构的重灾区。

以寿险企业为例，部分险企独立的个险系统和独立的团险系统并存，部分险企有独立的健康险系统、意外险系统、养老金系统，部分险企分红、万能、投连产品由单独的系统支持，甚至有险企为航意险、旅意险、建工险、赠险单独建设系统，还有险企新旧核心系统并行运转。这些系统构成类似，基本都是客户管理、产品管理、保单管理等业务基础模块，承保、保全等业务管理模块，都含有各自的工作流、任务引擎等技术组件。

近些年，互联网保险火热，险企大量建设互联网系统，包括：Web网站、微信服务号、App等。很多险企有数个独立建设的互联网系统，甚至独立建设多个服务号、多个APP系统。这些系统职能类似，都是宣传、销售、服务等职能，对应的功能也都类似。除系统本身建设外，每个系统还要单独对接业务系统和其他支持平台。

这些系统可能采购自不同的厂商，技术各异，架构各异，开发和运维标准各异。

烟囱式系统是保险企业沉重的负担

IT投入巨大。每个“烟囱”系统都要很大的投入，以上面提到的核心系统和互联网系统为例，单系统软件初始采购和实施费用至少数百万元。每个系统都需要配置服务器和基础软件，除生产环境外，还要准备多套测试和开发环境，当前，大部分险企IT基础设施还是采用成本较高的IOE，系统建设的基础设施部分投入甚至超过软件部分。系统上线后要进行长期的需求开发和运行维护，这部分投入往往数倍于初始建设费用。

制约互联网业务发展。很多险企在开展互联网保险业务，可其核心系统是单体应用，是内部紧耦合的、封闭的烟囱式系统，这与互联网业务对系统高并发、高灵活性的要求是矛盾的。一方面，这样的系统扩展能力有限，实时互联网业务规模较大时难以支撑；另一方面，互联网业务需要核心系统与在线销售系统全业务流程对接，而对于这样封闭的烟囱式核心，可能设计之初就没有考虑系统间大量对接的情况。无奈之下，一些险企投巨资建设单独的互联网核心，以支持大并发、高灵活性的互联网业务。但互联网核心与传统烟囱式核心的对接仍然避免不了。若互联网核心还是传统的系统建设思路和架构模式，何尝不是又立起一座“烟囱”。

致业务应变能力差。以推出新产品和业务规则调整为例：很多险企有不止一个核心业务系统和多个前端销售系统，这些系统都有单独的产品管理，推出新产品时，要多个系统都做完定义，才能形成销售和管理闭环，多系统同步上线，产品才能推向市场。险企常常会根据市场变化和监管要求调整一些业务规则，“烟囱”模式下同样的业务规则可能散布在不同的系统中，即便微小的变化也要多系统同步调整。多系统同步变动，每个系统都要制定计划、协调资源，任一处的延迟都会影响整体进度。这种模式下，简单的业务变化也需要复杂的IT应对，效率自然低，业务应对变化的能力自然不会高。

制约IT发展。各“烟囱”系统的持续开发和运维（尤其核心业务系统）消耗了绝大部分IT资源，IT人员疲于应对，用于发展的资源和精力自然就少。这些系统可能使用不同的技术，在有限的IT人员中要储备不同技术类型的人才，人员技术分散，很难形成技术合力。

影响企业创新。以产品创新为例：前文提到，险企推出新产品要在多个“烟囱”系统重复定义、重复测试；此外，创新的产品多是已有系统不能完全支持的形态，需要多个系统改造或建设新系统支持；若是场景型产品，还要将封闭的“烟囱”系统与场景硬对接。这些都是很大的投入，让创新产品一出生就背上沉重的成本包袱。系统重复开发还会拉长产品开发周期，等产品上线时，可能市场时间窗口已过。

先言明问题，再寻找解决之道，欢迎关注“保险企业IT架构转型系列”后续文章！