Enabling Extreme Agility At The Gap With MongoDB
The Gap's creative director insists that "Fashion is...about instinct and gut reaction." In the competitive world of retail, that "instinct" has been set to fast forward as Gap seeks to outpace fast-fashion retailers and other trends that constantly push Gap and other retailers to meet consumer needs, faster. As boring as it may seem, Gap's purchase order management system really, really matters in ensuring it can quickly evolve to meet consumer tastes. Unable to meet business agility requirements using traditional relational databases, Gap uses MongoDB for a wide range of supply chain systems, including various master data management, inventory and logistics functions, including purchase order management. Collecting Money From Happy Customers This is no small feat given Gap's size. The Gap is a global specialty retailer offering clothing, accessories and personal care products for men, women, children and babies. With nearly 134,000 employees and almost 3,200 company-operated stores and an additional 400 franchise stores, fashion-conscious consumers can find The Gap around the world. And they do, spending over $16 billion annually on Gap's latest track pant, indigo-washed jeans and racerback tanks. That's both the good news and the bad news, as presented by Gap consultant Ryan Murray at MongoDB World. Good, because it means Gap, more than anyone else, dresses America and, increasingly, the world. Bad, because at its scale change can be hard. Square Pegs, Round Holes And Purchase Orders Even something simple like a purchase order can have a huge impact on a company like Gap. A purchase order is a rich business object that contains various pieces of information (item type, color, price, vendor information, shipping information, etc.). A purchase order at Gap can be an order to a vendor to produce a certain article of clothing. The critical thing is that the business thinks about the order as a single entity, while Gap's RDBMS broke up the purchase order into a variety of rows, columns and tables, joined together. Not very intuitive. While this may seem like a small thing, as Murray points out, the RDBMS "forced [developers] to shift away from the business concept-- what is a purchase order and what are the business rules and capabilities around it-- and shift gears into 'How do I make this technology work for me and help me solve a business problem?' [mode of thinking]. And that destroys flow." Developers may be more technical than the rest of us, Gap wanted its developers helping to build its business , not merely its technology. Murray continues: "We don't want the developer having to work with the impedance mismatch between the business concept that they're trying to solve for and the technology they're using to solve it." Enabling Supply Chain Agility By Improving Developer Productivity As such, Gap realized it needed to evolve how it manages inventory and its vendors. It turned to MongoDB because it was able to easily make sense of data that comes in different shapes, which it needed to store quickly and transparently in Gap's database. MongoDB, in short, helped Gap become much more agile and, hence, far more competitive. One way Gap managed this was by moving from a monolithic application architecture to a microservices-based approach. The traditional model for building applications has typically been as large monoliths. In this case, that meant the PO system was one, big code base that handled everything related to a PO, whether that was handling demand from the planning systems and creating those purchase orders or simply handling how the purchase orders actually integrate to other systems and get down to the vendors. All of those things are actually fairly independent of each other, but the code base to manage it was monstrously big and monolithic. Instead Murray and team introduced the concept of the microservice, a service dedicated to one business capability. For example, a microservice could handle communicating out to the vendors by EDI or whatever technology that a new purchase order has been registered. It turns out that MongoDB is perfect for such microservices because it's so simple and lightweight, Murray notes. Gap uses MongoDB to power these single service and to connect them together. Each of these services lines up with a business function. Developers can work on separate microservices without bumping into or waiting on each other, as is common in a monolithic architecture. This enables them to be far more productive; to work much faster. MongoDB As An "Extreme Enabler Of Agile Development" In this and other ways, Murray lauds MongoDB as “an extreme enabler of agile development”, or iterative development. Waxing rhapsodic, Murray continues: MongoDB allow[s our developers] to essentially forget about the storage layer that's underneath and just get work done. As the business evolves, the concept of a purchase order as an aggregate concept will also change as they add fields to it. MongoDB gets out of the way. [Developers] drop a collection, start up new code over that database, and MongoDB accepts whatever they throw at it. Again, developers don't have to stop, break the context of solving the business problem, and get back to what they're doing. They simply get to focus on the business problem. And so as an agile enabler, as an enabler of developers to work fast and smart, MongoDB do is extremely useful. As just one example, Gap was able to develop this new MongoDB-based purchase order system in just 75 days, a record for the company. In true agile fashion, MongoDB enables Gap to continue to iterate on the system. Five months in, the business wanted to track in a dashboard style the life of a purchase order. With MongoDB, that business requirement turned out to almost require no development effort. Murray and team were able to add new types of purchase orders and have them easily coexist with old purchase orders in the same collection and keep moving. Not in months. Or weeks. But rather each day the development team was able to show the business what that feature might look like because of MongoDB's flexibility. All of which makes Murray and his team at Gap so happy to work with MongoDB. "Software is ultimately about people," he insists, and giving developers software like MongoDB that they love to use makes them happy and productive. And agile. **Sign up to receive videos and content from MongoDB World.** MktoForms2.loadForm("//app-abk.marketo.com", "017-HGS-593", 1151);
Best Of Both Worlds: Genentech Accelerates Drug Research With MongoDB & Oracle
“Every day we can reduce the time it takes to introduce a new drug can have a big difference on our patients,” said Doug Garrett, Software Engineer at Genentech. Genentech Research and Early Development (gRED) develops drugs for significant unmet medical needs. A critical component of this effort is the ability to provide investigators with new genetic strains of animals so as to understand the cause of diseases and to test new drugs. As genetic testing has both increased and become more complex, Genentech has focused on redeveloping the Genetic Analysis Lab system to reduce the time needed to introduce new lab instruments. MongoDB is at the heart of this initiative, which captures the variety of data generated by genetic tests and integrates it with Genentech's existing Oracle RDBMS environment. MongoDB’s flexible schema and ability to easily integrate with existing Oracle RDBMS has helped Genentech to reduce development from months to weeks or even days, significantly accelerating drug research. “Every day we can reduce the time it takes to introduce a new drug can have a big difference on our patients,” said Doug Garrett, Software Engineer at Genentech. Previously, the Genentech team needed to change the schema every time they introduced a new lab instrument, which held up research by three to six months, and sometimes even longer. At the same time, the database was becoming more difficult to support and maintain. The MongoDB redesign delivered immediate results. In just one example, adding a new genetic test instrument (a new loader) had zero impact on the database schema and allowed Genentech to continue with research after just three weeks, instead of the standard three to six-month delay. MongoDB also makes it possible for Genentech to load more data than in the past, which fits in well with the “collect now, analyze later” model, something he noted MongoDB co-founder Dwight Merriman has often suggested . Said Garrett: “Even if we don’t know if we need the data, the cost is practically zero and we can do it without any programming changes, so why not collect as much as we can?” To see all MongoDB World presentations, visit the [MongoDB World Presentations](https://www.mongodb.com/mongodb-world/presentations) page.
MongoDB Case Study: foursquare
Foursquare is a location-based social network which has grown rapidly since its inception in 2009, requiring efficient ways to scale with limited engineering resources. As its user profile and activity stream data increased, foursquare made the strategic decision to migrate storage of venues and check-ins to MongoDB as a long-term scalable solution to the company's continued expansion. Originally, the foursquare application relied on a single relational database. As the company experienced rapid growth, they split the data to two nodes: one for check-ins (the biggest data set) and one for everything else. However, it was clear that in time, check-ins alone would increase beyond what a single machine could handle. MongoDB not only solved the initial problem, but also provided the tools for agile development. Foursquare can now take advantage of MongoDB's built-in auto-sharding. MongoDB’s auto-sharding partitions the database, allowing foursquare to scale writes and spin up new nodes as their application grows. Instead of writing its own sharding layer, foursquare can rely on MongoDB’s automated scaling infrastructure, enabling engineers to focus on building their application. MongoDB has allowed foursquare it to dramatically simplify its data model. For instance, rather than storing tags (“has wifi”, “great for dates”, “hotspot”, etc) in a separate table, in MongoDB tags are embedded directly into the document representing a venue. This is both more efficient at run-time and easier for engineers to understand and manipulate. As Harry Heymann, Lead Server Engineer at foursquare, explained, ...MongoDB is a practical database for practical problems that engineers in the real world have…it's only going to continue to evolve into a database that just makes our jobs easier as application developers, which is fantastic.” To learn more, visit the case study or hear directly from Heymann about how MongoDB has made a difference at foursquare. Tagged with: mongodb, foursquare, agile development, big data, nosql, 10gen