#80: SAP Big Pic, Three Rants, Aliases

In this issue:

• SAP Big YUGE Picture

• Rant #1: Consultant Obsolescence

• Alias Confusion

• Rant #2: Everything Wrong With AI In And For SAP

• Keep It Simple, Developers

• Rant #3: Heads Out Of The Sand, Please

SAP Big YUGE Picture

SAP somewhat quietly published The Big Picture diagram, self-described as “Capabilities Reference Architecture for Best SAP S/4HANA Transformation.”

Considering the rapid growth of SAP’s offerings and constant renaming, a “big picture” is long overdue. Some folks on LinkedIn were rightly excited about it. The peanut gallery reactions were more snarky, including a humorous commentary from yours truly.

Generally, I’m a big fan of diagrams: a picture is worth a thousand words. This one though is not only “designed by a committee,” but it also has the SAP marketing department’s filthy paw prints all over it. “Best Custom Business AI,” “Best Business Data,” “Best Integration”- the list goes on.

Here’s one of my favorite USSR anecdotes.

A kindergarten teacher asks the children: “In which country do kids have the best toys?”
Children exclaim excitedly: “In the Soviet Union!”
The teacher asks: “In which country do kids have the best candy?”
Children: “In the Soviet Union!!!”
Suddenly, the teacher hears a little boy, Vova, crying.
“Vova, why are you crying?”
Vova sobs: “I want to live in the Soviet Uuuuuunion!!!”

This diagram is kind of like that. Oh boy, do I want to live in the SAP Best McBestface world! In the USSR, we simply had no idea what was going on elsewhere and had nothing to compare to. But I’m really not sure whom The Big Picture committee is trying to kid. In 2025, most SAP professionals don’t live behind the Iron Curtain of a totalitarian society (yet). Just claiming something is “best” is not how it works. JP

Rant #1: Consultant Obsolescence

The meme is called “Guess I’ll Die” - but that seemed a bit harsh.

On the r/SAP subreddit, AmbitiousAvocado7 asks: "Could SAP eventually reach a point where all of its products are so user-friendly and straightforward to implement and used by end-users, that the role of consultants becomes obsolete?" Jelena and I discussed this in a recent video rant-cast episode, and I thought I'd further break down a couple of perspectives.

So, will SAP get so easy to use that there won't be a need for consultants?

Perspective 1: NO F*****G WAY

• It doesn't matter whether it's SAP or Joe's Custom ERP - businesses will find a way to make their unique needs exceed the capabilities of their software. If SAP becomes so user-friendly and straightforward to implement, that will simply invite more customizations!

• Making software easy to use often means it's easy to break, or to do things you didn't intend. If there are a billion easy ways to do something, there are a billion and one easy ways to screw it up.

Perspective 2: Well…Maybe?

• SAP seems to think that it can be easier and more straightforward. I would like to see it more in action, but there's Joule For Consultants - will Joule be the sneaky Skynet to take consultants' jobs?

• CEO Christian Klein said "within the next two years, SAP software users will no longer be manually entering data, and all tasks will be processed with natural language commands". If that's actually true, does it affect consultants' role?

Perspective 3: The Wimpy Middle Ground

I think AI can get us there faster than most people think. But there’s a pretty big difference between AI that can do the magic and every corner of SAP having that magic. I don’t know how quickly that bridge will be crossed. Probably faster than I think…but that's because my expectations for SAP innovation speed are not high. PM

Alias Confusion

When I was learning ABAP 20 years ago, a typical example of reading data from the database looked like this:

SELECT a~vbeln … FROM vbak AS a JOIN vbap AS b… 

The “AS a” part is called an alias. Even more recent ABAP documentation still includes very similar examples, just with different tables like SCARR (pirates’ favorite!) and SFLIGHT. And there’s still zero explanation of the aliases.

At first, I naively assumed it was something we always had to do: just write AS, pick a random letter, and move on. Imagine my surprise when I saw code like this:

SELECT vbak~vbeln FROM vbak JOIN vbap…

Wait, what?! We can do this?! I spent the following years spreading the good word to other developers and getting rid of the confusing “AS a…” aliases.

These days, SAP doesn’t want us selecting anything from VBAK anymore (that would be dirty, dirty core), and this story might seem a bit “2000 and late.” But roughly half of SAP customers are still using ECC, and I hope this encourages everyone to explore plain SQL for better examples. So here is some ancient alias wisdom.

• Aliases are optional. ‘AS’ is marked as such in the documentation, but nearly all the examples include it - which I suspect misleads many developers. If the table name is already short (like VBAK), not much is gained by assigning it a one-letter alias.

• If the field name is unique, it doesn’t need the source table specified. In the examples above, the field VBELN exists in both tables, so we need to be more specific. But otherwise, it’s not required. However, I find it helpful to be clear about what’s being selected from where, especially for maintenance purposes.

• Using an alias makes it possible to include the same table multiple times in a SELECT statement. This is rather unusual, but one potential example is joining the VBPA table multiple times to include different partner types.

While we’re on the subject, there are other kinds of aliases in ABAP. One interesting case is described in this blog post. There are also aliases in the class/interface context. Cool stuff. JP

Rant #2: Everything Wrong With AI In and For SAP

In most cases it can reasonably be called AI in some way…but this is the best meme for this rant.

This is a rant laundry list with a twist: each mini-rant has a prescribed fix. The blame for each item belongs to different parties, but the state of the AI-in-and-for-SAP game remains the same: weird and hard for people to navigate.

• Problem: No two people agree on a definition of "agent" but holy hell everybody wants to be building (and more importantly $ELLING) them. Yes, I am the king of hypocrites on this one, because agents are exactly how we do what we do at Nova.

  • Fix: Make vendors prove to you that they can do what they say, and make them do it with your scenarios.

• Problem: An AI Thing can be announced and hyped for TWO YEARS before an appreciable amount of people get their hands on it. I'm looking at you, Joule - announced officially September 2023, and I am quite certain that far less than half of SAP users have touched it. Or understand it.

  • Fix: Mercilessly roast the vendor on social media and score some internet points. But seriously - complain and gripe to your account executive about the situation. Salespeople seeing money slip through their fingers makes things move faster than the speed of light.

• Problem: SAP Business AI isn't a clear thing. I've already complained about it so I won't go too deep.

  • Fix: Don't use "AI" as the key criterion for whether something will work for you. If you want to find ways you can improve your business processes, start by looking at the product pages for those business suite applications. If you hit on something "AI" - great!

• Problem: The pace of change of AI is such that only those people who work directly with it can even have a prayer of keeping up. (Actually, I don't think they can, either.)

  • Fix: The only winning move is not to play.

My spicy hot take is that the real problem is the term "artificial intelligence". Nobody agrees on what "intelligence" means. A murky definition and capabilities that change by the hour lead to a situation where only those with deep interest and time can hope to stay afloat. PM

Keep It Simple, Developers

“Clever engineers write code that makes them look smart. Exceptional engineers write code that doesn’t need explaining.” When I read this in a recent post by Rafa Paez, my first reaction was, “Goddammit, why didn’t I come up with this?” In a few sentences, Rafa brilliantly captured so many things I’ve always wanted to say to so many developers.

I think every developer eventually goes through a phase where we feel pressure to write code that others will see as “advanced” or sophisticated. To show off. And with sweaty palms, we bang out code that’s supposed to instill fear in the heart of every meek junior dev. Code that screams, “I’m a big-shot, experienced developer, a force to be reckoned with!”

But ironically, that kind of code often just screams insecurity. The only principle that has stood the test of time for me is this: keep it simple. “I can understand your code easily” is the highest compliment a developer can receive. JP

Rant #3: Heads Out Of The Sand, Please

One more rant for this issue. A direct missive to my SAP developer friends.

Your job is going to change. If you love the feeling of typing each line of code by hand - that's going to disappear. Software development is rapidly evolving - yes, even SAP development. The AI models are quickly climbing the skill tree. If you have a complaint about the output of a language model on your coding task, I will bet dollars to donuts that 80% of those cases are because you didn't give the model enough information.

I can think of two instances in the last 3 months where an AI model genuinely surprised me. (Not "Skynet became self-aware" moments - more like "the models are better than I thought".) Given the right tools and good guidance on the overall problem to attack, they can go further than you think. I thought I'd developed a pretty good taste for the boundaries of their capabilities. Wrong. They smashed through and didn't even have the decency to tell me.

Will there still be software? Yes. Will there still be a need to develop it? Yes. Will that process happen the same way? Emphatically no. It's always been true that continuous learning drives developer careers forward. Now is the time to learn how to effectively use AI. PM

• Watch the corresponding Nerdletter Talk on our YouTube channel for bonus content and spicy discussion of the subjects in this Nerdletter issue.

• Catch Paul’s guest appearance on the ASUG podcast. Spoiler alert! It is about AI.

• Clear your schedule to see Jelena’s ABAPConf presentation on June 5th in Vienna. Join waitlist for in-person tickets or live feed online.

• This newsletter is written by humans. Who run mostly on coffee. Support the Boringverse by buying us a cup or two. Well, there are two of us, so two cups really should be minimum. Anyways. Thanks for your readership and support!