How to deliver a Single View in Financial Services
Download as PPTX, PDF2 likes1,181 views
The document discusses the implementation of a 'single view' solution in the financial services sector, highlighting the challenges of poor data quality, siloed departments, and rigid relational databases. It advocates the use of MongoDB for its flexibility and ability to aggregate disparate data, ultimately improving customer engagement, reducing training costs, and enabling real-time insights. Successful case studies demonstrate improved customer experiences and operational efficiencies when adopting MongoDB for a unified view of data across numerous systems.
How to deliver a Single View in Financial Services
- 1. How to deliver a Single View in Financial Services Noel Ady – Technology Strategist Jim Duffy – Enterprise Architect 22 March 2016
- 2. Agenda • Challenges • Benefits of Single View • Why MongoDB • How to Single View • Customer Success • Start Today
- 3. Poor Data Quality Many versions of the truth Data consistency between providers Data in various forms and structure No inventory of what ‘complete’ is Challenges
- 4. Department Siloes Access to data is tightly controlled Governance issues on data ownership Unclear definition of what ‘single view’ is Challenges
- 5. Pulling it all together Data lineage between systems Multiple Developer & Operational Teams Various performance capabilities across systems Challenges
- 6. • Tried with relational databases • $25M Investment without progress • Customers limited to historical data • Rigid relational schema prevented change Examples of not addressing these challenges
- 8. Customer Engagement Service more customers (One stop to get full details of the customer) meaning you can serve more customers in less time Build customer confidence through having whole information to hand with no long ‘on hold’ experience Surface information to the customer / partners via online portals and account applications. Linking customers is a complex problem a large amount of linking can be automated but there is always an element of manual confirmation and validation which sits naturally inside a Single view solution/ application A better understanding of the customer to help retain and cross sell.
- 9. Reduced training costs for new staff . A single intuitive interface often requires little or no training for new staff. Compared to multiple system training sessions for backend end operational and financial systems. Training Reduce mistakes / missed conversations or important information due to a simple and easy to use system with a single approach to reading and updating information
- 10. Support A Digital Strategy Its not only customers that are becoming more demanding when it comes to technology interaction. The millennials will be working in your organizations soon and they have greater expectations . Collaboration of team members and customers is becoming more important as business moves to digital. Customers expect to be in touch and staff need to be able to share and work together , a single view solution provides an excellent platform for these activities
- 11. Insights and Analytics Depending on how you implement your single view, having data gathered together is an excellent place to start reporting and processing your information to gain further insights Run complex algorithms to match and merge customer / entity information Having a broader view of an individual allows us to build more robust and accurate recommendation engines.
- 12. ?Why
- 13. Expressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations Relational
- 14. Scalability & Performance Always On, Global Deployments FlexibilityExpressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations NoSQL
- 15. Nexus Architecture Scalability & Performance Always On, Global Deployments FlexibilityExpressive Query Language & Secondary Indexes Strong Consistency Enterprise Management & Integrations
- 17. In It’s Simplest Form Logically this is a Consolidated source of data relating to one or more entities (often a customer) across various systems , regions and departments Customer, Policy , Product … (Often a service layer) Often complimented by an intuitive UI to allow users to search view and update Often data source is multiple sources in multiple regions from multiple systems Analytics and processing. Build intelligent models based on consolidated data and external data sources
- 18. Responsibilities for each component • Search for entities on a wide range of search criteria • View full details of an entity • Execute actions to manipulate information UI SL • Query Interface • Get Interface • Trusted Security LoB • Application workflow between entities • User notification • Manual matching and match validation • Reporting • Business Logic • Data provision • Local security • Match / Merge • Aggregation • Insights • Updates (Routing) • Authorization • Caching/ Data Store AN
- 19. Single View (Breadth and Depth) Basic Customer information (Name + Address)System D Invoicing Web Analytics Risk Evaluation System E System G System H System F System CSystem BSystem A Depth (Detailsaboutanentity) Breadth (Ability surface a wide range of entities)
- 20. Consolidating Data (Options) On Request Batch Data Sync Real-Time Data Sync Single View Single View Batch Single View Sink Pros: Real-time data view, Simple Cons: Temporal coupling Canonical Models (lossy) Performance Impact Pros: Less (manageable) Performance Impact Responsive to end user Not lossy (when using mongo) documents Cons: Data Latency Additional complexity Pros: Near real-time view of large and fast moving data Cons: Complex Real-time ‘fill’ not always 100 % (although variance is slim)
- 21. A combination Lambda. Real-Time + Batch Single View Mongo Store Speed Pros: Cons: Batch cache Batch Layer Pre- Computes Views in Store Speed layer consumes real-time data (often using a distributed cache) and aggregates Service layer combines batch and speed data on request Service
- 22. Actor Cluster Fabric High Throughput, Low Latency and Concurrency Requirements? Service Customer 145 Customer 776 Customer 998 Account 6665 Account 556 Event Sink Mongo Store Independently addressable Ability to communicate from actor to actor
- 23. Why Mongo ? { id:’A88998’, name:’Mr John Doe’, address:’56 High Street, Lincoln, UK’ accountBalance:’1768.98’, Currency:’GBP’ } { id:’A88998’, firstName:’Harry’, lastName:’’Smith’, addressLine1:’77 Baker Street’ postcode:’L88 7TH’ account:{balance:99.00, accountNo:’7789’} } Store data as close to original data as possible. Keeping as much as you can about the data. Mongo’s dynamic schema allows us to build additive data models which may grow over time as systems collect more information. Think immutable. Store new versions of the data as it changes and timestamp it. This helps in many areas: • Analytics and insights • Entity id matching • Point in time data • Auditability Mongo can cope with this amount of data. {customerId: 889998, address:’55 Smith Street’} {customerId: 889998, address:878 High Street’} {customerId: 889998, address:’77 Church Street’} {customerId: 889998, address:’34 Langdon Lane’} {customerId: 889998, address:’556 Highfield Road’} Search Data Entity Data Pre Compute Single View Service Search Retrieve Generate separate collections for the purpose of search , pre aggregate values , simplify and flatten data structures in a way that makes search easy and efficient and as a pointer to the (latest) entity data for full retrieval. Mongo allows us to do this work on the fly. Building new logic based on existing data using the aggregate framework.
- 24. Why Mongo - Automated Matching Turning multiple versions of an entity to one accurate reflection of them all Jon Smith NULL 88 Headington Close NULL Jon Smith 16th Jan 1977 89 Main Street [email protected] Problem • Complex (requires fuzzy logic, training sets, soundex , block linking techniques) • Time consuming Solution • Utilizing richer information through immutability • Ability to process at scale with the spark adapter Having the capability to link customers with accuracy is key to the success of the platform, especially as the application landscape grows. John Smith NULL 88 Headington Close [email protected] Jon Smith 15th Jan 1977 88 Headington Close [email protected] NI# JC8 89 767 55
- 25. Why Mongo …? BI Connector/ODBC Mongo Community
- 26. Manual Matching ---------------- -------------------- ------------------ ------------------- ---------------- -------------------- ------------------ ------------------- ---------------- -------------------- • Highlight potential links when viewing an entity • Search Results to show potential links and probabilities • Pre written scripts to help the user interact with a customer to link with confidence without exposing private information • Avoid the “Potential Match List”
- 27. Writing Back SerachData EntityData Pre Compute Single View Service Search Retrieve System A System B System A Ingestion Write Back Channel Commands Execute Update Commands (Avoid crud) Eventual Consistency
- 28. Single View Approach Build a breadth view across two / three key systems as a pilot / PoC. Ideally building a search view which reflects the users most common search criteria. Increase breadth and begin building out the depth for more detailed information about individual entities. Introduce manual matching within application. Introduce a write mechanism . As discussed this often means implement an asynchronous pattern based on Win “Buy-in” : Clickable prototype, presentations and marketing videos to help sell the vision and build support cross your business units. Often the business is very excited to have a view of how a cross system application will work. on eventual consistence model Build out your analytics , matching capabilities and Deeper insights into your data.
- 29. Customer Success
- 30. Single View of Customer Insurance leader generates coveted single view of customers in 90 days – “The Wall” Problem Why MongoDB ResultsProblem Solution Results No single view of customer, leading to poor customer experience and churn 145 years of policy data, 70+ systems, 24 800 numbers, 15+ front-end apps that are not integrated Spent 2 years, $25M trying build single view with Oracle – failed Built “The Wall,” pulling in disparate data and serving single view to customer service reps in real time Flexible data model to aggregate disparate data into single data store Expressive query language and secondary indexes to serve any field in real time Prototyped in 2 weeks Deployed to production in 90 days Decreased churn and improved ability to upsell/cross-sell
- 31. Mobile HR App One of largest HCP solution providers builds app for single view of HR, serving 1M+ users globally Problem Why MongoDB ResultsProblem Solution Results One of top HCM solution providers in the world; serves 1 in 6 paychecks in the US Wanted to give customers access to critical info on smartphones to live up to modern consumer expectations – mobile app for single view of HR (benefits, payroll, etc.) Needed to pull in customer data from multiple legacy source systems built on Oracle Built ADP Mobile Solutions on MongoDB, leveraging flexible data model to pull in disparate HR data High performance, mobile-friendly user experience via auto-sharding Native, cross-DC replication and automated failover for high availability Able to serve 1M users and 41K companies across 17 countries 99.999% uptime Top iOS Business App in iTunes App Store
- 32. Problem Why MongoDB ResultsProblem Solution Results Rigid relational data model inhibits agility of application development Inability to scale as new price comparison services were launched Systems down for 30 minutes during failures or maintenance Flexible data model allows company to quickly build, launch and evolve new applications Scale-out across hybrid on-prem & cloud platform, with tunable consistency to optimize performance Self-healing replica sets and multi-data center aware architecture for service availability 2x faster time to market after migrating from Microsoft SQL Server to MongoDB. Enabled continuous delivery: now pushing new features every day Greatly improved customers service by eliminating 30 minute service downtime events UK’s Leading Price Comparison Site Out-pacing Internet search giants with continuous delivery pipeline powered by microservices & Docker containers running MongoDB and Hadoop in the cloud
- 33. Problem Why MongoDB ResultsProblem Solution Results Proprietary solution with rigid data model slowed rate of new service introductions, impacting competitiveness Unable to scale as subscriber and service portfolio expanded High TCO incurred from proprietary hardware and software Built new customer data management platform on MongoDB Flexible data model enables dynamic schema modification to support new service introductions Automatic sharding to scale database as the business grows MongoDB platform scales to serve 12M customers, with 50% reduced cost per subscriber Streamlined and simplified systems allowing faster innovation and higher agility Migration to MongoDB completed in just 6 months Customer Data Mgt. Telco leader unifies customer experience, driving 50% lower cost and reduced churn
- 34. Personalization Built personalization engine in 25% the time with 50% the team Problem Why MongoDB ResultsProblem Solution Results Needed personalization server that acts as the master storage for customer data. Originally built on Oracle (over 14 months) but it performed below expectations, did not scale, and cost too much New requirements made Oracle unusable – 40% more data, must reload entire data warehouse (22M customers) daily in small window – could not be met with Oracle Implemented on MongoDB, using flexible data model to easily bring in data from disparate customer data source systems Expressive query language made it possible to access customer records using any field Consulting and support significantly reduced upfront development and deployment costs New version of personalization engine was built on MongoDB in 25% the time with 50% the team Led to performance boosts of more than a magnitude Storage requirements decreased by 66%, lowering infrastructure costs
- 35. Problem Why MongoDB Results Problem Solution Results AXA Banque needed to differentiate themselves in the the retail banking space by offering a 100% mobile experience Reaching the “digital native” demographic required new tools and approaches The solution must be able to absorb large peak loads and true 24/7/365 availability “We were quickly convinced that MongoDB's open-source NoSQL model was the best choice” Pascal Lozovoy CIO AXA Banque Mobile application is capable of absorbing large amounts of unstructured data with ease Seamless integration with existing banking platform on AS400 mainframe is achieved using Java and web services SooN successful launch Jan 2014 now has thousands of users New functionality is quickly developed and released to the public Zero interruption of service despite not limiting what users can upload Mobile Banking Platform AXA Banque uses MongoDB to power “SooN” their innovative mobile banking platform
- 37. MongoDB Use Cases Single View Internet of Things Mobile Real-Time Analytics Catalog Personalization Content Management
- 38. Schedule a Discovery or Scoping workshop Work with our experts to define your roadmap for Single View
Editor's Notes
- #14: A lot of people expect us to come in and bash relational database or say we don’t think they’re good. And that’s simply not true. Relational databases has laid the foundation for what you’d want out of a database, and we absolutely think there are capabilities that remain critical today Expressive query language & secondary Indexes. Users should be able to access and manipulate their data in sophisticated ways – and you need a query language that let’s you do all that out of the box. Indexes are a critical part of providing efficient access to data. We believe these are table stakes for a database. Strong consistency. Strong consistency has become second nature for how we think about building applications, and for good reason. The database should always provide access to the most up-to-date copy of the data. Strong consistency is the right way to design a database. Enterprise Management and Integrations. Finally, databases are just one piece of the puzzle, and they need to fit into the enterprise IT stack. Organizations need a database that can be secured, monitored, automated, and integrated with their existing IT infrastructure and staff, such as operations teams, DBAs, and data analysts.
- #15: Because the relational database was not designed for modern applications, starting about 10 years ago a number of companies began to build their own databases that are fundamentally different. The market calls these NoSQL. NoSQL databases were designed for this new world… Flexibility. All of them have some kind of flexible data model to allow for faster iteration and to accommodate the data we see dominating modern applications. While they all have different approaches, what they have in common is they want to be more flexible. Scalability + Performance. Similarly, they were all built with a focus on scalability, so they all include some form of sharding or partitioning. And they're all designed to deliver great performance. Some are better at reads, some are better at writes, but more or less they all strive to have better performance than a relational database. Always-On Global Deployments. Lastly, NoSQL databases are designed for highly available systems that provide a consistent, high quality experience for users all over the world. They are designed to run on many computers, and they include replication to automatically synchronize the data across servers, racks, and data centers. However, when you take a closer look at these NoSQL systems, it turns out they have thrown out the baby with the bathwater. They have sacrificed the core database capabilities you’ve come to expect and rely on in order to build fully functional apps, like rich querying and secondary indexes, strong consistency, and enterprise management.
- #16: MongoDB was built to address the way the world has changed while preserving the core database capabilities required to build modern applications. Our vision is to leverage the work that Oracle and others have done over the last 40 years to make relational databases what they are today, and to take the reins from here. We pick up where they left off, incorporating the work that internet pioneers like Google and Amazon did to address the requirements of modern applications. MongoDB is the only database that harnesses the innovations of NoSQL and maintains the foundation of relational databases – and we call this our Nexus Architecture.
- #31: Metlife Industry: Insurance, Financial Services Use Case: Single View
- #32: -rigid schema impossible to keep pace with change --- Flexible model, future proofed --- build in resiliency ------ Truly global deployment ------ 5x 9's and on the app store
- #33: - rigid relational model - 30 minute downtime planned and unplanned --- self-healing cluster, no downtime --- hybrid deplotment model ------ 2x faster time to market ------ no more downtime and cost assiciated with it
- #34: - rigid data model - High TCO of closed source tech --- automatic sharding for scaling --- future proof infra and data model ------ 50% reduced cost per subscriber ------ 6 months from design to production
- #35: - 14 months spent on Oracle, solution was not viable - not able to handle current data demands --- Expressive query language for rich data access --- consulting partnership accelerated deployment ------ solution built in 25% the time with 50% the team ------ 66% less storage costs
- #36: - 100% digital, competitive retail market - 24/7/365 --- quote --- integration with AS400 ------ long time customer, growing with us, flexible solution ------ no downtime