Travelers Insurance is one of the top writers of commercial, property, and casualty insurance in the United States. As a senior architect, I’ve seen the industry evolve tremendously over the last 10+ years as data demands drove features that required data at rest, then data in motion, and, finally, data in consumption.
At this time, our board of directors mandated that we leverage technology to redesign manufacturing and selling — and, ultimately, improve our company's productivity and efficiency.
It stood to reason that software would reduce the bottlenecks, which meant we needed to become better at building and delivering software consistently. While we considered ourselves agile zealots adept with microservices, we did not wake up one day and suddenly change databases.
The truth is, it took several years of iterating before we finally replaced the underlying relational database with a document database that would enable us to capture the value of using microservices and increase our developer productivity and velocity.
Becoming more agile with an operational data store
Initially, our goal was to build a single-view application for our brokers, who were logging into 12 different services required for a single use case. What continued to hold us back was the relational data model.
With today’s software development practices, you are expected to build software from a two- or three-sentence business feature. The name of the game is to stay light and to constantly iterate. It’s different from the traditional waterfall method, where six months might be spent on requirements analysis before a single line of code is written. With a waterfall approach, this is fine — you know the end state in order to create your database objects. However, you simply can’t do this if you’re following agile methods because there’s no way to build a data model from a three-sentence business requirement. The reality is you’re constantly reworking the database.
At Travelers, we stood up our single-view app in 2014, although it was still ETL-dependent, had a monolithic code base, and presented consistent integration challenges. Now, we deploy software five times annually — major for us — and built internal buzz about the business impact of the redesigned app.
We realized if engineering teams needed to deliver faster, we needed to move away from the relational database.
Goodbye tables, hello JSON!
In 2017, we made the decision to use MongoDB Atlas, a document model database. However, to succeed, we had to do more than learn how to program against a different database. This was a massive change introduced to a company that had never used anything other than a relational database. As much as we needed to modernize our technology, to succeed, we also needed to modernize our culture.
While our developers built the software, we built relationships with many other groups to bring them along on our journey.
- We did this to make sure we could use their expertise
- To quiet the noise
- To teach every team how to data model in JSON
Modeling in JSON, as opposed to tables, was an eye-opening experience for many people, who recognized how much faster we could deliver software into production.
Quickly, backlogs for business product owners began declining as our dev teams delivered features into production faster. This created a flywheel of momentum. As word got out internally of what our business unit was doing, we began to see a massive uptick in interest from other teams curious about our results.
OK, now comes the microservices
Despite our developers having no experience with MongoDB prior to our first release, we were still able to ship to production in eight weeks, eliminate 600+ lines of code — and come in under time and budget. Pretty good, right?
Additionally, feedback indicated that the document data model helped eliminate the tedious relational database work of data mapping and modeling. And this gave time back for developers to re-focus on high-priority projects.
When we first began using MongoDB, we had two collections in production. A year later, we had 120 collections deployed into production and were writing 10 million documents daily. Today, each team owns its own dependency and has its own dedicated microservice and database leading to a single pipeline for application and database changes. Collectively, these changes — and the hours saved not refactoring our data model — allowed us to cut deployment time from hours or even days to minutes.
Setting the pace for future innovation
If you’re doing it right in relational, you have a lot of tables and, if you’re modeling your data properly, you will have a lot of objects even for the simplest use cases. Once we determined that our database was slowing us down, we knew it was time for a change.
Our decision to move to a document model database ended up having a profound effect on the company, and MongoDB has become the de facto standard for software development. Along the way, we embraced a lean product mindset and set our development teams up for successfully reducing time to delivery.
Learn more about MongoDB Atlas and how to build your next application with the document data model.