The ‘digital transformation’ of the ABAP developer

“Were ABAP developers the first full-stack developers?”

This controversial argument was brought up in a Twitter conversation during SAP TechEd Barcelona this year. And while it may seem to be sort of a philosophical debate, it got me thinking for the last couple of weeks. Ultimately, I realised that it’s a great lead-in to a much broader topic: how is the role of the ABAP developer impacted by digital transformation?

Looking back at my own career, I was introduced to SAP R/3 and the ABAP programming language in the late 90s, and frankly speaking I wasn’t impressed at all back then! Coming from a Visual Basic and Delphi background and comparing these graphical development environments to the ABAP editor it felt like stone-age (I still remember I had to enter “i10” or something like that to get 10 new lines in the editor…) As such, I was more intrigued by other, more exciting technologies and so I joined the Java camp… and it took a few more years till I got back to ABAP and R/3.

What I didn’t understand back then, was that the power and subtle elegance of ABAP lays elsewhere – it is a platform designed to facilitate the development of business applications. In fact, the English version of this abbreviation is zooming in on this value proposition: Advanced Business Application Programming (ABAP). In retrospect & applying today’s vocabulary one could probably refer to it as a “rapid (business) application development platform.”

As such, it is fair to say that ABAP developers were indeed developing “full-stack applications” from database, to business logic up to the user interface layer. However, calling them “full-stack developers” is definitely a stretch as ABAP provides plenty of abstraction and frameworks on all layers. Those layers greatly simplified the development of applications and know-how about the business processes and how they are implemented in R/3 or CRM was far more important than being a great software engineer: the standard way of interacting with data used to be a simple “READ TABLE” statement that leveraged the underlying OpenSQL abstraction. The business logic can easily be implemented in flexible & extensible fashion due to concepts such as user-exits or Business Add-Ins and there has been reliable & proven patterns such as pessimistic locking and a sophisticated commit/rollback mechanism taking away complexity. On the UI level, it used to be as simple as binding data structures to screen elements and the job was done.

In short, the ease of use and the speed & efficiency of ABAP to develop business applications has been a major factor of SAP’s success. In other words: the reason why ABAP has been so successful was that it did NOT require a “full-stack developer” to deliver impactful business applications.

This approach worked like a charm back in the days with ERP-dominated IT landscapes complemented with data warehouses (BW) and CRM systems. Nowadays, with more fragmented and heterogeneous system landscapes and fast-paced advancements in technology software development has to cater to a higher degree of complexity.

On the data side we are talking about in-memory databases that cover both OLTP and analytical use-cases, high-volume output from IoT devices and XL data sets from big data scenarios. On the business logic layer, developers need to have a thorough understanding of how-to develop scalable, robust applications that connect to distributed systems & microservices; and on the UI front UX designers face the challenge to provide intuitive, consumer-grade interfaces that are responsive and look great on many different devices.

Of course, this also has impact on the various SAP developer stereotypes including the ‘traditional ABAP developer’. While their understanding of business processes remains their strong point, they will have to adapt to the challenges that come with the fast-paced technology innovation of digital transformation. The inherent complexity of each layer in the development stack requires focus and as such most developers will have to make a choice – to be an expert on a particular layer or to be a polymath with just a solid understanding of each layer. As such, true full-stack developers will remain a rare breed!

So, how to tame the increased level of complexity in software development and address the constantly increasing demand for software solutions? This is a common challenge for enterprises of all sizes, yet especially for those that intend to move from ECC to S/4 HANA and herein facing the question of what to do with all their custom code…

Ultimately, I believe that – going forward – development tools will play a central role in empowering developers to rapidly deliver business applications. By lowering the entry barrier and increasing developers’ productivity, rapid application development platforms may be the “secret sauce” in a company’s digital transformation recipe. Of course, such development platforms cannot magically take away the complexity (see Joel Spolsky’s classic post on Leaky abstractions), yet they can provide a sophisticated level of abstraction that supports developers in their jobs without having to be a “full-stack developer rockstar”.

The key will be that such tools help accelerate the development process without resulting in a tool lock-in (aka “black box”) so that the productivity gained by using the tool is not lost at the final stages (aka the famous 80:20 rule.) Especially towards the end of the development process, when the finishing touches are applied, developers need to be in full control of every aspect of the stack. Consequently, model-driven, low-code frameworks will need to work seamlessly with pro-code editors to ensure a smooth development process.

Putting it all together I tend to believe that many IT departments may be well served in establishing a factory-like approach were developers with strong domain expertise use model-driven tools to develop the foundation of business solutions and experts on the various layers of the stack then provide their expertise to make these applications production-ready.

What’s your take?