Q&A with Joshua Greenbaum: SAP Custom Code and Digital Transformations

The benefits of digital transformation have been heralded for years now — and there’s arguably no denying them — but knowing when and how to make that leap can still be confusing. Should you go all-in or take a modular approach? Can you start now, or do you need to wait? What will work better (or break) when you make the switch?

To gain deeper insight into the factors affecting these decisions, Pillir partnered with the America’s SAP Users’ Group (ASUG) to learn how SAP customers leverage custom code, approach digital transformations, and manage migrations and upgrades at their organizations. Today, we’re speaking with Joshua Greenbaum, principal of Enterprise Applications Consulting to get his take on the findings.

As a computer programmer, systems analyst, author, consultant and industry analyst during the past 30 years, Greenbaum has followed the ups and downs of the enterprise software market. In the early 1990s, he wrote the first technical analysis of SAP’s R/3 enterprise software suite, helping to establish his role as an expert in the market. Here’s his take.

Pillir: ASUG's study shows that 91% of businesses are currently using custom code. While this is critical to running their operations, it can also present some significant challenges. Why is custom code so detrimental to organizations?

Greenbaum: Well, you know, custom code is a two-edged sword. When it's done well, and it's done for the right reasons, it adds an important level of competitive advantage to what would otherwise be a standard implementation. And for a lot of companies, this is very, very important.

Whatever industry you may be in — drilling for oil or making milk products — you may have a special way of doing things that really makes you as a company stand out. If so, you’re going to want to customize SAP to do those things. That's the positive. The negative is that often these customizations are not as necessary as people believe. Many times, they’re done for political or territorial reasons, and they don't stand the true test of business imperative. But that’s not the biggest issue. Custom code is not cheap to build, and it’s certainly not cheap to maintain. Worse, it puts a big question mark on an eventual move to the cloud because the cloud requires, as much as possible, a fit to standard model.

That said, you’ll still want to have the custom code that helps you stand out in your market. That's how you establish a competitive advantage. But it's not necessarily going to be those customizations you built in 1993. You need to look to customizations that are going to make that difference in 2023.

Pillir: Are there any areas of the business that are more likely to use custom code?

 Greenbaum: Generally speaking, there are four domains that have the largest amount of custom code interfacing within the SAP system: supply chain, procurement, logistics and finance. That's because those are the most basic core functions that SAP has been supporting since its inception.

But one of the great key findings of this study was that 13% of respondents said more than half of their central processes depend on custom code. And again, it’s hard to argue with finance, procurement, supply chain and logistics not being absolutely essential to running most businesses, particularly those in a product or manufacturing industry. So, I think the “Why” is more of a historical artifact. SAP has been around for a long time, which means some of these custom apps are six or more years older — and if you look at industries like utilities or oil and gas, they've got 20 plus years of legacy, custom code lying around that’s not necessarily appreciated or understood, but it's there.

Pillir: Let's talk a little bit now about the financial impact of custom code on the enterprise.

Greenbaum: It's expensive. Next question. It's the gift that keeps on giving, and particularly if you're the consulting firm that built it, and is now tasked with maintaining it. For decades, there have been studies documenting the drag custom code has on finances. In some cases, three-fourths of the budget can be devoted to maintenance and keeping the lights on.

When companies think about moving to the cloud, or migrating to SAP S/4HANA, there’s the initial concept that they’ll save a lot on maintenance, but that depends on how much custom code you’re willing to give up. Before taking that step, you have to consider a lot of factors. You need to understand what your custom code does (and doesn’t), who’s using it, why it’s still needed — despite how the core software system is evolving — and do a careful analysis because it is damn expensive, and damn complicated to maintain.

And in many ways, it's not just a barrier to the budget, it's a barrier to efficiency and to innovation as well. In many cases, custom code is a drag on innovation. That's another factor that must be weighed in terms of what you want to do.

In the digital transformation world we now live in, IT is more of a customer-facing, front-end function. IT can't innovate the front end if the back end is 20 years behind. You can't build the most efficient customer experience this way. If you promise product delivery in X number of days, but your supply chain is tuned to deliver in three- or four-times X number of days, those older processes can be anchors to new efficiencies.

So, you’ve got to really understand that there's a larger impact and how the hell do you move your company forward when you're dragging this is anchor behind you?

Pillir: That's a good analogy. So, how much of their technology budget would you say is focused on custom code?

Greenbaum: From what we see, people are underestimating how much they're paying for the custom code, because when we look at how many objects they have that are customized, and how much time their people spend on that, and then do the math, you're talking about millions of dollars.

I think the results we see in the survey are an artifact of a lack of ability by any individual in any company to understand how big and pervasive custom code is across a large enterprise. When you do these kinds of audits, you don't just find skeletons in the closet, you find closets you didn't know were there. I had a client who did an audit and literally found a closet with a bunch of servers in it that no one knew existed. Where are these servers running? They had to start doing a network trace to figure out what was coming in and out of the servers.

Pillir: How does custom code play into SAP Business Transformation Platform, particularly as it relates to RISE with SAP?

Greenbaum: To a large extent, RISE with SAP is about is helping customers manage their relationships with the hyperscalers. Under RISE with SAP, you have one contract with SAP, and that encompasses the hyperscaler.

One of the things SAP BTP does is take the full domain of customization away from the hyperscalers’ platforms and puts it on the SAP platform. This enables customers to build customizations using SAP’s toolkit, within its platform, running them in its cloud.

Once you've adapted to a fit-to-standard approach, BTP is central for building and managing these customizations. And obviously, super important from an SAP standpoint is, of course, doing it in a very, very efficient way.

That's the other problem with hyperscalers. They're not necessarily incentivized to have the cleanest, most efficient process running in their cloud, because they're paid mostly by usage. Sure, there are volume discounts, but at the end of the day, the focus of cloud SaaS is putting more cycles into the cloud.

Enforcing efficiency by moving the complex problem of customization to BTP is a way for SAP to control how well these new customizations — we now have to call them extensions, by the way — are running. So there's a lot of good, I think, to be had in this. And I think we're seeing this in other domains where SAP is starting to exert more control over how these hyperscalers implement SAP. Because at the end of the day, a bad implementation in an AWS or Azure or Google Cloud comes back to haunt SAP directly. SAP wants that control.

Pillir: Okay, so what sort of impact does all of this custom code have on a company's IT teams and/or lines of business (LOB)?

Greenbaum: I've looked at lots and lots of digital transformations, and the ones that are most effective and most successful are grounded in this interaction between lines of business and IT — from the get-go, not as an after effect. Not as the LOBs appearing on bended knee as a supplicant, begging the feudal lord to give them resources. It's a partnership. And that partnership is what makes for a successful transformation.

But, without a doubt, the IT department has to do the blood, sweat and tears of managing and maintaining the code as it is today. But this also allows them to be more aligned with the business and be a bigger contributor directly to business success by taking charge of this problem. Digital transformation can’t happen without this marriage between the IT and LOB teams. Having this alignment is going to be one of the most important fronts in any company's DT strategy.

The research shows the importance of LOBs in in making these decisions as well. I think that's a huge net positive for companies.

Pillir: Alright, so now let's talk about digital transformation. What happens with all this custom code if companies do decide to digitally transform their organizations?

Greenbaum: There are two fundamental processes in any digital transformation. One is the rendering of existing processes for more efficiency and better customer alignment. The other is related to net new opportunities. So, there's that balance of making the old better, and taking off in completely new directions. That's what most companies are grappling with simultaneously, and ideally their digital transformation is an answer to the question.

Pillir: Taking everything into consideration, how important is standardization when it comes to digital transformation?

 Greenbaum: I think it's essential and dangerous simultaneously. It's essential to standardize because it creates efficiency and cost effectiveness — and because it’s never over. The more you base your transformation on standards, the easier it is for these areas for your organization to adapt at the edge, and reinvent the edge, because the core is standard. But if you rely on it too much, then you've lost differentiation. So companies are always going to be looking at this as a balance.

It’s always going to be a complicated story. But at the end of the day, a company should start by asking 'how much can we standardize?’ Because that's a simple, cost effective issue that’s an opportunity not to be missed when moving to the cloud.

Pillir: What advice would you offer to companies about customization, and how to, you know, bring it all together?

Greenbaum: Talk to a partner who understates this problem. And I really mean it when I say that doing this alone is impossible. A lot of companies are really good at doing the things they've been doing forever. Doing things differently, however, with both custom code and imagining transformative new code requires some outside advice. And, when it comes to the complexities of understanding what to do with custom code, most IT departments aren't experts at that; they don't have the folks that are trained to do it. Having a partner that can come in and really do that assessment and give that advice based on deep experience with other companies who've done this is key. That's pretty valuable because going it alone is probably not going to work out the way you'd like.

You can read more of Josh's insights in his special report on Custom Business Processes and SAP’s RISE: Strategies for Migration and Co-Existence