SAP BTP is not a one-size-fits-all solution for all your SAP enhancement needs
Mateusz Skrzyniarz
S/4HANA Development Transformation Expert - Strategy, Execution and Governance in Managing Custom Code
“BTP is the only way to go if you want upgrade safety and clean core” is a popular misconception about the only proper technique for S/4HANA developments and extensions nowadays. Companies spend big bucks on building processes around BTP, up-skilling project teams and moving all their custom developments there. But if we look at the desired end result - less effort in performing system upgrades, we see a rather big misunderstanding of the current extensibility model.
Popular misconception
Let’s start off with a clear statement
Extending SAP S/4HANA systems with the help of BTP is NOT the only way to ensure upgrade-safety.
In fact, if you look at the official SAP S/4HANA extensibility guide, you will notice that side-by-side extensions are actually the third recommended way to extend SAP S/4HANA Public Cloud. Simple data model and Fiori app extensions do not need you to build anything on BTP and I would even dare to say that it would be considered insane if you decided to build them there. Actually, SAP even clearly states that extensions on the BTP are rather only useful in the following use cases
See? No mention of “Fiori apps that consume data from a single SAP ERP system” as many people claim to be the case.
Source of confusion
So, where did this confusion originate from? I feel like there are in fact 2 culprits that helped this popular misbelief evolve:
1 → The term “clean core” incorrectly implies that remaining upgrade safe is only ensured if the core (ERP system) is kept clean and all developments and extensions are done outside of it (on the SAP Business Technology Platform)
Recommended by LinkedIn
2 → If you really analyse the content of the S/4HANA Extensibility Guide, you will notice that in the case of on-premise (or private cloud) deployments (chapter 5), there is very little mentioned about the positioning of BTP. It still mentions 3 tiers but rather different ones:
But, directly after that, on the overview diagram we see BTP and SBS mentioned as Tier 1 without too much explanation
Do some developers or architects falsely interpret this as the go-to technology for S/4HANA private cloud & on-premise extensions? Maybe…
My interpretation of the S/4HANA extensibility guide for on-premise & private cloud
My interpretation of the S/4HANA extensibility guide for on-premise and private cloud customers would be to actually first look at the public cloud section (chapter 2 of the guide). Of course, not everything will be possible in the case of on-premise & private cloud deployments but the following hybrid 4-tier S/4HANA extensibility model could be derived:
What are your thoughts? Do you also see BTP being marketed as the solution for almost all extension needs? Or is it just my own (and some of the customers’ I’m dealing with) misconception and not a real problem? :-)
Disclaimer: Everything you’ve read above is based on the version of the document valid as of August 27th, 2023. I cannot take any responsibility for changes to the guide after this date. If you see any breakthrough changes, please let me know and I’ll do my best to update it.
Technical Architecture Manager at Accenture
1yTotally agree.Indeed "Clean Core" is a very confusing term. Clean Core doesn't mean everything has to be moved to BTP. Guide says that we can still build Cloud ready, modification free extensions using ABAP Cloud with S/4 HANA On-prem/Private Cloud/ Public Cloud.
SAP Programme Director & Trouble shooter | Future SAP & AI Advisory | Separation M&A TOM Architect | Finance Domain Business Transformation Expert | Data Alchemist | TOGAF Ent Arch - CTO | SAP Investor Analyst | XTed
1yAbsolutely Lets take our ECC RICEF, select what we want move it to BTP and implement a clean core S/4 public. Or those nice hyperscalers SAP have just nuked could offer PaaS with bells on including an alternate to abap and sap build enabling easy to maintain micro services to the side. BTP isnt the only show in town and SAP have in my opinion mis-timed the SAP cloud or bust strategy, just saying.
NOT a HCM/SuccessFactors consultant! Software development consultant. SAP full-stack developer/architect.
1yI'd say it's a general truth in software engineering that there are no cookie-cutter fit-for-all solutions. Whether you're talking about tools and technologies, or processes, methodologies and organizational patterns - building software is just too complex and unpredictable for that. Of course that's not exactly what majority of customers want to hear, and SAP is a market driven organization ;)
Mateusz Skrzyniarz has penned a thought-provoking article that certainly makes us ponder. At SNOK, being a gold partner of SAP, we often encounter similar challenges as described by Mateusz. 👉 The first thought that came to my mind after reading this article is how crucial it is to understand that there's no "silver bullet" in technology. SAP BTP has its place and value but is not a one-size-fits-all solution. 🤔 The second reflection is that terms like "clean core" can be misleading. SNOK always takes a holistic approach, analyzing the client's needs and tailoring the technology accordingly. 🚀 Last but not least, the need for continuous learning and adaptation is vital. Technology is ever-changing, and we must keep pace with it. That's why at SNOK, we organize workshops and consultations to keep our teams up-to-date. What are your thoughts on this article? Do you have similar experiences? I'd love to hear your opinions!
SAP Technical Architect | BTP | Gen AI | DevOps | Clean Core | S/4HANA | Design Thinking | Integration
1yI agree. BTP is not as mature as some PaaS. We’re using Azure on current client for APIs and Microservices to keep the core clean. Power platform, Event bus and .Net is doing all the heavy lifting for us. Concepts all the same.