- SAP has an enormous investment in ABAP. But ABAP has serious restrictions for the cloud.
- SAP is trying to push customers to use ABAP in the cloud.
SAP and ABAP and the Cloud
In order 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 when compared to modern high-level languages, and there is a healthy debate to be had as to whether ABAP is a true computer language or more of a framework. Interestingly, ABAP was originally 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 actually quite good, so we have included part of 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.”
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 premeditated choice in the part of SAP. ABAP allowed SAP to do was to more effectively control accounts 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 almost never 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 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 propose a single universal database, but 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 is lacking from SAP projects. To understand ABAP and how the story provided by SAP mutates, it is necessary get a perspective from a person who can write ABAP, but also someone who is 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, who is one of the few people with ABAP exposure who provides historical context concerning ABAP. What he has to say about ABAP and 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!”
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 has 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 enormous amount of code that was generated for 50 years by SAP and by customers.
Embedded languages was the trend when ABAP was first developed. Even MS Excel has its own embedded language – VBA.
For SAP it solved 3 core challenges:
- Developers get less able to write “unsafe” code. Actually, that was done as supposed to. For instance, C++ is the powerful language, but as observed by Denis Myagkov, it provides a whole range of opportunities to shoot your leg off with your own gun.
- Ability to write platform and operational system independent code. At that time there was a whole zoo of different platforms like mainframes and operational systems like FreeBSD and Solaris. Actually ABAP was designed like JAVA.
- Implement ABAP as DSL – domain specific language. ABAP was inspired by another DSL popular in 1970-1980 – COBOL. In addition, ABAP has native seamless integration with many databases (Oracle, Sybase, DB2 and few other).
So, for SAP’s solutions ABAP is like a Java Script (JS) for modern browsers. JS also has DSL options like native support of JSON data structures that could be considered like 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 to the customer that ABAP be used. Strangely, SAP customers very rarely pushed back on this, which is something that 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 simply integrated into SAP. However, they made a significant error in listening to SAP, because now so many decades of SAP usage, and because SAP (particularly SAP ERP) are so highly customized, an enormous number of customizations are sitting currently in ABAP.
The SAP consulting companies make quite a lot of money on ABAP and therefore are in favor of present and future customers using ABAP. It is important to consider that ABAP is never justified on the basis of any its 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 (for instance, 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 of the 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. Now, 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 again control development by allowing a different language in the SAP Cloud, 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 from an SAP friendly resources 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 language used outside of Google Cloud. There is no implication that this is some gift from Google. Google makes itself compatible with a number of languages.
Google Cloud offers a number of APIs for their services. Google explains how to use each of these with Python in this example screenshot. However, Google offers an explanation of 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 really 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 by any other way except with ABAP.
- SAP itself 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 that it will be 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, as 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 at 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 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 the announcement by Bjorn Goerke 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 made the announcement while wearing a Star Trek shirt. Take that AWS!
SAP Cloud is not much more than a marketing object. 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, which would dramatically shrink 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 is normally 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 to SAP.
- High Integration Overhead: SAP continues to be the most difficult system in which to integrate other applications (in fact SAP ERP only integrates to 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 as talk down all non-SAP solutions to their clients vastly overstating the TCO impact of integration. This is done entirely because 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 own small book.
All of this is for a fundamental reason. SAP must keep its system closed into order to retain its margins. Accepting open programming would have meant opening SAP, and this is inconsistent with SAP’s decades-long strategy. This is because 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 very good chance of losing. Teradata has already challenged SAP’s use of indirect access in a lawsuit as being in contradiction with 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 main page of the SAP Cloud website 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 to perform development using the SAP Cloud Platform before they understand 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 like much different, except the name has been changed and a few things like “apps” have been integrated.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other SAP Custom Code Content
AWS and Google Cloud Book
Interested in how to use AWS and Google Cloud for on-premises environments, and why this is one of the primary ways to obtain more value from SAP and Oracle? See the link for an explanation of the book. This is a book that provides an overview that no one interested in the cloud for SAP and Oracle should go without reading.