Get your buzzword bingo cards ready as today we’re talking about DevOps! This blog was inspired by the excellent Coffee Corner podcast episode 43 “DevOps in SAP” where several prominent community members discussed how this applies specifically to the SAP ecosystem.
What the heck is DevOps? According to Wikipedia, DevOps is “a set of practices that combines software development (Dev) and IT operations (Ops)”. When it comes to ABAP world specifically (not to be confused with wider SAP world), DevOps conversations revolve around developer skills, version control, development systems, automated testing, and transport / change management. Some of these subjects have already been discussed at length and you can find links for additional reading below. In this post, I’d like to focus on the subjects that, in my opinion, could use further discussion.
It has become almost fashionable to talk smack about ABAPers these days. These silly ABAPers still code like it’s 1999, cling to the function modules and don’t want to adopt OOP, hehe. It is undeniable that there are some folks working as ABAP developers who have neither skills nor desire for such work. But these exceptions aside, I feel ABAP developers do not get recognition they deserve.
“What if drivers were hired like programmers?” joke has been making rounds in IT for over a decade. For ABAPers, multiply this by 10. We are expected to know the full technology line-up that SAP put together since 1972. From SAPScript, to CDS views, from dynpro to Fiori UI, from SMOD to cloud extensions – you name it. We also have to know the business process, the data model, how each SAP module works. But wait, we also need to have enough infrastructure, DB, and system administration knowledge, so that when Basis team starts blaming something on the code, we can explain that it’s not the case.
At the same time, in the US, on average ABAP developers are compensated 10-20% less than functional SAP consultants and less than other, non-SAP, developers with comparable experience. Our jobs are more likely to be outsourced and, even if we are lucky to keep them, there is mostly no career path beyond a Senior Developer title. Given these conditions, it is quite amazing any ABAP developers even care about anything.
But this post is not just “woe is me” for ABAPers. There is a lot of talk about the developer “upskilling” and I find that most ABAPers are not sitting on their hands instead of learning new skills. On the contrary, they are actively seeking opportunities to improve. But to learn a new development skill, one needs time, training materials, and an environment to practice in. There is no shortage of training materials (the choices can be even overwhelming but that’s a different story) but two other factors can be problematic.
If any organization is serious about their Digital Transformation, it needs to let the developers officially allocate time to training (either organized or self-driven). It is unethical and unreasonable to expect the developers to spend only their private time on learning. It is plain discriminatory against the employee groups who need to provide care for the family members, for example. And should I mention developers also have lives? Time allocation for training needs to be part of “business as usual” for SAP customers.
Getting access to practice / Sandbox environments has been a perennial problem in SAP world. I don’t have a simple solution for that, sorry! But again, if an organization is serious about the developer upskilling, such environment needs to be provided. With the proliferation of virtual environments and cloud platforms, technology exists to quickly spin off Sandbox systems even for S/4HANA. The cost of that needs to be part of the training budget. And SAP should support the customers with such efforts.
Code “Building Blocks”
Every ABAP system has a custom Z report for journal entry upload from an Excel spreadsheet. While the rest of development world builds, or rather assembles, programs from the various “building blocks” and libraries, SAP customers keep reinventing our little bicycles. “Hello SAP, where are my APIs?” asked Christian Drumm back in 2014. Yes, where are they, indeed.
Good thing about the “building blocks” is that they not only allow to build programs faster but partially solve the developer upskilling issue. Even if I do not understand or embrace OOP, I can easily use a method. No need to understand how it works, just fill in parameters and get a result. More veterans would embrace OOP if they had more and better examples and code templates. But SAP either does not provide those or does not advertise them enough.
Thankfully, the grassroots efforts on GitHub really took off in the recent years and there are many helpful tools and programs available (see this blog for some examples). Open source code is still, sadly, frowned upon by some companies and this really needs to change.
SAP DevOps conversations inevitably circle around the company culture. This issue is just as complex as it is important. It’s difficult to make any changes when the culture is leaning towards “we’ve been doing X for 20 years hence X is good”.
But culture is not immutable. It influences people but it is also created and can be changed by people. And just like an eclipse event happens when Sun, Earth, and Moon align in certain way, a culture change happens when the right people are in the right places.
“Culture problem” is frequently the blanket term for something we all know but are afraid to speak of: clueless senior management with no clear strategy, politics-ridden middle management swamp, file-and-rank personnel that resists changes.
ABAPers frequently get bad rep for being old-fashioned. At the same time, the stories I hear through private channels are of the passionate, intelligent, and generous developers who are desperate to make changes in their teams but are not getting much support from their management.
To change culture, in all the layers of organization the right people (i.e. someone with the right expertise, passion, and drive) need to align. The developers who want change need to raise their hands and management of all levels should seek, encourage, and empower such developers. For most part, “culture” is simply a management problem.
More to Explore
Additional subjects mentioned in the podcast that I found interesting:
More by the podcast participants:
- Original SAP DevOps blog by Jakob Marius Kjær (don’t miss the response blog by Graham Robinson )
- Chris Kernaghan speaks at DevOps Enterprise Summit (video)
- Ethan Jewett writes about Agile in SAP
So, is DevOps in ABAP an impossible mission? I hope that just like in the namesake movie franchise, even if not everyone makes it to the end and there will be a lot of property damage involved, it is mission not-so-impossible. But it can’t be pulled by the ABAP developers alone.