要实现未来企业级To B业务的成功，唯一的出路就是SaaS化。SaaS不仅是一个技术理念，更重要的是它是一种商业模式，商业复杂性、模式复杂性都很高。本文主要会侧重于强调技术上的复杂性，以及如何用技术能力赋能业务价值。
1 什么样的系统，能称为互联网保险核心的SaaS系统？
为了避免大家对于目标理解上的偏差，首先我们先来定义一下什么样的系统，能称之为互联网保险核心的SaaS系统呢？最理想的情况，它是一套代码、一套部署环境、一朵SaaS Cloud，支持所有客户，满足他们差异化的客户需求，并能帮助他们做到安全隔离。
但由于我们的客户遍及全球，各国、各地法律法规以及云基础设施等的限制，一朵SaaS Cloud会造成客户数据出境，违反某些国家的数据安全法规，因此，一种可落地的方案是每个Region部署一朵SaaS Cloud，支持该Region的所有客户。
可以看到，产品化的一套代码，支持所有的客户，成为了技术上实现SaaS的前置条件，因此我们今天首先要讲到的就是 – 产品化。然而，对于保险公司这样的企业级客户，完全标准化的解决方案是难于满足他们的需求的，而我们跨Region，跨国家的客户战略，让这一切变得更加艰巨。
如上面提到的那样，大客户有钱任性，因此项目化方案也是有良好的现金流和利润的，所以在2年前（2020年），我们仍然在项目化还是产品化之间纠结过。最终我们坚定不移地选择了产品化路线，逐步演进到我们现在的SaaS化路线。
2 产品化架构设计的“三板斧”，一套代码，支持所有的差异化需求
2年前，产品化/SaaS化对我们来说仍然还是诗和远方，但是差异化的客户需求，客户交付的项目压力，是不可忽视的眼前的苟且。要用一套代码，支持所有的差异化需求，技术难度和进度压力都很大。我们如何在架构和设计上让这种转型逐步成为可能的呢？首先我们抽象出了产品化架构设计的“三板斧”，成为了今天成功支持我们产品化、SaaS化的基石。
三板斧 1.1
根据三板斧的Configuration理念，我们设计了我们保险核心产品Graphene的产品工厂，以配置化支持客户对相同产品的差异性需求，实现了以No Code的方式支持新客户的新产品：
（图：产品工厂）
三板斧 1.2
同样根据三板斧的Configuration理念，我们设计了Graphene Workflow，支持了流程的配置化，从而实现了保全、理赔等的No Code差异化支持：
（图：工作流）
三板斧 1.3
一些巨头型的客户，对于前端产品的上线时效性，以及风格的可定制性，要求很高，还是基于Configuration这块基石，我们的Graphene ZMart，实现了可配置前端的能力：
（图：高可配动态前端）
三板斧 2
除了上述的差异性、定制性需求，对于我们的不同客户，还有大量不同流量、渠道的接入，不同传统核心对接等需求，我们以Composition的设计理念，提供产品基线易于使用和扩展Open APIs，让项目团队可以用前置、后置等方式，快速地、解耦地对接各种流量和传统核心。
基于Open API的前后置
