How to Understand the Problem with ABAP in the Cloud

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

Executive Summary

SAP has an enormous investment in ABAP. But ABAP has severe restrictions for the cloud.
SAP is trying to push customers to use ABAP in the cloud.

SAP and ABAP and the Cloud

To understand SAP and cloud, it is necessary to dive into the topic of SAP’s coding language.

SAP uses an embedded coding language called ABAP. Today, ABAP is an inefficient language compared to modern high-level languages. There is a healthy debate about whether ABAP is an actual computer language or more of a framework. Interestingly, ABAP was initially designed by SAP as a report generator, as its original German acronym means “generic report preparation processor.”

The following explanation of ABAP from Wikipedia is quite good, so we have included it below.

“ABAP is one of the many application-specific fourth-generation languages (4GLs) first developed in the 1980s. It was originally the report language for SAP R/2, a platform that enabled large corporations to build mainframe business applications for materials management and financial and management accounting. ABAP establish integration between independent softwares.

ABAP used to be an abbreviation of Allgemeiner Berichts Aufbereitungs Prozessor, German for “generic report preparation processor”, but was later renamed to the English Advanced Business Application Programming. ABAP was one of the first languages to include the concept of Logical Databases (LDBs), which provides a high level of abstraction from the basic database level(s),which supports every platform, language and units.

The ABAP language was originally used by developers to develop the SAP R/3 platform. It was also intended to be used by SAP customers to enhance SAP applications – customers can develop custom reports and interfaces with ABAP programming. The language was geared towards more technical customers with programming experience. It is extracted from the base computing languages java , c, c++ , python.

ABAP remains as the language for creating programs for the client-server R/3 system, which SAP first released in 1992. As computer hardware evolved through the 1990s, more and more of SAP’s applications and systems were written in ABAP. By 2001, all but the most basic functions were written in ABAP. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, along with R/3 release 4.6.”

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

Why Did SAP Use ABAP?

SAP was never required to use ABAP, and there was no advantage to using ABAP over other development languages. However, using and making their customers use ABAP was a conscious choice on the part of SAP. ABAP allowed SAP to control accounts more effectively because ABAP could only be found on SAP projects. This is one of the great untold stories in SAP. This section will be particularly offensive to ABAP coders. However, ABAP coders and those selling ABAP coding consulting have been misleading customers for decades, and this area is seldom illuminated.

One primary problem is that SAP states that ABAP is good for everything. Therefore if one declares that ABAP is not good for something, say cloud, then the offense will be taken. SAP wants to propose ABAP as a universal language. However, there is no universal language. This is in the same way that Oracle intends to introduce a single universal database (which is, of course, theirs), something very similar to what MongoDB does). Still, again there is no single universal database. For many years on SAP projects, one author, Shaun Snapp, was brainwashed. He used to be told this, or that is SAP standard. And ABAP needed to be used because it was “standard.”

But what about a comparison of pros and cons?

That type of analysis lacks SAP projects. To understand ABAP and how the story provided by SAP mutates, it is necessary to get a perspective from a person who can write ABAP, but also someone independent because you can’t write 100% honest things if you rely on the SAP community for your employment.

Rolf Paulsen on ABAP

The following is from Rolf Paulsen, one of the few people with ABAP exposure who provides a historical context concerning ABAP. What he has to say about ABAP and the cloud is most interesting.

“It is simply not possible to port existing (non-trivial) ABAP development into the cloud using the massively restricted ABAP derivate that they made up for “ABAP in the cloud”. Test Driven Development, distributed/non-linear development (branching/merging), Continuous Integration and -Deployment, serverless and containerization (to name a few) can be considered as results from the demand to make software development safer and more efficient in spite of increasing change rate.

All these topics are mainstream for years in other languages and platforms but don’t play a role in ABAP development, no matter on premise or cloud. One major reason out of many major reasons is that the ABAP platform lacks something like a “build and deploy circle” of software. Every code change is done in the same centralized system.

The ABAP platform is in no way a competitive for software development.

As long as you are developing minor additions to SAP standard that remain stable over time (“fire-and-forget-development”) these shortcomings do not play a large role and only on premise they are often outweighted by the ease of integration e.g. with ERP data. But if you are planning to develop software that evolves over time, especially after go-live, the choice of a development platform like ABAP that has never been designed as a development platform from ground up is a choice that will eat up high costs for development, setup of development environments, manual testing… compared to other languages and platforms.

Although this view is shared by many people inside and outside SAP who know both sides, this cannot be sold and marketed very well. What is selling better is the vision that ABAP will have a great future in the cloud. IMHO this is likely to become a disservice to many ABAP developers. They are losing time that could be spent learning modern languages, tools and development mindset. They may not get budget and time for training because managers may think that their ABAP knowledge is sufficient to compete in the cloud.

The situation regarding ABAP may be compared to the Java story at SAP several years ago: SAP Netweaver Java came into market with a large amount of marketing hype and fanfare but failed in user acceptance. This is because it could not compete with alternatives like JBoss or WebSphere. Netweaver Java decayed to a platform for XI/PI/PO and Enterprise Portal and was cut off from further technological progress after around 2010.

This mislead customers that ABAP would be superior and Java and other modern development tools and paradigms do not play a role at SAP customers. Years have been wasted without building up knowledge etc. that cannot be made up easily.

We find the same situation today with ABAP in the cloud. Like FORTRAN continues to be for climate simulation, ABAP will remain in its niche as on premise language and maybe language for small “cloud extensions.” But it will not be a competitive platform for cloud development. And as is the case around 8 years ago, SAP consultants do not preach that you must not lose more time to learn Java, Python, Jenkins and other stuff.

ABAP in the cloud is a stripped version of ABAP on premise. What does this mean?

There is no way to port on premise ABAP development into the cloud. Every line of ABAP code written today on premise (=99.9999…%) prevents the move of an ERP system into cloud. The opposite for on premise applications e.g. in Java on premise: they can be moved into cloud, containers, and so on. Customers have to decide: shall I start new development in ABAP – with the consequence that not only my ERP system but also my own development will stay on premise forever – or shall I start future proof with another language?”

How would SAP customers gain access to the information provided by Rolf in the quotation above?

Reading Censored Books on ABAP

You can read all of these books on ABAP. You can read all the books on ABAP, and not one of them will explain the quotation above or how SAP uses ABAP to control their customers.

This is because these books are written by ABAPers (that would never write such a thing in the first place), and most of them are published by SAP Press – which is essentially SAP’s captive publisher. They are in on keeping the story clean. You, the reader, are the mark, useful to be told a partial story that makes SAP in the words of SAP Press when Shaun Snapp’s book was censored.

“Our job is to make SAP look good!”

SAP Press, nor nearly all of its authors care what is true. SAP Press exists to sell books that promote SAP.

ABAP Coming to the SAP Cloud Platform!

The description of this video on YouTube is, “During his SAP TechEd keynote, SAP CTO Björn Goerke announced ABAP as the next environment added to the SAP Cloud Platform. A new, modern version optimized for cloud, ABAP” A lot of what SAP does have no other purpose than to make a marketing splash. This ABAP in SAP Cloud is essentially this type of announcement.

SAP is locked into ABAP and has no choice today what language to use in their ERP, SCM, BW due to an enormous amount of code generated for 50 years by SAP and by customers.

Embedded Languages

Embedded languages were the trend when ABAP was first developed. Even MS Excel has its own embedded language – VBA.

For SAP, it solved three core challenges:

Developers get less able to write “unsafe” code. That was done as supposed to. For instance, C++ is a powerful language, but as observed by Denis Myagkov, it provides a whole range of opportunities to shoot your leg off with your gun.
Ability to write platform and operational system independent code. At that time, there was a zoo of different platforms like mainframes and operational systems like FreeBSD and Solaris. ABAP was designed like JAVA.
Implement ABAP as DSL – domain-specific language. ABAP was inspired by another DSL popular in 1970-1980 – COBOL. ABAP has native seamless integration with many databases (Oracle, Sybase, DB2, and a few others).

So, for SAP’s solutions, ABAP is like JavaScript (JS) for modern browsers. JS also has DSL options like native support of JSON data structures that could be considered NoSQL Key-Value.

SAP has always promoted the use of ABAP on projects. If any customization was to be performed on an SAP project, SAP insisted that ABAP be used. Strangely, SAP customers very rarely pushed back on this, which we cover in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.

Customers could have developed in a non-SAP-specific language and then integrated it into SAP. However, they made a significant error in listening to SAP because now so many decades of SAP usage. Because SAP (particularly SAP ERP) is so highly customized, an enormous number of customizations are currently sitting in ABAP.

The SAP consulting companies make quite a lot of money on ABAP and therefore favor present and future customers using ABAP. It is essential to consider that ABAP is never justified based on any inherent benefits. Instead, it is used because it is what SAP recommends using. The SAP programming project environment is unsophisticated. While outside of the SAP world, different languages are used for their fundamental properties (samples are – selecting Python for mathematics tasks. Scala for more concise code that is Java compatible, Swift for speed, debugging capabilities, and compatibility with iOS and the Mac OS,) ABAP is selected because SAP says it should be.

The Issues with ABAP

And what SAP says is reinforced by all SAP consulting partners as the right thing to follow. What is very rarely observed by SAP resources is that ABAP is not used outside of SAP environments. That should tell anyone everything they need to know about ABAP.

The story laid out above has been the standard for decades in SAP, but recently outside events have caused a change that has impacted ABAP usage. The dominance of ABAP is declining inside SAP, and this is again related to the cloud. Instead of opening the ABAP stack for any platform like an on-premise app server, SAP offers to use other languages but on SAP Cloud. That is, rather than controlling the language. They want to control the runtime platform. Essentially, SAP is trying to control development by allowing a different language in the SAP Cloud again but locking customers into SAP Cloud.

SAP has controlled its projects by force-feeding ABAP into customers, basically taking advantage of their naivete. And this has allowed SAP to control those accounts. But with ABAP incapable in the cloud, SAP needs to maintain control, so they give up the language but force development into their cloud. However, when SAP presents the SAP Cloud to customers, it does not tell them any of this. Instead, it tells them that the SAP Cloud is completely open and invites comparisons to AWS. Notice the following quote, not from SAP, but an SAP-friendly resource on a LinkedIn comment.

“And do not forget that with SCP Cloud Foundry you could take advantage of BYOL (bring your own language); language does not matter anymore! Every developer is welcomed!”

Notice the implied assumption contained in this statement. The implication is that SAP is now allowing its customers to use the computer languages that they want. But the question should be:

“When should that not be the case?”

Do We See a Similar Type of Control at AWS and GCP in Code Selection?

Since when does a packaged software vendor have the right to tell a customer what language they should use for coding? Notice that AWS and Google Cloud do not have this type of assumption.

Observe Google Cloud’s programming language page. The first language listed is Go, which is a Google-created language. However, the rest of the languages listed have nothing to do with Google. They are just popular languages. They are also the language used outside of Google Cloud. There is no implication that this is some gift from Google. Google makes itself compatible with many languages.

Google Cloud offers several APIs for its services. Google explains how to use each of these with Python in this example screenshot. However, Google explains how its APIs work for all the languages it offers support for as well.

There is nothing like this on Google Cloud. This is why statements about openness by SAP to non-SAP technologies fall flat once you peek below the surface. SAP and Oracle come from a mindset of cutting off options, and they can’t seem to change that mindset for anything but their marketing contentions.

SAP is at a curious crossroads with ABAP.

Clients are unable to customize their systems in any other way except with ABAP.
SAP has stopped ABAP development and shifted focus to its SAP Cloud, Hybris, and so on, where all code is in Java. ABAP was designed as an embedded language for SAP ERP/SCM/BW, and proposals integrated into the cloud are inaccurate.
SAP relies upon the lack of programming understanding on the part of people that receive the message of ABAP portability to the cloud to allow it to be a credible statement.
SAP’s non ABAP code usage is minimal compared to its ABAP code usage.

The Problem with ABAP and Cloud

SAP is facing a brick wall with the cloud. They are so accustomed to dictating the programming language and environment to customers that they do not like at all the fact that ABAP does not work well for the cloud. Moreover, the cloud is the future. SAP has tried to promote ABAP for the cloud. Björn Goerke, SAP’s Chief Technology Officer, announced the availability of an ABAP development and runtime environment on SAP Cloud Platform in September of 2017 SAP’s TechEd. There are some reasons why this will amount to very little.

The Enhancement Framework used in on-premise ABAP is not allowed in the cloud as multiple tenants share the same core code. This means that most existing ABAP-based solutions cannot be ported to the cloud without significant refactoring – if at all. This is probably the first thing that comes to mind when reading about the introduction of ABAP in the cloud.
A common cause of SAP project failure is recreating legacy applications in SAP. People naturally want things to work in the same familiar ways. Most ABAP language elements that have been used in on-premise development are no longer allowed in SAP Cloud. Even the most basic data access elements, like tables, are not included as whitelisted objects, which means that an ABAP statement referring to a standard ABAP table will cause a syntax error. You must use a whitelisted API to access any underlying tables. This approach is radically different from ABAP on-premises, where you can access almost any ABAP repository element, even if it was never intended for use in custom code.

A lot of what SAP does has no other purpose than to make a marketing splash. This ABAP in SAP Cloud is essentially this type of announcement. If you review Bjorn Goerke’s statement at TechEd, as soon as he announced ABAP, the crowd erupted in a cheer. Is it practical? Who cares? The important thing is that it sounds good and is trendy. Plus, Bjorn announced while wearing a Star Trek shirt. Take that, AWS!

SAP Cloud is not much more than a marketing object. It is a piece of cheese tied to a string, with a rather nasty surprise if you nibble on it. Try using the SAP Cloud, and you will give up very quickly. It is cloud facia, faux cloud, etc…choose your phrasing.

SAP Cloud receives a lot of marketing funding, but on SAP projects, it is a non-factor. It does not come up in discussions. SAP is so locked into its previous investments that it can’t change. It knows that as soon as it begins to incorporate outside influences, its account control drops. It must also force-feed large amounts of billing hours to an army of consultants or face the reality of no longer being recommended. Everything in SAP’s strategy is about defending its on-premises business model from openness, dramatically shrinking the SAP ecosystem.

SAP has many customers who cannot do any independent research and find Deloitte or Infosys to be “good sources of information.” SAP can milk that account base for many years, and the best way to do this is to block out alternatives like AWS and Google Cloud. Allowing these alternatives into “their accounts” opens a crack into a fantastic world that undermines SAP’s hard-fought account control. SAP needs, to the degree possible, to impede customers from experimenting with these options. Moreover, SAP’s consulting partner ecosystem will help SAP do precisely this.

The Relationship Between Closed Systems and Profit Margins

SAP’s system is closed from multiple dimensions, just how closed usually is not discussed in polite company. When SAP consultants speak of the fabulous “SAP ecosystem” and “standard SAP” or “certified SAP solution,” there is never the slightest hint to the term “closed” or “sectioned off.” The prescription of ABAP to customers is just one manifestation of the closed nature of SAP.

High Integration Overhead: SAP is the most complicated system in which to integrate other applications (SAP ERP only integrates with other SAP applications with significant difficulty).
Indirect Access: SAP uses indirect access to instill fear into companies about connecting non-SAP systems to SAP.
Partners Lobbying Against All Non SAP Solutions: SAP consulting partners talk down all non-SAP solutions to their clients, vastly overstating the TCO impact of integration. This is done entirely because of the financial benefits to the consulting partners.
Co-option of Open Source Components: SAP routinely introduces “SAP-ized” versions of open source tools and components.

The list of restrictions and controls in SAP would be its small book.

All of this is for a fundamental reason. The SAP must keep its system closed to retain its margins. Accepting open programming would have meant opening SAP, and this is inconsistent with SAP’s decades-long strategy. Once you don’t control the development language, you lose control of what the rules are for interfacing with other systems. That is, unless SAP plans to ratchet up indirect access threats even higher. However, SAP knows that if a significant case is brought against SAP for indirect access in the US, they have a perfect chance of losing. Teradata has already challenged SAP’s use of indirect access in a lawsuit as contradicting US antitrust law. Therefore, like Oracle, SAP prefers to bring claims that cannot stand up in court on an individual or customer-by-customer basis without having the legality of it tested in each country.

SAP’s management knows that it is not feasible to try to bring ABAP into the modern world. Therefore they have moved the control to the cloud. Fiori is another example of SAP’s need for control. Fiori provides Smart Widgets. These work together with the particular OData flavor provided by the ABAP backend, e.g., CDS Views. It would be terrific work to provide similar OData services, e.g., on a Java Stack. However, SAP will not do this.

Setting the Trap With Trendy Bait

The SAP Cloud website’s main page has an alphabet soup of trendy items (IoT, Machine Learning, cloud integration services), all things that SAP has little to nothing to do in reality. This is designed to be tantalizing. It is designed to get customers to move and perform development using the SAP Cloud Platform before understanding the consequences and how they will be limited if they take SAP’s bait.

The SAP Cloud Platform has been around for several years now. It was renamed from the SAP HANA Cloud Platform. We previously critiqued the SAP HANA Cloud Platform in the articles Is SAP HANA Cloud Platform Designed for HANA Washing? And Is SAP HANA Cloud Platform Designed for Cloud Washing? Reviewing the new incarnation now, it does not look much different, except the name has been changed, and a few things like “apps” have been integrated.