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 !

About these ads

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

  1. Reblogged this on Thoughts, Theories, Facts, and Notions and commented:
    Vijay,

    I like your idea of making Mongo more understandable. I know I struggled with it at first. I’ve always had very strong ideas about DB structures. I so agree on the flexibility. It is both exciting and scary at the same time. As a DBA, what am I going to do if I can’t go around telling people NO and how hard my job is when they want to make a change. While I do jest, it is a significant change. A few comments, as you know I would.

    Please don’t borrow slogans. It makes you into follower. There are hundreds of ideas along the same line. I always loved the GE one “we bring good things to light.” The double meaning is brilliant. That is what is marvelous about the English language. The real cloud database. An agile database that supporting your inspirations. A DB at the speed of cloud, thought, ideas, inspiration, etc. Give me a call and we can bounce a few ideas.

    On the standardization, you failed to mention the why. We standardize to lower complexity and cost. We diversify, creating heterogeneity, because new capabilities come into existence. The computer, and especially the software world, grow exponentially, so there is a universe of temptation out there and more arriving tomorrow. It is every CIO’s constant problem. It is why we drown in a sea of business cases trying to solve the equation where even the constants are changing.

    Regardless, good luck at Mongo and it is really cool product. I just have to find an excuse to play with it and better yet put it into a project. I’d like to be the DBA who gets to say “yes” for a change.

  2. Really nice blog. If you need to rate hana as a database (I know its not just a database) & also rate mangodb say out of 10 …how would you rate? Was also wondering if there is some interesting story behind name “mango”db.

    • Hana and MongoDB are not comparable on most dimensions . For ERP or BW database , Hana is awesome and MongoDB is not going to work at all . In other cases where data from various sources need to be combined for one view – like a customer 360 – MongoDB is more efficient to use . In most cases I think they are complimentary

      Also – it is not mAngoDB – it is MongoDB (O not A) . Mongo comes from the word humongous .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s