Developing an integrated customer view has been on the wish list at insurance giant MetLife for at least 10 years, but it recently took a fresh approach to the challenge by choosing a NoSQL database as the platform for bringing together data from more than 70 separate administrative systems, claims systems and other data sources. It moved from pilot to rollout in 90 days -- breakneck speed in an industry used to measuring IT projects in months and years.
"We had 60 different teams working together as one group, and they were working nights and weekends not because they had to but because they were excited and wanted to," says Gary Hoberman, MetLife's senior VP and CIO of regional application development.
The choice of NoSQL for the project makes sense because these databases can ingest structured, semi-structured and unstructured information without requiring tedious, expensive and time-consuming database-mapping or extract, transform and load (ETL) processes to normalize all data to a rigid schema, as required by relational databases.
[ 10Gen's Matt Assay will be a keynote speaker at the upcoming E2 Conference in Boston, June 17 - 19. ]
Like any big company, MetLife has a profusion of product lines and supporting systems. Some systems are home grown, some are commercial software products and some are commercial or home-grown apps gained through acquisitions. Many systems have to meet complex federal and state regulatory requirements imposed on the annuity and individual- and group-insurance products that MetLife sells.
Ripping out, replacing or otherwise touching these mission-critical systems of record was out of the question. So how could MetLife access information from these diverse sources? NoSQL databases have emerged in recent years as a diverse and scalable option.
MetLife also confronts its share of data-quality and data-diversity challenges within systems. By definition, life insurance and annuity products are long lived, but as healthcare and the insurance business have evolved, so, too, have data-collection requirements and standards. Today's policy records, for example, have many more fields of data than the records behind policies issued in the 1990s, 1970s or 1950s. Look across the corpus and you have what might be described as ragged or sparse data with missing fields -- another argument for NoSQL.
Finally, MetLife deals with semi-structured and unstructured information, such as images of health records and death certificates. This contributed to MetLife's selection of MongoDB -- 10Gen's open source document database -- over other NoSQL alternatives such as Cassandra, which MetLife is testing in other applications.
"Everything we know about a customer and everything we know about a policy stores into a single JSON [Java Script Object Notation] document," says Hoberman, one of three top IT execs at MetLife who report up to the Global CIO. "Any other database wouldn't allow us to view customers as a single record without caring about structure at all. With Mongo, we can bring a group policy and an individual policy together without any [data] normalization, and we use a Web services layer and the application to render the best view of that data."
MetLife worked with software development firm Infusion to select the database and together they envisioned an interface akin to a Facebook Wall. The screen shows a customer profile listing all products owned on the left together with a reverse-chronological timeline of events on the right. The event feed shows all interactions with contact centers, logins to various websites, and in-person interactions with insurance agents, claims specialists, employer administrators and other touch points.
Once the key technology and interface decisions were finalized late last year, it took just two weeks to build a prototype and seed it with 2 million fake customer records to prove that it would scale.
"Within a few weeks of building the prototype, we were in front of the executive group of MetLife presenting a live demo, and the excitement in the room was tremendous," according to Hoberman, who says the project was given an immediate green light.
"The call center reps had access to a lot of this information before, but they had to have as many as 15 different screens open, which is insane if your goal is to quickly serve customers," says Hoberman. In other cases, agents had to forward calls to back-office agents to gain access to records such as death certificates.
For now, The Wall is strictly an internal-facing application designed for service, in part because MetLife can't have 100% confidence that all records shown on The Wall resolve to a single customer. Is John Smith of Barrington, Ill., the same as John E. Smith of Barrington Hills, Ill.? Much like a search application, The Wall displays confidence measures for each record based on the number of coinciding data points.
[ Want more info on an up-and-coming NoSQL vendor? Read 10Gen Enterprise Release Takes MongoDB Uptown. ]
Here's where relational database advocates might pipe up about the certainty of having carefully mapped data indisputably resolved to a single customer. But Hoberman says most companies face inconsistencies and uncertainly even when querying records in conventional databases and applications. The Wall, he says, gives MetLife an opportunity to clean up its information and tie together formerly disparate records.
"If one of our employees is on the phone with a life insurance customer, he or she can ask, 'do you also happen to have an annuity with us, and do you happen to have the account number?'" Hoberman explains. "This gives us the ability to get the information right and link records behind the scenes."
The Wall complements an enterprise-wide roll out of Salesforce.com that's also in progress. The idea is to eventually get to just two screens: Salesforce for sales and service transactions and The Wall as the interface to customer records across the company's many business systems.
For now, the usual early-days bugs and kinks are still being worked out of the system, but The Wall is expected to roll out to 3,000 call center and research staff in the U.S. by this summer. The next steps will be going global and supporting sales as well as service.
MetLife is already moving ahead with service deployments in selected European countries, and it's testing a sales-facing prototype in Russia and a predictive attrition app in Japan. The predictive app will alert call-center agents when callers have a high propensity to switch to a competitor. This analytic application is based on real-time analysis of customer profiles and histories, and if attrition is likely, agents will be prompted to offer replacement products. The prototypes are expected to move into production by year end, according to Hoberman.
Another next step will be turning The Wall into a bi-directional application capable of updating legacy systems of record. That's something The Wall will have to support if it is to eventually become a platform for customer-facing self-service applications, as MetLife envisions.
The Wall has yet to go enterprise-wide and the vision extends far beyond the realities of the current deployment. But the scale, scope and speed of accomplishments to date points to a huge success. Looking beyond MetLife and even the insurance industry, The Wall may well be a prototype for the next generation of customer-360 applications.