Main content

Public cloud ERP versus private cloud ERP - more than a deployment option. SAP's Jan Gilg weighs in on the S/4HANA dual code line debate

Jon Reed Profile picture for user jreed April 11, 2024
At this year's SAP Sapphire networking events, you just might hear a debate about S/4HANA's dual code lines. But this isn't just navel-gazing. As this exclusive interview with SAP's Jan Gilg shows, this debate leads us right into SAP's Public and Private Cloud Editions of S/4HANA, and why these choices matter.

Jan Gilg of SAP
(Jan Gilg of SAP gives his S/4 take)

SAP is a complicated company to cover; the pros and cons can be tough to unravel.

SAP's moves have clearly impressed investors in 2024  - though SAP will have to justify investor confidence in its AI plans. SAP is hardly the only company facing that AI execution pressure.

Sometimes the best way to get your strategy across is to change your messaging. In my series on SAP's AI strategy with SAP's Chief AI Officer Dr. Philipp Herzig, I thought Herzig did well on both counts; enough to justify two articles (part two: SAP AI's strategy unfolds - on foundation models, cloud migrations, and how customers should respond). Vendors always like us to write about the latest news - but to me, these frank talks behind the news are where the real action and insights lie. I hope readers feel the same.

The SAP S/4HANA dual code line controversy - Jan Gilg clears the air

Enter Jan Gilg, President and Chief Product Officer, Cloud ERP at SAP.  Gilg is someone I have always looked to for a thoughtful explanation of "What the heck is SAP up to now?". When you consider the importance of customers moving to S/4HANA - not to mention SAP priorities like cloud, "clean core," and RISE/GROW, Gilg's cloud ERP team has a pivotal role. So, when Gilg agreed to answer a couple of burning questions, we met up on video.

My first question for Gilg conjures up a classic event barstool debate: did SAP make a mistake splitting S/4HANA on-prem/private and public into two code lines? To be honest, I'm not obsessed with this particular SAP question (I'm obsessed with a different one). Nor am I a big fan of enterprise navel gazing, for reasons I'll explain later.

But: I've run into a number of hardcore SAP folks on LinkedIn who bring up this point whenever I post SAP articles. Why is this barstool debate relevant? Because it sheds light on SAP's "clean core" mantra, and what a migration to the S/4HANA public cloud entails.

My contention is that the "two code lines" question is overrated. I believe that the move from S/4HANA private to public is more about how clean your SAP landscape is than anything else (with the exception of industry needs; I'll get to that later). Even if you did have the same code line to begin with, if you've customized the living heck out of that code, you're not moving to the public cloud easily.

But if you have a fairly clean S/4HANA core, and you can't move to the S/4HANA public cloud relatively easily, that opens up other competitive options - something SAP obviously wants to avoid. So, this question is relevant beyond LinkedIn potshots. I told Gilg about these LinkedIn debates - and asked him to weigh in. He told me about his talks with customers:  

I've had a lot of discussions with customers on it. To be honest, there's a little bit of a myth out there anyway; it was never a single code line in that regard. They were always branches, and thousands of them. The public cloud always had a different approach and different scope than the private cloud.

The question of feature parity also factors in. As Gilg wrote to me later:

I really also would like to de-mystify this 'feature parity' discussion (between private and public cloud). This was never the intention. Why? Because we have tons of longtail in the PCE [Private Cloud Enterprise] world – but since [PCE] is the primary path, especially for our very large enterprise customers, we need all this to ensure a smooth conversion from ECC.

But, as Gilg wrote, the public cloud is subject to different SaaS norms:

The SaaS world however is all about adoption, and we cannot afford to build much longtail, because you will always have a handful of customers using it and that requires us to continue to maintain and build on it – so again it ties up resources.

SAP's BTP platform play is envisioned to fill this gap:

That’s why the strategy for SaaS ERP is that we build what 60-80% of all customers need and partners should build the rest (of course, the way this can be consumed by our customers needs to be much better than it is today – but I am talking strategic intent here) – so again for me the code split is an internal optimization.

S/4HANA private versus public cloud - considerations for customers

Gilg says customers should not boil this down to a deployment option choice: customers should take their choice based on business model and tech priorities:

What is critical is that customers understand public and private are two products with different intent (while having commonalities) – they need to decide first what their business objectives are, and then decide which solution fits best – there is no better or worse – but for sure they are different (and not just a different deployment option of the same solution).

When SAP took a hard look at their on-prem industries years ago, a decision was made: attempting to duplicate these in the public cloud didn't make sense:

You mentioned the industry solutions, that's one of them, because we said, 'They're too heavy; they're too interwoven; you cannot really run them as a SaaS solution... We need them in the private cloud, for compatibility reasons, etc. - for those customers who really [need the older industry functionality to do a cloud conversion.' But in the SaaS world we need to be more selective – so we only took the parts that made sense. Because moving into a SaaS model anywhere is always a new project, right?

So when an SAP ERP customer is looking at private and public cloud options, what issues should they consider? Gilg:

A customer at the beginning of their cloud journey, they need to decide, 'Am I starting fresh, or am I trying to carry over some of my legacy?' And then to your point, there's also an in-between where customers say, 'Hey, to step into a SaaS model is too big for me. I will go down the route of private, but I started standardizing a lot of processes; I started adopting best practices. And I started especially to manage my custom code, in the sense of clean core, or move it out.' And then the eventual step to the public cloud, if that is something customers want to do, will be much, much easier. Still, you would have to kind of implement it new, but you can carry over many things. And we have a certain semantic [consistency]  which we will not give up.

The burning question - does a clean S/4HANA core lead to a smoother public cloud migration?

And with that, Gilg hit on the burning question. Can customers on a "cleaner" S/4HANA PCE move to the Public Cloud Edition with less friction? Gilg:

We wanted them to say, 'Hey, if you move to S/4 public cloud, this will be much, much easier.' We help you with data migration; we have certain semantics that are the same, and so on. And if you kept a clean core, you can probably reuse a lot of your extensions anyway. So I think this makes it much easier.

In my conversations, this has never been something that customers don't understand - once they understand that those are two different products. Maybe we haven't communicated this clearly enough at the beginning. Because it's not only the scope; it's also the configuration, which is limited by choice -  what customers can do in terms of variants in the configuration. We did that because we have to manage it for customers. And we have to make sure we can upgrade all those customers at the same point in time. Therefore, we have to manage the complexity.

Gilg says this type of SaaS ERP tradeoff is not unique to SAP; it's part of the inherent pros and cons of the SaaS software model.

This is often seen by install base customers as a limitation - one that has nothing to do with one code line or separate code lines. It's just the nature of the SaaS solution, where I cannot give so much freedom to our customers like I could in R/3, or even S/4HANA on-prem. I mean, you can do anything with configuration. There are also things that were never intended by us which customers do.

Thus Gilg's stance on the code line split:

Therefore, I think the code line split per se is not something which customers see as super-negative. I think it's rather that they see specifically for the public cloud; this allows us to do very different things in terms of innovation because we don't have to look after all the customers that sit on-premise. For instance, we have to be afraid that we make an incompatible change, and that hits those customers then. So that's a way for us to innovate faster, but also simplify the stack and reduce dependencies and so on.

But SAP is also resolute about making the private cloud a long-term solution also:

From what I hear from many customers, they say it seems rather positive, but they also say, 'Make the private cloud also a long-term solution,' which we absolutely do. So we don't force the customer to move away from the private cloud.

My take

I believe the future of enterprise software is (mostly) public cloud, so I always have mixed feelings thinking about private cloud as a long-term deployment option. But it's clear from a customer landscape perspective why SAP would do this. I agree with Gilg's explanations of the standardizations imposed by SaaS, though the whole point of an extensibility platform like SAP BTP is to take away some of the limitations of "vanilla" SaaS, and support richer industry functionality.

I've told Gilg I look forward to talking customers that make the move from a "cleaner" private cloud to S/4HANA Public Edition, and hear firsthand if this was an easier migration, or a painful, ground-up re-implementation.

This debate surfaces important points for customers evaluating their private/public options. One area that needs further discussion is the issue of industry cloud functionality. Customers have all kinds of good reasons to hold off on public cloud ERP. But if they see the lack of industry cloud depth as an issue, then SAP needs to close that gap. Gilg has alluded to the crucial role of partners there; agreed. SAP can't possibly build out across all the relevant verticals and micro-verticals. That should be a good topic for my upcoming podcast with Josh Greenbaum and ASUG CEO Geoff Scott on the potent issue of how SAP partners fit into the innovation strategy.

What is needed now is an update on which S/4HANA Public Cloud verticals (besides Professional Services) are ready for prime time, which are solid but still need micro-vertical tuning, and which ones are not there yet. I believe industry cloud depth is the hidden issue underneath the dual code line criticism. SAP's Industry Cloud approach is an interesting way to compliment a core SaaS ERP release; I'll look to get an update soon. (It's notable that three of the four use cases on SAP's S/4HANA Public Cloud Edition landing page are manufacturers).

I alluded to the futility of enterprise software navel-gazing. I see one misstep SAP made others may or may not agree with; that one will come out in an upcoming podcast, where Eric Kimberling of Third Stage Consulting put me in the hot seat. But as I said to Kimberling, the enterprise software market is a forgiving place. Customers are loyal; on the darker side of loyalty, it is not easy to switch ERP vendors. The dual code line decision is a bridge long since crossed. The reality is this: SAP still has an opportunity to deliver on public and private cloud ERP, not to mention on its AI ambitions. We'll see how that plays out.

I got some satisfaction hearing Gilg talk about SAP BTP in this context:

The private cloud is a long term solution with its own innovation roadmap - different innovation often than public and we can still cross port we do that. Also, from left to right. And we build many innovations now on BTP, and that is available for both public and private cloud customers. So I see private cloud customers adopting SaaS components in a modular approach more and more.

I'd like to see that extend to all SAP customers. But then I hold the outspoken stance that all customers should have access to SAP innovations, via BTP as the primary delivery platform for innovation. That brings us to burning question number two, on RISE with SAP - which I'll pick up in another article.

A grey colored placeholder image