The Boring Enterprise Nerdletter #18: SAP Skills, ABAP RAP, AI Hyperdrive, ABAP Grug
Hi there,
Happy reconciliation to those celebrating fiscal year end!
To others, we hope you are enjoying some well-deserved time off and will find this Nerdletter in your Inbox when you are back next week (or in September, if you are located in Europe).
We both are back from vacation (not together) and in recovery from COVID (also, totally uncoordinated). It’s good to be back and boy, do we have stories to tell!
-Jelena and Paul
Skills That Pay The Bills
I noted a story from Enterprise Times on skills. The title calls out "8 skills you must consider when hiring technical staff" - but in reality the piece talks about 2 separate skills concepts.
It leads off noting that digital transformation - for all the BS that term still carries - has focused on cloud, AI, and (for SAP teams) S/4HANA. By focusing in on those skills, legacy SAP teams who focus on keeping the lights on (here in the States, it feels like most SAP teams focus exclusively on that) lose out on the new skills that drive S/4. ASUG found that 26% of member companies see next-gen SAP skills as their biggest SAP challenges. UKISUG found that more than half of member companies see other next-gen skill gaps as slowing their S/4 adoption.
Scary numbers established!
But then the focus shifts to general-purpose skills that hiring managers should look for in new candidates, like integrity, discipline, collaboration, and so on. I completely agree with all 8 of the skills that the piece lays out for new hires - but it's a bit tangential to the first topic of the piece. In other words, it's great that you'll find people with discipline…but no amount of integrity will make an ABAPer understand CDS. The skill gap will persist, at least in the short term of the S/4HANA upgrade deadline.
So my add-on advice is this: large companies, service providers, and SAP team managers, your tech team isn't going to magically show up one day with the new skills they need - they deserve the right time and tools to improve. Sometimes keeping the lights on means learning how to operate a new light switch. PM
Got my mind on my product, and my product on my mind
Many IT projects are poisoned by the “give us all the detailed requirements and we will build exactly that, whether it makes sense or not” mindset. The antidote is the product-minded developer (or engineer). As Gergely Orosz describes them, they want:
[…]to understand why decisions are made, how people use the product, and love to be involved in making product decisions.
In the SAP world, product-mindedness comes with some special challenges because SAP standard is part of our product. Typically, SAP developers need to work with it to avoid another ZSAP or work against it to implement something the business users really need but SAP just doesn’t deliver. I think curiosity and not being afraid to ask “why?” is the key to not confusing one with another.
Also, in too many projects SAP developers are separated from the consumers of their product farther than from Kevin Bacon. This is a sure way for your product to end up like the tire swing meme. Want to avoid that? Then hire, support, and promote the product-minded developers. And let them ask the right questions to the right people. JP
Democratization Sweeping The Nation
In my other nerd life at Bowdark Consulting, we podcasted with Shane Young, a ninja master of Microsoft Power Platform, about democratizing the low-code/no-code space for everyone. That episode primed my eyes for an ERP Software Blog piece making some more distinctions about democratization in enterprise IT.
(Yes - the linked piece above is sponsored. Sponsorship doesn't automatically render something false, and this sponsor is beating a drum whose rhythm I happen to like.)
There's a bifurcation of democratization processes happening right now. First is data democratization. Think about every time in the last two decades you've heard the term "self-service BI" - that's the thing here. "Data democratization is the idea of making sure end users have the skills and tools to access, analyze, report on, and use data without IT's involvement."
Then there's what this piece calls "technology democratization", where IT enables business users by allowing them to BUILD the apps they need: "they want the power to develop solutions that help them do their jobs better-from achieving deeper insights to advancing workflows." Essentially, we're talking about low-code/no-code platforms here.
I have known so many smart, business-savvy people who also think deeply about tech and the processes they perform on the job. They have the right mindset to be developers, even if they've never bothered to learn how to write code. Now is the right time to get these people involved in building their own solutions, and IT doesn't have to hand over the keys to all the systems - they just have to think about providing platforms. PM
ABAP RAP: Unmanaged
There are two possible scenarios in ABAP RAP programming model (at the time of writing): managed and unmanaged. As Paul Hardy said in our Nerdcast, in the managed scenario, there is some “magic” going on behind the scenes. But the unmanaged scenario to me seemed to have somewhat questionable value. If you have to code everything yourself, then why even bother dealing with the RAP model constraints?
The code sample in the documentation (showing a simple function module call) has also been less than inspiring. As always, Community to the rescue! This recent blog post by Alwin van de Put offers a solution for implementing the unmanaged scenario using OOP design patterns. Even if you are not really into that (some day I’ll get to the “OOP sucks” article sitting in my backlog), this post also includes an excellent analysis of what the unmanaged scenario actually does.
And the comment section of these blog posts is delightful. One reader says:
“...we should be ready for the new and disruptive development paradigm which will probably raise within 2 weeks”
Ain’t that the truth. JP
AI Hyperdrive
There's a set of machine-learning performance benchmarks that the MLPerf consortium publishes. The goal is to build fair and useful benchmarks that can assess the state of machine learning hardware and software. It evolves alongside the general growth of AI and ML, so new tests and workloads are added as the state of the art changes.
According to tests run with MLPerf, systems that train large AI models this year do so at about twice the speed of the same models last year. This is better than the historical Moore's Law trend in general-purpose computing. The linked tests are focused on training time, which is a huge benefit. In this tech age of failing fast to move ahead, reducing the time to iterate and improve on models and simulations will help those models advance even faster.
This is so great. But take note of the past few months of news in the AI space. Just because models and be trained better and better doesn't necessarily mean that those models are closer to becoming fully sentient. Don't get fooled like the Google guy. PM
The Grug Brained ABAP Developer
ABAP grug developer lives in own cage many winters. other grugs laugh say ABAP old. grug does not care, more shiny rock this way
apex predator of ABAP grug is same as of other grugs: complexity
and SAP. customer wants requirements, SAP says “not released”. makes grug reach for the club but grug stay calm. grug go to community cave, summon ABAP spirit and offer sacrifice of pinots. this is the ABAP grug way.
test shaman visits ABAP cave sometimes. grug hides and pretends not at home. best to stay away, much to do without it. need to slay BAPI demon first.
stay safe out there, young ABAP grugs. repeat after grug: complexity very, very bad. JP