Skip to main content

SAP: On the future of ABAP

Submitted by Stefan Barsuhn on

I read some articles yesterday that largely discussed the sense and non-sense of SAP providing ABAP as a programming language in SAP Cloud Platform.

It had actually never occurred to me that it could be non-sense, and realizing that was quite a revelation. I do kind of blame it on the fact that all my previous SAP experiences had been in Germany or Europe, so I'd like to share my perspective.

Especially in Germany companies have always been quite conservative and slow in adopting new things. "Let's first see how this works out and if there is some benefit in it, we may take a look at it."

Crowd Behavior

Then something interesting happened: With the advent of Silicon Valley "start-ups" like Facebook, Apple, Google etc. a downright "pilgrimage" of German CEOs and CIOs to California began to learn about "disruption", "agile", "cloud", "big data", "AI", "machine learning", "fail fast and fail often" and so on.

Where previously the main concern of CEOs and CIOs in Germany had been to focus on production and use technology only if it enhances output, the question CEOs would ask their CIOs (and CIOs would ask their employees) was now: Are we doing this as well?

The business cases I see in my daily work that really benefit from those new technologies are rather limited. Largely, those investments are a result of crowd behavior. If you follow the crowd and things don't turn out as planned you can always say: "everyone was doing it". If you go against the crowd and things don't turn out as planned you don't have anyone to blame.

So currently, German companies still rather "impose" new technologies on themselves rather than embrace them. They're working as they did before, just in the cloud and not on-premise. And I have a feeling that this is not going to change anytime soon while nobody is going to stop buying German machinery or cars because of it.

ABAP in the cloud

From that background, it makes perfect sense to have ABAP in the cloud. It's what (German) companies are used to in their SAP system and to me it was always a given that German companies would only consider moving their SAP coding to the cloud if they could continue using ABAP.

You also have to see that Germany has very rigorous employee protection laws. You cannot simply fire your ABAP people because you've chosen to go to the cloud and your cloud only works on *.js. Instead, you have to invest and retrain your employees. And Germany being SAP's home market and a very important core market, too, it was out of the question that SAP would have to bring ABAP to the cloud. 

Adding to this, when SAP Cloud Platform embraces Bring Your Own Language (BYOL), why should that not apply to ABAP?

So I think what the discussion surrounding ABAP is really about is what ABAP represents - a 30 year old programming language from the past. Abandoning ABAP would certainly signal a radical change that some might welcome. For others ABAP is a quality feature of SAP products they have been relying on for 30 years.

Enable, don't dictate

My take: Let people code in the language they like. I personally like ABAP a lot. I've never liked Java much. I do like PHP. JavaScript is okay, too. All languages are abstractions of machine code, so unless there are objective (measurable) reasons not to use a language (slow, insufficient functionality, low productivity etc.) let people use them. If at some point SAP realizes that nobody is using ABAP anymore, they can do still do away with it.

One case that was made against ABAP was that it is difficult to find good ABAP developers. That is a valid argument, although a statistic one. It does not mean that ABAP developers are on average worse developers than Java developers. I would think that the percentage of "good" ABAP developers among all ABAP developers is similar for "good" Java developers among all Java developers. The real difference here is the population. There are many more Java developers than ABAP developers, so there will naturally be more "good" Java developers.

However, the programming language has nothing to do with the complexity of the backend. SAP has a history of bad documentation, especially function modules, reports, classes etc. (they're doing much better in recent years). So if all of ABAP were converted into similarly hard-to-understand Java classes, non-SAP Java developers would struggle just as much.

What companies should do

So if a company moves to the cloud and realizes that they have always struggled to find good ABAP developers but have a ready supply of good Java developers, they should go ahead and see if they can replace their ABAP with Java along the way.

If another company has a solid team of experienced ABAP developers and wants to move to the cloud, they should go ahead and keep ABAP in the cloud. BYOL should be about empowering teams to use the language that fits the team and the company.

Companies and teams should have a plan, though. Agree on a limited set of tools and languages that you use and that you are able to maintain. Having everyone use the language they are most comfortable creates unnecessary complexity.

In short, remember that you moved to the cloud because you wanted to outsource operations. If you use the efficiency you have gained to add a myriad of frameworks and languages you will need somebody to update each frameworks and support the code in each language. Use frameworks and languages because you have to, not simply because you can. Keep it simple is always good advice, especially in the cloud.

TL;DR

I don't think ABAP is the problem. It's complexity and bad documentation. Choose the language(s) you like, but keep it simple.

Tags