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 .
