Webinar: How to Drive Business Value in Financial Services with MongoDB
Download as PPTX, PDF2 likes1,632 views
The document discusses the advantages of MongoDB over traditional relational database management systems (RDBMS) in the financial services sector, emphasizing the need for agility, productivity, and low total cost of ownership. It outlines key requirements that MongoDB meets, such as handling large volumes of diverse data efficiently and supporting rapid development cycles, along with showcasing successful case studies of its implementation. The document ultimately presents MongoDB as a viable solution to contemporary challenges faced by financial institutions in data management and operational efficiency.
![14
Instead Match the Data in your
Application
Relational MongoDB
{ customer_id : 1,
first_name : "Mark",
last_name : "Smith",
city : "San Francisco",
accounts : [ {
account_number : 13,
branch_ID : 200,
account_type : "Checking"
},
{ account_number : 14,
branch_ID : 200,
account_type : ”IRA”,
beneficiaries: […]
} ]
}](https://image.slidesharecdn.com/drivingbizvaluejune2013-130627112848-phpapp01/85/Webinar-How-to-Drive-Business-Value-in-Financial-Services-with-MongoDB-14-320.jpg)
![16
No SQL But Still Flexible Querying
MongoDB
{ customer_id : 1,
first_name : "Mark",
last_name : "Smith",
city : "San Francisco",
accounts : [ {
account_number : 13,
branch_ID : 200,
account_type : "Checking"
},
{ account_number : 14,
branch_ID : 200,
account_type : ”IRA”,
beneficiaries: […]
} ]
}
Rich Queries
• Find all Mark’s accounts
• Find everybody who opened an account
last month
Geospatial
• Find all customers that live within 10
miles of NYC
Text Search
• Find all tweets that mention the bank
within the last 2 days
Aggregation
• What’s the average value of Mark’s
accounts
Map Reduce
• How many customers that have a
checking account also have an IRA](https://image.slidesharecdn.com/drivingbizvaluejune2013-130627112848-phpapp01/85/Webinar-How-to-Drive-Business-Value-in-Financial-Services-with-MongoDB-16-320.jpg)
![17
MongoDB Technical Benefits
Horizontally Scalable
-Sharding
Agile &
Flexible
High
Performance
-Indexes
-RAM
Application
Highly
Available
-Replica Sets
{ author: “roger”,
date: new Date(),
text: “Spirited Away”,
tags: [“Tezuka”, “Manga”]}](https://image.slidesharecdn.com/drivingbizvaluejune2013-130627112848-phpapp01/85/Webinar-How-to-Drive-Business-Value-in-Financial-Services-with-MongoDB-17-320.jpg)
Webinar: How to Drive Business Value in Financial Services with MongoDB
- 1. Driving Business Value in FS with MongoDB Matt Kalan, FS Solutions Architect Email: Matt.kalan@10gen.com Twitter: @matthewkalan
- 2. 2 • FS today requires agility, productivity, and low TCO • RDBMS not supporting requirements well • MongoDB built for these requirements • MongoDB has hit critical mass in adoption • Many valuable case studies in FS • We can help you get started Executive Summary
- 3. 3 Trends in FS Driving Change Mobile & Gamification (retail) New Opportunities Regulations Enhanced Risk Management CCP Central Clearing Cost pressures
- 4. 4 Requirements • Aggregate disparate data • Change apps quickly • Analyze data faster • Store more data • Increase productivity • Reduce TCO drastically Putting Urgency on These IT Requirements Like Never Before
- 5. 5 Unfortunately, RDBMSs Not Built for These Requirements Data Types & OOP • Unstructured data • Semi-structured data • Polymorphic data Volume of Data • Petabytes of data • Trillions of records • Tens of millions of queries per second Agile Development • Iterative • Short development cycles • New workloads New Architectures • Horizontal scaling • Commodity servers • Cloud computing
- 6. 6 • Customfield1…100 or separate tables • Caching & ORMs • Expensive hardware and storage • Data migration • One schema across apps • Application-specific partitioning • Use files instead of databases • Schema change takes 6 months As a Result, Shoehorn Requirements Slow time-to-market Agility lost High cost Business frustrated
- 7. 7 Now There Is Help 2010 RDBMS Key-Value/ Column Store OLAP/BI Hadoop 2000 RDBMS OLAP/BI 1990 RDBMS Operational Data Datawarehouse Document DB NoSQL
- 8. 8 What Requirements Are Needed to Address These Challenges Addresses Requirement Description Data Types Hierarchical data structure Can match the structure of objects in today’s OOP languages Data Types, Agile Dynamic schema Can handle differently shaped data in a table/collection and not a predefined schema Agile Native OOP language Keeps developers in one environment and encapsulates functionality/validation/rules in one place Volume Scale Can efficiently handle 100s tera & petabytes of data Volumes, New Arch Performance High throughput on a single node and scales horizontally easily Still req Software cost Open source with premium value added services Still req Data consistency How soon you can read data that was just written Still req Rich querying Querying based on any field, e.g. secondary indexes Still req Ease of use Short learning curve and easy to design
- 9. 9 How Databases Stack Up Requirement RDBMS MongoDB Key/value Wide column Hierarchical data structure Poor Great Poor OK Dynamic schema Poor Great Poor OK Native OOP language Poor Great Great Great Scale Poor Great Great Great Performance Poor Great Great Great Software cost Poor Great Great Great Data consistency Great OK Poor Poor Rich querying Great OK Poor Poor Ease of use OK Great OK Poor
- 10. 10 What Is Needed to Be Effective Broadly Requirement RDBMS MongoDB Key/value Wide column Hierarchical data structure Poor Great Poor OK Dynamic schema Poor Great Poor OK Native OOP language Poor Great Great Great Scale Poor Great Great Great Performance Poor Great Great Great Software cost Poor Great Great Great Data consistency Great OK Poor Poor Rich querying Great OK Poor Poor Ease of use OK Great OK Poor
- 11. 11 Operational Database Use Cases RDBMSs Key/Value or Column Stores MongoDB
- 12. 12 Relational: All Data is Column/Row Customer ID First Name Last Name City 0 John Doe New York 1 Mark Smith San Francisco 2 Jay Black Newark 3 Meagan White London 4 Edward Daniels Boston Account Number Branch ID Account Type Customer ID 10 100 Checking 0 11 101 Savings 0 12 101 IRA 0 13 200 Checking 1 14 200 Savings 1 15 201 IRA 2
- 13. 13 Have to Manage Change in 3 Places Relational Database Object Relational Mapping Application Code XML Config DB Schema
- 14. 14 Instead Match the Data in your Application Relational MongoDB { customer_id : 1, first_name : "Mark", last_name : "Smith", city : "San Francisco", accounts : [ { account_number : 13, branch_ID : 200, account_type : "Checking" }, { account_number : 14, branch_ID : 200, account_type : ”IRA”, beneficiaries: […] } ] }
- 15. 15 Instead Put Data Model in One Place Application Code Relational Database Object Relational Mapping XML Config DB Schema Application Code Rich Queries Geospatial Text Search Map Reduce Aggregatio n
- 16. 16 No SQL But Still Flexible Querying MongoDB { customer_id : 1, first_name : "Mark", last_name : "Smith", city : "San Francisco", accounts : [ { account_number : 13, branch_ID : 200, account_type : "Checking" }, { account_number : 14, branch_ID : 200, account_type : ”IRA”, beneficiaries: […] } ] } Rich Queries • Find all Mark’s accounts • Find everybody who opened an account last month Geospatial • Find all customers that live within 10 miles of NYC Text Search • Find all tweets that mention the bank within the last 2 days Aggregation • What’s the average value of Mark’s accounts Map Reduce • How many customers that have a checking account also have an IRA
- 17. 17 MongoDB Technical Benefits Horizontally Scalable -Sharding Agile & Flexible High Performance -Indexes -RAM Application Highly Available -Replica Sets { author: “roger”, date: new Date(), text: “Spirited Away”, tags: [“Tezuka”, “Manga”]}
- 18. 18 70%+ Lower TCO Commercial RDBMS Compute – Scale-Up Servers Storage – SAN Dev. and Admin Compute – Commodity HW Storage – Local Storage Dev. and Admin $1,680K $517K
- 19. 19 • MetLife Leapfrogs Insurance Industry with MongoDB-Powered Big Data Application – “innovative customer service application…in 90 days…from 70+ existing systems” • 10gen Establishes Financial Services Advisory Group – “ten leading global institutions…including Barclays, Goldman Sachs and MetLife.” • IBM and 10gen Collaborate to Bring Mobile to the Enterprise – “IBM will standardize on BSON, MongoDB wire protocol and query language” • Informatica and 10gen Partner to Expand Data Integration for MongoDB – “use PowerCenter Big Data Edition to access…data stored in the market's leading NoSQL database” Customers and Software Heavyweights Support MongoDB
- 20. 20 10gen Snapshot 250+ employees 600+ customers Over $81 million in funding Offices in New York, Palo Alto, Washington DC, London, Dublin, Barcelona and Sydney
- 21. 21 Common FS Use Cases Capital Markets 1. Reference Data Management 2. Risk Analysis & Reporting 3. Private DBaaS 4. Buy-Side Portal 5. Regulatory Reporting 6. Tick Data Capture & Analysis 7. Trade Repository 8. Order Capture Banking 1. Single View of Customer 2. Online Banking 3. Reference Data Management 4. Risk Analysis & Reporting 5. Product Catalog 6. Cybersecurity Threat Analysis Insurance 1. Single View of the Customer 2. Online Quoting 3. Customer Portal 4. Risk Analysis & Reporting 5. Reference Data Distribution 6. Policy Definition Catalog
- 22. 22 Common FS Use Cases Capital Markets 1. Reference Data Management 2. Risk Analysis & Reporting 3. Private DBaaS 4. Buy-Side Portal 5. Regulatory Reporting 6. Tick Data Capture & Analysis 7. Trade Repository 8. Order Capture Banking 1. Single View of Customer 2. Online Banking 3. Reference Data Management 4. Risk Analysis & Reporting 5. Product Catalog 6. Cybersecurity Threat Analysis Insurance 1. Single View of the Customer 2. Online Quoting 3. Customer Portal 4. Risk Analysis & Reporting 5. Reference Data Distribution 6. Policy Definition Catalog
- 23. 23 Distribute reference data globally in real-time for fast local accessing and querying Reference Data Case Study: Global investment bank Problem Why MongoDB Results • Delays up to 36 hours in distributing data by batch • Charged multiple times globally for same data • Incurring regulatory penalties from missing SLAs • Had to manage 20 distributed systems with same data • Dynamic schema: easy to load initially & over time • Auto-replication: data distributed in real-time, read locally • Both cache and database: cache always up-to-date • Simple data modeling & analysis: easy changes and understanding • Will save about $40,000,000 in costs and penalties over 5 years • Only charged once for data • Data in sync globally and read locally • Capacity to move to one global shared data service
- 24. 24 Previous Reference Data Management Architecture Feeds & Batch data • Pricing • Accounts • Securities Master • Corporate actions Source Master Data (RDBMS) Batch Batch Batch Batch Batch Batch Batch Destination Data (RDBMS) Each represents • People $ • Hardware $ • License $ • Reg penalty $ • & other downstream problems
- 25. 25 Solution with MongoDB Feeds & Batch data • Pricing • Accounts • Securities Master • Corporate actions Real-time Real-time Real-time Real-time Real-time Real-time Real-time Each represents • No people $ • Less hardware $ • Less license $ • No penalty $ • & many less problems MongoDB Secondaries MongoDB Primary
- 26. 26 Global 360 degree view of customers’ policy portfolio and interactions Single View of Customer Case Study: Tier 1 Global Insurance Provider Problem Why MongoDB Results • 70 systems and 20 screens to view customer policies • Many CSR calls taken just to reroute customer • Poor customer experience • Source systems are hard to change • Dynamic schema: can combine 70 systems easily • Performance: can handle all data in one DB • Replication: local reads and high availability • Sharding: can add data easily by scaling out • Delivered in 3 months with $4M – previous attempts failed with $25M • Unified customer view available to all channels • Shorter and less calls re- routed • Increased customer satisfaction
- 27. 27 Single View of Customer Case Study: Tier 1 Global Insurance Provider Source database 1 Source database 2 … Source Database 70 Custom app exports JSON Document • per product • per customer CSR Application Customer Application Agent/RM Application OLTP/real-time access Future phases Queue to Update Source Systems
- 28. 28 Enable a globally distributed, centrally managed private data cloud with optional persistence framework DBaaS Case Study: Global investment bank Problem Why MongoDB Results • Wanted app groups to focus on building apps, not data access logic • Horizontal scaling done by each application • Up to 6 months for app groups to procure hardware • Each phase has hardware procurement • Native language drivers: groups can focus on agile application development • Auto-replication: data distributed globally in real- time • Auto-sharding: linearly scale automatically • Time to market decreased by at least 50% • Object persistence included in framework • DB capacity added in minutes not months • Same environment from prototype to production
- 29. 29 Risk Analytics & Reporting Use case requirements: • Collect positions, pricing, ratings, and other source data • Calculate risk metrics and exposures • Handle high throughput for intraday metrics or large simulations • Be highly available so can be relied on Why MongoDB? • Dynamic schema => data can be collected from many different sources and formats without time delays for data modeling and schema changes • High throughput => more up-to-date data or high volumes • Aggregation framework => database-supported roll-ups from various desks, asset classes/products, geographies, etc. • Map-reduce capability (Native MR or Hadoop Connector) => perform batch risk analysis and simulations
- 30. 30 Aggregating Risk Reporting Reporting Trades in real-time
- 31. 31 Online Banking/Trading Portal Use case requirements: • Store portfolios, accounts, positions/balances, orders, market values, etc. • Ad hoc querying by account, security, date, trader, thresholds, etc. • Fast response times and iteration keep customer satisfaction high • Relationship manager wants real-time reporting and alerting on customer activity Why MongoDB? • Low latency & caching => fast response times for all data available • Dynamic schema => Can handle any portfolio structure, assets, or accounts • High scalability => Reporting requirements on often large customer data sets • Aggregation Framework => calculate metrics, aggregations, and analysis
- 32. 32 • FS today requires agility, productivity, and low TCO • RDBMS not supporting requirements well • MongoDB addresses all these requirements as a general purpose operational DB • MongoDB has hit critical mass in adoption • Many case studies demonstrating value in FS • Let us know if we can help you get started Summary
- 33. 33 Subscriptions Professional Support, Subscriber Edition and Commercial License 10gen Products and Services Consulting Expert Resources for All Phases of MongoDB Implementations Training Online and In-Person for Developers and Administrators
- 34. 34 Resource Location MongoDB Downloads 10gen.com/download Free Online Training education.10gen.com Webinars and Events 10gen.com/events White Papers 10gen.com/white-papers Case Studies 10gen.com/customers Presentations 10gen.com/presentations Documentation docs.mongodb.org Additional Info info@10gen.com For More Information Resource Location
Editor's Notes
- #2: Mention FS includes cap markets, banking, and insurance. Looking at attendees, cap markets most but also touch on insurance and banking
- #4: Reg- Cap markets – uncertainty plus changing regs with Dodd-Frank, Basel III, Volkor, etc. More regulatory reporting demands as GreatBanking – pressure from the fed for reportings, TBTFRisk mgmt – financial crisis showing failure of risk mgmt, so changing analytics, and the drive to be intraday, take more factors into accountCost pressure – esp. banking with low interest rates and fees
- #5: Bringing data together (regulatory, risk, trade repository, etc.) painful with RDBMS => polymorphicAgility to change systems generally is painful => agileRun risk analysis more often towards intraday => performanceStore many years of audit info cheaply but online => scaleData warehouse not timely or performant enough => performanceStuck in expensive contracts without leverage => cost
- #6: RDBMSs built before OOP, agile, cloud, and big dataData types – social networking and IM compliance; multiple desks, products, geographiesVolumes – store and analyze more data than ever for auditing and risk esp. and at low cost; data warehouse has some data but not how you want it and performant enough
- #10: Add H-M-L
- #11: Add H-M-L
- #19: Then 10x better performance50% less dev time
- #27: Good for regulatory reporting, e.g. KYC