As an insurance technology company, ZA Tech has accumulated dozens of overseas leading insurance company customers. And we have also realized that the enterprise-level To B business has not been able to explode as quickly as the To C business. The fundamental reason is that the enterprise-level To B business is easy to make one project per customer, and there is a lot of customization, and the demand for core talents grows linearly with the growth of business scale, and the business cannot be replicated quickly and safely horizontally.
Two years ago (2020), ZA Tech already had a bright revenue and good cash flow after supporting several benchmark customers in the insurance industry, but it also gradually began to face the problems of the above-mentioned To B enterprises. So we started looking at finding a second growth curve and a better business model, and we started thinking about how to strategically define future success.
After a series of arguments, we found that the only way to achieve the future great success of enterprise-level To B business is SaaS. SaaS is not only a technical concept, but more importantly, it is a business model, and the complexity of business and model is very high. Of course, as a technical article, this article will focus on emphasizing the technical complexities and how to use technical capabilities to empower business value.
1 What kind of system,
Can it be called the core SaaS system of Internet insurance?
In order to avoid the deviation of everyone's understanding of the goal, let's first define what kind of system, which can be called the core SaaS system of Internet insurance? Ideally, it is a set of code, a set of deployment environment, and a SaaS Cloud to support all customers, meet their differentiated customer needs, and help them achieve security isolation.
However, due to the fact that our customers are all over the world, and the laws and regulations of various countries, local governments, and cloud infrastructure, a SaaS Cloud will cause customer data to be exported abroad and violate the data security regulations of some countries.
It can be seen that a set of productized code to support all customers has become a precondition for the technical realization of SaaS, so the first thing we will talk about today is - productization. However, for enterprise-level customers such as insurance companies, it is difficult to meet the needs of fully standardized solutions, and our cross-regional, cross-country customer strategy makes this even more difficult.
As mentioned above, large customers have money and willfulness, so the project-based plan also has good cash flow and profits, so 2 years ago (2020), we were still entangled between projectization and productization. In the end, we unswervingly chose the productization route and gradually evolved to our current SaaS route.
2 The "three-board axe" of productized architecture design
One set of code to support all the differentiating requirements
Two years ago, productization/SaaS was still a distant place for us, but differentiated customer needs and project pressure delivered by customers were immediate difficulties that could not be ignored. To use a single set of code to support all the differentiated requirements, the technical difficulty and schedule pressure are very high. How do we make this transformation possible in terms of architecture and design? First, we abstracted the "three axes" of productized architecture design, which has become the cornerstone of today's successful support for our productization and SaaS.
Three-plate axe 1.1
Based on the Configuration concept of Sanbanaxe, we have designed the product factory of our insurance core product, Graphene, to support the differentiated needs of customers for the same product in a configuration way, and realize the new product to support new customers in a non-code way:
(Photo: Product Factory)
Three-plate axe 1.2
Also based on the Configuration concept of Sanbanaxe, we designed Graphene Workflow to support the configuration of the process, so as to achieve differentiated support for no code such as security and claims:
(Figure: Workflow)
Three-plate axe 1.3
Some giant customers have high requirements for the timeliness of front-end products and the customizability of style, and based on the cornerstone of Configuration, our Graphene ZMart realizes the ability to configure front-end:
(Figure: High configurable dynamic front-end)
Three-plate axe 2
In addition to the above-mentioned differentiated and customized requirements, for our different customers, there are also a large number of different traffic, channel access, different traditional core docking and other needs, we use the design concept of Composition to provide product baselines that are easy to use and extend Open APIs, so that the project team can quickly and decoupled various traffic and traditional cores with front-end and post-docking.
Front-to-back based Open API
Three-plate axe 3
In some scenarios, the customer's customized requirements need to change the core logic of the product baseline, and these requirements cannot be abstracted into enumerable situations, so the configuration mode cannot be applied to such scenarios. So how do you change the core logic of a product's baseline code without changing it? The answer lies in our third cornerstone – the plugin.
We have developed our own Plugin Framework, which can realize the extension points of the product baseline without code intrusion, and at the same time allow different customer needs to be accessed in the form of plugins. The Plugin Framework implements three tiers by customer, country, and product by default:
Plugin and Lookup mechanism
It should be noted that plugins are easy to abuse, so we stipulate that we should use the Configuration and Composition patterns as much as possible, use the Plugin pattern only as a last resort, and conduct a requirements and design review by the Architecture Committee of the Product Baseline before we can open an Extension Point on the product baseline.
Combining the above three-plate axe design patterns, we have achieved a scalable product baseline that satisfies the open-closed principle:
Scalable product baselines that use a combination of three models
3 From project-based to SaaS-based (productization)
How do we move forward with the final implementation of the architecture design?
The architecture design is fleshed out, the reality and technology are skinny, and it's not enough for us to know where the goal is, we need to know the right path to the goal. So two years ago, when we were still focusing on large project delivery, how did we get the above architecture design to be implemented, and what was the optimal path to the destination?
We have discussed the three modes of the three-board axe above: Configuration, Composition, and Plugin; the Plugin pattern is a model that should not be used as much as possible, but it is a bottom-up model, and without Plugin, it cannot support the last mile of our productization, so its importance is self-evident. So how do you do it without intrusion? We have developed our own ZA International's Plugin Framework (we plan to open source the framework):
(1) Introduce the plugin framework
(2) Define the extension point-
All you need to do is make your extension point interface inherit from ExtensionPoint
(3) Using Extension Points-
简单的面向接口编程和Spring DI（Autowired）
(4) Project delivery to achieve the expansion point -
Or simple annotation, you don't have to care about anything but business!
Caption: Implement the extension point to change the function of the baseline default
(5) It can be coordinated and easy to manage
Caption: Development, packaging, and deployment of baselines and project collaboration
Okay, see here, how we use a set of code to support the needs of all customers, and truly achieve productization and core essence, I believe you have understood. So we're a SaaS company? Wait, not yet!
4 Multi-tenant design and framework
SaaS products require not only one code, but also one deployment to support multiple customers. Here's another extremely important point, which is multi-tenancy:
There are three core elements to supporting multi-tenancy:
多租户三要素1-Security 之 Authentication
多租户三要素2-Context
The Three Elements of Multi-Tenancy 3.1
Data isolation is based on the first layer of isolation at the data model level, and the tenant_id is used to logically isolate tenants.
The Three Elements of Multi-Tenancy 3.2
Although tenant_id has done tenant logical isolation, the database mode still adopts the per-tenant tenant isolation mode to ensure more secure data isolation, which is the second layer of data isolation.
The three elements of multi-tenancy 3.3
数据的二层路由 2-Layer Sharding。
The Three Elements of Multi-Tenancy 3.4
The following diagram shows other data stores that need to be transformed into multiple tenants, and they also need to be transformed to achieve isolation and security in a multi-tenant architecture.
If you're interested in our multi-tenant framework, the good news is that we plan to open source them, so stay tuned!
In addition to multi-tenancy, a highly customizable SaaS subscription model is also a very important part of SaaS products:
Author: Jiang Jiyun/Gao Wentao
Source-WeChat public account: Zhongan International Technical Team
Source: https://mp.weixin.qq.com/s/ddgrZlXqWlH57aHw7czO-Q