Why custom solutions?

Over 400,000 companies around the world use SAP systems as a basic business tool. One of the foundations of this success is the perfect integration of the ERP system with the development environment. This allows customers to create specific functions resulting from the needs of a given organization – the so-called custom software.

ABAP, a programming language created by SAP and dedicated to business applications, was used to build the ERP system and was made available in the form of an integrated development environment (the so-called ABAP development workbench). Several accurate assumptions underlying SAP’s custom development philosophy have provided partners and customers with virtually unlimited possibilities to customize and expand the system. These included:

  • making the entire system source code and data model available for developers to view,
  • scheduling many places in SAP programs where the standard logic of the system can be extended by adding own ABAP code (so-called user exits – code fragments that will not be overwritten by subsequent versions of the system),
  • the ability to freely extend the system data model through additional fields (in standard SAP tables) or creating own tables.

Of course, there were also more typical tools usually included in enterprise systems, such as editors for designing forms, reports, and workflow processes.

Software development tools and practices have continued to evolve over recent decades. In 2023, we will not convince developers to use in their daily work the tools first introduced 30 years ago with the SAP R/3 version. On the other hand, SAP customers (many of them are the largest enterprises in the world) highly value the stability and predictability of the IT platform.

Subsequent generations of systems (from SAP R/3, through SAP ERP introduced in 2004 and S/4 initiated in 2015) have a very long period of manufacturer’s support and allow for seamless upgrades to subsequent generations, while keeping the data history and company-specific functionality.

This is why the approach of SAP to custom development is changing in an evolutionary way. It allows customers to use several different work methods in parallel and gradually move to more modern solutions. From the point of view of IT managers or developers, this is an advantage because a development created, for example, 10-15 years earlier does not have to be urgently rebuilt. At the same time, it poses some challenges to get a good understanding of the meaning and relationships between the coexisting “old" and “new" tools and work methods. In this article, we organize and present the main directions of this evolution and SAP’s motivation behind it.

Upgrade challenges

How to reconcile the extensive custom development capabilities available in SAP systems with the release of subsequent application versions? This situation is illustrated in the diagram below. It shows the existing approach to system expansion.

SAP upgrade according to the classic ABAP programming model

SAP provides a number of tools that support carrying out system upgrades, including custom software customization. Programs and other system objects, created or modified by customers, are automatically versioned. Any conflicts (between different versions of objects) that occurred when installing a new system release are clearly presented. This allows for managing the upgrade process in an orderly and predictable way. However, due to the large number of objects to be analyzed with each upgrade, projects to install a new version of SAP have so far been major undertakings lasting many months. Each time, customers had to consider whether it was worth using new functions (available in the current system release) in exchange for the workload related to the project.

In an era of widespread use of SaaS IT systems, we are accustomed to applications we use every day (such as Microsoft 365 or JIRA) being updated incrementally and regularly. New features are introduced to them every few months, without the need for multi-day reinstallations and system downtime. SAP is also trying to get closer to the ideal of “frequent and simple system updates". To achieve this, it is necessary to introduce a more structured approach that separates custom development from the standard SAP system code.

The standard data model and interfaces have been divided into objects “made available for external use” and internal objects. The definitions of objects made available will remain stable in the future and therefore custom development based on them will be compatible with future versions of SAP systems. This division is reflected in the data model (so-called CDS views, which we use in S/4 instead of direct reads/writes to the SAP database) and in the API programming interfaces published on the SAP Business Accelerator Hub website (api.sap.com).

Determining a set of API objects “made available” is of course not groundbreaking and seems… completely obvious at first glance. However, this is a significant change due to the existing possibility of more open access to the system code, a huge base of existing SAP custom development (for some customers: even 30 years old), which gradually needs to be adapted to this approach, and the habits of tens of thousands of ABAP developers.

SAP refers to its new approach as a clean core, i.e., the ability to more easily swap the system’s “core platform" for a new version by separating the customer’s development sphere from the system developer’s responsibilities (see diagram below). As a result, this significantly reduces the risk of conflicts and surprises during future updates, and allows the ERP system to gradually come closer to the ideal of “transparent" upgrades known to us from the SaaS model.

Clean SAP core approach

Evolution of the ABAP programming environment

Along with the general evolution of the approach described in the previous section, SAP has introduced a number of other innovations over the last few years. They allow full use of the capabilities of all versions of the S/4HANA system (on-premise, private cloud and public cloud). They also take into account the SuccessFactors SaaS platform, which is the successor to SAP HCM.

  • The successors to “classic ABAP" are three new custom development modes: in-app extensibility, developer extensibility and side-by-side extensibility; each of these modes offers a different range of possibilities and benefits; they can be used in parallel, within one system installation;
  • The Restful ABAP Programming (RAP for short) programming model, ensuring separation of data and business logic (back-end) from presentation logic (front-end) and communication with the server via REST API/OData protocol;
  • The existing ABAP Workbench development environment (the SE80 transaction in SAPGui) is being replaced by ABAP Development Tools (ADT), based on the Eclipse editor.

Three modes of extending S/4HANA and SuccessFactors functionality

In-app extensibility – sometimes also referred to as SAP Key User Extensibility – a mechanism for adding small extensions; it is the easiest to use of these three modes (hence the term key user in the name, although this seems to be a bit of an exaggerated promise; however, it is rather a mechanism intended for IT specialists but relatively easy to learn). In S/4HANA, we have more than a dozen types of in-app extensions, such as: additional fields in the database and on screens; additional processing logic in places designated for this purpose by SAP as so-called Business add-ins (BAdI); templates for forms and emails; simple reports (queries). An analogous solution in SuccessFactors is the Metadata Framework (MDF).

Developer extensibility – a direct successor to the existing Classic ABAP development; a comprehensive development environment based on ABAP Developer Tools (Eclipse), allowing you to create extensions that run inside S/4HANA instances.

Side-by-side extensibility – application development environment on the SAP BTP platform; custom development is here therefore technically separate but tightly functionally integrated with the SAP system; we have the option of using both the ABAP programming language and other technologies; BTP is the recommended environment for developing larger, more complex applications that extend the functionality of S/4HANA or SuccessFactors.

Each of the innovations mentioned is a broad topic deserving a separate article. Here I present them only in the form of an overview – as a list of matters that are worth paying attention to if we want to stay up to date with the current possibilities of custom development in SAP.

A good overview of SAP’s evolutionary approach to custom development in various versions and generations of the system is presented in the table below.

Evolution of custom development in SAP

What conclusions can be drawn from this overview?

  • if our system is still SAP ERP (ECC 6.0), we don’t have much choice, however it is worth at least getting acquainted with ADT as a successor to the current ABAP Workbench (SE80);
  • in the on-premise or private cloud version of the S/4 system we have the most comfortable situation; both “old" and “new" options are available; this may give a false sense that… nothing needs to be changed because Classic ABAP development still serves us well; however, the effort put into learning new extensibility modes will pay off in a short time in the form of higher developer productivity, and only in this way will we use all the possibilities offered by the S/4 version;
  • when we implement S/4 public cloud, we have no dilemma: if we have not yet familiarized ourselves with the new approach to custom development, we need to get started urgently, the traditional ABAP Workbench (SE80) is not available at all in this version.

Java, Node.js and other programming languages

ABAP allows programmers to achieve good productivity, however in the scale of the entire IT world it is quite a “niche" solution. Significantly more developers use Java, JavaScript/Node.js or Python. SAP has been supporting the integration of systems with software created in other programming languages (e.g. through the SAP Java Connector, .NET Connector libraries) for a long time. In recent years, SAP has been paying much more attention to this area when developing and promoting SAP BTP (Business Technology Platform).

From the point of view of developers, BTP is the equivalent of comprehensive cloud solutions such as Microsoft Azure, Amazon Web Services or Google Cloud Platform. Currently, it already offers more than 200 different services covering typical enterprise-class application development tasks:

  • application runtime environment for multiple programming languages,
  • storage and analysis of different types of data (relational databases, documents, geographic data, etc.),
  • mobile application support,
  • application integration,
  • user access management,
  • other, such as application monitoring, background task scheduling, etc.

A few scenarios in which custom development for SAP is recommended to be considered in programming languages other than ABAP:

  • we have applications that we do not want to “rewrite" from scratch in ABAP but to continue their development, while integrating them closely with SAP,
  • the organization has a team of programmers with competencies in other programming languages and wants to use this potential,
  • other languages are more popular and better supported in a specific field (e.g., availability of specialized programming libraries) – an example would be the use of Python in AI applications.

SAP BTP is the basis of the side-by-side extensibility approach and the clean core philosophy mentioned in the previous section (see diagram below).

SAP Business Technology Platform (BTP) vs. custom development

This helps clearly separate the development of dedicated applications from the installation of the ERP system. If we place our custom development on the application server in BTP and connect to the SAP instance via API, we will obtain the following benefits:

  • from the users’ point of view – the application is seamlessly integrated with the rest of the system, it appears as another tile in Fiori Launchpad, and does not require a separate login,
  • from an IT perspective – systems are separated in the technical layer, which facilitates monitoring, version updates, and division of responsibilities for administrative activities,
  • on BTP, we can develop applications in other programming languages, depending on the organization’s preferences.

It is worth noting that it is possible to connect a single application running on BTP with multiple SAP S/4 or Success Factors systems. Within one group of companies, this may be useful if we have a complex SAP systems landscape, but want to start centralizing some applications. However, providers of services and applications extending SAP functionality can install their products on BTP and connect many clients to SAP systems (the so-called multi-tenant solution).

Where to start?

Custom development – the creation of company-specific features – is carried out with virtually every SAP implementation or upgrade. Of course, we should implement SAP processes defined in the SAP Best Practices library whenever possible, as this is the fastest and most efficient use of a standard system. However, in the context of SAP systems we will definitely deal with at least customizing printout/e-mail forms, creating a few additional data validations or interfaces to other systems in the IT landscape.

SAP draws conclusions from decades of previous implementations and upgrades of systems in tens of thousands of companies. At the same time, it also takes into account the development of software creation practices, which are constantly evolving. It includes these conclusions in its approach to custom development for S/4HANA. This results in new possibilities and directions of development of the ABAP language and the SAP BTP platform described in this article.

The number of these changes and new capabilities – introduced in the relatively short period of the last few years – can be somewhat overwhelming at first glance. At the same time, it is worth noting that the development environment is becoming more and more open, and SAP is trying very hard to facilitate the development of the competencies of developers choosing this platform.

The free tier version of SAP BTP, combined with publicly available tutorials and documentation at developers.sap.com and api.sap.com provides entirely new possibilities. They were unheard of a decade earlier, when programming in SAP meant a large investment and a barrier to entry for new developers.

If you have not yet begun to explore these new areas, it is worth taking an interest in them as soon as possible so as not to be left behind. From the point of view of an individual developer – regularly updating one’s competencies is a prerequisite for remaining competitive in the job market. From the point of view of the company/SAP customer – this is the only way to fully take advantage of the possibilities offered by the current version of S/4HANA, which will definitively replace the previous generation of SAP ERP systems (ECC 6) in the next few years.