Business Technology Platform

In addition, the Business Technology Platform, BTP, offers new possibilities that do not exist in the on-premises system. However, companies must plan strategically whether and how they want to use the platform. The goals that companies want to achieve with a migration of ERP systems to S/4 are manifold: streamlined processes, the chance for more innovation and increased responsiveness to change, better optimization opportunities, as well as new, expanded integration scenarios with customers and suppliers, and many more. Often, the conversion to S/4 is also intended to bring the company's own SAP landscape closer to the SAP standard again, so that future upgrades and release changes can be completed more easily and quickly. 

Some companies have the option of scaling back their own developments and perhaps even system modifications. In fact, it seems to be a good opportunity to get rid of old, possibly obsolete and no longer needed individual developments and modifications during such a major software leap. This is particularly true for greenfield implementations, where the new S/4 Hana system is metaphorically started on a greenfield site, i.e., not merely a technical upgrade (brownfield conversion) of the previous ERP system to S/4.

Other companies, however, require many in-house developments and modifications, even after the switch to S/4. Moving these to the new system is an obvious thought. But that would leave everything as it was and the SAP standard a long way off. For them, BTP can be a solution.

With BTP, which was known as SCP, SAP Cloud Platform, until the fall of 2020, SAP offers a cloud platform that provides numerous building blocks and services for development, enhancement and integration projects, in addition to many other functions. This opens up new ways of pursuing the "Keep the Core clean" approach - in other words, keeping SAP's own systems as close to the standard as possible. This is because developments that were previously impossible due to a lack of alternatives within the SAP
On-premises systems, existing customers can instead implement and run in the BTP.

In addition to rapid development through many services and best practices, this enables a loose coupling between the company's own enhancements and the SAP standard. This supports the aforementioned goal of being able to perform future upgrades and release changes more easily and quickly. But when does it actually make sense to use BTP and how should companies proceed with implementation?

The ability to implement extensions on the BTP, to use business services offered via the BTP, or to integrate partners or systems via the BTP opens up a wide range of possibilities: If the focus is placed on developments in the BTP, however, fundamental considerations are necessary despite all the advantages. After all, not every company will rely entirely on S/4 Hana Cloud (Public) and thus develop exclusively via the BTP. In addition, S/4 systems will continue to exist as on-prem in the future. To make a qualified decision, the following criteria are relevant: Costs, infrastructure and integration.

Entry costs at BTP

The costs are divided into three areas: Development costs, operating costs, cloud fee. Particularly in the first attempts, development on the BTP will initially tend to cause more effort, since the developers are mostly moving into uncharted territory. Here, it is crucial to create a steep learning curve through appropriate training measures and a skillful composition of the team. Future developments will benefit from this and all developers will appreciate the accelerators known from SAP. 

The internal operating costs of a BTP application may be regarded as lower because the platform is provided entirely as a service. In return, however, fees are incurred for the use of the services. An estimator tool can predict these very well. Then it is still a matter of finding a clever mix of subscription, pay-as-you-go and CPEA (Cloud Platform Enterprise Agreement) to optimize costs.

This is offset by the costs saved on future upgrades of the on-prem system. Any individual development that does not exist there can then also not cause any expenses. Other cost advantages, for example in the case of end-to-end processes with integrated external partners, can also arise depending on the use case.

Leaner infrastructure

Especially applications that are used externally benefit from being mapped on the BTP. Here, the questions of secure access to the application, the connection to on-premises systems and the connection of data are already answered by appropriate services. For applications that process a large amount of data from on-premises systems, companies must make clever architectural decisions. There are various ways and means to replicate large amounts of data - even near-realtime - into the BTP. But this has to be well thought out in order to actually achieve loose coupling and not spend the data in yet another silo.

The available services can enable some use cases and significantly accelerate others. For example, the possibilities to use AI models for predictions are only possible in on-premises systems with a current version of S/4. Via BTP, these can also be used for older ERP systems. Another example is the development of a chat bot, for which the BTP brings a corresponding service to be developed.

Integration efficiency

Finally, the entire process flow and the overall architecture must be considered. If a new application should sensibly access many functions (function modules, classes and methods, etc.) available in the on-premises SAP system, this may speak more in favor of an implementation in the on-premises system than in the BTP. Similarly, if the new function is only a small module in a mass processing in the on-prem system. A constant "ping" (function call) from the on-prem system to the BTP, repeated for many thousands of records, is also unlikely to be a particularly performant solution. All of these considerations make sense and are necessary for a well-considered decision. The evaluation can also be kept in corresponding decision trees or strategy papers for the next cases, so that a certain routine sets in when deciding whether to develop on-prem or in the BTP in a particular case. If the scales tip in favor of the BTP, the first real development activities are preceded by considerations of the right architecture within the BTP and the cloud structure or overall architecture.

Cloud Foundry, Kyma, Abap 

In addition to the criteria that generally distinguish between development on the BTP and on-premises, companies also need to find the architecture within the BTP that is right for them. Three environments are available for this purpose: Cloud Foundry, Kyma and Abap. This decision depends on the requirements to be implemented and the existing skills of the architects and developers. Cloud Foundry, for example, can be used to deploy Fiori apps internally and externally in a very lightweight way in a short time. The Abap environment in the BTP is relatively heavyweight and, among other things, forces a dedicated Hana DB in the cloud. In return, it offers the possibility to work in the well-known SAP programming language and to implement a very tight integration to on-prem functions. Containerized applications can be developed and deployed in the Kyma environment. Common to all environments is the good integration into the SAP landscape.

SAP provides each customer who has opted for BTP with a global account. This forms a bracket around the so-called subaccounts, as closed areas for separating projects or stages, for example. The subaccounts are the most important structural element within the BTP, as they contain parameters that are defined once when they are created. A global account can contain one or more subaccounts, for each of which it is individually defined in which geographical region, for example North America, Western Europe or others, and with which infrastructure provider the subaccount is physically implemented.

Currently these are: AWS, Microsoft Azure, Google Cloud Platform, Alibaba Cloud and SAP Cloud Infrastructure. Although SAP leaves the choice of hyperscalers to the customer, the contractual relationship is exclusively with SAP. In addition, companies must specify whether they want to use the subaccount for developments in the Cloud Foundry standard, for Kyma-based containerized microservice architectures or for Abap developments.

It is advisable to design a subaccount model right at the start of using the BTP to enable synergy effects and to be able to reuse services and data. Of course, a proper, transparent and traceable structure is also absolutely necessary for growing platforms. It is important to check which similar applications can share a subaccount (per stage) if necessary and how strict the separation should be. Individual applications cannot or cannot easily "see" and use the resources such as services or data of another subaccount. The following questions therefore play a central role in selecting the appropriate subaccount model:

Is a staged development environment - Dev, Cons, Prod - necessary in the BTP? Should data in the BTP be stored centrally in one or distributed in several subaccounts?

Should applications that use comparable architectures - CF, Kyma, Abap - all run in one subaccount, in as few as possible, or in separate subaccounts? Are interfaces or APIs kept in a central or in each individual subaccount? 

Is it necessary for organizational reasons (for example, access protection) to separate certain applications and/or data from others via dedicated subaccounts?

Security

The security model must then be defined in coordination with the subaccount model. The aspects of user authentication and authorization are particularly relevant here.

When developing an application, it is then necessary to consider which layers (user interface, business logic, persistence) are affected or implemented on the BTP. The more layers a company maps on the BTP, the more important the choice of programming model becomes. For a UI5 app that uses data from an on-prem SAP system, this decision is very simple. For a more complex app that may require a lot of data, the programming model requirements also increase. For the choice of programming language and tools, there are the three approaches mentioned earlier: Cloud Foundry, Kyma and Abap.

While Cloud Foundry and Kyma environments allow diverse programming languages, such as Java, Node.js or Python, Abap environments in the BTP are naturally designed for Abap code development. So making the right choice depends on several factors. Both technical possibilities of the individual platforms and the respective technical knowledge available in the organization - for example, of the developers - must be taken into account.

So while classic SAP developers in BTP are still most likely to find themselves in Abap environments, Cloud Foundry and Kyma now provide technical approaches that enable "non-SAP developers" to build applications in the SAP context.

In both cases, managers should plan for additional training activities to master the technical innovations in the cloud platform. Sound knowledge of OData, SAPUI5, Fiori Elements, Abap CDS and generally a good understanding of the Abap RESTful Application Programming Model are essential for creating fullstack developments (using the RAP model). 

In the case of Cloud Foundry developments, staff involved with BTP should learn OData, SAPUI5 and, if applicable, Fiori Elements for Fiori app development. For fullstack apps, SQLscript, Node.js, and of course the CAP model are also relevant. For many of today's developers, this should be a challenging, but definitely also interesting and future-oriented training path.

It is well known that the development and operation of cloud-based applications also place special demands on security, access protection and technical operation. The Busi-ness Technology Platform is no exception here. Similar to applications within the company's own network, which are located behind the corporate firewall, the applications in the BTP must also be secured by means of authentication and authorization mechanisms. If mistakes happen, the risk of damage in the cloud is of course infinitely greater. Securing all applications throughout the entire lifecycle must therefore play a central role by ensuring that all parties involved observe and internalize the concepts and guidelines.

The use of Platform as a Service as the basis for enterprise applications also opens up new perspectives for companies in terms of operation. New "infrastructure" can be set up in the cloud at the push of a button; a new subaccount can be set up within minutes and is ready to run. The cloud provider - in the case of BTP, the respective infrastructure operator such as Microsoft, Amazon, Google or others mentioned above - and of course SAP itself also take care of the technical stability of the "hardware" and the basic cloud services (upper edge of the operating system).

On the other hand, you also give up some habits that have become a matter of course, such as the ability to freely and self-determinedly define the release cycles of all software stacks, even "below" the application layer. In the BTP (as in presumably practically all other cloud environments), this is normally specified centrally by SAP and ensures a constantly up-to-date basis for the company's own applications.

Conclusion

In addition to the expected advantages in operation, faster development and the very good integration into the SAP world, the BTP as a development environment for In addition to the expected advantages in operation, faster development and the very good integration into the SAP world, the BTP as a development environment for the use of SAP SaaS applications is even partly the only possibility to make own enhancements. SAP provides developers with many tools, as we have come to expect from the company, to make everyday life easier and speed up the development process.

But even beyond the development of applications, BTP is the strategic platform for SAP users. One small example is a service for providing exchange rates even without S/4 already in the ERP system. But also other business services such as a central master data integration or the X-invoice are turnkey in the offer.

Last but not least, the Business Technology Platform opens up previously unavailable opportunities and possibilities for companies to establish completely new business processes. Thanks to the organizational and IT openness of the BTP applications and the extensive integration tools available in SAP BTP, scenarios can now be implemented much more easily and quickly. Suppliers, customers and other partners can thus be networked closely(er) with the company's own data and processes, resulting in true end-to-end processes. 

The constantly growing intelligent services (AI services) in the BTP, which companies can excellently link and combine with their own applications, help to create value from data. If implemented and used consistently, SAP BTP thus helps companies to get fit for current and future challenges and to adapt agilely to changes in the market situation.