#82: Double Joule, ABAPConf, Interviewing
In this issue:
ABAPConf 2025
Recently I had an opportunity to present at ABAPConf event in Vienna. Both event and the city were 10/10, would recommend. Here are some highlights of the presentations for ABAPers and ABAP-curious (there really were no bad presentations, so this is like ABBA Gold).
Keynote Capabilities turned out to be about the developer capabilities rather than the SAP ones, to my surprise. The bit about SAP Joule for ABAP ought to russle some jimmies at Waldorf. Good storytelling.
Behind XCO and Much Further by renowned blogger Björn Schulz. XCO library kind of snuck up on the ABAPers, and it looks like it’s going to be important going forward. Check out Björn’s post about it here, his whole blog in general is highly recommended.
The last Overview you need on how to Extend S/4HANA On-Premise (as a developer) by Joshua Heisler - well, it’s all in the name in this case. :) Interesting decision tree and an open-source project demo in the end.
Christian Punz stepped in to fill for a cancelled presentation in Vienna and did a great job talking about ABAP Cloud in refreshing stoic European manner. No marketing bs, just what, how, and why should you care.
CDS-only Data Modeling - Harnessing New ABAP CDS Object Types for Modern RAP Applications presented by SAP’s Katharina Altrichter and Matthias Herchenröther. (Katharina and Matthias also did an excellent presentation in the last Devtoberfest.) Lots of information about CDS news and lively Q&A in the end.
Effortless ABAP dependency management with TRM by Simone Gaffurini showcased his open-source project Transport Request Management. Object dependencies have always been a pain in the butt in ABAP transports. There are some $$$ solutions for this, but if you’re on a tight budget, check this out.
Special thanks to the organizers, all the volunteers who worked to support this event in multiple locations, to all the speakers, and so many people who traveled near and far to be in the room. I always say it takes a village to raise a developer, and our village showed up, big time! JP
Joule For Joule
Karsten Kötter: Joule for Consultants is priced at many multiples of other Joules, even more than ChatGPT Pro. That might seem gobsmacking, but SAP says roughly "90 min saved per consultant per day", and around 14% SAP project time reduction. If those claims are even half true, the price has got to be worth it. Right?
Extrapolate that out a little bit. If saving 90 minutes justifies a price like that, what would saving 3 hours justify? 6 hours? Will paying for the AI that knows how to configure SAP cost more than the license for SAP?
The most expensive version of Joule is the one that's an SAP expert. Not business-y things like SCM or HCM; the one that knows about monkeying with its own ecosystem. I've spent a fair portion of my career in consulting, and honestly…sometimes I hate it. Not the work itself, which can be varied and challenging, but the very idea of consultants. I wish software wasn't so hard. PM
Breaking News: ABAP Developers Not Dumb
Robert Eijpe asks Are ABAP Developers Ready for AI with SAP Joule? The rule of thumb for questions in article titles is that the implied answer is "No". (I don’t think Robert meant it that way.)
However, in this case I think the answer is "Yes". ABAP developers are ready for AI with SAP Joule. Why?
No one is actually ready, until they are. Using tools based on large language models (LLMs, like GPT-[x], Claude, or Gemini) is a vibe. You can read all the preparatory posts (like Robert's) you want, but you won't find your personal groove until you go play.
If you feel like you're not ready, here are a couple pointers:
LLMs aren't command line interfaces (though you can equip them with tools that use CLIs). Don't treat them that way. Brainstorm. Go back and forth. Ask questions that you're not sure have an explicit answer. Tell them more than you think you need to.
In some sense, LLMs are constructed to behave like humans. As you're saying something to Joule, think to yourself: "If I asked this question to a smart human, would I have given them enough to be able to figure out what I mean?" It can be hard to reflect in this way.
Even if you believe they can't really think, treat them like they can.
ABAP developers can't use Joule for ABAP Developers anyway. Joule for ABAP Developers is available on S/4 Public Cloud (now also known as "SAP Cloud ERP") and BTP ABAP. Not many ABAP folks are running their real-world ABAP thingies in either of those places. (There are some, I know! Haters to the left, please.) ABAP developers are just as smart as any other kind of developers, but professionally speaking they have fewer opportunities to flex their AI muscles.
And realistically, inside enterprises, ABAP developers get no love. If you are the manager of a team with ABAP developers, and some poor soul wants to expense $20 a month for ChatGPT or Claude or WhateverCopilot... for the LOVE OF ALL THAT IS GOOD, GET THEM AI TOOL ACCESS! Go fight any bureaucracy that stands in your way. Anyone who is eager and motivated will deliver that $20 back to you on the first day. Easily. PM
Interview “Prep”
It’s always confusing to me to see the questions online like “how do I prepare for an ABAP interview?” A certification test is definitely something one should prepare for, but a job interview is supposed to be a conversation about the job and the candidate’s experience, isn’t it?
I’ve heard some people are still doing quiz type interviews and don’t see much value in this. Anyone can just look up stuff online or in ABAP Help. It’s more important to find whether a person can solve problems, be creative, and isn’t a total jerk.
In a way, your daily work is how you prepare for the next job interview. But there are a few things anyone could do to make the interviews more effective.
Your resume (CV): it’s a sales pitch, not a task list. Keep it short. No one cares about the details of an ALV report from 2012 or names of every BAdI implemented. I also find that for developers their resume is typically representative of what their code looks like.
An interview is a chance to sell yourself (yes, job search is a sale and you are a product). Many developers are not good at selling - it’s just not what we do. But you might not get another chance, so gather all your strength, folks. You might have heard about the elevator pitch. Think of one for yourself in advance and work it into the interview.
“Don’t lie” seems obvious, but you’d be surprised. The chances that you’ll be interviewed by someone who actually knows their stuff are pretty high - and getting caught is painfully embarrassing.
One issue I often see even in interviews with experienced developers is that they can’t explain why they did something. “Oh, the architect/senior just told me to do it and I did” is a common response, and it’s just sad. We can’t grow as professionals if we don’t ask “why.” Doing the same thing mindlessly is how developers get into all kinds of trouble.
Good luck in your next interview and I hope it’s not a quiz-type one! JP
You Guys, Data Is Really Hard
I've been part of multiple S/4 transformations. You've got your typical big project phases: blueprinting, analysis, build, and so on. Some of the toughest work of the project happens in the integration testing cycle(s). Scripts have to be written, authorizations handed out to the right testers, code and config transports properly moved, and…just so much crap to do.
When you execute the test phase, you'll accumulate a heap of defects. If your experience is like mine, even a cursory glance at the pile should make you shout "omg our data is F--KED". There is so much time wasted moving missed or mangled data, which brings important testing to an agonizing crawl.
To the best of your ability, determine what the golden truth of your data is and RUTHLESSLY compare the systems in your environment to it. Figure out what is missing from where it should be, what is present where it shouldn't be, and the minutiae of field-level comparisons. You might even have to write special data validation programs (I've been there). The first few times you do this, you will probably want to scream. This is understandable - it's painful. But if you push through, tune your processes, and painstakingly maintain your migration scripts, the sun will begin to peek through the clouds.
A lot of data stories are about feeding your enterprise AI beast, or your analytics strategy, or whatever fancy data-buzzword-of-the-week. But the only way to get to Data Buzzword City is by going through Boring Data Operationsville. And if you don't maintain the roads in Boring Data Operationsville, you'll never make it. PM
Importance of Scale
I am an avid fan of The Great British Bake Off (known in the US as The Great British Baking Show): I’ve binge-watched all the available seasons, bought the books, and even attempted some of the recipes myself. It’s been an endless source of inspiration for many of my presentations. Baking and development have surprisingly much in common, but that’s a story for another day.
One of the challenges the contestants on the show face is producing a number of pastries that are exactly the same. The significance of this task is that consistency and scale are precisely what separate casual home baking from artisanal or professional quality. When baking for family and friends, no one is going to complain if every pastry looks different - as long as it’s delicious. But producing consistent results at scale requires a whole different level of skill and experience.
When I presented about SAP at my kid’s high school, I ended with the message that if the students took only one thing away from the presentation, it should be this: scale is very important.
It’s not difficult to make one pretty pastry, one simple app, or build an interface to be used once a day. Doing those things at a much larger scale is an entirely different matter (there is a cool newsletter about it). When people talk about IT and ERP, I feel this fact is often overlooked.
“We’ll just build our own AI/ERP/<insert product name> with blackjack and hookers!” - well, good luck with that. You might build it, but will it scale? That can be a many-million-dollar question. JP
Watch the corresponding Nerdletter Talk on our YouTube channel.
Watch Jelena’s ABAPConf presentation The Magical World of SAP EWM on YT and get the slides here.
This newsletter is written by humans for humans. Support the Boringverse by buying us a cup or two. Well, there are two of us, so maybe two cups? Thank you for your readership and support!