SAP BTP: the question is not whether, but what
Every S/4HANA landscape has requirements the standard does not cover. They used to be programmed freely into the core; today SAP sets out clear routes: extensions in the core via released interfaces, extensions alongside it on the SAP Business Technology Platform – or deliberately doing without when the standard is enough. Taking that decision before the first developer is commissioned is the real lever for a system that is still maintainable in five years.
We do not develop on the BTP – and that is exactly why we can assess independently what belongs there. Our job is the evaluation: which custom development is still needed at all, which becomes an extension on the platform, which disappears into the standard.
How you know you need this
The BTP question rarely comes up by itself. Typical triggers:
- You are facing the S/4HANA transformation and have several hundred custom developments of which nobody can say which are still needed.
- You are considering the Public Edition – changes to the core are not provided for there, and extensions run via key user tools, released interfaces or the platform.
- Your implementation partner proposes an extension on the BTP, and you would like to judge independently whether it is necessary.
- Interfaces to partners, customers and authorities are multiplying, and each one is built differently.
What the platform is – and what it is not
The SAP Business Technology Platform bundles the tools with which S/4HANA is extended and integrated without changing the core: side-by-side extensions next to the system, the Integration Suite for interfaces, data platform and analytics, and the foundation for SAP’s AI functions. The idea behind it is called clean core: the standard stays upgradeable, anything individual lives alongside it.
The BTP is not an end in itself and no substitute for a process decision. Whoever moves a poor custom development onto the platform has a poor custom development on the platform. The first question is therefore always: is this function needed, and does the standard not cover it after all?
How we sort your custom developments
- First we count what sits in the system, how often it is called and which process depends on it. In our experience a considerable share has been unused for years.
- Every remaining development lands in one of four categories: it goes, because the standard replaces it; it is rebuilt as a clean in-core extension on released interfaces; it moves to the Business Technology Platform; or, by exception, it stays as a classic modification because there is no other route.
- This classification is not for IT alone. It belongs with the departments that use the development today – otherwise a working step someone relied on disappears along with the code.
- Alongside the recommendation you receive guardrails for future requirements that your team and your implementation partner can align to.
The three-step sequence behind it applies to all our assessments and is described on the SAP overview. How we work – the shared framework
From your side we need the business departments that use the developments, someone from IT who knows the landscape – and the willingness to part with the familiar when the standard replaces it.
What you end up with
- An evaluated list of your custom developments: dropped, in-core extension, extension on the platform, stays as an exception
- A written recommendation with rationale that holds up before your committees and your implementation partner
- Guardrails by which future requirements are classified – so the list does not grow again
What we do not do
- We do not develop on the BTP and do not operate platform components. Our service is the assessment – independent of what gets built afterwards.
- We do not recommend an extension whose process we have not understood. First the business question, then the technology.
Typical questions
- Do we need the BTP if we stay on-premise?
- Not necessarily, but the clean core idea applies there too. Those who keep extensions out of the core get through every upgrade faster and cheaper. The platform is the place SAP intends for that; whether it is the right one for you we clarify in the evaluation.
- Won’t that be more expensive than a development in the core?
- At first often yes, over the lifetime usually no. Developments in the core cost again with every upgrade and every test. We compare both over five years, not just the initial effort.
- Who then develops the extensions?
- Your implementation partner or your own team. We provide the evaluation and the guardrails, check the results against the requirements and keep to the guardrails together with the team so the core stays clean.
- How does this relate to SAP Business AI?
- SAP’s AI functions build on the BTP. Those who have already assessed the platform can evaluate Business AI more easily later – one more reason not to leave the decision to chance.
Initial consultation on the extension strategy
How many custom developments are in your system, and who can say which of them are needed? If you hesitate at the second question, that is a good reason for a conversation. Anyone preparing this assessment as a consulting firm for a client gets the same appraisal from us – then on behalf of the partner.