Fishing For Nerds

Over at diginomica, Mark Chillingworth describes a few CIOs out there in the world doing the best they can in the tech talent crunch. They’re making headway by transforming recruiting from an externally-sourced job to an arm of IT itself. A key finding:

talent acquisition is, like technology, not just a bolt-on, but a strategic approach and a good investment.

The folks Chillingworth talked with saw benefit from in-sourcing recruitment. Vital to success appears to be giving recruiters incentives to go the extra mile, and relationships that can only be built with colleagues. When tech talent ups its game, the business notices.

I often work with IT teams. It is no lie to say they are stressed, short-staffed, and in need of skill-sharpening time. Getting good tech talent means investing in lots of things, and recruiting is a key factor. The best people are never on the market, so you need something more than LinkedIn spammers to find them. I have worked with recruiters in the past and I can tell you: if the recruiter is invested in the business they’re hiring for, it makes a huge difference. Recruiting follows the same adage as other talent: you get what you pay for. PM

Welcome To Connector Hell – Here’s Your API Key

I don’t know how I got there, but I landed on the SAP Open Connectors help portal. Open Connectors helps “unify the developer experience across all kinds of applications and services”. Check out how many connectors are available for integration use.

Every platform I touch has a similar concept – there’s a need for simplifying connections between apps, clouds, databases, and everything in between. If you can draw a picture of what you’re trying to do, you can probably find a pre-built connector somewhere to smooth the path.

The ubiquity of connectors shines a light on that eternal question: build or buy? If I can make a Visio drawing and just plug in little pieces with API keys and credentials, doesn’t that lead to agility? If I can hand-write my own custom application in any language I choose, doesn’t that mean that I can truly make anything I desire?

If I need to build something in order to communicate that thing’s value, I will glue connectors together all day long. If I need to make something that can stand the test of time, I’ll happily open VSCode. But the world is changing, and I don’t think that distinction will remain as clear as it seems at the moment. PM

It’s Not Easy Being Green (But It Should Be)

I parse the word “sustainable” in two ways.

  1. A corporate BS buzzword focused on by companies who don’t want to lose their Millennial/Gen Z workforce, mumbling something about making safe communities and locally resilient supply chains.
  2. An environmentalist term meaning this object or activity can persist in such a way as not to immediately destroy our planet/climate.

A couple of items in the last week made me think about these two definitions. First, Julia White of SAP gave a quick talk at Cloud Wars Expo which included some mentions of sustainability. I am cynically inclined to interpret most corporate folks as acting in the first parsing above – but Julia and her interviewer’s chat actually left me feeling more charitable. Give it a listen.

With regard to the second, I saw news that Google and Oracle suffered data center outages in a recent London heat wave. The cloud computing market sure ain’t gonna get smaller, so cloud providers have to both plan for heat disasters and – more importantly – be good citizens of power usage. A study in Science found that data centers use around 1% of all worldwide electrical power, and a great deal of that power goes into cooling. Climate change should be top of mind for an industry that relies on cooler temperatures and massive amounts of power.

Time will tell whether corporations are truly serious about buzzword-chasing. I hope they are. PM

Microservice Megadisasters

In the beginning, there was the big, bad monolith that did not want to change. Then along came Netflix and said let’s break the monolith apart into the small pieces. These pieces could then be put into the containers and shipped off to the Cloud to be easily scaled up or down, depending on the demand.

These Lego brick-like pieces called “microservices” and they are supposed to make it as easy to scale SAP systems as to open more cash registers at a supermarket. Except when not.

Turns out monolith is not necessarily bad and microservices are not always great. In this interview, the author of Monolith To Microservices book Sam Newman talks not just about how to break up a monolith but also when you probably shouldn’t. This quote could not have been truer in the SAP world that is sometimes too tech-obsessed after being tech-starved:

We focus on the tech tool, not the thing that the tech tool lets you do.

When considering microservices for your next project, think what they would “let you do” and if they’re the right solution in the first place. To avoid, you know, a megadisaster. JP

This story appears in Issue 20 of The Boring Enterprise Nerdletter

Psst, Want to Influence SAP?

It takes 10 votes for a request to be accepted, so we’ll need a bigger car

Discovering that there is a place to submit ABAP improvement requests to SAP feels like stumbling upon a magical portal accidentally left open by a scatter-minded wizard.

I certainly hope though that the Influence Opportunity “SAP BTP ABAP Environment” (the official name) will not just disappear. It runs continuously, i.e. there is no specific deadline for the request submission, and is accepting new requests for anything ABAP related. Don’t let the BTP nomenclature scare you, there is an option to enter requests even for classic ABAP.

If you have any improvement suggestions for ABAP or development tools, go to this page (registration required), click Submit Improvement, and influence away. While there, check out the existing improvements too and vote (see some of my recommendations). But shsh, don’t tell anyone I sent you! JP

This story appears in Issue 20 of The Boring Enterprise Nerdletter

Of Bulls And Bears

The article Of Bulls And Bears (Von Bullen und Bären) by Peter Hill is written with German precision, brutal honesty, and trademark humor (so subtle that you don’t recognize a joke until it suddenly hits you 3 sentences later). This expose talks about the different types of SAP customers:

  • the “powerful and well organized” bulls, large global corporations that run a tight ship;
  • the bears that “roar – and lose sight of the project”.

Peter’s description of the bears is chillingly accurate:

[…]those corporations that – out of sheer company politics and preoccupation with themselves – often lose sight of the real work on the necessary changes. Huge sums of money are sometimes spent just to end up with fewer functions and automations than before.

I bet every seasoned SAP consultant has encountered those projects where whoever screams the loudest gets their way, even if it adds no value for the business at large. Yikes.

Peter also offers solid advice for the consultants. The bull “can be tamed with a lot of patience and brain power” and the bear, “requires a thick skin and a lot of caution”. Power up your trusted translator and read the article in its entirety to avoid getting mauled on your next SAP project! JP

Check out more from this issue!

I Want My ERP

This is actually a really cool graphic. No snark here.

SAP turns 50 this year. Stuart Browne over at ERP Today has a great piece on what’s changed over the years, and why – dissimilar to MTV – SAP’s aging has been not-so-graceful in some areas.

In the past, solutions that offered great integration got the most attention from businesses. This was SAP’s kingmaking feature from the start – bundle business processes together and integrate them. Just like MTV with artists aiming for music videos as key to their image, consulting companies put SAP at the front of their partnership plays, creating an entire ecosystem.

But time marches on. MTV adapted from solely focused on music videos to creating other forms of viewer content. Browne rightly points out the best example of this: Beavis and Butt-Head. And then he (convincingly) argues that SAP hasn’t been able to reinvent itself similarly. Monolithic ERP has meant sacrificing the agility of some parts for the sake of moving things “at the pace of the slowest functions”.

Lots to chew on in this piece. I am also in agreement with two things: companies seem less apt to choose huge monoliths and instead want to break things up into best-of-breed, and the skills shortage in SAP consultants doesn’t help. I’ll add that orgs who take hyperscaler capabilities seriously and architect their networks of solutions around elastic platform resources will be best enabled to overcome challenges quickly. PM

Democratization Sweeping The Nation

In my other nerd life at Bowdark Consultingwe 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

See more at this story’s original home.

Got My Mind On My Product, And My Product On My Mind

Typical project NOT involving any product-minded developers

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.

Gergely Orosz, “The Product-Minded Software Engineer”

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

See more at this story’s original home.

Skills That Pay The Bills

Girls only want boyfriends who have great skills

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

See more at this story’s original home.