Transformation of the ABAP Developer

Table of contents

• Introduction
• Creeping Change
• Fiori
• BTP
• Composable ERP
• Clean Core
• IDE
• SAP Developer
• Extension
• Toolbox
• Technology
• ABAP
• Frontend
• Addons
• RAP or CAP
• Conclusion

In this article, we look at the changes in the role of the ABAP developer and how an ABAP-only focus evolves into an SAP focus.

 

Introduction

As ABAP developers, we have primarily focused on extending SAP ERP systems. We have written reports for evaluations, designed more complex GUIs to support the requirements of the business department, and linked SAP systems via RFC and IDOC to create complex structures within companies. Of course, modification was also a key aspect. The business department urgently wanted a new button in its standard transaction to easily inform colleagues about processing updates. Then came a form here, a workflow there, and a transformation via LSMW over there, which further specialized us as ABAP developers.

However, the focus was always on the ERP system and the SAP GUI as the overall picture for the ABAP developer. Almost all tools were written in ABAP and were operated and extended via the SAP GUI. Partners wrote their add-ons for the ABAP stack, which companies then installed and ran on their systems. But this was actually rather to the detriment of the partners, as there were so many different releases and possibilities that all had to be supported.

 

Photo from Chris Lawton on Unsplash

Creeping Change

Basically, nothing changed in this concept with the introduction of the first S/4HANA version; companies and ABAP developers could continue as before, unless they had already tried new things in the past.

 

Fiori

Fiori already existed in the ECC era, but it wasn't widely adopted by companies because the The main applications were still in the SAP GUI, and for the special use cases of attractive applications, a different developer than the ABAP developer was usually employed. Thus, initial implementations mostly emerged in the HR area for end users outside the SAP bubble. The ABAP developer was then usually needed to create the SEGW service and provide data; the UI was created by the Fiori developer and was usually more of a black box for the ABAP colleague.

 

BTP

Then there is also the Business Technology Platform. Introduced to provide a cloud infrastructure for companies, but also solutions that SAP itself can build upon. Various cloud services are provided, each handling specific tasks and often replacing an on-premises service. For example, when creating PDF forms, there's the Cloud ADS. However, each company should individually review and evaluate the services, as the ADS, for instance, has issues with mass document generation or is simply too expensive for a large number of documents.

 

Composable ERP

The term "Composable ERP" was coined at BTP. Not every service and application resides in a monolithic system (one large system), but is distributed across services, middleware, cloud, and on-premises infrastructure. Let's look at the solutions SuccessFactors and Ariba. These systems are cloud-based, no longer written in ABAP, but largely use master data from SAP systems. This means that components of HR and purchasing are distributed across different solutions.

 

Clean Core

Clean Core is currently a very prominent topic. It's not a technology in itself, but rather a collection of concepts affecting various areas. For us as developers, extensibility is particularly important, but there are also data, integration, processes, and operations. We use these to evaluate our extensions, determining which platform and tools to implement them on. This includes key user extensibility, on-stack with ABAP Cloud, or side-by-side in BTP. Clean Core also sets new standards and restricts existing technologies. While the current Clean Core Level Concept lifted the ban, the direction towards Fiori instead of SAP GUI is clear to most.

 

IDE

Formerly SE80, today ABAP Development Tools, and tomorrow VS Code? The landscape of tools has evolved in recent years and will continue to evolve. Today, the development environment is no longer just SE80, but consists of a multitude of tools that you need for your daily work. In the morning, the SPAU in the GUI, then finishing development of the new app in Eclipse and generating the UI with BAS. In the afternoon, adjusting the workflow in SAP Build Process Automation, backing up the data in Git, and carrying out the deployment via Cloud ALM. The tool landscape hasn't shrunk in recent years, and as developers, we need to be flexible.

 

Photo from Sigmund on Unsplash

SAP Developer

This also changes the image of the ABAP developer, who now has to develop further for many of their tasks. Therefore, from this point on, we would no longer speak of "ABAP Developers" but of "SAP Developers". Let's look at some different points on this.

 

Extension

One of the core tasks of the SAP developer will continue to be the extension of SAP systems. However, the methodologies, tools, and platforms will change somewhat. The new function will then no longer be implemented as a report, but as a RAP app. The workflow will no longer be created in the system, but, because cloud systems are also affected, in Process Automation. The standard is to be extended, then no longer by modification, but via Key User Extensibility or by using the standard service. Basically, we will continue to extend the standard systems for the customer in the future.

 

Toolbox

Our toolbox now contains not only the hammer, aka. ABAP, but additional tools have been added that we should look at and understand.

• Key User Extensibility - Extending the standard with low-code tools to bring customer-specific fields into the process. Implementation of BADIs or creation of customer-specific CDS via Fiori apps.
• Workflow - Modeling workflows with SAP Build Process Automation and using JavaScript to bring custom logic into the workflow. The workflows connect cloud and on-premise solutions and give us the ability to map decisions in the new world.
• Destinations - Setting up, maintaining, and understanding the Destination Service in BTP to establish a connection from cloud to on-premise. Ultimately, to consume the functions and services of the systems.
• Fiori Elements - Native development with Fiori Freestyle Apps costs time and money. Fiori Elements with native integration into RAP significantly increases the time to production for an app and should not be overlooked if you want to deliver a high number of applications.
• Web - Understanding how web communication and REST work. This forms the basis for understanding how the systems interact.
• Integration - Integration involves not only an RFC connection, but usually an interface, middleware, and protocols. Which of these work in your environment and which should you use for your application?

 

Technology

The technology stack has become much more diverse. You may still need to maintain classic applications in the SAP GUI or consider how to migrate them to the new Fiori world. As an SAP developer, this will give you a broader range of technologies to work with for the next few years. Your specific toolkit will also come into play.

 

ABAP

ABAP will very likely remain a central part of your daily work. It is still the business programming language for extending systems and can also be used in the cloud. Therefore, investing time in this skill is still justified and important. However, you will also need JavaScript, whether as a script task in process automation or for reading Fiori Elements applications. AI will certainly be able to help you understand the JavaScript code or find a solution. However, you are always responsible here as well.

 

Frontend

The "new" frontend is Fiori, and new applications can be created annotation-driven using the ABAP RESTful Application Programming Model. Therefore, Fiori Elements also belongs to the SAP developer and is slowly replacing the SAP GUI. Here, it doesn't really make much sense to separate the roles of ABAP and Fiori developers anymore. Currently, the "majority" of development is in ABAP and usually only the generation and minor adjustments in the frontend area.

 

Addons

Partners no longer need to provide the add-ons as an installation for an on-premise system. Products with the ABAP environment can now be provided as a SaaS solution. This keeps developers up to date with the latest technology, and partners no longer have to worry about outdated releases, at least as long as all standard interfaces are available.

 

RAP or CAP

Ultimately, the question always remains whether CAP and/or RAP should be learned. The SAP developer should definitely be able to master and implement one of the two models. Currently, however, we wouldn't recommend learning both methodologies. If you're now asking: Why not? I can develop software in both frameworks. Then that's generally fine for building simple applications. But professional development involves more than just creating a functional application; it also includes other concepts such as:

• Software Architecture
• Testability
• Performance
• Clean Code
• Maintainability
• Security

 

From our own experience, we can say that all these points usually only apply to one programming language and one framework, especially if the language is still evolving. Staying up-to-date and learning new methodologies is something some talented individuals can manage in multiple languages, but it usually doesn't fit into a normal workday. Therefore, we recommend keeping your focus on one topic and developing professional software within that area.

 

Conclusion

The role has been changing for a long time, and you should consider for yourself or within your company where your focus will lie in the coming years and what skills you still lack. The traditional ABAP developer will still exist for a few more years, as not every company is ready for the current technology stack, and therefore ABAP developers are still in demand.