2018 MongoDB Innovation Award Winners

Marissa Chieco
June 20, 2018 | Updated: July 10, 2018
#Customer Stories#Events

We received an overwhelming number of nominations for the fifth annual MongoDB Innovation Awards, recognizing companies who are using MongoDB to dream big and deliver incredibly bold, innovative solutions that are moving forward industries and changing lives for the better.

We are thrilled to announce our 12 winners who will be honored at MongoDB World, New York, June 26 and 27.

See the full list and read a bit more about how they are disrupting the status quo here:

Global Go to Market Partner of the Year: Accenture

Accenture is a leading global professional services company, providing a broad range of services and solutions strategy, consulting, digital, technology and operations. Combining unmatched experience and specialized skills across more than 40 industries and all business functions, Accenture works at the intersection of business and technology to help clients improve their performance and create sustainable value for their stakeholders. The company partners with more than three-quarters of the Fortune Global 500, driving innovation to improve the way the world works and lives. Accenture and MongoDB have worked together to help organizations leverage the power of data to gain a competitive edge.



The Enterprise: Charles Schwab

Charles Schwab is one of the largest financial services firms in the United States. To improve customer experience, speed up development cycles, and prepare for cloud portability, Charles Schwab is modernizing a significant portion of its applications by migrating to MongoDB-powered microservices. Multiple applications are built on MongoDB, including an authentication app leveraged by retail customers as well as a portfolio management solution utilized by registered investment advisors.



Launch Fast: Coinbase

Coinbase is dedicated to creating an open financial system for the world and defining what the future of finance will look like. To do this, they built the most trusted and regulatory compliant global cryptocurrency trading platform to broker exchanges of Bitcoin, Bitcoin Cash, Ethereum and Litecoin as well as pioneering cryptocurrency indexes and institutional cryptocurrency trading. In 2017, they experienced exponential growth with over 20M+ users and $150B+ being traded on their platform in over 190 countries. The Coinbase engineering team scaled and optimized MongoDB to respond to this unprecedented volume of traffic and to prepare for future waves of cryptocurrency enthusiasm.



Scale: Epic Games

Epic Games develops cutting-edge games and cross-platform gaming engine technology. Their massively popular, multi-platform game, Fortnite, has been played by more than 125 million gamers around the globe. The Epic team has implemented a number of best practices and performance improvements to get the best scaling and availability characteristics out of MongoDB.



Data-Driven Business: Freddie Mac

Freddie Mac set out to modernize a number of applications that were previously built on legacy relational databases. One mission-critical application, a property appraisal tool, held massive amounts of property and loan information, but was increasingly expensive and time consuming to update. Turning to MongoDB, Freddie Mac was able to collect information from a variety of different sources in a variety of formats to build a single view of all the information needed to accurately appraise a property. In the months since using MongoDB, Freddie Mac has seen an increase in developer productivity.



Customer Experience: Fresenius Medical Care North America

Fresenius Medical Care North America is the premier health care company focused on providing the highest quality care to people with renal and other chronic conditions. Through its industry-leading network of dialysis facilities, outpatient cardiac and vascular labs, and urgent care centers Fresenius Medical Care North America (FMCNA) provides coordinated health care services at pivotal care points for hundreds of thousands of chronically ill customers throughout the continent.

Since 2015, FMCNA has used MongoDB Enterprise Advanced for a variety of projects to help support their mission to deliver superior care that improves the quality of life of every patient. These projects have included analytics platforms, a data lake and the FHIR platform (a healthcare standard for exchanging medical records securely and at scale). However, the most impactful application has been a single view of the patient platform built on MongoDB. This platform brings together a variety of data sources to ensure the patient, doctors and other caregivers all have a complete understanding of the treatments required and can make adjustments with confidence.



Healthcare: Genomics England

Genomics England, a company owned by the UK government's Department of Health and Social Care, is working with the NHS to sequence 100,000 genomes from patients with rare diseases and their families, as well as patients with common cancer. In the future, there may be a diagnosis where there wasn't one before and, in time, there is the potential of new and more effective personalized treatments for patients.

On average, 1,000 genomes are sequenced per week, which amounts to around 10 terabytes of data per day. To manage this immense and sensitive data set as well as power the data science that makes it all possible, Genomics England used MongoDB Enterprise Advanced. The partnership with MongoDB allows the processing time for complex queries to be reduced from hours to milliseconds, which means scientists can discover new insights more quickly.



Internet of Things: Humana Inc.

With a variety of applications built on MongoDB, Humana is changing healthcare for the better. One of their IoT applications called Go365 is a corporate wellness and rewards program which helps employees live healthier lives, which in turn increases productivity and reduces overall health claims costs for employers. Go365 features a personalized program that inspires, supports, and rewards members for taking steps to improve and continue healthy behavior. Users are able to compete in challenges, connect their fitness devices and mobile apps to log healthy activities and earn points, reward themselves through the Go365 Mall, and track their progress. In fact, by year 3, people who engaged with the program saw that the cost of their health claims were reduced by over 10%, relative to those of unengaged members.



Delivery Partner of the Year: Infosys

A perennial winner, this is the third year in a row Infosys has won a MongoDB Innovation Award. As a global leader in consulting, technology and next-generation services, this year Infosys has been working closely with MongoDB to accelerate application modernization for client organizations. A key part of this is the joint delivery of single view and mainframe modernization offerings to migrate and digitize business-critical applications away from rigid tabular databases and on to next-generation technology. In this long standing partnership, Infosys and MongoDB are already helping many large enterprises with renewing and modernizing their IT landscape.



The William Zola Award for Community Excellence: Ken W. Alger

Ken Alger is one of the most prolific bloggers on MongoDB's technology with dozens of posts in the past two years. He is a self-taught programmer and a teacher at Treehouse. An avid follower of open-source, he has previously sat on the board of directors of the Django Software Foundation. He is delighted to share his extensive MongoDB knowledge via his blog, Twitter, and his GitHub account. He exemplifies the true community spirit of MongoDB and The William Zola Award for Community Excellence.



Savvy Startup: Radar

Radar, a seed-stage startup and member of the MongoDB Startup Accelerator program, has built iOS and Android SDKs on MongoDB Atlas and AWS. As the location platform for modern apps, Radar allows developers to easily add location context and tracking to their applications. Radar currently runs on more than 25 million devices around the globe, processing billions of locations each week.



Atlas: 7-Eleven

7-Eleven is continuing to redefine what convenience is. By leveraging MongoDB Atlas on AWS and a microservices architecture, 7-Eleven has built an e-commerce application called 7-Now which allows consumers to browse a product catalog connected to their local store’s inventory, make purchases on their mobile phones, and schedule in-store pick up or delivery through services like Postmates. This application not only streamlines the consumer’s experience, but also gives the 7-Eleven team extensive analytics capabilities allowing them to improve the overall customer experience. This is sure to have a major impact in their 10,000 stores in the US and Canada, and with 60% of the US population living within one mile of a 7-Eleven.

← Previous

Scaling Your Replica Set: Non-Blocking Secondary Reads in MongoDB 4.0

MongoDB 4.0 adds the ability to read from secondaries while replication is simultaneously processing writes. To see why this is new and important let's look at secondary read behavior in versions prior to 4.0. Background From the outset MongoDB has been designed so that when you have sequences of writes on the primary, each of the secondary nodes must show the writes in the same order. If you change field "A" in a document and then change field "B", it is not possible to see that document with changed field "B" and not changed field "A". Eventually consistent systems allow you to see it, but MongoDB does not, and never has. On secondary nodes, we apply writes in batches, because applying them sequentially would likely cause secondaries to fall behind the primary. When writes are applied in batches, we must block reads so that applications cannot see data applied in the "wrong" order. This is why when reading from secondaries, periodically the readers have to wait for replication batches to be applied. The heavier the write load, the more likely that your secondary reads will have these occasional "pauses", impacting your latency metrics. Given that applications frequently use secondary reads to reduce the latency of queries (for example when they use "nearest" readPreference ) having to wait for replication batches to be applied defeats the goal of getting lowest latency on your reads. In addition to readers having to wait for replication batch writes to finish, the writing of batches needs a lock that requires all reads to complete before it can be taken. That means that in the presence of high number of reads, the replication writes can start lagging – an issue that is compounded when chain replication is enabled. What was our goal in MongoDB 4.0? Our goal was to allow reads during oplog application to decrease read latency and secondary lag, and increase maximum throughput of the replica set. For replica sets with a high write load, not having to wait for readers between applying oplog batches allows for lower lag and quicker confirmation of majority writes, resulting in less cache pressure on the primary and better performance overall. How did we do it? Starting with MongoDB 4.0 we took advantage of the fact that we implemented support for timestamps in the storage engine, which allows transactions to get a consistent view of data at a specific "cluster time". For more details about this see the video: WiredTiger timestamps . Secondary reads can now also take advantage of the snapshots, by reading from the latest consistent snapshot prior to the current replication batch that's being applied. Reading from that snapshot guarantees a consistent view of the data, and since applying current replication batch doesn't change these earlier records, we can now relax the replication lock and allow all these secondary reads at the same time the writes are happening. How much difference does this make? A lot! The range of performance improvements for throughput could range from none (if you were not impacted by the replication lock - that is your write load is relatively low) to 2X. Most importantly, this improves latency for secondary reads – for those who use readPreference "nearest" because they want to reduce latency from the application to the database – this feature means their latency in the database will also be as low as possible. We saw significant improvement in 95 and 99th percentile latency in these tests. Thread levels 8 16 32 64 Feature off 1 2 3 5 Feature on 0 1 1 0 95th percentile read latency (ms) Best part of this new feature? You don't need to do anything to enable it or opt-into it. All secondary reads in 4.0 will read from snapshot without waiting for replication writes. This is just one of a number of great new features coming in MongoDB 4.0. Take a look at our blog on the 4.0 release candidate to learn more . And don’t forget, you’ve still got time to register for MongoDB World where you can meet with the engineers who are building all of these great new features.

June 14, 2018
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024