Platform Support in a Cloudy World

SAP get enterprise software. They understand things like having a rock solid technical platform, scalability, 24×7 operations, multi-language, etc. They highly value backwards compatibility too because they understand their customers want to be able to upgrade without  having to make wholesale changes – or even any changes – to their custom code.

Arguably one of the great technical achievements of the ABAP application server is that it remains backwards compatible. ABAP code that was written for R/2 more than 30 years ago can potentially still run on S/4HANA. That is pretty amazing.

It is also a huge load of baggage that SAP need to carry around with them as they enhance the ABAP application server to support contemporary development paradigms and techniques. As they add support for things like the Internet Communication Framework and Object Oriented programming they have to still support things like TABLES parameters, internal tables WITH HEADER LINE, CHANGING parameters, etc. Whilst we all know we should only develop new code using contemporary syntax we also know we can use deprecated ABAP as a “Get Out of Jail Free Card” whenever we need it – and we do.

It may well be the that over the years some deprecated features of ABAP have actually been removed – but I can’t recall a single one.

The typical SAP Customer has a lot of custom code in their system of varying quality and use. Lots and lots and lots. Much of it is probably never even used as it has been replaced by new code over time but the old code has never been deleted – just in case. Similarly customers have been reluctant to upgrade more than once or twice every five years – creating a long tail of SAP releases that SAP have to maintain support for across decades. I know customers still running R/3 4.6B – I have been told of some on 3.1H and earlier.

SAP are now being very clear that they want to change this pattern. They now want you to build all custom code outside your S/4HANA system – no matter if it is the on-premise or cloud version. They want you to resist the urge to pollute (my word not theirs) your SAP applications with your own code. Instead they want you to build custom code in another system – their preference is the SAP Cloud Platform – and have it call standard API’s to integrate with the your SAP applications.

This is key to allowing you to upgrade your S/4HANA system more readily so that you can adopt the latest versions – and associated innovations – soon after they are released confident they won’t break the existing code. It is also key to customers choosing the cloud version of S/4HANA rather than the on-premise version – once those pesky API’s are available. 😉

But what about ongoing support for the platform we use to build these so-called “extensions” on? In other words the SAP Cloud Platform. What is SAP’s plan for supporting it?

In our familiar ABAP world support for our custom code was pretty much guaranteed due to this backwards compatibility characteristic. But that becomes a bit more problematic when cloud technology can change very significantly in short periods of time and new technologies have no obligation – or interest – in supporting old technologies. In fact their main purpose is to provide an alternative to those older technologies.

Take the SAP Cloud Platform. It started with Neo. Plenty of applications, extensions, etc. have been built on and now run on the SAP Cloud Platform Neo stack. Recently SAP have started to direct developers towards their Cloud Foundry stack on SCP. We are now being encouraged to build our apps and extensions on CF. Neo you are dead to me.

At SAP TechEd this year SAP announced they had joined the Cloud Native Computing Foundation the controlling body behind Kubernetes – the open source project that acts as an orchestration layer for containers. And – as Dick Hirsch describes so well in this blog – SAP already have significant capabilities and experience building and running “containerised” applications.

Does this mean Cloud Foundry will soon be dead to me too?

All the signs are that “Serverless Computing” will be the next significant change to how we construct and run applications. And what will come next? Does this mean that Containers will become dead to me too?

Of course not. It is clearly a case of choosing the most appropriate technology for the workload at hand – just as it always has been. That might be Cloud Foundry, containerisation, FaaS, or something else. Remember also that one runtime technology can be provisioned inside another. Nothing is necessarily mutually exclusive. (Neo, I probably still think you are dead to me.)

I can see that SAP will now need to rethink how they define and position ongoing support for SCP and how they articulate this to their customers.

Backwards compatibility meant that supporting the current ABAP release also implied supporting the ability to execute all my old custom code. But there is, for example, a clear distinction between the SCP Neo and Cloud Foundry runtimes – as there will be for containerised and FaaS runtimes too. As we move to building our code for CF we still want our Neo code to keep running and the Neo-based platform to continue to be available. Maybe for a very long time.

In the consumer world cloud providers might be able to simply remove/change/enhance their services and cop any backlash on the chin. Not so in the enterprise world where – to quote the late Les Hayman – “Organisations bet their future on SAP“.

SAP get enterprise software – so I think we can be confident they get this issue as well.