Why SAP Customers Followed SAP’s Advice on Coding

What This Article Covers

  • Setting the Stage
  • Why Was Customer Development Programmed in SAP’s ABAP?
  • Why Use ABAP on SAP Customers in the First Place?
  • Estimating ABAP’s Productivity
  • Should SAP Even Be Using ABAP for Coding its Own Applications?
  • Years of Broken SAP Functionality
  • The Faulty Logic of Accepting SAP’s Proposal on ABAP
  • The Rise of PaaS Environments
  • The SAP Consulting Companies and Jumping on the ABAP Money Train
  • SAP’s Unending List of Development Items They Want Customers to Adopt

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 what is 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 as 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 a number of SAP sales pursuits. I can say 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 is stating 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 that “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 actually meet their requirements.
  3. Implementation: The “Surprise” Phase: After the requirements have been gathered, it becomes obvious that SAP mislead 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 receive pressure to pressure the customer that their requirements are wrong and that they need to use standard functionality. There are actually several standard methods used to try 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 simply coded communication for the fact that a custom object must be created in SAP. SAP and SAP consulting companies are very careful to not present the development of 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, then it makes sense that the vendor dictates that the customer of their application follow certain rules as to 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 are offering a development coding language, various tools, why 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 Actually 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 what 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 that have experience with multiple computer languages often refer to ABAP as the worst computer language, along with the worst tools that 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 its quite good.

Should SAP Even Be Using ABAP for Coding its Own Applications?

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

  • Comparing SAP Development Versus Other Vendors: I know plenty of software vendors that have very high levels of development productivity. I observe how they are able to develop functionality versus how SAP is able to develop functionality and there is really 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 input does not equal output. Whatever SAP’s development organization is doing, it is not leading to productive development outcomes. ABAP seems like one of the likely reasons for this (there are actually quite a few reasons which I could get into, but that is an entirely different topic).

Therefore, not only is it bad for SAP customers to use ABAP, there is really no reason for SAP to use it — except for the fact 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, and it is often stated that there are 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.”

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

It is now very common for documented functionality to not 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 to not 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 problems in SAP from any other software vendor, and the functionality problems will persist for years. Companies have hired me to try to get functionality working that is also broken at several other accounts I have worked on. They are hoping for that one “platinum” consultant who can come in and fix it for them. In the SAP customer space, hope springs eternal, and every next version of the software will fix their current application problems.

Years of Broken SAP Functionality

As an example, I found one issue related to SAP’s optimizer — which had a field that supposedly switched the processing to be 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 actually connect to anything (those that are interested can read the details in this article). After reviewing the history of the development, 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!

There are some obvious productivity problems with ABAP. One major and rather an obvious 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 not simply connect to SAP but develop in a competitive development environment such as an Outsystems? (I just came from Outsystems NextStep conference, so I have Outsystems on the mind)

You are looking at SAP function modules and SAP APIs within Outsystems. Outsystem can connect directly to SAP through their SAP connector where the SAP function modules are available.

SAP structures are created within Outsystems after the API is imported.

An application can be created quickly in Outsystems that has the full ability to update data in SAP. Now it can be easily connected with other data from other systems. It can be published so that it can be consumed by any number of applications.

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

The Rise of PaaS Environments

Platform as a service or PaaS is greatly enhancing developer productivity, but these increases in productivity 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 HANA Cloud Platform (now called SAP Cloud) unless you are an SAP customer.

But why have SAP choose your PaaS for you if all you wanted from them in the first place was their packaged solution?

Outsystems among some other PaaS environments reduce the amount of coding necessary. That is some of the “code” is actually adjustments made within the Outsystems development environment. Development environments can now be found that combine all these benefits for developers that save directly to low-level code.

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 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 productivity as it cuts billing hours. If you spend time with senior members of SAP consulting partners without the customer present, the discussion is normally not about the effectiveness of the solution. It is about how many resources could work the project, how long they could stay on the project, the perceptions of the customer, the customer’s budget, etc. That is senior members within the SAP consulting partners, and in particular, the larger 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, and this means 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 simply continually lead to the 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 and on. By is constantly introducing new languages (WebDynpro, Floorplan Manager, Fiori, Lumira, BRF, etc ect) almost yearly, programmers are in constant fear of being left behind and dedicate evenings to learning these new languages, leaving them no time to learn non-SAP stuff (like OutSystems). This has turned into a major 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 it is “a thing.” There are books that exist for SAP items with barely any following. There is a book on oData, which most likely has a very limited future. I am embarrassed to say that I purchased this book myself to see what the hubub was about.

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

I spoke to a UI vendor that had a list of 15 failed UI initiatives introduced by SAP in the past 17 years. After the presentation, they refused to give me the list 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 that is released by software partners that is out of spec will often get you called a “bad partner.”

Closing Off Customer Options

One of the biggest 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 “propreitized” 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 their Hadoop instance to HANA, the overall ROI of their Big Data project will promptly nosedive. As soon as Accenture or Deloitte show 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, its related to their personal 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 built 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, they are, outside of SAP consultants who happen to be billing hours in the tool, not adopted outside of SAP, and not considered of good quality.

Conclusion

SAP and their 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 actually be a developer or have a development background to figure this out. But you do have to spend some time investigating this and comprehend that many of the things SAP says are simply self-serving for SAP. 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 things that are 100% SAP to keep the customer continually investing in SAP as much as possible and to allow for SAP to maximally control the account. 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.

Future Research

This article is introducing this topic, but the issues of development productivity per environment can be demonstrated through research and comparison. It would be of interest to benchmark the development speed in Outsystems versus ABAP and other SAP development tools.

This could be a future research area for Brightwork. In fact, one of the future areas of research we are considering is a comparison of ABAP’s productivity versus Outsystem’s productivity.

References

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