Tier 1 banks, top insurance providers and other global financial services institutions have discovered that with the use of MongoDB, they are able to achieve a single view of the customer. This allows them not only to comply with KYC and other regulations, but also to engage customers efficiently, which helps reduce churn and increase wallet share while reducing costs. We will focus on how MongoDB's dynamic schema, real-time replication and auto-scaling make it possible to create a global, unified data hub aggregating disparate data sources, which can be made available to customers, customer service representatives (CSRs), and relationship managers (RMs).

1. Making A Single View of the
Customer Real with MongoDB
Marcelo Rocha DaSilva
Senior Solutions Architect, MongoDB
@SQLorNot

2. MongoDB
The leading NoSQL database
General
Purpose
2
Document
Database
OpenSource

3. MongoDB Vision
To provide the best database for how we build and
run apps today
Build
–New and complex data
–Flexible
–New languages
–Faster development
3
Run
–Big Data scalability
–Real-time
–Commodity hardware
–Cloud

4. Fortune 500 & Global 500
• 10 of the Top Financial Services Institutions
• 10 of the Top Electronics Companies
• 10 of the Top Media and Entertainment
Companies
• 8 of the Top Retailers
• 6 of the Top Telcos
• 5 of the Top Technology Companies
• 4 of the Top Healthcare Companies
4

5. Global Community
5,000,000+
MongoDB Downloads
100,000+
Online Education Registrants
20,000+
MongoDB User Group Members
20,000+
MongoDB Days Attendees
20,000+
MongoDB Management Service (MMS) Users
5

6. MongoDB and Enterprise IT Stack
CRM, ERP, Collaboration, Mobile, BI
Data Management
Online Data
Offline Data
RDBMS
Infrastructure
OS & Virtualization, Compute, Storage, Network
6
Security & Auditing
Management & Monitoring
Applications

7. MongoDB Overview
Agile
7
Scalable

8. MongoDB and Enterprise IT Strategy
Legacy
Apps
Strategic
On-Premise
SaaS, Mobile, Social
Oracle
MongoDB
Teradata
Hadoop
Compute
Scale-Up Server
Commodity HW / Cloud
Storage
SAN
Local Storage / Cloud
Network
Routers and Switches
Software-Defined Networks
Database
Offline Data
8

9. MongoDB Features
• JSON Document Model
with Dynamic Schemas
• Full, Flexible Index Support
and Rich Queries
• Auto-Sharding for
Horizontal Scalability
• Built-In Replication for High
Availability
• Text Search
• Advanced Security
• Aggregation Framework
and MapReduce
• Large Media Storage with
GridFS
9

10. MongoDB Business Value
Enabling New Apps
Faster Time to Market
10
Better Customer Experience
Lower TCO

11. Data Integration
• Data Integration is about processes
and knowing the data well.
• Old technologies make progress very
difficult and slow
• MongoDB enables easy/incremental
approach to Enterprise Data View
11

12. • Extract customer info from many source systems
as often as desired
• Load into one database and application
• Link data together for each customer
• Query for all customer and associated product
info at once
• Enable CSRs, RMs/Agents, customers, etc. to
know all customer and product information at
once
13

13. Single View of a Customer –
Why MongoDB?
•
Dynamic schema => can handle vastly different data together and
can keep improving and fixing issues over time easily
•
High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
•
Auto-sharding => can automatically add processing power as
customers and products are added
•
Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
•
Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
•
Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub
14

14. And We’ve Done it Before
• MetLife Leapfrogs Insurance Industry with
MongoDB-Powered Big Data Application
•
New York—May 7, 2013—10gen, the MongoDB company, today
announced that MetLife, Inc. selected MongoDB as the data engine
for “The Wall”, an innovative customer service application that went
live last month. …
•
http://www.10gen.com/press/metlife-leapfrogs-insurance-industry-mongodbpowered-big-data-application
15

15. High Level Data Flow
Source
Source
database 11
database
Source
Source
database 22
database
ETL or
Custom app
OLTP/real-time
access
Document
•per product
•per customer
CSR Application
CSR Application
Customer
Customer
Application
Application
…
Agent/RM
Agent/RM
Application
Application
Source
Source
database N
database N
16
Queue to Update
Queue to Update
Source Systems
Source Systems

16. Case Study: Tier 1 Global Insurance
Provider
Single global view of customers’ product
portfolio and interactions
Problem
• Siloed view of customer
across products
• Changing policy
definitions takes months
or more
• Source systems are
critical but stuck on old
technology
17
Why MongoDB
• Leverage dynamic
schema to include
evolving policy details
Results
• Able to deliver in 3
months with $2M, when
previous attempts costing
$25M failed with no results
• One data hub across all
• Unified customer view for
contact channels for
consistent customer view call center and web site
with changes available to
• Leverage replication for
all channels
high availability to reduce
• Dramatically lower cost
pressure on ops team
through less and shorter
• Leverage sharding to
calls
scale linearly

17. Case Study: Tier 1 Global Insurance
Provider
Source
Source
database 11
database
Custom app
exports JSON
OLTP/real-time
access
CSR Application
CSR Application
Source
Source
database 22
database
Customer
Customer
Application
Application
…
Source
Source
Database 40
Database 40
18
Document
•per product
•per customer
Agent/RM
Agent/RM
Future phases
Future phases
Application
Application

18. Pre requisite Data Analysis

19. What questions to answer to feed
into design?
• What is the scope of customer info to aggregate?
– Start with a manageable amount
– Focus on satisfying particular valuable purposes (e.g minimizing
MTTR and re-routed calls)
– Need executive political support to get time from all groups
• How to link data across customers and products?
– Identify the rules both exact and fuzzy
– Specify common fields
– Try to normalize but dynamic schema is tolerant
– Can always refine rules as you go even based on human
feedback
20

20. Load Data into MongoDB

21. Customer Records in Source
Systems, e.g. banking
Personal Bank Accounts
Personal Bank Accounts
•Account ID
•Account ID
•Open date
•Open date
•First name
•First name
•Last name
•Last name
•Joint First Name
•Joint First Name
•Joint Last Name
•Joint Last Name
•Joint SSN
•Joint SSN
•Address
•Address
•City
•City
•State
•State
•Zip
•Zip
•Address 22
•Address
•Home phone
•Home phone
•Work phone
•Work phone
•APR
•APR
•Account type
•Account type
•Branch ID
•Branch ID
•Region ID
•Region ID
•….
•….
22
Credit Cards
Credit Cards
•CC number
•CC number
•SSN 11
•SSN
•Full name 11
•Full name
•Address 11
•Address
•City 11
•City
•State 11
•State
•Zip 11
•Zip
•SSN 22
•SSN
•Full Name 22
•Full Name
•Address 22
•Address
•City 22
•City
•State 22
•State
•Zip 22
•Zip
•Primary phone 11
•Primary phone
•Mobile phone 22
•Mobile phone
•Issue date
•Issue date
•Reward type
•Reward type
•….
•….
Mortgages
Mortgages
•Mortgage ID
•Mortgage ID
•Borrower name
•Borrower name
•Borrower SSN
•Borrower SSN
•Borrower address
•Borrower address
•Borrower city
•Borrower city
•Borrower state
•Borrower state
•Borrower zip
•Borrower zip
•Co-borrower SSN
•Co-borrower SSN
•Co-borrower name
•Co-borrower name
•Co-borrower address
•Co-borrower address
•Co-borrower city
•Co-borrower city
•Co-borrower state
•Co-borrower state
•Co-borrower Zzp
•Co-borrower Zzp
•Mobile phone
•Mobile phone
•Effective date
•Effective date
•Term
•Term
•Interest
•Interest
•Money down
•Money down
•Principal loan
•Principal loan
•Total loan
•Total loan
•….
•….

22. Bank Account JSON Document
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
homePhone: “123-456-7890”,
workPhone: “897-389-8987”,
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { accountID: 9874983789} )
23

23. P&C Policy Document
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
policyNumber: 2398439343,
policyType: “Homeowners”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
homePhone: “123-456-7890”,
workPhone: “897-389-8987”,
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.policies.find( { lastName: “Smith”}
address: “52 Vanderbilt Ave.” )
24

24. Bank Account JSON Document
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”,
contactMethods: {
mobile: “389-897-8987”,
home: “983-893-3873”,
email: “john.smith@abc.com”,
work: “298-389-8983” }
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { “contactMethods.mobile”: “983-893-3873” } )
25

25. Joint Bank Account Document
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
accountID: 9874983789,
accountType: “Checking”,
ownershipType: “Joint”
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …},
{ firstName : ”Anne",
lastName: “Smith”,
address: “52 Vanderbilt Ave.”, …} ]
openDate: ISODate("2013-02-15 10:00”)
…
}
> db.accts.find( { accountOwners: {$elemMatch: {
lastName: “Smith”,
address: “52 Vanderbilt Ave.”}}} )
26

26. General document per customer per
account
{
_id : ObjectId("4e2e3f92268cdda473b628f6"),
sourceIDs: {
ABCSystemIDPart1: 8397897,
OR creditCardNumber: 8392384938391293
ABCSystemIDPart2: 2937430,
OR mortgageID: 2374389
OR policyID: 18374923
ABCSystemIDPart3: 932018 }
accountType: “Checking”,
accountOwners: [
{ firstName : ”John",
lastName: “Smith”,
contactMethods: [
{ type: “phone”, subtype: “mobile”, number: 8743927394},
{ type: “mail”, address: “58 3rd St.”, city: …} ]
possibleMatchCriteria: {
govtID: 2938932432, fullName: “johnsmith”, dob: … } },
{ firstName : ”Anne",
maidenName: “Collins”,
lastName: “Smith”, …} ],
openDate: ISODate("2013-02-15 10:00”),
accountFeatures { Overdraft: true, APR: 20, … }
}
27

27. Querying for single view

28. Index any fields: arrays, nested, etc
// Compound indexes
> db.accts.ensureIndex({accountID: 1, lastName:1})
// Index on embedded docs and arrays
>db.accts.ensureIndex( {contactMethods.mobile: 1})
// Index on any depth
> db.accts.ensureIndex( {“owners.matchcriteria.ssn”: 1} )
29
// Full text search
> db.accts.ensureIndex ( { address1: “text”,
address2: “text” } )

29. Query For First Product and Then All
// Customer knows his/her account number
> db.accts.find( {accountNumber: 9789732839} )
// Use looked up account to find other accounts
db.accts.find( {matchCriteria.ssn: 8973829438} )
// In reality, it’s more complicated
> db.accts.find({
$or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })
30

30. Query For All Products Without ID
// Customer only knows phone number
> db.accts.find({ contactMethods.number: 9789732839
lastName: “Smith” } )
// Confirm correct result w/ customer, then pull all accounts
// Same query as before to pull all accounts
> db.accts.find({
$or: [ {mc.fullName: “johnsmith”, mc.dob: “01/01/1970”},
{mc.ssn: 8923784789},
{mc.homePhone: 29838923845}, … ] })
31

31. Text Search Example
(e.g. address typo so do fuzzy match)
// Text search for address filtered by first name and NY
> db.ticks.runCommand(
“text”,
{ search: “vanderbilt ave. vander bilt”,
filter: {name: “Smith”,
city: “New York”} })
32

32. Analyzing/Aggregating Options
• Custom application code
– Run your queries, compute your results
• Aggregation framework
– Declarative, pipeline-based approach
• Native Map/Reduce in MongoDB
– Javascript functions distributed across cluster
• Hadoop Connector
– Offline batch processing/computation
33

33. Aggregate: Total Value of Accounts
//Find total value of each customer’s accounts for a given RM (or Agent) sorted by value
db.accts.aggregate(
{ $match: {relationshipManager: “Smith”}},
{ $group :
{ _id : “$ssn”,
totalValue: {$sum: ”$value”} }},
{ $sort: { totalValue: -1}} )
34

34. Why MongoDB is the most
capable?

35. Single View of a Customer –
Why MongoDB?
 Dynamic schema => can handle vastly different data together and
can keep improving and fixing issues over time easily
 High scale/performance => directly impacts customer experience or
CSR MTTR so every second counts
 Auto-sharding => can automatically add processing power as
customers and products are added
 Rich querying => supporting ends users directly requires multiple
ways of access and key/value is not sufficient
 Aggregation framework => database-supported roll-ups for analysis
on data hub for customer information by marketing, sales, etc.
 Map-reduce capability (Native MR or Hadoop Connector) => batch
analysis looking for patterns and opportunities in data hub
36

36. Why [Not] an RDBMS
37

37. Why [Not] Other NoSQL DBMSs
38

38. Summary of Value

39. Before MongoDB Solution
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
CSR Application
40

40. With MongoDB Solution
CSR Application
CSR Application
Single Customer
Single Customer
Portal
Portal
41

41. Short-term Value over the Long-Term
1. CSR Application
–
–
–
–
–
Minimize calls routed to other call centers
Shorter MTTR because CSR has all information
More efficient staffing because can pool CSRs better
More effective cross-sell/upsell
Better customer satisfaction
1. Customer portal
– Minimize calls needed at all
– Better customer service
– More effectively cross-sell/upsell
42

42. Short-term Value over the Long-Term
3. Regulatory Compliance Initiative
– Minimize KYC or other regulatory risks
– Turn compliance costs into costs savings or revenue
generation
3. Marketing
– Analyze buying patterns more completely
– Target much more accurately for better results
3. Relationship Manager or Agent Application
– Effectively cross-sell/upsell and increase wallet
share
– Provide better, more complete customer service
43

43. Summary
• MongoDB is the most capable for a single view of a
customer
• Dynamic schema can handle data from numerous
different systems all in one place
• Fast, flexible querying, analysis, & aggregation is
necessary to get maximum value
• High performance both on a single machine and
automatically across a cluster by auto-sharding
• MongoDB has all these features with low TCO
• 10gen has helped others with this and can help you
44

44. For More Information
Resource
MongoDB Downloads
www.mongodb.org/download
Free Online Training
education.mongodb.com
Webinars and Events
www.mongodb.com/events
White Papers
www.mongodb.com/white-papers
Customer Case Studies
www.mongodb.com/customers
Presentations
www.mongodb.com/presentations
Documentation
docs.mongodb.org
Additional Info
45
Location
User Data Management
info@mongodb.com

45. THANK YOU!
@SQLorNot

46. Talk to us
@MongoDBInc
@MongoDB
#MongoDB