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 🙂

 

An Ex-Influencer’s take on influencing


I read this today morning http://getlittlebird.com/2013/04/how-to-influence-the-influencers-ask-for-their-advice/ and thought it was good advice . Influencers – they are an invaluable source of information to any vendor , and the good ones can help you do course corrections before you do something awful .

For a brief period , SAP considered me as an influencer . First as an SAP mentor and then also as a blogger . It also probably played some part in SAP hiring me . And now I deal with several influencers as an SAP employee, similar to what I did as an IBMer till last year.

I never quite figured out why there are multiple categories of influencers – analysts, bloggers, press , mentors et al. I am not a communications expert – so I trust there is some good reason that such distinctions exist . As someone who talks to most of the “50 shades of influencers” , I don’t personally see any difference in the quality of input I get . Maybe it is just organizational inertia to change an existing model .

In my opinion – choosing Influencers is exactly like choosing your mentors . It is never easy . It is a complex balancing act – you need to establish long term relationship with the best of them, but you also need to keep bringing in new ones to negate any bias . All influencers have some bias – which is why you should have more than one to begin with . However , if you stick to the same ones for an extended period – your chance of getting fresh new ideas will decrease quite a bit . And after some time passes, you would have influenced your influencers too much in reverse and will start painfully wondering why you seem to be stuck in echo chambers all the time .

In my opinion, it is probably safer for both sides to introduce a retirement scheme for all influencer programs . A change of scenery can do wonders for ones perspective . And if it is a planned activity, it will feel more like a nice vacation than a divorce . Sure you will lose a bit of continuity and comfort feel – but it is a small punishment compared to the doomed echo chamber !