#31: Hyperautomation, Upskilling, Oracle Alloy
Hi there,
In the spirit of IBM upgrading automation to hyperautomation, we’re upgrading the Nerdletter to the HyperNerdletter. You get the same never-dull six stories bi-weekly, only now that it’s the HyperNerdletter, we promise they’re way better.
-HyperJelena and HyperPaul
The Upskill Side of Digital Transformation
From Enterprise Times, I note a Rimini Street report about a hodgepodge of topics for IT leaders. I think most of them could fit under the broad umbrella of "digital transformation", even if that's actually one of the sub-questions in the report.
As I read through, I actually latched on to the IT skills gap section. (It's something we've discussed before.) It reminded me of past experiences on both sides of this scenario: a major project is happening, and an army of consultants swarm over an enterprise busily implementing $BIG_THING. Managers try to make this work for their teams of internal employees by establishing consultant-employee buddy systems and dedicated upskilling goals.
I've been on the successful side of that equation at least twice (as employee and as consultant), and on the not-successful side of it…um…several more times. Here are two hard-won lessons in upskilling internal staff. First, if you're planning a large project in the early phases, you have to bake in that upskilling time from the very first estimate. Before the people who need to upskill even know there's a project, time to upskill must be budgeted. Second, if you're planning to have your team learn from consultants, you must plan for deliverables that are entirely owned by the employees without in-the-moment help from the consultants. That easy button of the person who already knows the answer will stand in the way of learning.
In upskilling, the only way to get there is to get there. PM
SAP Functional Consultants Also Learn
In the last issue, I wondered about what people are doing with the SAP systems and also raised a concern about functional consultants keeping their expertise up-to-date. There is plenty of information on how SAP developers are learning (or not) but what about our functional comrades? I ran an informal poll to find out.
The tongue-in-cheek option “wait, we need to do that?” accounts for 35% responses on Twitter but only for 4% on more serious LinkedIn.
With adjustment for possible trolling, free online resources (SAP Community, openSAP, new SAP Learning site) are the leading choice. Significant percentage also rely on SAP Certification / Learning Hub.
Interesting input from the comments:
Several people mentioned that they learn specifically by answering questions on SAP Community. Sharing your knowledge can be a great way to learn, as long as you don’t mind scrolling through LMGTFY questions.
Simply talking to others (at an event, for example). In the good old days of large in-person conferences, you could always get the best scoop in the random corridor chats. I miss that!
Learning on the projects – this is the best way to learn IMHO and SAP customers should not be shy to include “knowledge transfer” in the consulting contracts.
If you hurry, there is still a chance to answer the poll on LinkedIn. I would love to hear more from the functional consultants. Developers can also get their voices heard by answering the new SAP Developer Insights survey. JP
Infrastructure-as-a-Service-as-a-Service
I'm guilty of being an Oracle pessimist - but it's really because the nerd/hacker sites I frequent have lots of Oracle hate. I have nothing bad to speak of in my experience, so maybe I have no reason to be a hater.
So to temper my hater-ness: late last year, Oracle rolled out a new product/service called Alloy. And it's actually a cool idea. The way I read it is that you, as an Alloy customer, make your own customized cloud on top of the Oracle Cloud Infrastructure. Your customers think of you as a cloud service provider for all your magical apps and services and whatnot, blissfully unaware that you're just the middle man. You choose the specific locality where your infrastructure runs.
Oracle seems to be looking for financial services and telecoms as their first targets, which I think makes sense as those are often highly regulated within national boundaries. If you, as a service provider, can guarantee that your services don't live on a multinational hyperscaler, you're positioned to get into those regulated spaces. As a growing cloud infrastructure provider, this puts Oracle in place to be part of the bedrock, foundational level of cloud compute.
And as usual, as soon as I think I've found something cool, Bob Evans has already said something about it. PM
Much Hype About Hyperautomation
Hyperautomation sounds suspiciously like a marketing department’s invention and it’s probably true. For example, Gartner’s glossary on this looks like someone asked ChatGPT to name every technology buzzword of the last 3 years.
IBM’s article on the subject admits that “the difference between automation and hyperautomation is often unclear” (thank you for that!). It’s a black cat in a dark room that might not even be there. The “hyper” is defined as “business-driven” and “disciplined approach”. (As opposed to regular automation that is totally chaotic and IT-driven? Hm.)
Once you set aside the hyped-up “hyper” part though, the article makes some good points with regards to automation. “Ever-growing and evolving marketplace of products” doesn’t make choices simple. Would you go with an SAP solution just because it should work better with their products? Or would you rather pick a vendor with special expertise in automation?
From my “technologist layman/woman” point of view, one of the main challenges in automation is choosing what to automate and simplifying the processes before automating them. Otherwise, you just end up with doing stupid things really fast. One might think that “hyperautomation” means automating everything and then “let God sort them out”, Duke Nukem style. But that’s not really the case. Don’t let the “hyper hype” fool you. JP
Programming principles IRL
As someone who’s been writing programs and existing on this planet for a rather long time, I’ve gathered many bits of wisdom along the way. It is customary in my age group to start sharing said wisdom with the next generation (which likely will roll eyes and ignore it). So, gather ‘round, kids.
Always do your best. Expressed so perfectly here, it is the motivational poster stuff that you can take anywhere, including programming. Paying attention to detail, following guides like Clean ABAP, and constantly asking yourself “is this the best I can do?” is a great start.
DRY principle is vital in programming but has many other uses too. For example, in writing, include a reference to Wikipedia (like I just did) or another article instead of repetition. Doing something over and over? Find a way to automate it! Or even hyperautomate.
Famous Scouts’ motto “leave it better than you found it” is my Refactoring Anthem. Just make sure not to make a bigger mess (use abapGit for better version control).
Like a vampire, complexity waits to be invited in (and, as we know, complexity is bad, very bad). YAGNI principle helps to avoid not just superficial features in the apps but also real life junk. Alton Brown’s disdain for “unitaskers” comes to mind here: “I have a bagel slicer. It’s called a knife!”
Here you are, kids, Jelena’s four principles to live and program by. Now, get off my lawn! JP
Gift Nerd Rescues an Enterprise Nerd
Here's a small, new product that I feel is directed right at me. Gift Nerd helps you make intelligent choices about giving gifts to people, with smart constraints and quick recommendations. Why is this for me? Because I completely suck at giving gifts. Like, to the level that let's just keep this subject away from my spouse entirely, thankyouverymuch.
There's actually another great thing in Gift Nerd's favor. It uses AI, but doesn't need to sell you on the fact that it uses AI. That's the point! AI isn't a feature. It's a tool to get to a feature. Or to put it in Halt and Catch Fire terms: "[AI] isn't the thing. [AI] is the thing that gets us to the thing."
Why is this in an enterprise newsletter? Because this thing needs an enterprise version for team gift-giving on a budget. My current company does amazing stuff with holiday gifts (seriously you should come work at Bowdark) - but I think that's secretly one behind-the-scenes genius gift-giver working magic. If I was responsible for gifts for a team of people, you bet your behind I'd be looking for a tool where I could input a bunch of people with a bunch of preferences, and have it spit out a list of things that I could just immediately go spend my gift budget on. Like - right now. Gift Nerd people, listen up and make this thing work for companies and teams. We can work out the terms of my cut of the billion-dollar IPO later. PM
Support The Nerdletter
Soon, the low-code / no-code solutions will leave us unemployed and this Nerdletter will be written by AI. Very soon, we hear. But in the meantime, your humans would very much appreciate a cup or two of coffee.
Thank you for your continuous readership and support!