Before we start the next part, let's review some of the key contents in "The Road to SaaS Practice of Insurance Products (Part I)".
We mentioned the three stages of ZA Tech's SaaS evolution: project, product, and SaaS, and explained that productization is a prerequisite for SaaS. Next, we discussed the three axes of productized architecture design: Configuration, Composition, and Extension/Plugin, which have become important technical architecture and design concepts for ZA Tech to become a productized company and gradually evolve into a SaaS company.
If the three axes of productized architecture design are the three cornerstones for us to become a productized company and gradually evolve into a SaaS company, then our multi-tenant framework and solutions are another indispensable technical cornerstone to support us to become a SaaS company.
Today, we will continue to discuss in the previous part, in addition to productization and multi-tenancy, what important technical capabilities do we need to support an enterprise-level SaaS model?
1►
The importance of Agile and DevOps
Why is agile and DevOps so important for productization companies and SaaS companies? Let's imagine a realistic scenario, there are 100 customers, each customer needs to go online at their own pace, release a new version, etc., each customer will have more or less customized needs, of which 50% of customers have 30% of the needs are in a hurry to go online, and 10% New customers are eager to replace their old and overburdened core insurance systems, and the acceptable go-live time for each customer is affected by different countries, different auspicious days, different legal compliance audits, etc., and it is unlikely that it will be arranged exactly according to our schedule.
If the R&D of the product is a traditional waterfall style, and a new product version is released in 2~3 months, then for some of these customers, in the worst-case scenario, it will take about 6 months to wait for their needs to go online. Why 6 months? Because the customer may have a requirement at the beginning of the development of the current version, then this requirement can usually only be scheduled for the next version at the earliest, otherwise the current planned version will keep inserting unplanned requirements, resulting in indefinite delays, and the next version will not be delivered until 6 months later. As you can see, the smaller the shippable iteration, the more agile it is to adapt to agile delivery and multi-customer collaboration, and agile is our only choice.
At the same time, because a set of code and a SaaS Cloud support so many customers, quality, reliability, and availability have also become the core values that cannot be sacrificed, and time and quality cannot be compromised.
2►
ZA Tech's path to agility
Agile is also a common topic, many companies regard it as the bible, and many companies practice it as pure theory and cannot be practiced, the fundamental reason is that the concept of agile is not combined with the organizational structure and business characteristics, but only rigidly applies the process, which is just similar to the form rather than the god. Agile thinking is not dogma and needs to be adapted to local conditions. Obviously, our multi-customer, multi-dimensional, multi-priority collaboration, high-quality, silky upgrade requirements, we need to find a suitable engineering methodology to guide us forward, and the agile concept of "delivering more important customer value as soon as possible with a smaller iteration cycle" can well deal with the problems of many customers and requirements and the inability to unify the iteration cycle.
After in-depth observation and reflection on the end-to-end process of product development and delivery, we have formed a large-scale agile practice methodology with ZA Tech's characteristics. We found that the classic Scrum model is very suitable for 2C business, especially for the ability to split into smaller, low-coupling technical R&D teams, so as to achieve a high degree of autonomy and on-demand (in this case, the new version is online). For our To B enterprise-level customers, we need to be more rigorous and span user security psychology for each delivery, we need more "formal" product version iterations, and we need to deliver formal releases, test and stress test reports, security scans and penetration test documents, etc., which require more cross-team collaboration and more full-product perspectives. Therefore, the classic Scrum model has certain limitations for us.
Figure 1: The classic Scrum model
At the same time, an effective technical team must achieve the goal of building a team with a high degree of alignment and low coupling.
Figure 2: Highly aligned, low-coupled team building goals
In summary, we finally chose Nexus, an extensible agile framework, as our agile model (as shown below). Nexus is ideal for agile development with 3~9 Scrum teams. Ensure that at the end of each iteration, the entire system is delivered as an integrated whole.
Figure 3: Nexus model
Figure 4: Our Nexus-based organizational structure
Since the time span of the upgraded version of our customers is sometimes relatively large, and we also have some large-scale requirements, we cannot break down to a single iteration of the User Story, so we use the improved requirements management model as shown in the following figure.
Figure 5: Our Requirements Management Model
In this way, our product baseline (the core of the non-customized part of the product that is common to all customers) is practiced according to the agile model and methodology mentioned above, and a steady heartbeat rate is formed:
Figure 6: 1 Sprint of the Baseline Agile Iteration
However, our customers will always have some customized needs, which need to be supported by the special project delivery team in the form of plugins, and some customers are not in the Public SaaS model, but have adopted the group-style Private SaaS model, they will have their own online management cycle, and they are not willing to follow our release every 2 weeks to do frequent upgrades, how to support so many customer needs and different online life cycles?
We introduce an important concept called Project PI, which means Project Iterative Release, and a project PI usually spans multiple product baseline Sprints (iterations) to deliver a larger, complete product upgrade:
Figure 7: Project PI
Figure 8: An example of a 4-Sprint project PI
Figure 9: Example of a 2-Sprint project PI
Through a well-designed and managed project PI, the evolution of our product baseline and the promotion of all customers' needs are decoupled from each other, and the product baseline supports each customer's project according to the rhythm and priority, and the project requirements become a good input for the baseline product evolution, forming a good rhythm with each other:
Figure 10: Rhythm between multi-project and product baselines
We have dedicated delivery teams for our key customers, who need to maintain constant communication with customers, maintain transparent plans, and maintain our product baselines and delivery processes to achieve continuous improvement:
Figure 11: Good Project PI Execution
In this way, with the Sprints of the product baseline and the PIs of each major project, we have a global multi-dimensional Kanban, so as to ensure that the priority of each customer needs is reasonably arranged, and the heartbeat rate of product evolution is maintained:
Figure 12: Project PI Kanban
The above is ZA Tech's agile model based on Nexus' To B. From the theoretical foundation to full practice, the results have been good so far, which has well supported our To B enterprise SaaS model.
One of the most important points you may have noticed here is that our product baseline sprint, which is done every 2 weeks, must be able to go live very smoothly and with high quality. Because every time a baseline goes live, there may be 1 or N customers following the release of production. If every release relies on SRE human flesh and there are many bugs in each iteration, then the above patterns are a nightmare and a hell of a model for both business and technical students.
How to ensure that under such frequent releases, we can still go live with high quality and extremely smooth online production? Our answer is based on DevOps automation + quality shift, which also echoes the "Technical Manifesto" of our team culture:
Figure 13: A technical statement that echoes our team culture
3►
1:N collaborative DevOps practices
DevOps is a spirit and a culture, DevOps is to run in small steps, agile delivery of high-priority customer value, DevOps is to automate everything, continuous iteration, continuous improvement, quality first, quality shift left:
*Note: 1:N collaboration represents collaboration between 1 product baseline team and N customer delivery teams.
Figure 14: DevOps
So, how do we do DevOps? First of all, starting with our branching strategy, we designed a set of Git branching strategies that are more suitable for the development of To B products.
Figure 15: Our branching strategy
At the same time, we have introduced Source Code CICD based on Gitlab CI to achieve MR automatic code verification (Sonar, Fortify, etc.), automatic UT running, code review triggering, and automatic deployment of DEV environment:
Figure 16: Our CI Kanban
Figure 17: Our Test Coverage Kanban
In addition to SourceCode, we implement incremental and idempotent management of DB changes based on Liquibase, and design our DB CICD to automatically verify incremental DB changes and deploy DEV DB environments:
Figure 18: Our Database CI solution
In addition to automated verification and R&D of our own UT verification, we have introduced the QE Auto Integration mechanism as a continuous integration environment for the test team to automate Functional Testing and End 2 End Testing, so as to achieve 100% automated regression and integration testing in all core scenarios every day:
Figure 19: Our test team's automated testing for continuous integration
So far, we have shared all the core content related to technology in the entire productization and SaaS process of ZA Tech. Due to the limitation of the level, mistakes are inevitable, welcome to leave a message for correction.
Author: Jiang Jiyun/Gao Wentao
Source-WeChat public account: Zhongan International Technical Team
Source: https://mp.weixin.qq.com/s/GEFwahvnvCDZuVUFbNIVFA