Free Does Not Work Most Of The Time


Ever since I had my first job, I have wondered about the concept of “Free” in corporate world. And many years later, I am pretty convinced free is usually a bad strategy for all parties. This is strictly a rant on my personal views – nothing official about it, and do not represent the views of my present and past employers .

Nothing is really free

That took me some time to realize – absolutely nothing is really free. Someone has to pick up the tab always. Since I have worked in the consulting business most of my life – let me use that as backdrop to explain . This is true for big and small consulting companies I have worked for.

Customers do pay a pretty penny for consulting – and rightfully think that since they are giving so much business for the consulting vendor, they should get some things for free. This is usually in the form of proof of concept work. And most of the time – Vendors do agree to throw in free POCs. Vendors do not do this out of kindness – since they typically do this only if there is upside down the line for them via more business. The POC starts – customer does not always go all-in for these projects , given they are not putting in direct money on the table. And eventually the project finishes with no one happy and no decisions made . The Vendor does not exactly lose here – they will make it up in next project, either at that customer or at another customer. Those vendors who do not have multiple projects and clients might actually lose serious money in these POCs, and hence they might not do it a second time either. Whichever way you look at it – no body is moving a good step forward in this picture.

Even when something is given away for free, it does not get used much

If you walk the show floor at any trade show, you will get a lot of free stuff – from coffee mugs to iPads. I have seen software companies give iPads to their prospects and clients preloaded with presentations etc, that usually end up in a teenager’s back pack in few days, usually without the presentation ever being looked at. And no prizes for guessing who is paying for those iPads 🙂

Then there is the case of vendor charging a maintenance fees for software, and using part or all of that fees for “free” new functionality added to already sold software. Customers might genuinely like to see all kinds of things to come out of this arrangement for free – new business processes, mobility, BI etc. The hard part is – it is next to impossible to draw a clean line on what should be free.

If you look at the adoption of the new functionality provided for free , very rarely do you see big adoption. But if you look in further – there might be other reasons for this , like cost of hardware, testing, change management etc. So on one hand, the vendor uses a lot of money for making stuff, and on other hand customer has no way of using it – due to lack of awareness, lack of resources or lack of interest. The take away here is again that Free did not work as expected.

It can of course be argued that in a multi-tenant SaaS model, customers might use free stuff more often. I seriously doubt it. Example : if you never had parallel ledgers till today, and now your cloud vendor gave it to you for free – will you implement it ? Many customers will not – either because they don’t care, or because it needs more change management , SI work etc (probably less than on premises world, but still usually enough to help inertia rule). And it is not as if cloud does not have lock in – if you have any doubts, look at the SEC filings of cloud companies on internet.

Should Vendors charge for a different UI or for mobile versions of existing applications ?

UIs will change over time – as technology changes (hardware and software advances, consumerization of IT and all that) . Should Vendors charge for that? Will making it free increase adoption and make customers happy? I don’t know the answer – but my (of course biased) answer is that it is fair to charge for this. Here is my rationale – when customers don’t like UIs, they will find work arounds. Vast number of screens delivered by vendors are replaced by loads from spreadsheets . I know a company where the financial analyst loads JV entries twice a day by putting it in an excel sheet and putting it in a sharepoint drive, System does the rest and the analyst is happy and productive. I have asked this guy personally many times if a different UI is a better solution, and he consistently likes to stick with his excel in sharepoint approach. I know a hundred other examples like this where people refuse to move to better UI for fear of change. Giving a free UI for these cases just would be a bad investment.

Mobile is a harder nut to crack. Vendors with a limited footprint – like just HR or just CRM as their offering, might throw it in for free and build it into their price case. I think that is the right thing to do for them since it makes business sense. However, for vendors who sell many different things – they might not have a good way to do this across their portfolio. For these cases – All I can say is “pick your battles” . They are probably better off selling packages mobile applications for best usecases. Or they might sell (or partner with) some development platform that helps customers build their own. Or maybe leave it to the partner ecosystem to bridge that gap. It might also make sense to throw in a few things for free on mobility front if it makes sense for competitive reasons.

But if you charge – what is fair and what is not? I have a simple POV on that – the price to charge is the maximum $$ that will not stand in the way of adoption. Price is driven by market – if you over charge, customers won’t buy and use it. So start with what you think is fair, adjust as you go – with a good tradeoff between adoption and your financial KPIs like revenue and margin.

What about consumer side of the house?

You would think that consumers are happy with all the free stuff they get – like facebook, free uploads in flickr and so on. Nothing is really free there either – you still pay in terms of sacrificing privacy, suffering through advertisements (or paying to avoid the advertisement). And of course you use the same facebook to complain of their free service 🙂

So in short (well, I guess this was not very short – sorry) – I doubt “free” really works anywhere. There is no free lunch – I have accepted that and made peace with it. What do you think ?

Platforms Everywhere – For All 50 Shades Of Developers


Right up front , this is not some official SAP strategy that I am trying to describe below, just some personal opinions and thoughts I am chewing on in my mind .

First I ever heard of a platform ever was in the context of Unix , when I was a trainee in TCS. I remember asking the guy who introduced the term and even more clearly remember him making a mess of explaining what a platform is . Then along came java – and the word platform was thrown around a lot again. I learned java without a lot of difficulty , but did not like it for the longest time , thinking it was not as good as C/C++ that I learned first.

When I started in ABAP , I don’t remember the term platform being used . But once Netweaver brand came out – platform came with it . And more loosely , it became common practice to say ABAP platform too . I don’t know what the SAP product and branding strategy was at that time , but will find someone for a history lesson. By this time the notion of platform was a bit more clear – if multiple developers can develop applications ( apps and applets were totally java, and hence I never used those terms at that time) in multiple ways – that is roughly what a platform is . And while there are probably better definitions for platform now, I still rationalize it that way in my mind 🙂

Despite having an array of options to choose from , Developers are generally loyal to a subset of tools , which they will invariably refer to as a platform . Same with vendors – they too latch on to the term platform quickly as they cater to various parts of the developer ecosystem. As a result, it is not uncommon for a big vendor to have multiple platforms – like SAP did for cloud , mobility, Hana et al. Initially I used to think this is confusing as hell – how would developers know what SAP means by platform?

Well, as I talked to multiple developers outside SAP – I was surprised to learn that very few worry about this . Mobile developers did not seem to have any significant interest outside mobility platform generally. A handful of architect types did make a case for convergence since they have end to end responsibility in their jobs . And from the provider side , there are obvious advantages in converging all platforms under one umbrella . But such convergence makes sense only in some cases – and is not a one size fits all type thing.

Consider ABAP – which is still very close to my heart despite the compiler yelling at me every now and then that I am obsolete . SAP business applications are built on it in most cases – and between SAP and its ecosystem , there must be several million lines of code . And I am sure there are a gazillion ABAP developers in the ecosystem , probably mostly in SI partners. So it is important that this big investment is protected somehow in long term. However , ABAP has its limitations for developers outside the traditional SAP backed systems . So while there needs to be an easy way to talk bidirectionally with ABAP systems , it might not make sense for ABAP to be a native development experience per se in SAP Hana Cloud Platform. This should not be confused with hosting ABAP based systems in cloud , which is a valid requirement and completely feasible.

The functionality in Suite needs renewal and modernization as business processes evolve . With Suite now capable of working on Hana , and ABAP understanding how to use Hana – this is easily solved when applications need to be fixed at its core. Another common use case is extending existing SAP applications – including SaaS offerings like Sales on Demand . These will probably need some non SAP data to be combined with SAP data . Such cases are easily done using the SAP Hana Cloud Platform , commonly using published APIs from source systems (without needing to deal with ABAP directly) , using maybe Python or some other JVM friendly language . Or if it is data intensive, a more native XS/SQL Script type developer experience might be optimal . Again, New functionality developed from ground up – including completely non SAP data ones – do not make sense for ABAP development . What about acquired solutions like Ariba and successfactors ? Long term – I think it makes sense to move everything to HCP , but it seldom makes sense to re platform for academic reasons . So for those applications , parts that could immediately benefit from Hana could be replatformed , and rest left alone for now . And of course extensions could use HCP wherever it makes sense.

So essentially , the platform strategy needs to cater to all types of developers . They all serve a useful and important purpose – and need to collaborate to build world class enterprise applications . And if there is one thing I could humbly suggest to my developer buddies – this time around, lets not create a deep division like “technical and functional consultants” in ERP market in the 90s. Lets try to learn a few more things outside our core skill set and interests .

SAP Hana and “The Killer App” Problem


Ever since SAP announced Hana , I and many others have wondered about what would be the set of killer apps that would come out and wow us. While several apps have come out , and hundreds of others are in the works at SAP and its ecosystem, this question has not quite gone away. Next week is SAPPHIRENOW in Orlando, and I have already been asked a lot by a number of people about what killers apps will be demonstrated there.

Obviously, we have cool things on Hana to share with you next week – and I have no plans of spoiling it here. I am pretty sure some of them have real potential to be killer apps.

There is no consensus on what makes a killer app though – if existing SAP applications like Business Suite and BW run on Hana and a lot of customers deploy it, would they be considered killer apps? There will be some who agree and some who disagree and both sides have good reasons for their stances. If a high value use case comes out for a specific niche industry – something that 10 companies in the world can use and get outrageous benefits, but no one else has any use of it – will that be a killer app? I guess the opinion on that too is divided. What if the app is downloaded by 10 million people , but it does not significantly alter the top line for SAP? Will that be considered a killer app? I have a feeling that we won’t get consensus on that either.

So what then is a killer app? and is it a goal worth pursuing? and if there is no one killer app – what happens then?

As you would have guessed by now, I am at a loss on the killer app definition – so I will leave it to my readers to define (ideally in the comments section below). However, I do think that this is not as big a hurdle as I used to think 2 years ago.

All the examples I gave above of potential killer apps are 100% valid for different people – and whatever is the solution should cater to all parts of the ecosystem. However, it is probably different parts of Hana that help each scenario . Some apps need more of Hana’s raw power to process lots of data in quick time , others might need industry specific libraries, yet others might need Hana’s predictive capabilities and so on. And for existing customers – they need the ability to modernize their existing SAP systems with minimal trouble, as well as extend them and even build brand new apps from ground up.

So what is the solution – the solution in my mind is to treat Hana as a platform. Not a “run of the mill” platform – but a modern, standards based platform that caters to a wide variety of developers and customers. It should make it easy for developers to have a native, open and integrated development experience and should scale with their needs. And hopefully some of the apps built on this platform will get to a consensus “killer app” status.

SAP Hana Cloud Platform does this, and a lot more. Come to SAPPHIRENOW or follow along online – we will share a lot more on the platform direction there. Trust me you will like it – so don’t miss it 🙂

Â