Leaf in the Wild: Foyer Assurances SA Moves from Relational Databases to MongoDB to Accelerate Digital Transformation
Every enterprise is embarking on digital transformation – bringing applications and services online to more quickly and efficiently serve their customers and enter new markets. But some of their technology choices of the past are now holding them back.
I met with Damien Goosse, Chief Architect in the IT department at Foyer, to discuss how they turned to MongoDB to accelerate application innovation, and build new services that were just not possible with relational databases.
Can you start by telling us a little bit about your company?
The Foyer Group was founded back in 1922 and has grown to become market leader in Luxembourg’s insurance sector, and one of the country’s largest financial services companies, providing insurance, pension and asset management products to the consumer and corporate markets across Europe.
What are challenges are you trying to address with MongoDB?
We have traditionally built our applications on top of relational databases. But we are finding that they are increasingly holding back our digital transformation initiatives, and our strategy to accelerate application delivery by embracing agile development methodologies and cloud computing.
How is MongoDB helping you address those challenges?
We have several applications running on MongoDB today, with many new projects in the pipeline.
Our first application with MongoDB was a migration from one of the leading commercial relational databases. The application is used to capture customer data, which then drives back-end operational processes. We increasingly engage with our customers through web and mobile channels, using online forms to collect the information required for insurance quotes, applications, claims and other business applications. The forms are rich data structures, which we had to flatten and split across relational tables. Any new attributes we needed to capture through the forms incurred painful migrations to our relational database schema. These migrations meant lots of coordination between developers, DBAs, and the operations team, which slowed down how quickly we could implement feature enhancements for the business.
So we decided to switch the application to MongoDB. Now forms are stored in their native structures as JSON documents directly within MongoDB. This has given us a number of benefits: *We have removed the complex ORM layers that were required in the previous implementation to translate between application objects and the relational database schema. *We can add new attributes and features without the convoluted coordination cycles of the past, and without performance impact to our customer-facing applications. *It’s much easier for our backend business applications that need to process the form data to extract JSON data directly from MongoDB, without converting the data between different formats.
As a result of the migration to MongoDB, my team can innovate faster, responding instantly to business requirements, and we’ve seen significantly greater application performance, which translates directly to improved customer experience.
I believe you have also built a new mobile application using MongoDB? We have equipped our agents and partners with tablet devices, enabling them to more efficiently collect information when they are out with customers. All of the data they collect is stored locally on the device, and then securely synchronized back to our central MongoDB database when they are connected to the network.
This is a full-stack, end-to-end, JavaScript application. Using MongoDB’s flexible data model and native JSON support, we have been able to build this application in weeks, rather than the months it would have taken had we used our traditional relational database.
What led you to use MongoDB in the first place?
Recommendations from my developers. A number had used MongoDB in previous roles, and believed that it would be a great fit for us. I asked several members of the team to build a prototype app on MongoDB. They did it in hours. Not days or weeks.
Clearly there are many “NoSQL” choices available. For me, what was really critical in my final selection was production-proven deployments at scale, breadth of tooling, developer productivity, and community vibrancy. MongoDB was the clear leader across all of these dimensions.
Can you describe how you deploy MongoDB?
We are using the latest MongoDB 3.2 release. We deploy against MongoDB replica sets, which provides us fault tolerance against failures, and the ability to perform zero downtime maintenance operations. As we bring more projects onto MongoDB, we will move our replica sets to sharded clusters. All of our hosts run Red Hat Linux and VMware.
We are customers of MongoDB Enterprise Advanced, which provides our teams with access to 24x7 proactive support. As part of Enterprise Advanced, we make extensive use of Ops Manager to automate the configuration, provisioning and upgrading of our deployment. We also use its continuous backup with point in time recovery. I didn’t want my team to spend time scripting all of these operations. Ops Manager allows us to run a very lean and highly productive ops organization.
We will also be integrating MongoDB into our LDAP infrastructure in the next few months.
Do you make use of other MongoDB Services?
Yes, we have used MongoDB’s Production Readiness consulting service. The consultant was able to advise on our overall architecture, and help with MongoDB configuration best practices. The quality of the advice was extremely high, and was key in accelerating the launch of our new MongoDB services. We did initially use a third party consultancy that had worked with us in the past, but they did not have the depth of expertise we expected.
What advice would you give to someone considering MongoDB?
Take time to study the MongoDB documentation, and the online MongoDB University courses. These are both excellent resources that will get you up to speed quickly.
I think what is important is to select a meaningful project, and to use it in order to demonstrate productivity gains and quality of the applications you can build with MongoDB. You will always encounter someone within your organization who is cautious about selecting any new technology. So use your project as an example, to prove what is possible when you think outside of the world of relational databases.
Damian, thank you for taking the time to share your experiences with the MongoDB community.
Want to explore moving from relational databases to MongoDB?