Defining Hadoop with a straight face

Unlike datalake, I don’t think of Hadoop as a buzzword at all. It is a real thing – a real project you can touch and feel. Also, I love elephants (The one in the picture is an eighty year old Guruvayoor Padmanabhan, owned by a famous temple in Kerala)  – which might explain why I have a particular soft spot for Hadoop 🙂 . Hadoop is perhaps not yet ready to be an elephant this size, but it is not such a little baby elephant as shown in the marketing pictures either.


By now, it is stable enough even for an obsolete programmer like me to play with it minimum fuss. In my day job, I don’t program any more (sadly – but probably a good thing for my team, and perhaps for the rest of humanity). But there is hardly a week that passes me without a need for explaining hadoop to someone. Even when I was between jobs and enjoying a nice vacation, I was pulled into “help me understand hadoop” discussions.

The primary problem for me personally is that the folks I usually have to explain hadoop to are not always conversant with open source. I get to talk mostly to people who are smart enterprise technologists, but who have very little idea of open source per se. Vast majority of them equate open source to free software. And it is not as if open source is a good all encompassing way to explain hadoop (hello MapR). And if I somehow manage to get these folks to understand open source and a few licensing models, I lose them again on the idea of what a distribution is and what is different between the distros. I think its mostly a mental block that there are commercial vendors who make money of software that is supposedly free – and they all do it in different ways. Can’t blame them – I had those questions too for a long time.

Once you get past open source, then there is a question of what constitutes Hadoop.

No one in my circles apparently cares about Hadoop common , so I no longer utter a word about that. And the few times I have mentioned it, mostly to friends who come from coding backgrounds – I have to deal with “why would anyone use java for building this?” 🙂 . Hence no “common” – nothing but grief from that conversation.

Then I talk about HDFS and MapReduce . Enter more rat holes – why does the world need yet another file system – why not use GPFS? I have heard of Spark – so when do we use MapReduce and why not just use Spark all the time? If I get a breather, I also get to mention YARN and Arun’s explanation of datacentre operating system, and that there is a MapReduce2. People get why YARN is a good idea almost instantaneously. Everyone appreciates the vision of pluggability – but invariably someone will ask about its compatibility with stuff that came before YARN .

This is usually where I start with the idea of different kind of nodes, mechanics of replication, why 3 is a default value, and why the whole thing is built for commodity servers daisy chained together. You would think this is the easy part – but it is not. We are dealing with people who have spent their entire careers working on high end servers that have all kinds of resiliency. It is a really hard thing for them to visualize the world hadoop is built for. Usual starting questions include “if I just repurpose all my high end servers, can I just avoid replicating thrice?” or “I already have tooling that takes care of HA and DR in all my data centers. Surely there are APIs that I can use to connect my existing tools to this hadoop thing ?”. This is a game of how many times you get to say “it depends” in any one conversation without taking a breath.

Just when I am ready to wind down the conversation – impatient listener will ask “can you fill me in on hive, HBase etc”. Sure why not – so I explain how there are a bunch of other projects that play alongside hadoop. “Are they all java?” – well, they are not ALL java, but ideally you should not have to worry given they all have interfaces you can use relatively easy. I can see relief !

HBase seems to be a trigger for starting on the NoSQL part of this Odyssey. This is particularly so because my friends know I spent some time working at MongoDB. Sadly – as in REALLY sadly – 90% of my conversations include a part of convincing people that MongoDB is not hadoop. And at a minimum at that point I have to touch on Cassandra to explain there are more NoSQL options out there. Invariably this opens up the question of “does MongoDB work with Hadoop” – thankfully it does and I explain the connector. It also usually leads to my friends from ops background sigh aloud “can’t we just use a general purpose database that does all these things” ? . I no longer fight them on this topic – mostly for lack of energy.

“So you have explained how data sits in hadoop, but you have not explained how I can put it in there or how I get these awesome insights from that data”. Ah I forgot all about that. So I go on to explain even more projects ( at some point it is overwhelming to remember all the names and the right spellings ) – and also manage to get in a plug that a lot of closed source tools can access hadoop. This is usually the point at which my ops friends give up on me and say “good Lord,  it is complicated to manage all this” and my dev friends get all excited that there are so many cool new toys to play with.

Usually the final question is on security. On the bright side, Ranger and Sentry are both easy names to remember. On the not too bright side – I don’t want ( or even know fully well enough) to explain why two major distros have two different approaches. And this usually leads to other examples like impala to show that not all distros share the same implementation philosophy. I should use something other than impala in future as my example – since that goes into “how many possible ways can you do SQL on hadoop?”. My usual temptation is to say “more ways than enough for you to get a costco size jar of aspirin” 🙂

I have not counted, but there are certainly more than 30 projects that can somehow be called a part of hadoop. I have personally played with less than half of them. And every day more projects are starting and it is getting hard to keep up. No wonder why my friends/customers/random people all get stressed out trying to understand hadoop and how to make use of it. And yet – everyone is excited about their hadoop journey, despite all its twists and turns. Marketers like my friend Ingrid who recently joined HortonWorks as CMO should have a fun time articulating a message that makes it much simpler to understand.

Alright, so who wants to ask me about Hadoop next ?

Before you take a dip in a data lake

We all love our jargon and buzzwords, don’t we ? Off late, I get pulled into a lot of discussions on “data lakes”. People are either huge fans of the the data lake approach, or they are super negative. And that is what makes these discussions a lot of fun.

I did a google search on what exactly is a data lake and got this as the number one hit. A data lake is a storage repository that holds a vast amount of raw data in its native format until it is needed. If we stick to this definition (which I like), it also makes it easy to understand the tradeoffs of this approach.

The major benefit of this approach is that you reduce upfront costs associated transformation. Instead of ETL (extract-transform-load), we just extract and load, and leave transform for some other time. On the bright side with a data lake we can cross our hearts and honestly say “no more silos of data” and “one repository to rule them all” . This has its advantages – better deals on HW and SW costs and potential some breathing space to stagger analytics projects to make use of this data.

The whole reason for dumping all data into data lake is to analyze it at some point. For analysis, we need to know the meaning of the data that we are trying to crunch. When we try to do analysis at some point in time – we in all probability cannot make sense of what the data is anymore. Even in the tightly controlled world of datawarehouses, we spend a lot of time in rework when a new data source is introduced . We run to the people who manage the source systems and try to establish rules and governance and so on so that there is less error in steady state and data can be meaningfully combined.

So while data lakes are definitely serving a good purpose – there is an aspect of dealing with the “kicking the can down the road” that often comes with it. A data lake that is meant to prevent data silos, could just end up enabling silos at scale when there is no governance around it. This is the part of the message that marketing peeps usually don’t say out loud. Perhaps the reason they don’t say it is because once governance is established, data lakes might look very similar to the now uncool data warehouses – maybe not physically, but certainly logically.

Data lakes are quite useful as long as the expectations are correctly set. I would not shy away from it. Just keep the expectations real on the trade offs. I was joking with someone that all the fans of data lakes should be made to work in a data curation project for some time on a mandatory basis. That will give them a much more balanced perspective !

This is my second attempt at writing this blog. My (much longer) last trial yesterday night had to be deleted 🙂

Customer references and strategic relationships 

I had an interesting discussion with two friends on Twitter yesterday – Frank Scavo who is a well respected analyst and has advised a lot of customers on buying enterprise software and services , and Ben Haines who used to be the CIO of Box and who is now a VP at Yahoo . The topic was about customer references . I thought I will jot down my (strictly personal) views on this matter.

There is nothing more valuable for a vendor than having a customer who is willing to act as a reference to other customers and prospects.  Nothing puts a prospect at ease about a vendor like another customer who can vouch for the vendor. Customer references are also invaluable in securing favorable analyst reports for the vendor. 

References are very important for the customer too. Vendors will typically paint as bright and rosy a picture as possible to make the customer buy . It is by asking around other customers that a prospect typically gets a full picture . In most cases they just directly ask the vendor for the reference . As a seller and then as a sales leader in my career , I have been asked a zillion times to arrange such reference calls . I am greatly indebted to the customers who have provided such references.

There is a strange irony from this point forward in the story . Many customers who absolutely insist on reference calls are themselves not comfortable to be a reference for the vendors whose products and services they have successfully implemented . The most common excuse I have heard is the generic “it’s against company policy”. These same customers also often lament that their vendors have a very transactional relationship with them and doesn’t take the relationship to strategic levels . 

I am all for hard negotiations upfront . Haggle on price , payment terms , indemnity , dress code or whatever it is that both sides need to agree . But I always request my customers one thing – let’s agree on success criteria and a way to measure it . And let’s put it in the contract that if the success criteria are met – then please be ready to be a reference for a few prospects . As both Frank and Ben correctly pointed out – This is also the first clause in the contract that some CIOs and procurement folks ask me to remove . Their typical response is “we are happy to be a reference , but don’t want it in the contract”. Strangely enough I have not had a single business buyer EVER push back on me on this clause . Not one ! 

I trust my customers . If I don’t trust them , I won’t do business with them . And I earn their trust . So I am almost always sure that a customer who promises to be a reference will typically not decline at the end . But on the other hand I have been in this line of work long enough to know that people change jobs and roles . I also know that if I put it in contract , then any legal issues etc will surface upfront and get resolved one way or other . In many cases the person I am dealing with might not have the right authority to be a reference . In short – it gives me a chance to mitigate “not in policy” risk upfront . It also saves a lot of embarrassment for the customer Employees who find out after the project is over that they can’t keep their word to me . 

What does a strategic relationship mean between vendors and customers ? We both help each other to further our businesses beyond the transaction we have contracted for . As an example , I have many a times helped customers by providing them access to experts in other domains or markets that they need help with . And many customers have helped me win business elsewhere by being a solid references. If all we care about is price and budget and scope – then that is all we will get at the end . That is a fine way of doing business in some cases – but then the expectation should be appropriately set on both sides that there is no strategic nature to this relationship . 

So what is my success rate at getting referrals ? I would say maybe 30 to 40 percent at best . But I am hopeful that I can double the rate at some point . Life in enterprise software is not worth living for transactional relationships – at least for me .

Spreadsheet slaying is futile in enterprises

It would not be the first time that a friendly banter with my pal Dennis Howlett leads me to post a blog. This time it is about spreadsheets . I have a (not so) slightly difference of opinion with Den on the topic of use of spreadsheets in enterprises . The short version is Den thinks spreadsheets are evil, and I don’t 🙂 OK that is dramatizing it a bit…but here is my (strictly personal) defense of spreadsheets for whatever little it is worth

1. If past performance is indicative, spreadsheets will thrive

Spreadsheets provided continuity for business users from early 80s till now. In this time frame, a lot of BI and EPM tools came and went away. Lotus 123 faded out, but its users just moved on to MS Excel . I don’t see this changing in near future either. Today there are more BI and EPM tools than ever before – and all the more reason for FP&A types to hold excel near to their chest to resist change.

2. BI and EPM companies use excel internally – a lot !

I know – I have worked in some of those companies, and partnered closely with others. They all use excel for BI and EPM alongside their own tools. They all market their wares as “excel killers” when it suits them – but can’t seem to convince their own planners and analysts to let go of excel.

The smart vendors all integrate excel into their products. Despite marketing hype they create, they all know that the product management rationale is solid that excel won’t go away, and recreating excel functionality elsewhere is not a good use of resources.

3. Analysts and Executives use Excel all the time too !

Not naming names – but every analyst I know who cover BI and EPM have excel on their laptops, and have an assortment of files with complex versioning schemes via naming conventions. The more modern ones use google docs instead of excel – but that is not exactly too different.

Similarly I have often seen data loaded in spreadsheets used by vendor executives in their demos . They just don’t say the backend is excel ! I am not saying this is what everyone does – just that I have seen it multiple times. I don’t blame the execs either – rarely do they know what happens behind the scenes of the demos they have on their iPads 🙂

What is the most common data source used by the new generation BI tools ? Excel ! People dump data from other systems to excel , add formulas etc, and put a nice visualization on top via the slick BI tool. Just that they don’t talk about excel in the scenario explicitly.

4. Convenience trumps functionality almost always – except for legal reasons.

World changes faster than BI and EPM tools can keep up with. The ability to change formulas on the fly and and rows and columns means that analysts can keep up with the changing world without waiting for the tool vendors to catchup. The only time they stick with tools 100% is if there are legal reasons to do so – like final copies of financial documents that need to be kept in a proper system of record.

I know top reference customers of pretty much every EPM vendor I know of that do plenty of work offline in excel and just upload the final copy to the tool for safe keeping. Or, they will do high level planning in the tool and then do finer details in excel. For example – they might allocate expenses to the head of a department and then let her manage it offline as long as she does not shoot over budget. How does she do it ? she uses excel !.

Den asked me if enterprises will use manual invoice processing if they have ERP. I have implemented SAP in a lot of Fortune 500 customers – and every single one of them have had a mass upload of invoices from excel !

5. Licenses, maintenance and training favors excel 

Even if someone creates a magic tool that does everything – it is still hard to beat excel . Why ? because excel is a general purpose tool needs very little additional training , and it does not need constant network uptime for usage across the company.  The incremental cost of keeping it running over time may not “appear” to be that high. True cost might be high – but as with everything else in enterprise land – perception is reality.

6. Does that mean all is good with excel and you should not use EPM and BI tools ?

No – Excel can, and does, cause grief in a lot of companies every year. A cursory internet search will provide you several horror stories. What the internet won’t tell you is that vast majority of the time, spreadsheets are a life saver in enterprises. But then, good news has no value in press . If my house gets water damage just once in 30 years , would anyone write an article called “House has not had single issue with water damage in 29 years and 11 months” ?

The goodness of spreadsheet is only apparent by first hand observation of its users. This is the same kind of shit that happens with ERP too . How many “ERP is dead” articles have we read ? And how many companies actually took out their ERP ?

When you see customers who say “we have displaced excel” , at best it means one department for one use case has been using a new tool instead of excel . What would be great to know is if there are entire companies who have completely gotten rid of spreadsheets as a BI, EPM and ETL tool. I have not seen any in the nearly twenty years I have spent in this field.

The smart thing in my opinion is to find the best co-existence strategy for excel and all the other tools. Spreadsheets are invaluable when used reasonably – please just don’t paint it evil with broad strokes.

That is it . Defense rests, your honor !