Why SAP Customers Followed SAP’s Advice on Coding

ByShaun Snapp

Executive Summary

  • SAP provided biased and self-serving advice when it recommended that customers use its inefficient coding language.
  • We evaluate why SAP customers accepted this advice.

Introduction

In this article, we will review a mostly unpublished area in the history of SAP. And the fact that it is unpublished brings up interesting questions about who benefited from the present state of SAP development at SAP customers.

Setting the Stage

When one talks to SAP customers and the subject turns to custom development, the discussion around ABAP, which is SAP’s proprietary coding language, ensues. ABAP has the following attributes:

  1. It is the “standard” development language in SAP.
  2. It is nearly always used for SAP customers.

But the question that is not discussed is…..

Why Was Customer Development Programmed in SAP’s ABAP?

Any programing language and any set of programming tools or development environment can be used as long as that environment/PaaS can be connected to SAP. Ten years ago, these easy connections to SAP were less common, but today they are becoming more and more available. This means that custom development can be performed without ABAP. Yet, it is still rare for this to be the case.

Why?

Some insights as to why this is the case can be found in the SAP sales process. The standard sales process and implementation process at SAP is the following:

  1. Overselling Applications: The application begins by being significantly oversold. While most of my career has been as an SAP implementation consultant, I also worked as a pre-sales resource, and therefore, I participated in several SAP sales pursuits. With confidence, the information presented by SAP account executives (salespeople) is quite high. Other vendors also exaggerate the scope of coverage offered by their applications, but SAP’s exaggeration happens to be higher than most.
  2. All Requirements Can be Met: A big part of SAP’s oversell states that standard SAP functionality covers all requirements or almost all the requirements at the prospect. The first reflex of SAP sales to whatever question the customer has regarding a requirement is to say, “We can do that.” And executives don’t have enough understanding of the details of business requirements to validate whether what is shown in demos can meet their requirements.
  3. Implementation: The “Surprise” Phase: After the requirements have been gathered, it becomes evident that SAP misleads to the prospect during the sales process, and the executives did not bring a sufficient understanding of the requirements to the sales process. At this point, the implementation consultants begin to pressure the customer that their requirements are wrong and that they need to use standard functionality. Several standard methods are used to convince customers that they don’t need to use their requirements (one being best practices, the other being reengineering) show links.
  4. “Ztables and ZPrograms”: Once customer development must be written, SAP has a rather bizarre and misleading terminology used by SAP consultants to hide this fact. They use the terms “ZTable” and “ZProgram.” A strange sentence will be constructed that goes like this. “We can meet that requirement, but it will be a ZProgram.” This is coded communication for the fact that a custom object must be created in SAP. SAP and SAP consulting companies are cautious not to present code outside of SAP as an option to customers. According to SAP, all customer development must be written in SAP.

This brings up an interesting question…

Why Use ABAP at SAP Customers in the First Place?

Let us review some foundational assumptions.

  1. Scenario 1: Bringing something to the Table: If a vendor is offering a packaged solution, it makes sense that the vendor dictates that the customer of their application follows specific rules regarding how the application works. That is, they are bringing “something” to the table.
  2. Scenario 2: Bringing Nothing to the Table: However, if the vendor is not bringing anything to the table as part of a packaged solution. That is, they offering a development coding language, various tools. Why is it necessary to use what the vendor “prefers” or “highly recommends” the customer to use?

What if the customer already has development tools that it is comfortable with? What if the vendor is not offering a competitive coding environment?

Let us review the backdrop once again.

  1. What Was Purchased: The customer purchased SAP to gain access to their packaged software.
  2. Coming Along for the Ride: The ABAP and various coding tools and methods came “along for the ride, ” but they were not really what the company was buying or attracted them to SAP. The evidence? No company that does not have SAP codes anything in ABAP or uses any of SAP coding tools. That is, SAP coding tools have no following outside of SAP accounts. Hmmmmm…..that is strange. It is almost like the SAP development language and tools are not competitive.

Estimating ABAP’s Productivity

Developers I speak with who have experience with multiple computer languages often refer to ABAP as the worst computer language and the worst tools they have ever worked with. It is widely considered a massively inefficient language in which to work. That is, unless you bill hours as an ABAP developer, quite peculiarly as it happens, then those people seem to think it’s quite good.

Should SAP Even Be Using ABAP for Coding its Applications?

SAP has had significant problems in developing new applications, and one of the reasons for this lack of productivity is the overhead that ABAP imposes.

  • Comparing SAP Development Versus Other Vendors: I know plenty of software vendors with very high development productivity levels. I observe how they can develop functionality versus how SAP can develop functionality, and there is no comparison. When I ask them, they tell me that one of their advantages is choosing the development platform that they think is best.
  • Being an SAP Developer: SAP developers cannot do that. They must use ABAP or find another company to work for.
  • R&D Efficiency: SAP brags about how much it places into R&D, but the input does not equal output. Whatever SAP’s development organization is doing, it is not leading to product development outcomes. ABAP seems like one of the likely reasons for this (there are quite a few reasons I could get into, but that is an entirely different topic).

Therefore, it is bad for SAP customers to use ABAP. There is no reason for SAP to use it — except that it is a legacy for SAP as all of their internally developed applications are developed in it.

One example of this is S/4HANA. S/4HANA is SAP’s considerably delayed new version of its long-running ERP system. S/4HANA appears to be taking forever to finish. There are often 300,000 lines of code that have to be rewritten from ECC as any experienced programmer will tell you, the less efficient the coding language, the more lines of code it requires to complete a program. Yet, many people in the SAP community throw around the 300,000 lines of code quotation as if it is a badge of honor. It is also used as an excuse as to why S/4HANA is taking longer than expected. I am often told by SAP supporters that.

“rewriting 300,000 lines of code does not happen overnight.”

My response is that

“SAP should have thought about that before they the announced the product years too early.”

This is a constant feature in the SAP space. First, an exaggerated claim is made, then when the claim is exposed as false, the SAP resource admonishes the observer of the inaccuracy for their naïveté. If it were so obvious that it would take longer to complete S/4HANA, why didn’t SAP change their public statements? It seems like SAP, not outside observers, needed to be aware that it is not so fast to change 300,000 lines. And pointing out the complexity of adjusting 300,000 lines of code does not change the fact that SAP missed its deadline.

Code Quality

Switching to the topic of code quality, SAP has very significant quality problems in the products it has internally developed.

It is now prevalent for documented functionality not to work. This means that SAP contains a lot of broken functionality, functionality that consultants like me have to stumble upon, go back and forth with SAP support, and generally consume time to troubleshoot.

SAP support has developed a way of running you around in circles and being careful not to admit that the functionality is broken but that there must be other factors at play. I have worked with many applications, and I have never witnessed anything like the number of SAP problems from any other software vendor. The functionality problems will persist for years.

Companies have hired me to get functionality working that is also broken at several other accounts I have worked on. They hope that one “platinum” consultant can come in and fix it for them. Hope springs eternal in the SAP customer space, and every next version of the software will fix their current application problems.

Years of Broken SAP Functionality

For example, I found one issue related to SAP’s optimizer, which had a field that supposedly switched the processing to parallel processing. I activated this field for several years, thinking I was performing parallel processing. After testing the difference, I found that the field did not connect to anything (those interested can read the details in this article). After reviewing the development history, it turned out that it had never worked and that the field was never removed.

And that this had been the case for nine years! (however, it made little difference, I suppose, as the optimizer does not work with or without parallel processing).

There are some obvious productivity problems with ABAP. One significant and an instead visible item is that ABAP is proprietary, and the final objects created in ABAP are less shareable than if created in any nonproprietary language.

Does this sound like a development language that companies need to be adopting? Does SAP’s internal development effectiveness argue for the use of ABAP in SAP customers?

The Faulty Logic of Accepting SAP’s Proposal on ABAP

SAP is about locking customers in, and this has always been true. You can’t understand SAP without understanding that they are fundamentally about account control. Quite obviously, enlarge their control over the account stipulated that development should be performed in SAP.

But why do SAP customers so passively accept SAP’s proposal?

Why would I want to maintain multiple coding PaaS systems, each recommended by a different packaged software vendor? What is the expertise that packaged software vendors bring in PaaS selection?

*As a note, the low code provider Outsystems has been infested by what is commonly known as a “Bozo Explosion,” which we cover in the article Harvard MBA Syndrome Definition (AKA Bozo Explosion). Therefore, while we had an Outsystems example here earlier, we no longer recommend Outsystems or any low code environment. Our view is that low code providers have drastically overstated the concept of the citizen coder and that furthermore, they know they are lying about this topic, as they have the first-hand experience with taking non-developers and converting them into “developers.” 

The Rise of PaaS Environments

Platform as a service or PaaS is greatly enhancing developer productivity. Still, these productivity increases are not available to SAP customers as they must use SAP’s PaaS — called HANA Cloud Platform. (one of the primary reasons SAP introduced the HANA Cloud Platform was to seem more cloud-oriented — as you can read about in the article Was the HANA Cloud Platform Designed for Cloud Washing?) Once again, you don’t use the HANA Cloud Platform (now called SAP Cloud) unless you are an SAP customer.

But why have SAP chosen your PaaS if all you wanted in the first place was their packaged solution?

The SAP Consulting Companies and Jumping on the ABAP Money Train

Now is the right time to move to the discussion of SAP consulting companies. Let us begin by asking this obvious question.

Did the SAP consulting companies ever contradict SAP on their proposals on using ABAP and in getting deeper and deeper under SAP’s control?

Surprise surprise, no, they did not.

Quite the contrary.

The SAP consulting companies liked this approach because it allowed them also to sell SAP development resources. And because ABAP and SAP’s coding tools are so inefficient, it meant the maximal of billing hours.

  1. Attaining the Quota: SAP consulting companies have a twofold issue with looking out for their customer’s interests. First, their business model places enormous pressure on the partner level to sell services. This means they have a disincentive to do things more productive as it cuts billing hours. If you spend time with senior members of SAP consulting partners without the customer present, the discussion usually is not about the solution’s effectiveness. It is about how many resources could work the project, how long they could stay on the project, the customer’s perceptions, the customer’s budget, etc. That is, senior members within the SAP consulting partners and the more significant consulting partners are pressured into putting the commercial aspects ahead of the solution.
  2. Being Part of the SAP Partner System: Secondly, they are part of the SAP partnership ecosystem, following SAP’s directives. As part of this, SAP demands that you repeat everything they say to the customer. No deviation is tolerated.

This brings up the question once again of the purpose of these SAP consulting companies. They cannot question anything SAP says, and they merely continually lead to poor decisions, decisions that lock customers into the least efficient ways of doing things. If the SAP consulting companies had a catch-phrase, it would be…

“But it’s not standard SAP; it must be standard SAP.”

SAP’s Unending List of Development Items They Want Customers to Adopt

oData, Dynpro, Fiori, HANA Studio, Visual Composer, HANA Cloud Platform, the list goes on. SAP is continually introducing new languages (WebDynpro, Floorplan Manager, Fiori, Lumira, BRF, etc.) almost yearly. Programmers are in constant fear of being left behind and dedicate evenings to learning these new languages. This leaves them no time to learn non-SAP stuff. This has turned into a significant downside of being part of SAP development.

Most are introduced with great fanfare. In most cases, a pollyannish book is printed by the ever willing and compliant SAP Press to help communicate to the market that whatever they have is “a thing.” Some books exist for SAP items with barely any following. There is a book on oData, which most likely has a minimal future. I am embarrassed to say that I purchased this book myself to see what the commotion was about.

And then, the development item introduced by SAP eventually declines in the marketplace.

I spoke to a UI vendor with 15 failed UI initiatives introduced by SAP in the past 17 years. After the presentation, they refused to give me the roster for publication because they feared retribution by SAP.

This is a common situation for SAP software partners. SAP has a habit of calling up software partners and threatening them with the loss of their partnership. Information released by software partners that is out of spec will often get you called a “bad partner.”

Closing Off Customer Options

One of the most significant issues is that SAP wants to make all of its offerings closed. So they make their offerings as incompatible as they can. Everything points back to SAP. But the problem is that the efficiency of code is, to some degree, dependent upon how open it is. SAP realizes that it must restrict this openness to make its offerings SAP-centric so that the monopolistic pricing approach that SAP has ridden to great heights can continue. SAP adores co-opting new IT concepts. For example, they have tried to get into Hadoop’s space. But once again, while they talk “open systems,” their offering is something called Vora, which is a “prioritized” version of Spark — which is a data connector between Hadoop and HANA. They have been since looking for low information executives to buy it and get “into the sandtrap.”

Once a company purchases Vora and connects its Hadoop instance to HANA, its Big Data project’s overall ROI will promptly nosedive. As soon as Accenture or Deloitte shows up to bring SAP skills as part of a coalition of the billing, problems begin. Do Accenture and Deloitte push Vora because it makes sense technologically? No, it is related to their profit maximization. 

It was introduced with great fanfare, but in our analysis adds no value to Hadoop. SAP would like to invade the Big Data space with proprietary solutions — to parasitize a space built on open standards and then created a castle around a portion it can charge monopoly rents.

This is how SAP works and how it has always worked.

Yet, when SAP consultants talk to you, they often talk about a “golden age of SAP,” but that new developments have had SAP lose its way (pick the topic, treatment of partners, of customers, development productivity, etc..). Well, this was the way SAP has worked even back to this supposed golden age.

SAP is continually promoting new development tools, however, outside of SAP consultants who happen to be billing hours in the tool, not adopted outside of SAP, and not considered of good quality.

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. But you have to spend some time investigating this and comprehend that many of the things SAP says are merely self-serving. And of course, actually sitting and speaking with your developers — rather than spending most of your time talking to other executives is also helpful.

  • Keeping in the SAP “Family”: SAP thrives on having its customers using 100% SAP to keep the customer continually investing in SAP as much as possible and allowing for SAP to control the account maximally. SAP and their surrogates want to keep telling companies how to do development, even though SAP has probably the most expensive development cost in the market.
  • PaaS: Particularly with the low-level coding PaaS environments on the market, it is high time to begin questioning SAP’s wasteful approach that does little but serves SAP.

References

https://whydoesitsuck.com/top-five-most-annoying-programming-languages/