From Stalled to Success in Three Months
In 2011, MetLife’s new executive team knew they had to shake up how the insurance giant catered to customers. Because today’s consumers – hyper connected, digitally empowered, information savvy – have little patience and even less loyalty.
MetLife wanted to harness Big Data to create a 360-degree view of its customers so it could know and talk to each of its more than 100 million clients as individuals. But the Fortune 50 company had already spent many years trying unsuccessfully to develop this kind of centralized system using relational databases.
Which is why the 145-year old insurer in 2013 turned to MongoDB. Using MongoDB’s technology over just 2 weeks, MetLife created a working prototype of a new system that pulled together every single relevant piece of customer information about each client.
Three short months later, the finished version of this new system, called the 'MetLife Wall,' was in production across MetLife’s call centers. The Wall collects vast amounts of structured and unstructured information from MetLife’s more than 70 different administrative systems. After many years of trying, MetLife solved one of the biggest data challenges dogging companies today. All by using MongoDB’s innovative approach for organizing massive amounts of data.
Inside the MetLife Wall
Today, when a customer calls MetLife to ask about a claim, add a new baby to a policy, or dig into coverage details, customer representatives use the Wall to pull up every bit of information they need in seconds – name, address, policies, and life events.
Using a touchscreen and a design based on how Facebook dishes up information, The Wall is instantly familiar to MetLife’s call center operators. Which means customer reps can quickly and efficiently answer questions, handle claims, suggest new services, or offer promotions, while slashing wait and call times. MetLife now understands and serves each customer individually.
Power of the Flexible Data Model
What sparked this change? We’re all too familiar with typical customer service. Call any business and you enter an endless maze where you’re passed around to different people who ask for the same bits of information.
The culprit is data silos. Like most companies, MetLife has scores of data systems created or acquired over the years. MetLife’s systems contain a huge array of structured and unstructured data, including policy and customer information and transactional history about everything from claims to payments. Few are connected and many are on mainframes with cumbersome interfaces.
Ripping out its administrative systems and replacing them with one unified system wasn’t an option for MetLife. So the company had tried over the years to use relational databases, which require a common schema and strict mapping of data sources. Adding each new system was an expensive and time consuming process of changing schemas, and extracting, cleansing, and matching data – one that MetLife never won.
MetLife’s Challenge: Data Variety
MetLife’s 70+ administrative systems contain a massive variety of structured and unstructured data, of two main types. One includes 50 million policies and 118 million customers. Another represents transactional history about payments and claims, and includes about 190 million documents. MetLife needed a way to pull this all together in a single view.
Relational Database Didn't Work
A relational database resembles many Excel spreadsheets. It has a highly structured table organization (its schema). When it comes to customers, for example, you know different things about each one. You may have just the name and email of some, while for others you also know their phone number and different shipping addresses. To make this fit into a spreadsheet, you need to create lots of columns, many of which will be empty. This database becomes unwieldy and difficult to manage.
MongoDB's Document Approach Worked
MongoDB stores information like a series of Word documents. A set of data is stored in a document that has its own schema. When you add a field to a given dataset, you can do so without having to add that field to all of the other documents. For instance, when it comes to managing customer data, you’d use a document for each individual. Everything you know about that person is stored in the document. Some documents have just a few fields, while others contain a lot of information. Adding new information about one customer doesn’t require updating all the other documents.
Working with MongoDB, MetLife could finally sidestep this whole exercise. What makes MongoDB different is its flexible data model. MongoDB looks at data more naturally, making it easy to evolve schemas in real time. If relational databases are like Excel spreadsheets – where data is organized into sheets but where you add a column every time you add a field, creating a structured but unwieldy project – MongoDB is a series of Word documents. Each entry is a document that can have its own schema.
Flexible, Scalable, User Friendly
MongoDB also makes the most of today’s computing resources, including commodity hardware and cloud infrastructure. This helps slash the cost of ownership and lets organizations scale their operations and applications quickly. MongoDB’s horizontal scaling via automatic sharding provides reliable partitioning of massive amounts of data across multiple servers. And it’s flexible, allowing organizations to leverage multiple data centers and multi-temperature storage techniques.
Just as crucial for productivity and agile application development is the ease of use MongoDB provides developers. Developers can interact with the database in the same programming language they use to write the application, whether Java, Ruby, Python, or something else. Which means they can focus on building apps instead of wrestling with ORMs.
And MongoDB provides a variety of rich features, such as integrated search, geospatial, and native analytics, that don’t exist in a traditional database. Giving companies the right resources they need to get projects done quickly.