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?
Nice thoughtful post for the weekend, thanks Matthias. Something to ponder, for sure. A few thoughts, not in any particular order:
Happy (full-stack) hacking!
Thanks DJ for chiming in and sharing your thoughts & the link to the audio version of the referenced article!
When it comes to favorite IDEs I have learned it's ok to disagree, after all I don't want to get caught up in a "Emacs vs Vi(m)" or "Eclipse vs VS Studio" discussion 🙂
And regarding the stack and keeping the core skills sharp... well, I do believe that all developers should have an interest to understand the principles of each level of abstraction as otherwise they are no longer in control, but depending on these abstractions layers and the tools/platforms providing them.
Have a great TechEd in Bangalore - cheers!
I enjoyed your blog, nice and philosophical... Being an ABAP OldTimer myself, here is my take:
ABAP never existed in a vacuum, as you already pointed out, and as the name (ABusinessAP) says. Any ABAP program always exists with a purpose, towards the solution for, and in the context of, a specific business problem. (Of course you can have purely academic examples, but they are rare). So in order to be a successful developer, you have to have some basic understanding of the business. At least enough to understand the language the business people are talking, so you can get the requirements right.
For the same reason, I came to see ABAP 'programs' as complete systems, containing elements of all sorts of specialized technologies. Initially, a transaction (e.g. Order Entry) was built in one pretty much homogeneous environment; combining User Interface, Business Logic and Database Access (and others...) all within one 'set'.
Now, with increasingly complex system architectures and specialization into disciplines (also driven by languages like JAVA and C++, certain academic concepts, and tools like Fiori) this sometimes comes out of focus. Which, in my mind, causes all kinds of misunderstandings and therefore problems to the final solution.
Therefore, in my mind, the discussions should not be 'single stack vs. full stack'. When I start with a new project, I always try to get the 'Lay of the Land' first. Find out where I am in the bigger scheme of things. How do my requirements fit into the overall project; who are my neighbors, and what are they doing?
So whether you see yourself as a UX specialist, or 'Agile OO' guru, or Business guy, or ABAP all-rounder - I think it is critical that you have what I would call the 'ABAP Feel' - the view and appreciation of the big picture.
OK that was a bit 'theatrical' - but hey, it's Friday!
Loved reading your "theatrical" reply Mike - keep'em coming!
And you're spot on... sometimes it's easy to et carried away and neglect that software is just a means to drive business value. And as such, yes.. it's essential to understand what the project is all about, the business processes it needs to support and the broader context of the target industry.
Agree with you and may be we already see some of that with SIs like IBM where we take more factory like approach for the development.
Thanks for confirming Prasenjit!
I'm looking into some of these "software development factory" models in order to be able to compare the various approaches and see similarities & differences. So, if you should have any further details or the like I'd be very interested!
Yes sure may be we take it offline then .
Thank you, Matthias, for that food for our ABAP minds 🙂
The guys I'm working with tamed the increased level of complexity with RainbowSAP as a an approach.
The guys here came up with a development tool that preserves both the legacy assets of the organization and ABAP developers' applications knowledge. It could be very interesting from the point of view of the article.