Does anyone have a better name handy to call “NoSQL” ?


Today marks my one month anniversary at MongoDB – time just flew by , and I am having a great time . If there is one frustration with my new gig – it is the term “NoSQL”. This term provides nothing but grief . Does anyone have a better name handy ?

To begin with , SQL is not going anywhere . There are some use cases – like the complex transactions in an ERP system – where SQL is an excellent fit . So the idea of NoSQL is more of “not JUST SQL”. The term is like the grand daddy of all nuances.

If we think of all possible things that need a database in it , I think about 20% or so might always need SQL . And another 20% will always need one of the solutions loosely classified as NoSQL . The true issue is – what about the rest of the 60% ?

In general – depending on the skills of a project team, these 60% can be done in either SQL or NoSQL with different trade offs . When I joined MongoDB, I rationalized in my mind that vast majority of that middle 60% would lean towards NoSQL . You can take your own percentage of course depending on your world view 🙂

Now within this NoSQL space , there is plenty of variety too . MongoDB for example is what is called a document database – given the JSON/BSON nature of holding the data. You wouldn’t believe how many times I have been asked whether MongoDB is a solution for storing documents like word and PDF files ! Of course MongoDB can store all kinds of files – pictures too – and it is great for content management applications . But that is just one of say 10 categories of use cases this database can do .

And once I explain the JSON document story – the invariable follow up question is “oh what is the big deal there – doesn’t your competitor do it too?” . Yes there are other solutions out there that can use JSON – there are ones built on XML too . However, the nuance that gets missed is that everyone handles it differently . Some just store it as a BLOB associated with a key , unlike how MongoDB handles it .

So clearly – the “document database” term is not exactly helpful either . A combination of just plain misunderstanding , and some marketing misadventures have made sure that neither NoSQL nor document databases clarify exactly how these various databases differ .

The JSON discussion with anyone who has written a SQL query once in their life usually results in the gotcha moment “oh – so you can’t do Joins in your cool new technology . You do know we can’t live without it right?”. It’s a simple yes or no question in the mind of the person – and they know the right answer . I am now researching history now to find what Henry Ford must have answered to people who asked him ” so what kind of horse whip goes with this car thingy that you are selling?” 🙂

Then I have attempted to explain MongoDB using the Gartner 3V model – which a lot of people already relate to due to the big data hype . So I say things along the lines of “Variety” is the key V that differentiates MongoDB . That doesn’t always cut it – I am tempted to use another V – for “Versalitily”, to point out the differentiating features . But here as a matter of principle – and out of respect for Doug Laney and Gartner – I won’t hijack the original 3V model . Just like I don’t like the original 4Ps of marketing mix being changed . Those models are all fine – we just need to resist the urge to change them for our random interests .

By the way – Is Hadoop considered NoSQL ? Yes ? No? Yes?

I don’t know really. It’s a personal taste thing I guess . There are plenty of initiatives in and around Hadoop to make it more SQL friendly . I can’t really say where one could draw a line .

There are plenty of people who have asked me if MongoDB is another NoSQL system like Hadoop . It always makes me stop in my tracks . How exactly should I answer that ?

To begin with – I don’t know whether Hadoop should be in NoSQL category . Then there is the fact that MongoDB has complimentary features to Hadoop – and is not competitive to Hadoop (despite having some similarities like MapReduce and an aggregation framework). So I can say yes or no and make it sound credible – or I can smile, or I can roll my eyes , or do a combination of all of these things . I also tend to remember the joke about a lawyer asking an accused “Do you still beat your wife every night?” . Yes ? No? Yes?

It’s no big deal really – but if anyone has any bright ideas on a new name to replace NoSQL , please share . You will have my eternal gratitude and I will buy you a pitcher of beer when we meet . Please , please . Pretty please ?

Root Cause Analysis – it needs a grain of salt


Vast amounts of time and resources are spent in the corporate world in what is called “root cause analysis” (or RCA for short). I have done my fair share – countless spreadsheets and PPT decks have been created by me too like most of you who are reading this . And from the time I was in engineering college to today , I have read a lot of books, white papers and blogs on this topic . I have asked my team to do root cause analysis countless times – at least occasionally in a mindless fashion.

And I have to say this – skills and luck are both needed to do a decent job . It’s more art and less science – and it will take a lot to convince me otherwise.

Here is something I once ran into at the beginning of my career . An incoming high value sales order EDI document failed to post in the ERP system . It was the second time in one week that this happened and the customer ordered a root cause analysis – and finally it was me who had to do it at the bottom of the hierarchy . It took me all of 10 minutes to find that the translation system had wrong mapping for a field or two . It took a day to work with that vendor to change the map . We didn’t see the problem for a good while after that . My ability to analyze was praised – and although I didn’t get a raise , I did get some lovely emails and all that .

And then at a party few days later, I was introduced to a VP at the customer. He thanked me profusely and said the business impact was pretty high for missing the order twice . He also asked me if I thought EDI was the wrong medium for an order of that high a value . His other question was whether the contract with my employer had any SLA’s based on business impact . I had never thought of that angle – and in all honesty I told him I can’t answer it . My boss picked it up from there – except, 15 years or so later I haven’t forgotten the incident .

1. There is seldom “A” root cause

I – and many others – assume there is this one clean reason why something (bad) happened . There is never one reason . It’s always a combination of reasons . ( I can’t resist the temptation of saying it is like a nested JSON structure in a document database than the near rows and columns of a relational table )

2. It’s not repeatable for the most part

The way I do root cause analysis is not how someone else does it . More often than not – you will get different causes if you ask two persons to do RCA .

And it will cost an arm and a leg to come up with MECE answers ( MECE is what consultants learn in their bootcamps – mutually exclusive, collectively exhaustive) . And even at that cost – it might not be MECE after all.

3. Asking “Why” 5 times doesn’t solve it either

Asking “Why” is necessary – but to the best I can jog my memory , I can’t remember one incident where I exactly asked it 5 times to get to the root cause(s). It is an arbitrary number that on occasion might be 5.

To begin with, you can’t ask the right “why” questions about things you don’t know at a deep enough level even if all data is available . When programs fail and we debug and look at logs – it makes sense only if we understand correctly what we are looking at . A C programmer might not be the best to analyze a Unix dump .

Asking too many “why” questions is also counter productive from a time and budget perspective – you can only bark up so many trees at a time before the cows come home 🙂

4. You can’t always determine cause and effect

What we find as root cause might be the effect of another cause . It almost always is the case . It’s like a recursive function which can’t get out of itself .

Over a few beers, a friend and I were once discussing the root cause for the poor performance of an application we had coded . I will spare you the many colorful details (all very logical if I might say so) – but by the time we left the bar , it was crystal clear that the reason for sub par performance of the code could be traced back to some traumatic childhood experiences of a common friend .

Parting comment – set the right expectations before you dive into root cause analysis . Make peace with the fact that most probably you can only treat some symptoms , and over time and with luck on your side – you will solve enough symptoms and some causes to make things work at a decent level .

RCA is a dish that always needs some salt – some times a grain , and at other times a pound . I will leave you with that .

Looking back and forward on the same day


So it’s my birthday – and my mind is oscillating furiously between being too old and not growing up fast enough . It’s a strange feeling !

20140423-085658.jpg

the boat that my 9 year old daughter made for my birthday

On one hand – I do feel rather old . I work in a company where vast majority of people I run into are smart, good looking twenty somethings. At a company party, in my first week there , I heard a woman colleague lamenting that she can’t keep up with the young crowd . So I asked her how old she was – and her answer was 29 ! I nearly broke down in tears ( and under my breath said something like – “shoot me dead now – actually poke me in both eyes before you shoot me, and drop kick me as I fall” 🙂

And yet – talking to several friends my age and older who continue to work at large companies , and not all of them are thrilled with their status quo but for their own reasons they can’t move out – I feel like the young guy with free
spirit 🙂

Ok that was a stretch – practically no one equates me with free spirit , but hey it’s my blog and I am going to take some blogger’s license here .

When I finished my MBA – I had a clear plan for retiring at 35. 35 came and went and I am nowhere close to retirement – which made it rather depressing , but I wrote it off as my MBA naïveté . Now I am firmly convinced that I don’t ever want to retire – I think I will go nuts and will drive my family nuts if I do . What I need is periodic vacations – and I am slowly getting better at taking time off work . It’s one of my goals for when I grow up . The guy I need to thank the most for finally taking time off from work is my mate Dennis Howlett . He told me many times – with and without beer in our hands – how time off work helped him, and it kind of worked out that way for me too .

I used to take pride in my programming abilities – and looking back today, I had no right to be . I can still code in C , ABAP and a little bit in java . And over last few years, I figured out JavaScript and Hana – but clearly I am nowhere as good as I thought . Bad news – I doubt I can get a programmer job anymore to pay bills . I better forget that security net and focus on improving skills I need for my current job . There was a time when I could write 500 lines of code in a stretch with no syntax or compilation errors – and I used to take that for granted . Can’t do it any more – and it hurts !

On the bright side – what didn’t kill me made me stronger . All those hours spent tackling programming stuff is coming in very handy when I learn MongoDB – given my natural way of understanding something new is by comparing and contrasting with stuff I know from past . There is some light at the end of the tunnel after all .

Looking back – I am most thankful to some fascinating leaders I got to work for who paid it forward to let me be successful in my career . And I am incredibly proud of the people who came after me who I could help along their way . I know they will go places – and I would be proud to work for them one day . If I am ever successful in my life to deserve a good legacy – I want to be remembered as a guy who helped create a few more leaders in this world . I could do a lot better on that front than I have done in the past – and I intend to do just that going forward .

Last but not least – if there is one true regret above all others , it is that I didn’t spend enough time with my family and our dogs . I can’t go back in time and fix that retrospectively – but I hope to make up for it, and then some, from now on .

Definitely need to lose some weight too – but then , some promises seem to be meant for following year – on a rolling one year basis 🙂