In this issue:
ABAPConf 2026
Doubt Your Self-Doubt
Enterprise Lore
Tabbing Around: A Small Show-and-Tell (this one’s slightly longer)
ABAPConf 2026
We’ve been proudly covering every ABAPConf conference, and this year is no exception. The 2026 eclectic agenda is quite representative of what’s going on in ABAP (or SAP development at large): lots of changes and a hint of uncertainty.
This year, the keynote featured what the US folks might call “a wish list for SAP,” but with German directness, it was called a to-do list. Funny enough, one of the demands was “free CVA,” which we also asked about back in 2023. What would it take, SAP? Please, someone ask this at the next quarterly earnings call.
As always, you can find the full event recordings on YouTube: there is Track 1 and Track 2 (both 8+ hour videos). My highlights include:
RAP Application Patterns by Marcel Hermanns (of former openSAP fame). Every RAP-loving rapscallion will love this session! :)
Make Fiori Search Actually Find Things by Stephan Heinberg. This one is going to bring some ‘Nam flashbacks for full-stack developers. Watch out for an Influence request at the end to upvote if you’re interested in making SADL great (aka actually working).
Nice template! Can we buy it? by Christopher Graw. An interesting journey of “productizing” a niche solution.
Back to ABAP - a rare appearance by Holger Bruchelt, friend of the Nerds. Bonus: find about Holger’s unexpected side-gig. ;) JP
Doubt Your Self-Doubt
Standing out from the LinkedIn slop cannon feed, a friend of mine wrote a genuinely great reflection post. In it, he mentions a brush with impostor syndrome: the feeling that you’re a fraud who is just waiting to be discovered. I often feel this way, too.
For me, it comes on strongest when I get some kind of praise or commendation. I can feel my brain resisting: “I desperately hope the person giving me positive feedback never finds out what a complete idiot I am.” Then, I further wreck my life by overworking or over-worrying about meeting unrealistic expectations. It’s as if, somewhere deep inside, there’s a belief that I can elbow grease my way out of impostor-ing. But the only real outcome from that is sleep deprivation and being a jerk to my dog. (I’m sorry, Phoebe.)
I’ve found two approaches that help me combat this.
Keep a little stash somewhere of positive emails, texts, and other messages. Once you’ve accumulated a few of these, you can refer back to this stash occasionally. A mini-flood of positive vibes helps me overcome the doubt that can happen with a singular instance of feeling impostor-like.
Consider the source: if someone you respect is offering you good vibes, think about your respect for that person. Maybe they’re right! Focus your attention on their competence rather than your doubts of your own. If they’re wise, there’s a pretty good chance they’ve read you correctly.
If no one has yet found you to be a fraud, you’re probably not one. PM
Enterprise Lore
There is always a revolving door of technologies in the IT world. Some of it is progress, some is just marketing, but nevertheless, both regular folks and enterprises end up replacing their hardware and software regularly. Since no one wants their old and outdated stuff to be called exactly that, the titans of industry came up with the term “legacy.” While “old” is bad, “legacy” is almost noble, something you might want to keep around a little longer (just not beyond 2027, ok fine, 2030 if you sign up for RISE).
But lately, I’ve been finding posts that go further. Now it’s not just legacy, it’s “heritage” (an even better, important-sounding word!).
The train of thought goes like this: the problem with “legacy” was that the UI sucked and you could never make sense of the data, or even get it fast enough. But now, with The Magic of AI (tm) - who cares? You can keep your vintage systems and databases! AI will just sort it out and vibe code awesome UI for everyone! And because AI craves more data, your “heritage,” your Corporate Rubric, Business Ethos, Enterprise Lore, etc., suddenly becomes a great asset.
What I’ve noticed is that the people writing about this also happen to have something to sell you. That’s not a coincidence because, in reality, your “legacy” is, well, mostly junk. And nobody (even AI) wants to go digging through this pile of heritage.
A few years ago, I had the unfortunate task of helping my mom sort through my late father’s belongings. My dad wasn't a hoarder, but like many Soviet people, he grew up with constant shortages. Throwing something away was almost a luxury. His eclectic collection of tools and cables was eagerly adopted by friends and neighbors. Few items of sentimental value made it to the territory of former “potential enemy”. Many things (some I didn’t even know he had kept) had to be discarded. This made me reassess my own possessions: more than anything, I don’t want my kid to have to go through the same exercise.
Renaming “legacy” just pushes the problem onto the next generation. AI or not, someone will eventually have to decide what to do with your teddy bear collection. Be brave and start cleaning up your heirlooms already. I hope we all have wisdom not to confuse heritage with baggage. JP
Tabbing Around: A Small Show-and-Tell
SAP just finished up its acquisition of Prior Labs, the “pioneer of Tabular Foundation Models” (TFMs). I wrote previously about SAP RPT, SAP’s home-cooked TFM, and wondered whether SAP would start putting RPT into production use. The acquisition puts the spotlight on RPT, and how Prior’s own model fits into the puzzle. Will SAP stitch them together and brand a new thing RPT-2? Or does it really matter what you call any future thing, as long as it kicks ass?
So I dug in to do some learning about TFMs. Here’s what I found and experimented with.
How To Make a TFM
You may already be familiar with the standard way to train a modern large language model: take a chunk of text, split it up into useful sub-divisions called “tokens”, blank out the last token, and ask your language model to predict it. Use the difference between the model’s prediction and the actual next token to update a gazillion little settings. Repeat this trillions of times, and you’ll eventually get a model which is exceedingly good at predicting the next token.
The core of this model is known as a transformer, a neural network architecture pioneered in a famous paper in 2017, “Attention Is All You Need“. A key part of transformer-based language models is that they encode and learn meaning from relative word positions. In other words, one of the things the model learns is how the relative positions of words influences their usefulness in predicting the next word.
The tabular foundation model also uses a transformer, but instead of structuring the training input data as a big long one-dimensional string of tokens, it uses row and column information from a structured dataset to create its own style of tokens. Just like a table in a typical database, one record being right next to another record in the physical representation of the data doesn’t really mean those two records have any relationship. So a TFM doesn’t care about a single one-dimensional collection of inputs - it cares about the tabular-ness of its input data. By including a marker in those tabular data sets of where you’d like the model to predict a value for you, you can have the model output its prediction for the cell of data you’ve asked it about.
Playing Around
Google recently released its own TFM, TabFM, and because both it and SAP RPT have open-source versions it makes it easy to do a little experimenting to see some of the differences in the TFM world.
Reading through the various papers on SAP RPT and TabFM (and with some helpful pointers from the Sovanta blog), I see one way the two approaches differ: RPT encodes and learns the semantic meaning of the column headers and cell data as it trains, whereas TabFM is much more focused on encoding and learning a purely statistical-style prediction approach.
I wanted to see if I could see this difference at work in the data. Both RPT and TabFM have open-weights versions available, so you can play around with your own local instance of the models. I set up a test (thank you, Claude Code) where we would examine two datasets and monkey around with the text fields and column names, to see if that had any effect on the outcomes of the models’ predictions. If RPT actually uses semantic meaning, scrambling the column names and text values should hurt its predictions but not TabFM’s.
Setup
I used data from the SAP RPT trial dashboard, where you can download a 1000-record .csv of some sample order data. I also used data from OpenML, a 9,000ish record employee salary set. Claude helped me set up the tests: a regression analysis for the employee salary data where we predict a salary amount, and a classification for the orders data where we predict the incoterms value.
We’re going to use both models, SAP RPT and TabFM, and for each dataset we’re going to do a run with the semantic-style data (column names and textual column values) intact and a run with the semantic-style data ablated. For ablated tests, column names change from meaningful to “COL_1”, “COL_2” and so on, and text like “Police Officer III” becomes “TOK_abc123”.
If it’s the case that one of these models is learning something about the semantics in the data, then ablating the textual data should have an effect on the outcomes of the predictions. And as it turns out, only one of our four comparisons shows a mild effect: for SAP RPT, predicting the employees’ salaries is slightly affected by removing semantics from the textual data. The effect is pretty small, too:
TabFM doesn’t show any change between the two runs - it’s pretty happy just to crunch numbers as-is. So the weakly-justified conclusion here is: semantic information impacts the prediction capabilities of tabular foundation models whose training preserves that information.
Interestingly, when we do a classification task on incoterms values (which are typically short text codes, not raw numbers), ablation doesn’t seem to have any effect. Could this be because the meaning is less clear on text codes versus full words and phrases?
Caveats
Short tests were only run with two models, and only run on two datasets.
These models are the open-weights models. As they both become more productized and available in different ways, it would be worthwhile to try with a more rigorous set of tests and with the full model power that SAP or Google intend.
I barely even looked at the raw test data.
I reviewed Claude’s code for understanding but not for cleanliness. There may be bugs laying around.
Vibe at your peril. I had Claude write all the code and even brainstorm with me how to test this stuff - but because I did not fully run the process in my own head-meats, I had to follow up quite a few times with Claude to check my understanding. It was faster than doing it by hand, but not a hundred times faster.
Interesting aside: being able to play with the open-weights versions of the models also meant that I could influence how the inference was done. It turned out the SAP codebase was not tuned to use Apple’s M-class graphics power, so in my first trial runs getting a result was incredibly slow. Claude noticed this as it was working through the setup of the experiments (!) and casually tossed out a comment like “You know, I could fix this up to run on your Apple GPU. Want me to do that?” A couple lines of tweaked code later, a verification test, and I had a much faster process available. I continue to be astounded by model intelligence. PM
Watch our Nerdletter Talk 103 for a an exclusive look behind the curtain and bonus content.
Are you interested in sponsoring the Nerdletter and featuring your amazing product? Have a story to share or feedback to give? Get in touch!
This newsletter is always free and proudly written by humans and for humans. Show your support before it’s too late!
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.