SAP Custom Code - The Pink Elephant in the Room

Every successful technology in the world creates technical debt. At first, you can think of it as a pink puppy, small and manageable, but hard to ignore. As the technology matures, the pink puppy grows into a dog, transforms into something more on par with a pink horse, and then eventually becomes the proverbial pink elephant. Big, always present, but something that everyone tries not to talk about. In the case of SAP users, the pink elephant is all the customizations and SAP Custom Code development in their SAP instances.

In the early days, (i.e., 1990s and early 2000s) these customizations were limited to Advanced Business Application Programming (ABAP). Customizations in ABAP weren’t that big of a deal because they were limited to one language and although customizations were frequent, technical debt was manageable. Then came an onslaught of technologies from SAP, everything from SAP Portals and SAP MII at first too, more recently, UI5, OData, SAP Cloud Platform, Business Technology Platform, and many others. Now custom development work happens everywhere, from ABAP and OData to SAPUI5, JavaScript, HANA CDS, AMDP, Steampunk in BTP and the list keeps growing. These expanding customization options have created quite a few problems in the SAP community. Not only are technical resources specialized, which means fewer resources for each technology, but customization also becomes all the more complex, expensive, and difficult for the customer to maintain an SAP environment.

Going back to basics, every SAP customer bought the software for its immense power to execute complex business processes and, really, its ability to provide this capability out of the box. I doubt that any customer ever brought SAP to develop apps in ABAP, UI5, etc., or even realized the magnitude of customization they need to create.

Yet, all of the custom developments were absolutely needed to fill in the gaps between what SAP provided and what the business stakeholders wanted, making these customizations very important. They make the company and its processes truly unique and provide an edge in the competitive landscape. Businesses did nothing wrong by building these customizations, but now the pink elephant has grown so huge that it is hindering SAP customers’ speed.

To understand the size of this elephant, let's look at some statistics from a recent ASUG survey:- 

• 91% of SAP organizations use custom code in their SAP environment.
• 90% of custom code is done in ABAP followed by 55% in Fiori, 46% in Java, and 27% in UI5.
• 90% of this custom code is anywhere between “important” to “extremely critical” for these organizations to run their business.
• An average of $800K+ is spent on the most important 2-3 custom applications, every year. A typical customer has many custom applications (in thousands)  and sometimes multiple instances of SAP ERP. You can do the math on the total spend. Note that some Fortune 500 companies have 20-30+ SAP instances running in their organization and the cost only multiplies as the customizations differ in each instance.
• For 50% of the SAP organizations, the most valuable custom code was implemented 6 or more years or more ago. That means most likely that the resources who developed this code have moved most likely moved up the ladder (i.e., they aren’t developers writing code anymore) or moved to other organizations

The Challenge of Cloud Migrations as Part of Digital Transformation

One of the biggest challenges enterprises need to address are these customizations when they move to S/4HANA as part of their digital transformation journey. A lot of thought, effort, time, and money over many years has gone into these customizations resulting in many millions of lines of code and millions of objects. In many cases, that custom code is the life-blood of these organizations playing major roles in its mission-critical operations making it a huge risk to move it to S/4HANA. 

We all know SAP is aggressively encouraging its customers to move to S/4HANA. Gartner estimates the number of customers who have moved to SAP S/4HANA by the end of 2020 at 14%, but some accounts have the number as high as 33%. Regardless of the exact figure, there are still many SAP customers who need to move to S/4HANA this decade and will face these challenges. Some statistics that will help you understand the magnitude of this massive transformation: 

• 55% plan to move due to end-of-life of SAP ECC, and 48% for business opportunities.
• 80% of organizations think custom code is the biggest barrier to migrating or upgrading to a new SAP environment.
• As of Q1 of 2021, there are 220,000 ABAP developers across the globe. Compare this to 65,000+ SAP ERP installations globally and the number of SAP instances to be migrated with millions of lines of code and custom objects in each instance. (source: Slashdata)
• 71% of organizations struggle in finding expertise to maintain and enhance their custom code.
• SAP estimates the total cost of customizations and custom code will double with every new release of S/4HANA.

So why aren’t more companies taking action regarding the Elephant?

The big question is if such a large majority of the customers are having this problem that is hampering the transformation efforts, then why aren’t more customers taking action on it?

In my opinion, SAP realizes this problem and has been urging users to keep a clean SAP core. This is a topic of discussion in several SAP Forums, including one from SAP’s CTO, and there are multiple SAP partners talking about this - from consulting partners and software partners including low-code / no-code providers like Mendix and Outsystems. Although everyone recognizes this problem, no one has really come forward with an efficient solution to tackle this problem. 

The only solution that SAP and its partners offer is to dump their custom code and start afresh. Businesses can choose greenfield SAP S/4HANA implementation, building new ABAP customizations on SAP S/4HANA, or using third-party no-code/low-code platforms (like Mendix) which is an expensive affair and requires dumping the tribal knowledge behind existing customizations and starting from zero. Another option is a brownfield implementation with remediating as much custom code as possible, but bringing the same technical debt into S/4HANA., which means your SAP instance will not be clean, to begin with. With many, many years of effort, time, and money spent on these mission-critical customizations, neither of these really addresses SAP users’ basic concerns of handling custom code. 

How to Deal with SAP’s Custom Code Pink Elephant

SAP customers need the best of both worlds, leveraging all the legacy investments they have made in these mission-critical customizations as well as keeping a clean SAP core, irrespective of which SAP version (ECC or S/4HANA) they are running. Spending millions of dollars along with the inherent risk of making changes to mission-critical customizations should not have to be a precursor to reducing operating costs by having a clean SAP core or accelerating their pace of digital transformation.

Honestly, this is not too much to ask. Technology has come a long way since the early days of SAP to solve this problem. If technology could be the savior for humankind to survive this pandemic, then solving this pink elephant is relatively easy and simple. All we need to do is:

1. 1. 1. 1. Recognize and start talking about this pink elephant openly 
         2. Identify and measure the size of this elephant
         3. Start chopping off in small chunks to reduce the pink elephant to a pink horse, a pink dog, and maybe a pink puppy

We at Pillir have spent years working on addressing this pink elephant. We provide a dashboard that not only sizes your pink elephant in technical terms but also in financial and business terms, i.e., how much these customizations cost and where they really impact your business. Once you identify your biggest pain points, we provide tools to slowly but surely remove those customizations from your SAP system automatically and convert them into cloud-native applications without losing any capabilities for your business stakeholders. In fact, most customers actually enhance these custom processes to meet current and upcoming business needs. And all of it is done using a visual, building-block drag-n-drop model based on MIT’s Scratch model (originally built by MIT for kids from are 8-16 years old.). 

This not only brings you to a clean core, no matter what SAP version you are on (ECC, Suite-on-HANA/HANA Business Suite, or S/4HANA), it reduces your business risk by addressing these customizations one-by-one and reduces your cost, time, effort, and resources in moving to S/4HANA.

Final thoughts on SAP Custom Code

Realistically, I don’t think anyone can really get rid of all customizations in their SAP environment, but it is a hell of a lot easier to take a pink puppy with you to the new SAP environment instead of dragging a large pink elephant.

My hope is to initiate a discussion in this forum about this big problem and collectively find ways and means to solve this. Looking forward to your comments and feedback.