Three-in-one Migration Endeavor for US Insurance Top Player
USA
- 6 months (ongoing)
Client and Business Goals
A US insurance leader approached us with an ambitious project implying a complete application revamp. The business application provides functionality for real estate title insurance and reinsurance which both client’s agents and partners use in their day-to-day work. The previous vendor started the project six years ago and by now it has grown significantly. However, the tech stack had seen few updates since the project initiation. Severe technical debt made it impossible for the previous vendor to ensure proper application support, let alone new features development. The previous partnership with the software development vendor became more of a burden for the client, as it would take the vendor unreasonably long to meet business demands. By the time the client handed the project over to us, the need for new functionality had reached a critical point. Several modules didn’t function properly, so the client wanted it fixed, too.
Challenge
- In order to migrate the application to microservices, the infrastructure team of the client needs to get the infrastructure ready. Off-the-shelf solutions don't exist for our client with their complex infrastructure and comprehensive business logic.
- Employee turnover is an issue for any corporation. Our client is no exception. The valuable knowledge is often lost — server configurations, container settings, pipeline settings, access rights modifications, URL settings, etc. It translates into new changes in the infrastructure, which is a lengthy and costly process for a company.
Thus, the distributed team consisting of the Symfa and client talents collectively tackled:
- the infrastructure planning and designing;
- system knowledge restoration (through reverse engineering in the absence of the knowledgeable engineer and/or complete documentation set);
- infrastructure implementation.
Solution
The pile of the technical problems that came with the project couldn’t be resolved overnight. The tech stack had not seen any significant upgrade in years, so the tech debt accumulated over time asked for a rigid approach to deal with.
The technological stack (both backend and frontend) was to be migrated to the latest releases. When Symfa joined the project, both backend and frontend were running on the unsupportable software versions, which was a source of potential security breach. The team was to improve/rewrite the code on the new tech stack. The application is also going to migrate to the cloud and the microservice architecture afterwards. Last but not least, the client is planning to expand the application functionality with new strategic features.
To summarize, the solution to the complex client’s problem lies in three consecutive steps:
- To support the existing application in order to make the day-to-day business operations possible.
- To improve/rewrite the code and migrate the system to the microservice-based architecture.
- Implement new business modules and functionality as per the client’s requests.
Work done
To implement a wide scope of changes, together with the client, we shaped the following strategy:
Phase 1 — backend code revision + migration to the cloud.
Phase 2 — migration to microservices + frontend code revision and refactoring.
Currently, the project is in Phase 1. The application is running as two macroservices that later on are planned to undergo further decoupling. Each macroservice refers to a single separate module.
The application has been under development for six years and has grown massively complex for its relatively modest size. To migrate a single backend module, five developers have been working on code improvements and fitting it into the cloud infrastructure for five months now.
The application frontend was migrated to the cloud as is. In the following phase, the team will do a significant frontend code revision and refactoring, along with revising the existing app functionality and adding new modules.
Why microservices?
Microservices isn't a one-fits-all solution. Despite all the fuss it has received recently, it is far from the best fit for many projects. As for the current application, it is still subject to future speculations within the project team whether a costly decoupling into microservices will pay off.
Microservices isn’t mainly a technological solution. Rather, it is an architectural approach embracing the whole organization. If a company has a set of digital services that represent all its business landscape, microservices can match its business needs.
Let’s consider a situation, where each business service in a company is represented by a monolith. It may hamper data transfer between the services and the company operation, in general. For example, one monolith supports five types of orders and provides some customer info; the other provides different customer info and supports warehouse operations. In a monolithic structure, two neighboring modules can’t freely communicate with each other. In order to get the information from a neighboring monolithic application, several painful integrations sometimes need to be performed. Such functionality as a rule implies multiple intermediate points (gateways, data buses, APIs). Thus, information interchange becomes a tedious labor-intensive process.
Microservices allow direct informational requests between the neighboring modules. This architectural approach implies that neighboring microservices can use properly documented APIs for an easy data interchange. Simply put, it enables granular information retrieval without intermediaries.
Such an approach eliminates intermediate points, frequent support requests, long project timelines and allows organic shift from waterfall to agile methodology. These are the major reasons why companies move to microservices and why our client is considering microservices migration on this project. However, with the complexity that microservices introduce, it is yet to be decided whether this particular project qualifies for the migration.
Technologies
Results
Onboarding stage took the Symfa team no more than a month. The client’s team (BAs and QAs) has undergone massive compositional changes not long before the Symfa talents joined the project. The learning curve was steep for both teams given the fact that the available project documentation wasn’t complete and a lot of reverse engineering was required. In a few weeks all the talents engaged in the project developed a strong understanding of the business domain and system knowledge.
Despite working in different time zones, time overlap isn’t an issue. The team has developed efficient communication patterns based on the Scrum principles. Daily sync-ups keep all the team members well informed on each other’s achievements and overall project progression. In case any points require extra clarification, stakeholders join the team meetings for discussion. The client highly praises transparency and efficiency in our processes.
Latest projects
BACK TO PORTFOLIOContact us
Our team will get back to you promptly to discuss the next steps