How to Remove ABAP from SAP Environments - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

ABAP is a highly inefficient development language that should be removed from SAP accounts.
This article will explain how to do this.

Introduction

ABAP is not a fully functional development language. It is instead a report writing language with a large number of libraries. ABAP problems are covered in the article Why Did SAP Customers Follow SAP’s Advice on ABAP?

What To Do with ABAP

Customizations should be pulled out of ABAP. There is no reason to be coding in ABAP or to have tables or code in SAP.

A service can be created that integrates with SAP and that allows full flexibility on the languages used that are purpose fit to the coding challenge. If any cloud is desired, which is increasingly an effective way to develop, ABAP is a significant hindrance, as we covered in the article Why ABAP is a Major Hindrance for the Cloud.

Continually Losing Efficiency with ABAP

The more companies stay with ABAP, the more they lose control of their environment. It is difficult to understand the continuation of ABAP, but a significant reason is that ABAP is continually pushed by both SAP and the SAP consulting firms. With SAP consulting firms, in particular, making a lot of money billing for inefficient ABAP development.

These inefficiencies are highlighted by Rolf Paulsen, a long-time developer with experience in many languages.

The Issue with The Language Being Intertwined with the Platform

ABAP is only available to SAP customers and required a running SAP Netweaver instance (or S/4HANA instance). Unlike other languages, you cannot just download a compiler or interpreter, open your favorite editor and start your “Hello World” program. In ABAP, the language is baked into the platform. The developer edits code stored in database tables of the ABAP platform like a clerk edits an order or invoice. This is a fundamental disadvantage and burden of ABAP compared to other languages and the root of many other hindrances.

The Issue with the Language Being Out of Date with New Database Features

ABAP is legacy and the discovery of database features from the 90s that SAP is celebrating in the last years does not affect many lines of ABAP code in S/4HANA. But many customers have many ABAP developers employed and have require that these can continue to create value. The “ABAP in cloud” thing is mostly addressed to those companies and their CEOs. Hey, if you stay with SAP, your experienced ABAP developers can continue to work – no need to learn a new language, no need for restructuring.

And of course, this is a significant problem. Developers should be learning a new language because ABAP is an inferior development language.

The Logic of Developing Outside of ABAP

It is true that customization should be developed outside ABAP.

If SAP tries to force their customers into S/4HANA Cloud SaaS, there cannot be customization inside the ERP system itself and you have to develop against open interfaces and APIs.

It does not make any sense to use ABAP (Cloud) then. One challenge is to get a seamless user interface for both ERP system and custom development. By providing OData that is not very widespread outside SAP and Fiori that consumes OData easily, SAP does a good job in keeping customers close to their development tools like SAP Web IDE.

SPA is presenting a false explanation of the continuation of using ABAP. When companies use SAP’s tools, those companies lose.

Replacing “Legacy” By Porting Entire Applications to SAP

There was an illusion that if you recreated “legacy” systems in SAP, this would be a good thing. But this only leads to higher costs, less flexibility, and agreement to use SAP’s development tools (and SAP’s consulting partners.) But SAP has nothing of value to offer development.

Their internal development efficiency is appalling; the ABAP efficiency on projects is abysmal. It’s time to admit that SAP has no development knowledge to offer. The generally available public languages and tools and approaches are superior to what SAP is and has recommended.

Go to top

Conclusion

SAP and its surrogates bamboozled customers for decades into adopting one of the most inefficient development platforms. And while it never made any sense, it was so easy to do. You don’t have to be a developer or have a development background to figure this out.

It is long past time to refactor ABAP code into the best development languages of one’s choice. And IT departments should never again listen to application vendors for advice on what development language to use, what development environment to use, development approaches to use, etc. This is because any information offered by application vendors is simply the camel’s nose in the tent to increase their account control.