2017保险IT微服务架构(Elvis-Zhang)

迭代回顾会议 Sprint Retrospective
一般3个小时， ScrumMaster将鼓 励团队在SCRUM过程框架和实践 范围内，对开发过程做出修改，使 它在下一个Sprint周期中更加有效 和令人愉快
产品负责人
Scrum主管
开发团队
适应变化，认清“客户是逐步发现真正需求”
美好愿望

什么是敏捷开发？
• 敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐 进的开发方法。
子项目特征
各个子项目的成果都经过测试 - 具备集成和可运行的特征 - 小项目相互联系
-
Scrum总体骨架
Daily SCRUM 每24 小时
每日站立会议 Daily Scrum Meeting
客户知道自己要的是什么 开发人员知道如何开发来满足客户 需求 在开发过程中需求不会发生变化
我们认识到

残酷现实 客户是逐步发现他真正要的东西 开发人员逐步发现如何开发产品满 足客户需求 在这个过程中随时可能发生变化


价值
实际需求
• •
期望客户一开始就想清楚他们真正 要的东西是不现实的。 我们应当通过不断的向客户交付可 用的产品，启发客户逐步的发现真 正的需求。
信息时代，我们需要快速的响应和交付，未来业务的敏捷依赖于IT的敏捷
DevOps（Development和Operations的组合词） 是一种重视“软件开发人员 （Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或实践。 通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件 能够更加地敏捷、频繁和可靠。
预期需求
时间
适应变化，小批量是快速交付的关键
排队理论：小批量与缩短交付周期、人员 有效产出的关系
减小批量 交付周期
大批量
减少批量的好处
1.减少排队
3.缩短交付 周期
2.加快反馈
6.降低管理 成本 5.改善创新 7.更高的效 率 Source：Craig Larman
中批量 小批量
4.增强质量
$$ 资源利用率
保险行业是我国市场经济体系的重要组成部分，随着国际化竞争地加剧，对内降 低组织的摩擦力，提升公司的运营效率；对外实现与客户更友好的沟通，提升服 务水平，对客户需求给予迅速回应成为行业亟待解决的战略问题。
在保险行业信息化发展上主要经历了三个阶段： 第一阶段是业务处理阶段，各保险公司主要实现了各自的核心业务系统； 第二阶段是业务拓展阶段，主要围绕业务拓展，渠道管理、客户服务等面进行扩展。 第三阶段是经营管理和决策支持阶段，通过商业智能等技术，推动保险公司管理和决策水 平的提高。并充分对信息数据进行分析、挖掘、处理，为保险公司经营及管理提供支持。
微服务架构的目标
目标 期望的成果 • 洞察客户需求、满足客户期望， 与客户建立长期关系 • 实现创新的营销、无缝多渠道的 销售、实时精准的风险控制、灵 活高效的运营模式 • 优化企业价值链，促进资源跨界 整合，共建开放、共赢的产业生 态系统 • 让业务模式与产品具备高度的可 配置性与可扩展性, 快速捕捉市 场机遇
在简会上，每个成员主要回答三个问题; –自上次SCRUM简会后的一天了（昨天）， 你做了什么? –从现在到下次SCRUM简会的一天里（今 天），你要做什么? –在实现SCRUM及项目目标的工作中，你 遇到哪些困难吗?
产品订单 Product Backlog
迭代订单 Sprint Backlog
迭代
每30天
新产品 现有渠道 现有渠道 类型的扩展 新渠道 类型
客户Βιβλιοθήκη Baidu
现在 扩展 新类型
已有保单
产品
现有产品 保障的扩 展
渠道
敏捷开放的IT架构 • 建立基于微服务架构的IT平台 • Scrum、敏捷开发 • DevOps、持续交付
通过对现有各业务系统的整合，建立对内对外统一的、高效的平台，满足业务管理、销 售支持、决策分析等各方面需要；支持应用系统在不同用户界面或渠道的拓展，如柜面、 微信、APP、WEB、银保通、医保通。。。
随着保险行业新渠道、新业务的推出和发展，敏捷开放的IT架构、移动互联、大数据、商业 智能等技术对保险行业的销售、决策、管理等方面起着越来越重要的作用。
本着满足客户需求，面向未来发展，结合产品营销策略、业务发展规划、业务形态和业务 流程的原则建立敏捷开放的IT平台。
微服务架构的建设策略
以客户为中心 • 建立360度客户视图 • 支持个性化和个人自助服务 • 各渠道与客户信息平台集成 场景化产品 • 提供参数化配置，缩短新产品和服务达到市场的时间 • 保障范围更加具体化，产品融入渠道业务场景 • 结合渠道的业务形态与合作伙伴的需要研发定制产品 灵活应对变化与合作 • 支持新渠道和新合作伙伴的开发与集成 • 嵌入式营销，产品贴近用户场景需要 • 基于数据，精准营销
2017保险IT 微服务架构
Elvis Zhang 2016年10月
保监会发展改革部副主任罗胜在“2016中国互联网保险大会”上表示，大数据可能带 来保险产品、作业、组织、监管模式的改变。在大数据的支撑下，风险可以更精细 划分，保险作业更深更广融地入具体场景，即所谓场景保险。
保险产品可以更加碎片化；保险公司采取更多甚至全部在线的作业流程，即所谓 保险的O2O；保险公司内部完整作业链条的围墙被拆除、打碎后重新组装。


在需求响应周期相同的情况下，批量 （一次开发的需求量）越小，资源利用 率更高。 在资源利用率相同的情况下，批量越小， 交付周期更短。

减小批量不仅带来缩短交付周期，而且还带来提 高质量、促进创新、降低管理成本、更高的效率 等其他好处，大幅提升商业价值。


我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ——摘自敏捷软件的十二个原则
健康信息 移动互联 访问日志
处 理 后 大 数 据
客户汇总 客户主题
业绩汇总 业绩主题
理赔汇总 理赔主题
机构汇总 … 机构主题…
数据计 算层
保单数据
理赔数据
产品数据…
贴源数据区 数据交换平台
……
大数据交换组件 数据库数据交换组件 数据区数据交换组件
数 据 安 全 企业内外部半结构化、非结构化数据 员福业务 银保业务 渠道业务 政保业务 ……业务
新的功能 增量
高优先级
工作项 分解
可运行的软件
迭代规划会议 Sprint Plan
一般不超过8小时。 前4个小时：产品负责人向团队展示 最高优先级的产品，团队则向他询问 产品Backlog的内容、目的、含义及 意图。 后4小时：团队计划本Sprint的安排
迭代复审会议 Sprint Review
一般4个小时，由团队成员 向产品负责人额其他利益 相关人展示Sprint周期内的 产品开发情况
• 以客户为中心，创建360度客户视图(客户画像)， 更好地理解客户，以个性化的方式与客户交流
• 通过大数据智能分析， 提升业务决策支持能力， 实时、准确的预测风险，制定贴合客户需求并有 竞争力的产品、营销和风险战略 • 业务系统可以灵活地和外部伙伴的业务系统建立 集成、合作关系，对外提供功能服务或者使用外 部的服务变得简单而灵活
用户访 问层 数据应 用层
流程 调度 平台
流 程 调 度 监 控 告 警
内部管理分析 应用集市数据区
客户管理 保单管理 风险管理 财务数据
业务沙盘演练
沙盘演练数据区
数 据 管 控 层
数 据 质 量
流 程 调 度 层
实 时 数 据 区
元 数 据
历 史 归 档 数 据 区
大数据区
待 处 理 大 数 据
医疗信息
保险移动展业、自助理赔等逐渐成为各大险企积极发力开拓的营销与服务模式。 微服务平台利用开放式标准化的接口技术（RESTful API），可以灵活地匹配多渠道移动展 业的需要，并实现客户自助服务，把客户与企业及合作伙伴无缝连接起来。充分利用移动 终端设备的功能，提升营销效率、降低营销成本、提高服务品质。
数据交 换层 数据 产生层
Kubertenes + Docker
基于容器云的微服务架构与DevOps平台
基于微服务架构的SAAS开放平台
基于API的服务开放中心框架
基于大数据分析的业务运营管理后台
统一的运维管理中心
采用敏捷开发模式，通过敏捷高效的设计、稳定的开发速度、拥抱变化、 积极调整来保证微服务的开发质量和敏捷交付。
通过大数据分析平台和商业智能（BI）的应用建设，搭建统一的大数据共享和分析平台， 对各类业务进行前瞻性预测及智能分析，为各层次用户提供统一的决策分析支持，提升数 据共享与数据服务能力。
大数据分析平台总体架构
数据 管控 平台
数 据 标 准
IT人员
内部用户 实时数 据查询 历史数 据查询
外部用户 数据增 值产品 增值产 品数据区 主 题 数 据 区
适应变化，利用多层次反馈不断调整以逼近目标
多层次反馈手段 客户验收 站立会议/回顾会议 持续集成 单元测试 结对编程 对客户需求的反馈 对团队运作的反馈 对系统功能的反馈 对单元功能的反馈 对代码质量的反馈

利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整 自身行为，并逐步逼近靶心
随着保险产业网络的不断成熟，将出现大量在价值链的某些环节提供专业化服务的专家型 企业，保险价值链充分分离成大量由相应专业企业运作的业务功能，需要IT平台可以灵活、 自由地和很多外部伙伴的业务系统建立集成、合作关系。如何突破业务系统的制约，使企 业在整个价值链上进行优化，将成为企业降低运营成本、为客户提供更高效的服务，从而 增强企业整体竞争力的关键。
选择了微服务架构也就意味着选择了一个开放、自由、大型的技术应用平台。微服务架构 能在任何操作系统和硬件配置上运行，现有的操作系统和硬件能被保留使用； 微服务架构 可以将通用的繁琐的服务端任务交给中间件完成，这样开发人员可以集中精力在如何创建 商业逻辑上，相应缩短开发时间。
目前保险企业各个业务系统存在较多应用竖井，每个竖井都需要通过专有的接口提供各自 的服务。依据业务发展趋势和建设规划，需要从面向系统转型面向服务，通过服务组件提 供应用和数据；需要进行架构解耦，消除应用竖井，让业务功能以标准化的业务服务形态 暴露给最终用户，使服务可共享并重复利用。通过建立微服务架构的IT平台将信息技术与 业务的有效结合起来，从而推动企业产品创新、服务创新及市场创新。
微服务架构良好的开放性和兼容性，支持标准的协议和接口类型， 提供多种开放的应用开发接口， 能够和业界主流的产品实现互连互通，并具备有效的、统一的手段和机制进行业务管理、设备管理 、应用软件环境设置调整管理、开发管理以及运维人员的管理。
微服务技术架构
通过微服务解耦业务系统的各个业务功能，可以根据用户的需求灵活定制不同的用户界面 与具体功能。接口适配器池完成对不同业务系统的接口适配的功能，同时实现与合作伙伴 的网关接口连接和管理。
• 灵活的产品建模工具、便捷的产品发布方法
紧密衔接的业务流程、灵活配置的业务规则
未来的业务模式不再是面向产品或者面向保单的，而应该是面向客户的，所以需 要IT平台可以提供跨企业各个系统的客户统一视图。
不断变化的市场环境需要IT平台可以针对产品、业务的迅速变化提供即时的支持 ，例如产品规则的变化、新的业务流程的应用等。在开展新地区、新渠道或者新 形态的业务时，需要IT平台提供更加完整、丰富的数据支持。
随着“互联网+”向着“移动化、专业化、社交化、场景化”深入发展，服务与体验将成为市 场竞争的关键。通过“服务”而不是“销售”，保险才能深入到更多用户（先用户再客户） 的生活，才能真正“连接一切”。
从传统的保险公司发展历程看，现在遇到最大的问题不是技术，最大的问题其实是它的客 户群发生了改变。客户的期望也正在发生根本性的变化：简单、便捷、透明、个性化以及 社交化。