Personal Insights
Mission Impossible: DevOps and ABAP
Folks,
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.
Developer skills
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.
Culture
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:
- GCTS (Git-enabled Change and Transport System), see blog 1 and blog 2
- Feature switches
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
Conclusion
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.
Hi Jelena,
for your JE APIs have you tried this yet: https://api.sap.com/api/quickbooks/resource ?
i wouldn't necessarily blame SAP for Intuit's openness or (lack thereof) for sharing their not so quick books.
Cheers,
greg
P.M. didn't know about that 10-20% discount for ABAP programmers but other factors may be at play like COLA or the cut the middlemen would take to land a gig.
Hi Greg!
Sorry, I don't really get the comment... JE upload has nothing to do with Quickbooks. This data could be coming from any sources.
Obviously when I'm comparing salaries I'm talking about the same geography and comparable conditions. I'm not comparing a consultant in CA vs ABAPer in Alabama. And disparity applies to the permanent positions as well where there is no middleman.
Job market is in bad condition right now but in other times, this can be easily confirmed by just looking at the job ads. In the same town, you'd see, for example $130k annual salary for a functional but $90k for a senior ABAPer.
Thanks.
Hi Jelena,
sorry for being a bit confusing. my comment about JEs and Quickbooks was based on my experience with the APIs that SAP and Intuit have exposed to each other. it just strikes me that for something so simple as a ledger for posting the simplest of transactions Intuit managed to make the APIs very complex even when compared to SAP, which is obviously a lot more complex and multinational than a popular package for small businesses here in the US.
as far as pay differentials go, i think there is a lot of misinformation about what is available in terms of jobs and at what pay. in my experience a lot of professional positions do indeed require some sort of recruiter or head hunter who may charge quite a substantial fee for making the hiring smooth for both parties, so permanent is not always without somebody in between.
i suspect a big chunk of that 130K is not all salary but some sort of sales commission for drumming up business or placing someone in a position that will look totally different from the one advertised or simply collecting resumes for one's own recruiting business.
i probably went a bit off topic here, but it's just my humble opinion.
cheers and happy Friday,
greg
I can't give you specific ad links because we're in pandemic right now and jobs are scarce. My statements are the result of observing a local job market (I live in Raleigh, NC area) for several years. And I mean regular job ads for permanent positions placed by the employers themselves that anyone can see online, not some posting through a recruiter that never sees the light of day.
And I've seen invoices with my own eyes for the SAP projects where functional consultants were paid $125 per hour and home and best ABAP consultant was $115 per hour (most were $100). Again, not talking junior vs senior or different hiring conditions or the same geography. People with same experience, sitting in the same room working on the same project. ABAP developers are always paid less.
I have never seen the disparity between ABAP development and monitoring i.e. looking at ST22 / SM66 and so on in production every day. I have always done both since the year 2000.
Writing something and then screaming "Ha! Ha! It's not my problem any more!" does not seem to make much sense, even if that is what a lot of people do i.e. that was the specification, I coded it to match without questioning it/thinking about it, all done, goodbye!
It is true we (programmers) are supposed to know the business process and I would even argue that is vital. It is a bit difficult unless - like my company - they took the two programmers who were hired to replace me (boast boast) when I went off to work in Germany in 2009 and in their first week took them out to concrete plants and quarries for a week to see what the business did before they had even written one line of code. How many organisations do that? How many think it even matters?
One big plus to Germany where I worked - they let people watch open SAP courses (e.g. the TDD one) in work time. They even have every last Friday a month as "don't do your normal work do training all morning and pick one of these many topics". Heavy Plus Sign.
When I started by SAP life back in 1997, I spent two weeks working shifts in the various part of the plant just so I could understand the business. But that kind of thing doesn't happen often. I'm approaching the end of a fifteen year stretch with one client. At first, I just worked in an abstraction - I had no idea what the client was really doing, as I mostly dealt with munging financial data.
My latest project though is right out there in the realms of logistics, one of the highest profile IT related projects in the company, directly relevant to the general population. It's really great when you are able to see the impact of the work you are doing. Even though I'm working with a junior ABAPper who thinks static classes are great because "you don't have to create an instance"... He'll learn.
I've always had access to the production system in the past 20+ years of being an ABAP developer, because when something doesn't work right, the first stop is to ask the developer. So just yesterday and invoice was printing with the correct total value, but the line items were all zero. First stop - invoice printing, must be a problem with the print program. Nope. Incorrect condition type in the document. It's even noted on the conditiion type tab that it's in error.
And this is fairly typical, and why you can never say "it's not my problem anymore" - even when it really isn't.
It really bugs me that EVERY problem somehow lands on the ABAPer laps and we don't have a luxury to just throw it over the fence to someone else. Because everything in SAP is a program, anything that's wrong is perceived as a programming problem.
And not sure if it's just my bad experience but I feel others don't even try much because they know they can simply claim "ask an ABAPer". For example, a user complains about performance. Even if it's a standard SAP program, if the issue goes to Basis team, they simply look at their KPIs for the whole app server and say "system performs as expected, not our problem, ask ABAPers". They won't even try checking what the issue is, not even run SQL Trace or something.
I really hope that DevOps can help in this area because Basis and ABAPers should be working together, not just pass problems along to the next team. And in the projects where this was happening, we had the best results.
On the other hand, when you solve the issue, you get a reputation for being a genius and a nice helpful person!
To be fair with the issue I related, we're a small company, so we're all really in it together.
Thanks for the comment, Paul! Agree completely. It was very beneficial to me when I could be in the actual warehouse before and after SAP go-live. And even if it's not possible to be on location frequently, I think visiting different operations at least once is great experience. Unfortunately, in many companies developers are not invited.
Great idea on "learning Friday" as well. Something I'd recommend to every SAP customer.
After on go-live I was on location and I was working in the area where customers could come in off the streets and buy things (rare in the building materials industry). It suddenly dawned on me I was the only staff person there and if the customer actually did want to buy something I would have to process the order in the live system - using software that I had written. I was terrified. What if that software was unusable by a human, or did not work at all? I'd have no-one else to blame but myself.
I imagine if every developer ran the risk of having to use their own software for real in front of a total stranger who will get really angry if it does not work, maybe it would change the way we write things....
Hi Jelena,
It is very nice blog, i am agree with you. I want to say something about SAP’s strategy aspect of Abap-SAPUI5 developers;
SAP is not innocent one in this circle. As a developer when you start to learn something new, Sap changes it instantly. For example, as an classical Abap developer, SAP will say you after that your main development environment is Eclipse-IDE. We can sure that it will publish Visual studio code as a development environment soon. Or you can begin to development process with WEBIDE( even if SAP still give it support ) of course SAP will change it to Business Application Studio before you get used to use it. Or you can try to learn BOPF, before SAP change it to Abap Restfull Programing model. Of course finding sandbox environment isn’t always hard process even if you find S4 Hana 1909-SP02 system, SAP will say you that it is on-premise system you can’t develop RAP-Managed model in on-premise system, find yourself a cloud system. As a developers we want stability.
Best Regards.
Well, if you want stability, development is not the right profession.
I do understand what you mean though: it is becoming a bit tiresome and confusing. As soon as you learn about something, it’s obsolete in less than a year. And the big thing about Eclipse was that “oh, you can use a non-SAP IDE” yet here we go, SAP BAS, another SAP IDE. What the heck is that about.
By the way, ABAP in VSC is yesterdays news already, keep up!
Thanks for the comment!