Vishal Sikka leaving SAP – My initial thoughts


20140504-150133.jpg

I had heard this news over the back channel yesterday . Having known Vishal for a few years , and having worked for him for a bit – It was a surprise, but not exactly a shock . This photo above was a picture I took the last meeting I had with Vishal and Hasso before I left SAP .

As a friend, I think this is a good thing for him to do. It was a big job with a lot of stress . He could use a breather before his next adventure . For a man of his caliber , there is no dearth of opportunity in this world .

For SAP, there is both a real issue and a perception issue to overcome . Bernd Leukert is a known and respected entity in SAP leadership – and I think will do as good a job as any one else to keep the ship steady . What Hana needs is a set of apps – and Bernd’s pedigree is all on apps side . He has Bjoern Goerke and other leaders to take care of technology. I am a tad surprised Bjoern didn’t get into Managing Board – but I am sure it’s just a matter of time . So I think SAP board did the right thing in picking Bernd to be Vishal’s successor . I do expect to see some “thought leadership” cues from Bernd (and probably Bjoern too) at Sapphirenow Orlando on how he sees SAP evolve .

It’s not enough to build apps – it needs to fit into the “we are a profitable cloud company” message, which probably needs a renewed focus on mobile business too .

Rob Enslin goes to executive board with Bernd – and I think that was a no brainer too . Rob is as good as the best sales leaders anywhere in enterprise software today. When Bill becomes sole CEO in few weeks , I expect Rob to be a solid general for him . Congrats to Bernd and Rob – very well deserved . I just wish SAP managed to keep Sanjay Poonen too . But Steve Lucas is still there – so there is no real shortage of top talent .

And I think this reshuffle helps Bill McDermott get a great start on his tenure as sole CEO with almost a completely new board to assist him. With Hasso and Jim in supervisory board, he should have plenty of support to chart a great course for SAP. Wish you the best, Bill !

What about Hana , Vishal’s little girl ? As much as Vishal was the face of Hana – there are plenty of people who are experts on Hana in SAP at all levels . The real question is whether SAP continues to keep a technology focus on Hana , or let apps take front seat again and Hana just powering everything in background . Success of a platform is based on apps built on it – so I am hoping SAP strikes a good balance on apps VS technology when it comes to hana . SAP is not breaking down Hana numbers for its quarterly reporting anymore – so I am guessing such an equilibrium will happen soon .

I hope SAP keeps the Hana startup program alive and well – and in addition focuses on building a deeper relationship with other type of partners (HW, SI, SW, Cloud). Ecosystem is SAP’s biggest advantage – and it is important that the company takes the partners in confidence as they transition product and engineering leadership .

I do feel bad for my many friends in SAP who work in P&I – it’s always painful to go through a leadership transition and it’s after effects . I can only hope that you emerge stronger on the other side . I can’t even begin to imagine what I would have had to go through emotionally if I hadn’t left SAP .

I can only speculate what Vishal is going to do next . With his eye for spotting technology trends and passion to see world change for the better – my best bet is that he will become a VC or an Angel investor . But then he could surprise me by choosing to be an entrepreneur again , or join a big company (unlikely but not discounting it ). But whatever option he chooses – I just want to wish him the very best and hope he takes some significant time off to recharge . Good luck V !

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 .