The hottest SAP issues always seem to come back to RISE with SAP, or S/4HANA migration rates. But one overlooked story of importance is SAP BTP (Business Technology Platform).
SAP leadership has become quite vocal about the need for customers to move away from overcustomized legacy ERP, into an app-building/extensions model based on BPT.
Given that the traditional bread-and-butter revenue model of SAP's systems integrator partners were often based on code customization, this is no small shift - either for customers, or for SAP's partners. But the incentives are there - and not just for extending SAP applications. For those customers involved in multi-year projects, building smaller workflow applications on a platform like BTP can potentially serve up the "quick wins" most projects now need - if you want to maintain executive buy-in.
Extending on SAP BTP - a viable alternative to custom code?
SAP Executive Board Member Thomas Saueressig explained how SAP employed that same tactic internally, rolling out 400 mobile-enabled BTP apps during their own internal S/4HANA migration. But does this hold traction on the customer side as well? Yes, there are 10,000+ SAP BTP customers, but not all are using the platform for app building.
One prominent example from SAP TechEd 2022? Executive Board Member Juergen Mueller's keynote with Apple's use of BTP for iOS app development. Last year, I published a deeper dive on BTP, via How Bristol Myers Squibb uses SAP BTP to evolve their S/4HANA landscape - and their business. This summer, I was introduced to Hilti, a long time SAP customer with an S/4HANA go-live under their belt. When I heard SAP BTP is a key factor in their project results, I took the opportunity to learn more.
Hilti is also a RISE with SAP customer. Microsoft documented why Hilti made the move to RISE on Microsoft Azure:
If we hadn't scaled up, this would have had a significant business impact, so we're happy we could do it in less than six months using RISE with SAP on Azure - in the middle of a global supply crisis, no less. [Dr. Andreas Weiner: Hilti RISE Program Manager and Head of Strategic IT Projects]
Hilti's cloud story - scale and resiliency must be evaluated
With supply chains straining - and the subsequent need for digital visibility - a global construction industry supplier like Hilti can't cling to older ways of working. But from a tech standpoint, whatever Hilti undertakes must scale internationally - including their core markets in Asia, Europe, and North America. That prompts my first question: if Hilti successfully went live on S/4HANA in 2018, why sign onto RISE with SAP in 2022? As Hilti CIO Johannes Reichert told me during our video interview:
We had our on-prem solutions in a data center at our headquarter location [Liechtenstein], and a secondary backup center maintained in Switzerland. At that time, nobody actually believed that in Europe, you could discuss power grid failure and resilience on such a level of magnitude.
But in today's economy, you must consider these scenarios:
Even with 200 kilometers in between, you could have power grid situations that [render] your primary and your secondary actually unusable. When we started the discussion in 2020, that was the primary driver.
So the cloud discussion started with resilience - and less dependence on one energy grid. Reichert:
It makes sense long term to think about, 'If we do move into the cloud, how can we significantly increase the resilience of the setup?'
But that challenges the internal data center approach. That led to comparisons with the costs of Azure, and RISE with SAP:
That reaches a level of resilience that we cannot, with reasonable effort, produce ourselves. If I take today - and that is very often done - people compare the costs of running it yourself with running it on RISE, or on Azure, or whatever. And then you hear, very often, people saying, 'Yes, this is so expensive.'
You need to compare apples with apples. Because if you would need to create the same level of resilience, high availability, cut over, a failover data center, full blown, in a second site, with everything surrounding it being really operational - if you want to engineer the same level of resilience, the cost would be much, much higher.
We did the disaster recovery test just recently, and we were able to get to operational within a very short period of time - again, full blown, the entire landscape.
Reichert's evaluation led to RISE on Azure:
We compared apples with apples and said, 'Okay, if we want, as a company, to have this desired level of resilience, then it is actually more beneficial for us to leverage the power of SAP and Microsoft to get this done.'
Why RISE with SAP?
This decision proved fortuitous: new business opportunities increased hardware demand, beyond what Hilti could have scaled internally. Hilti's RISE with SAP implementation happened in three phases, finishing in July 2022. This allowed Hilti to launch new programs in parallel with RISE. As per Microsoft:
For example, Hilti recently introduced Nuron, an all-new, 22-volt power tool platform that unifies a wide range of tools in a single ecosystem. That launch, together with the requirements brought on by an SAP revenue account and recognition solution implementation, led to an increase in volume needs for its system landscape, and was a key driver for the company to upgrade and scale up its S/4HANA deployment from 12 TB to 24 TB.
That really rounds out your cloud business case. Yes, the additional resilience/rollover is important, but supporting new business models/product rollouts is the real ROI sizzle factor. As Reichert told me:
We would have never have been able, within a decent timeline, without the help from SAP and Microsoft in their data centers, to actually get 24 terabyte boxes installed. So this ability to engineer, and to deliver on the scale. To have that as a midsize company with 6 billion turnover, you would need to spend so much more than you spend on RISE. That, for us - it was very clear that it overall gives a significant amount of benefit.
On SAP BTP - and the value of the clean core
And what about SAP BTP? Does Reichert buy into SAP's "clean core" model? As I put it to Reichert: SAP is encouraging customers to take a hard look at customizations, rather than just shift it all to a cloud environment, and miss out on benefits of easier upgrades, easier integrations, better use of AI, etc. Is this something that Hilti buys into as well, this 'journey to the clean core?' And how does extending on BTP fit into that? Reichert:
Our IT strategy, since many years, has a lot of these elements included, making sure that the leading systems in the center are run according to our architecture and security principles. One of the architecture principles is obviously, especially in the SAP environment, we have hardly any; we have one modification in the system. Modification of SAP standard code - that's what you should absolutely not do.
When Reichert's team migrated to S/4HANA, they re-evaluated custom development, with an eye to standard:
The custom development that you can do within your own namespace in the SAP environment, we have some of that. We also have business differentiating things where SAP didn't have the capabilities. And yes, it is a good practice. We did that when we did the S/4HANA move, to actually review this and try to bring stuff back to standard, wherever you can.
Now, in the cloud environment, keeping the core clean is a discipline:
We do an evergreen approach every two years. We run the upgrade, so we suffer the pain actually as well. We have an interest to keep it as clean as possible. Nevertheless, it is still quite an extensive exercise.
And how does SAP BTP fit into the picture?
With BTP, and the predecessors of BTP, we already have multiple applications on them, where we run very specific business applications that are way too complicated to put them into the SAP core, but where we consume and interface with the system over standard interfaces. So we've followed this development paradigm since the first [BTP] application we built in 2018.
BTP lines up with the forward strategy, which is the same across Hilti's software vendors:
We also believe going forward that this was already part of our strategy - only develop stuff that is differentiating. We put it on cloud platforms, and interface them with our leading systems, which we try to keep as close as possible to the vendor standard.
The wrap - how SAP BTP fits into a different apps strategy
After our first interview, I asked for an example of the BTP apps Hilti has developed. Reichert wrote:
We are running quite successfully on top of BTP, our SAP Subscription Billing in the Cloud which also uses SAP Event Mesh on BTP to provide a solution for our Software & Service Products to be bought by customers in subscription models.
Overall, it's quite a big success for us, covering not only Hilti Profis Engineering but also Fieldwire SaaS Subscription sales, and we plan to further expand this in the future. BTP as operating platform in combination w/ dedicated BTP services allowed us to spin up our Software Sales based on Subscription Billing in the Cloud very fast and efficiently – while staying compliant & well connected to our S/4 on RISE setup. (Btw. also a topic which we on regular basis exchange with Thomas Saueressig on, and is part of our strategic project roadmap).
This is a good example of BTP-based SAP Products plus extension of capabilities as required with dedicated BTP Service, and to my understanding, following to a large degree the reference architecture from SAP of the future for a clean core.
I have never felt it's diginomica's job to recommend a particular software vendor, or upgrade path. Just as Hilti carefully evaluated their options, so should any customer. But I do agree with Reichert: this development model of keeping to standard cloud configurations, and extending with differentiated apps, is far more appealing than the on-prem custom code/tech debt quagmire too many businesses are still caught up in.
I also agree with Reichert on this: cloud data center evaluations should be true apple-to-apples, including the factors of resiliency and business model expansion that have proved important to Hilti. I would add cybersecurity to that pros/cons scenario - something Hilti also examined that I'm out of space for here.
For customers considering such moves, Reichert adds one final piece of advice: make sure your business users are not thrown off by your architectural shifts. Speaking of their phased RISE with SAP project, he says:
I've rarely seen that size and amount of changes executed in sequence so tightly, without the major business interruptions. The business did not notice.
End note: for more data on how SAP customers perceive the custom code challenge, check the latest from ASUG CEO Geoff Scott, ERP customers and the custom code dilemma – can automation help? The numbers say yes.