MongoDB for the non-technologist – It is not just what we make, it is what we make possible !

I borrowed the title from an inspiring Intel slogan from 2008. http://www.intel.com/content/www/us/en/history/history-2008-annual-report.html

How exactly does someone choose one database over another?

That of course depends on who the “someone” is – the answer differs whether you are a developer, and ops person, an architect, an executive or an end user. If you are a developer , an ops person , a consultant or another kind of IT expert, and you are reading this – you probably already know why you chose MongoDB over other databases. Your next step is probably to convince someone else on “why MongoDB “ . And typically that person does not come with deep technical background like you do.

A good part of my job is to explain to our partners and customers what is new and different with MongoDB – in non technical terms . And having done that a few times now – I thought maybe it is worth typing it into a blog post and get some feedback from my readers . So here is my attempt – I am happy to explain more, answer your questions and accept and fix any flaws in my current thinking .

I think one of the best ways to explain a database to a non technical user is to explain what kind of apps can be powered by it, how it will help the business and their day to day life.
It is not just what we make – its what we make possible with MongoDB that drives the massive adoption (Did you know that there are about ten thousand downloads of MongoDB every day now?)

So, what are the three biggest challenges that an IT organization faces today ?

1. Keeping pace with the business that seemingly changes its requirements every day.

It is not as if IT wants to say NO to every request that comes its way – it is frustrating to explain to a business user that “ can you add just this one field to capture this attribute?” is not like adding a column to an excel spreadsheet and altering a formula or two. Coming to think of it – I know many analysts at my past clients who will not alter their complex spreadsheets for fear that something will get messed up. Yet the same folks hate it when their IT colleagues say NO to their change requests. You have to change the data model, update information, change code in multiple places and there is a high risk of something else going wrong while you were adding “just one field to the screen”. So IT pushes back and introduces increasingly complex governance procedures , which further frustrates the business users. Some version of this story plays out every day in companies all over the world. There are tables that hold billions of lines – like sales orders, financial document line items etc where “just one field” to be changed takes months to fully implement.

RDBMS has many benefits – but to make use of it, you need to agree upfront to a given schema and then try everything possible to not change it after you start coding and loading data. I once worked in a project where an extra column in a table that is in production needed the approval of the CIO of that $40 Billion annual revenue company. With its dynamic schema (thanks to JSON) – MongoDB is a lot more flexible . You can tweak your schema as you learn more about data. This is not to say that there needs to be no schema design at all. It just means that you have a lot more ability to respond to changing requirements as projects progress. Bottom line – You don’t need to say NO as many times to business anymore.

2. Ability to start small and expand when needed

There are very few companies today that have an IT budget that is growing every year . Capital intensive projects go through increasing levels of budget scrutiny – and for good reasons . One of the reasons for this is the “scale up” requirements of many databases. Scale out is typically cheaper than scale up – it takes less money to daisy chain several small servers than buy one big server. But if the database does not scale out well – your hands are forced into buying a big server upfront and not optimally using it for significant periods in time. MongoDB takes this problem away – you can start small and expand footprint over time. I should add here that before you scale massively – some significant thought needs to be put into deciding the best sharding key .

The same holds true for skills. Developer productivity is an important core aspect to MongoDB design. There is practically a driver for every possible development language out there – java, javascript etc. This means you can get started on MongoDB with your existing skills and very little training. In my own case, it took me less than 30 minutes to download MongoDB (http://www.mongodb.org/downloads and http://docs.mongodb.org/ecosystem/drivers/ ) and write a hello world . There is a vibrant community of developers who help each other on the technology – and there is world class online education (and traditional class room training too in case someone prefers that).

3. The need to standardize on limited number of technologies

IT landscapes are heterogeneous in nature. While that is hard to change – most companies prefer to standardize on as few technologies as possible. This is especially true for the lowest levels of the stack like Hardware, OS and database .

Once the decision to treat a database as standard is made – the team gets used to thinking “why not the standard?” when new applications need to be built. There will always be some applications (say 20% of the total apps) that are clear candidates for RDBMS – like the complex ERP like transactions. There will be another similar set of apps (say another 20%) that are obviously great use cases for MongoDB. That leaves about 60% of apps that could go either way. Typically the “why not the standard we chose” thinking will impact this important decision that has really big long term impact.

Standardization on as few platforms as possible is definitely a good thing to do – as long as the project team knows what were the use cases that were used to determine the standard platform when the decision was originally made. Many of those decisions would have been made in the past where the requirements facing an organization today couldn’t have been possibly considered ( say like handling sensor data or needing projects to deliver into production every week or every month instead of once a year).

Database is one of those layers where there was hardly any revolutionary changes done for decades. So these platform choices didn’t have to revisited by few generations of project teams. But that is not the case today. With MongoDB, Hadoop and similar technologies – there are modern ways of satisfying the data requirements better, faster and cheaper.
MongoDB is a general purpose database – a technology that can solve a variety of use cases. Check out a small sample of these use cases here http://www.mongodb.org/about/production-deployments/ .

Platform standardization decisions are not only about technology differentiators alone. An equally important part is the ease of doing business with the platform vendor. At MongoDB – we want to be the easiest vendor for our customers and partners to do business with. We believe in complete transparency – like putting our subscription pricing and discounting information on public domain. https://www.mongodb.com/products/subscriptions/pricing . I wonder how many traditional database vendors can do business with this level of transparency .

So , that is what we make possible at MongoDB – we want to make working with the technology and working with us as a business partner as successful , frictionless and transparent as possible . Everything else is secondary !