The name covers several different things
SAP Business Technology Platform is one name sitting over four fairly different sets of products, which is most of the reason nobody walks out of the slide able to explain it. There is somewhere to build and run applications that are not inside the ERP. There is integration between SAP systems and everything else you own. There are data and analytics services. And there are the AI services SAP layers on top of the rest.
Those strands have almost nothing to do with each other day to day. A team building a customer-facing application on BTP and a team wiring SuccessFactors to a payroll provider through it share an account and a bill and very little else. The presentation puts them in one story because they arrive under one contract, so the room hears one product and goes looking for one use case.
The first useful question about BTP is which strand somebody means. Ask it in a vendor meeting and the conversation gets concrete inside a minute, because the answer decides who on your side has to learn something new. SAP BTP on a licence line is one item. BTP on your roadmap is four separate pieces of work with four different owners.
Custom logic in the core is what it argues with
BTP exists because of an argument SAP has been making for years about where custom logic belongs. Modify the core ERP and every upgrade has to carry those modifications forward, which means a regression test cycle scoped by how much of your own code sits in the path. Anyone who has run an ECC to S/4HANA move has seen that bill arrive.
The clean core position says custom logic should move out to somewhere with its own release cycle, talking to the ERP through released APIs and business events rather than reading and writing tables directly. BTP is where SAP wants that logic to go. Most of the platform makes more sense once you read it against that one sentence.
The argument holds up on the technical side. The money is harder, because the saving and the spend land in different places, which makes clean core a budget decision before an architecture one. The upgrade team banks the benefit. The project that has to build the extension pays for it, usually in a quarter with no upgrade anywhere near the plan.
What building on the extension strand involves
The extension strand gives you runtimes to deploy to and services to build against. Cloud Foundry and Kyma are the two most teams choose between, and there is an ABAP environment for shops that want to stay in ABAP under cloud-ready rules. Around them sit the services an extension needs to reach the core safely: connectivity back to on-premise systems, destinations, and an identity service that carries a user into the ERP without a second login.
The part that never appears on the slide is that you have just acquired a real deployment target. Code has to be built, versioned, released, monitored and patched by somebody. An extension running on BTP needs a promotion path between environments, a place where its logs get read, and a named person whose job includes noticing when it stops. None of that comes free because the runtime is managed.
Skills move the cost more than the licence does. An extension built in Node or Java on SAP's Cloud Application Programming model is an ordinary application with ordinary application problems. The ABAP developer who owned the enhancement it replaced may not be the person who can support it at three in the morning, and that gap is worth costing before the first sprint rather than in the second month of hypercare.
Integration, data and the AI services on top
Integration Suite is the strand most organisations touch first, often long before anyone writes a line of extension code. It covers the connections between SAP and everything else, with API management, message and event handling, and a stock of prebuilt content for SAP to SAP flows that would otherwise be hand-built. Teams land here because they have SuccessFactors on one side and a payroll provider on the other, not because somebody drew a platform strategy.
The data and analytics strand covers SAP Datasphere and SAP Analytics Cloud, which handle modelling data across systems and reporting on it. Whether you need them depends almost entirely on what your reporting already runs on. Plenty of SAP customers have a warehouse elsewhere that works, and standing up a second one because it came in the same contract is how an organisation ends up with two numbers for the same figure.
The AI services sit above all of that. SAP AI Core and the generative AI hub give applications a governed route to models, and Joule is the assistant experience SAP puts in front of users. The dependency order matters more than the feature list. AI services read business data, and business data quality is a problem the other three strands have to fix first.
The returns portal that had no business in the ERP
A distributor I worked with for most of a year ran its returns process on three custom ABAP transactions and a spreadsheet the depot supervisors emailed round on Fridays. Trade customers had no way to raise a return without phoning the service desk, and the service desk rekeyed every one of those calls into the ERP by hand. Around ninety returns a week, each one handled twice by two different people.
The fix was a portal those customers could sign into themselves. It could not live inside the ERP, because the people using it were never going to hold an ERP licence. We built it on Cloud Foundry, kept the returns rules in the extension, and had it call the core through released APIs to check the original order and post the return once a depot approved it. The ERP kept the goods movement. The extension kept the conversation with the customer. Deciding where business logic should live was the whole design review.
What convinced their board had little to do with the portal itself. The business case rested on the three ABAP transactions we switched off, last changed in 2014 and already flagged for rework in their upgrade assessment. The portal paid for work they owed anyway. Without that second half, I doubt it would have survived the first budget review.
The test before you open a subaccount
Not every customisation earns a platform. S/4HANA has in-app extensibility for good reasons, and key user tooling covers custom fields, logic at defined extension points and custom CDS views without anyone leaving the system. If what you want is an extra field on the sales order and a rule about when it is mandatory, build it there. Standing up BTP for that adds an environment to secure and a release path to maintain in exchange for very little.
Three things move the answer. The users are not ERP users, so the work needs its own front end and its own identity handling. The logic has to reach systems outside SAP, where small integration contracts start earning their keep. Or the logic has a release cycle of its own and cannot sit behind the ERP transport calendar. One of those landing clearly is enough to justify the separate platform, and the same reasoning drives the rebuild, extend or patch call on existing custom code.
Before your next BTP conversation, write down the one thing you actually want to build and which of the four strands it belongs to. Then ask who deploys it, who reads its logs, and who gets the call when it fails during month end close. If all three answers are the same overloaded person, you have found the real price of the platform before anyone signs for it.
