Do I really need a Business Technology Platform by SAP?
Many SAP customers do already have experience with cloud computing, running their environments within providers like Amazon Webservice (AWS), Google Cloud Platform (GCP) or Azure Cloud by Microsoft.
Having this in mind, the question “Do I really need to spend time, money and resources on the Business Technology Platform by SAP?” is coming up really fast and the question must be asked as the digital transformation is killing budgets already.
What's the strategy of SAP with BTP?
As SAP customers have multiple onPremise systems up and running, they know the key drivers of SAP budgets. One of these key drivers is doing upgrades and updates. Patching systems is burning money and resources, but the only way to get newest features and bug-fixes from SAP.
SAP is trying to get rid of these circumstances and resource-blockers by fulfilling the strategy “keeping the core clean” (read more about the extensibility concept of SAP here). The BTP is acting as “central place for integration and extension” and therefore is a required piece of your new cloud architecture within your new SAP cloud landscape.
My environment is already in the Cloud - Do I need a BTP instance?
If you want to use synergy effect, services, features and tools, supplied by SAP, yes. You will need the “layer” or “framework” of the Business Technology Platform by SAP to be able to subscribe to services from SAP.
You could think about hosting applications (e.g. UI5 apps in a docker concept) directly without a BTP around on your AWS instance (e.g. “Application Runtime 3 + 4). But you will need to solve some issues to avoid dangerous reefs. Services, like the destination-service by SAP, are not available without a BTP. So you will need to simulate or build some custom solution around your app running on your own environment.
Using a hyperscaler to get a cloud-enviornment is something like Infrastrucutre-as-a-Service (IaaS). Some of them do also provide additional services (e.g. for event-based integrations), but using a BTP is moving the responsibility a little bit more to SAP and “only” getting a Platform-as-a-Service (PaaS).
I already have a middleware for integration purposes - So therefore I can skip a BTP contract?
It is common practice to use the existing middleware from your IT infrastructure to connect within your SAP systems. Moving your SAP systems to the cloud, you’re able to harvest synergy effects using tools and SaaS services (applications), coming with the toolchain of your Business Technology Platform.
This Platform-as-a-Service (PaaS) Solution by SAP is providing you a bunch of best-practice tools supplied by SAP and 3rd party providers.
On the example high-level landscape architecture slide you can see BTP between your business tenants and your (local) environment. Your existing middleware is used to distribute between BTP’s interfaces and your local systems (e.g. Master Data Management (MDM)). So the BTP is taking care of the right data to be selected and aggregated from one or multiple sources / business suite tenants.
This gives you a lot of other opportunities with existing services on the BTP. You could start a new workflow task to an users inbox, for example. Or show results of API calls within a custom made FIORI UI5 application – and many other things, like using Business Rules to fetch business logic, using AI aspects to search for the right component and more.
Using the BTP as central integration point, e.g. with Cloud Process Integration (CPI), to integrate your SAP Cloud Business Suite tenants within your own (existing) environment is best practice and recommended, as you
Besides the integration, what can I do with this BTP cloud either?
Beside the integration aspects BTP is providing you a lot of capabilities to extend your business suite tenants, e.g. S/4 HANA Cloud tenant.
Some examples of applications, you could host on BTP-Cloud Foundry:
Using this opportunity endusers can’t see a difference while navigate through a business suite tenant as the UI5 app will be integrated to the existing FIORI Launchpad (FLP).
High-Level: It’s the next generation of this fancy old WebDynpro Frontends (do not tell a techie someone said this)
CAP apps are some kind of full-stack applications. Using the full stack of your Business Technology Platform, you can use CAP apps to deploy HANA databases / tables, host your own oData service for this tables and inject this oData service with your own custom logic.
Within this framework, made and supported by SAP, you can build a full-stack-application on BTP.
High Level: As soon as you need to save your own data ‘somewhere not in your business suite tenants’, you will need a database and a framework who does support you with this journey.
Workflows and SAP – 2 things you can not separate as both is belonging together. As soon as you did check out the standard workflow capabilities of your business suite tenants, e.g. within S/4 HANA, you will notice that SAP is trying to keep it so easy and so standard as possible. This will not fit within your requests and processes – so you will start create your own workflow definitions on BTP.
This workflow definitions can be used to start workflow instances, as soon as something is happening.
Also you can build and realize your own use-cases. E.g. you can raise a new workflow instance 24 hours before a down payment invoice is going to be generated. So someone could ‘stop’ this process before it gets send to a customer.
High Level: With workflows you’re going to build your business-logic into processes, touchable and reviewable processes.
This service is the ideal place to save custom business logic on the BTP.
You can access your ‘custom data’ within REST APIs from everywhere – even from S/4 BAdIs.
High Level: This is the place to be for Z-Tables of the future.
Is it possible to connect a BTP on AWS with my existing AWS instance?
Yes, it is possible to do this.
In the entrance of this article we thought about other departments, who are already doing Proof of Concepts on AWS, Azure or Google Cloud – maybe there is already stuff running on some of these hyperscalers. Of course there are opportunities to connect these different instances.
One important point to highlight: Even if it is your BTP instance – SAP is controlling and maintaining the AWS / Azure / Google Cloud account. Following the PaaS principles, your responsibility is starting within the Platform, not the infrastructure around.
The idea behind connecting different hyperscaler tenants (here: AWS) with each other, is simple, efficient and the effort is high. You can route directly from A to B, without touching your (local) environment / network first. Cards on the table: The network strategy and architecture of many big companies is ridonkulous and flatulent on the same hand – so connecting peer-to-peer from instance A to B can scale down the latency (and complexity) a lot.
Check out AWS webpage, to get more details about it.