Top 3 sources of technical debt in SAP ecosystems

SAP is known for its integrated, industry-best practices for business processes. However, these out-of-the-box processes generally do not meet the needs of organizations, so the system needs to be customized in order to meet unique business needs. 

The top three sources creating technical debts are:

• SAP customization
• ABAP development
• Development practice

SAP Customizations (a.k.a. non-core modifications)

Enterprises and their IT teams have spent time, money, and resources to ensure their out-of-the-box SAP implementation meets their organizational needs. A custom line of code is not a problem, however, as custom lines of code accumulate over time, organizations lose the ability to track the customizations within these 100’s and 1000’s of lines of code.

Further, SAP is considered a system of record, and organizations should not be building and accumulating unique processes in their system of record. The most recent major upgrade across the SAP technology stack in the SAP world have been moving from SAP R/2 to R/3 in the mid 90’s, i.e., moving from mainframes to the client-server technology and, subsequently, moving from R/3 to ECC / Business Suite in the mid-2000’s.

Many customers have been running SAP since R/3 and that means any customization that customers have put in place in R/3 have moved to ECC and will now likely move to S/4HANA. That means thousands of custom objects, or technical debt, per SAP instance will need to be remediated and moved to S/4HANA. These customizations can be considered technical debt.

ABAP development of customized business processes

S/4HANA is the latest product from SAP that has been built on HANA database. S/4HANA is built on ABAP (Advanced Business Application Programming), which was modeled after COBOL in the 1980’s and introduced in SAP R/2.

Since its introduction, ABAP has been SAP’s core language of choice for building all of their applications. That is not necessarily a negative, but issues typically surface when customers write custom programs for their own needs in the ABAP language. ABAP is nearly 40 years old and quickly becoming the oldest coding language in use. Read more on ABAP Development Tools for SAP NetWeaver.

This has created a shortage of qualified experience ABAP developers. In fact a 2020 Indeed market research showed that ABAP developer is the second most in-demand tech job in the market. With SAP ABAP Developers are earning the highest salaries, with an average annual salary

Developer productivity when building in ABAP has not changed, even as new development tools have come to market. Some organizations are evolving and beginning to adopt new technologies, like low-code software tools that provide drag-n-drop development capabilities. However, many other organizations are stuck in their ways using ABAP, which requires intensive coding skills from a dwindling pool of professionals.

SAP is well aware of the problems that ABAP customization can cause. In fact, SAP introduced the Java stack in SAP NetWeaver in the early 2000’s. They pushed the Java stack in all of their applications until Oracle acquired Sun Microsystems, the owner of Java. As a result, SAP moved away from Java and has attempted to modernize ABAP. To SAP’s credit, they have made a concerted effort, and ABAP programs can now run in the SAP Cloud platform. That said, this does not solve the core issue of ABAP being an out-of-date language that is not suited for today’s world and the evolving workforce.

Development Practices

It is critical to define software development best practices. Unsurprisingly, this is extremely challenging within SAP because custom lines of code are created over a number of years by various contributors, such as in-house staff, consulting firms, contractors, and offshore developers. As a result, it is very difficult to design and implement consistent development standards, such as naming conventions and documenting the logic and variables.

Given that most SAP installations are 10-20 years old, it’s also likely that programmers have lost the tribal knowledge required to maintain custom developments. Some of the customizations may be so large that they could be considered stand-alone applications. With so many hands involved in writing the code, it is highly unlikely that all of the developers were capable of writing quality ABAP code.

The inefficient and inconsistent development practices create technical debt. To be honest, technical debt, by itself, is not always a problem – but significant problems will come up as the complexity and amount becomes unwieldy. These issues are directly tied to the amount of custom code.

Do you know how much technical debt your custom SAP code costs you?

Use our free interactive technical debt calculator to find out.