The move to S/4 HANA is a good opportunity to obtain the benefits of existing modifications with the developments to the SAP Business Technology Platform (SAP BTP), while also making future upgrades and release changes easier and faster to complete. In addition, the BTP offers entirely new possibilities that are not available with an on-premises system. However, companies need to plan strategically whether they want to use the platform and, if so, how.
Enjoy the advantages of the SAP Business Technology Platform
S/4HANA migration – SAP BTP developments streamline the entire system versus on-premises software
The goals companies want to achieve by migrating their SAP ERP systems to S/4HANA are many and varied:
- streamlining processes, in order to optimize innovation and responsiveness to change,
- improving optimization possibilities, as well as
- creating new, expandable integration scenarios with customers and suppliers
- and many more.
Often, converting to S/4HANA also aims to return a company’s own SAP landscape closer to the SAP standard, so that future upgrades and release changes can be completed more easily and quickly.
Some companies have the option of deconstructing their own developments and, perhaps, even their system modifications during the move. In fact, this seems to be a good opportunity to dispose of old, possibly obsolete and superfluous individual developments and modifications during such a major software leap. This is especially true for greenfield implementations, where the new S/4HANA system is set up on a metaphorical greenfield site, i.e. it is not just a technical upgrade (brownfield conversion) of the previous SAP ERP system to S/4HANA.
BTP developments over on-premises – returning to the standard
With SAP BTP, SAP offers a cloud platform that, in addition to many other functions, also provides numerous modules and services for development, extension and integration projects. This opens up new ways to pursue the ‘keep the core clean’ approach – in other words, to keep a company’s own SAP systems as close to the standard as possible. This is because developments SAP customers previously carried out within the SAP on-premises systems due to a lack of alternatives, can be implemented and executed using SAP BTP instead. In addition to rapid development via a range of services and best practices, this enables a loose connection between a company’s in-house extensions and the SAP standard. This supports the aforementioned goal of being able to carry out future upgrades and release changes more easily and quickly.
When is BTP suitable?
Being able 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 on developments within the BTP, however, fundamental considerations are necessary despite all the advantages. Not every company will rely entirely on S/4HANA Cloud (Public) and thus develop exclusively using the BTP. In addition, S/4HANA systems will also exist as an on-premises option in future. The following criteria are relevant in order to make an informed decision:
Higher entry costs for BTP are amortized quickly
The costs are divided into three areas: development costs, operating costs, and the cloud fee. Especially in the initial attempts, developments on the BTP will require more effort, as this is mostly uncharted territory for the developers. Here, creating a steep learning curve through appropriate training measures and a skilled team is key.
The internal operating costs of a BTP application may appear lower, since the platform is provided entirely as a service. Conversely, however, fees are incurred for the use of the services.
More streamlined infrastructure and more possibilities, even with older ERP systems
Specific applications that are used externally benefit from being mapped on the BTP. Here, the questions of secure access to the application, connection to on-premises systems and integrating data are answered by corresponding services. Companies need to make well-considered architectural decisions concerning applications that process a large amount of data from on-premises systems. There are various methods for replicating large amounts of data – even nearly in real-time – into the BTP. However, this has to be thought out well enough to actually achieve a loose connection and not to move the data into another silo.
Considering efficiency issues during integration
Ultimately, the entire process flow and the overall architecture must be taken into account. If a new application is expected to access the many functions (function modules, classes and methods, etc.) that already exist in the on-premises SAP system, this may speak more in favor of implementing it in the on-premises system than in the BTP. This also applies if the new function is only a small component of mass processing within the on-premises network. A constant ‘ping’ (function call) from the on-premises system to the BTP, repeated for many thousands of data records, is also unlikely to be a particularly efficient solution.
Steps to creating your own BTP
The considerations laid out above are sensible and necessary for making a carefully informed decision. However, for the following cases, they can also be kept in corresponding decision trees or strategy papers, allowing a specific routine to set in when deciding whether to develop on-premises or in the BTP in each individual case. If the scales are tipped in favor of the BTP, the first real development activities are preceded by considering the appropriate architecture within the BTP and the cloud structure or overall architecture.
In addition to the criteria that generally differentiate between development on the BTP and on-premises, companies must also find the architecture within the BTP that suits them. Three environments are available for this purpose:
- Cloud Foundry
- Kyma
- ABAP
This decision depends on the requirements to be implemented and the architects’ and developers’ existing skills.
SAP provides each customer that has opted to use BTP with a global account. This forms a bracket around what are known as ‘subaccounts’, as closed areas, for example, to separate projects or stages.
The subaccounts are the most important structural element within the SAP 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.
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 subaccount or distributed across several?
- Should applications that use comparable architectures – CF, Kyma, ABAP – all run in one subaccount, in as few as possible or in separate ones?
- Are interfaces or APIs stored in a central account or in each individual subaccount?
- Is it necessary for organizational reasons (e.g. access protection) to separate certain applications and/or data from others via dedicated subaccounts?
The security model must then be defined in coordination with the subaccount model. User authentication and authorization are particularly relevant here.
When developing an application, it is important 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. This decision is very simple for a UI5 app that uses data from an on-premises SAP system. For a more complex application that may require a lot of data, the programming model requirements also increase.
For optimal training, managers should plan for additional training activities to master the technical innovations in the cloud platform. In-depth knowledge of OData, SAPUI5, Fiori Elements, ABAP CDS and a good general understanding of the ABAP RESTful Application Programming Model are essential for creating fullstack developments (using the RAP model).
Similar to applications within the corporate network that are located behind the corporate firewall, applications in the SAP BTP must also be secured using authentication and authorization processes. Of course, mistakes risk greater damage within the cloud. Securing all applications throughout the lifecycle must therefore take on a central role by ensuring that all stakeholders adhere to 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 operations. New infrastructure can be set up in the cloud at the touch of a button, while a new subaccount can be set up within minutes and is ready to run. The cloud provider also takes care of the technical stability of hardware and the basic cloud services (‘top operating system’) – in the case of SAP BTP, this means the respective infrastructure operator such as Microsoft, Amazon, Google or others mentioned above – as well as SAP itself, of course. On the other hand, some habits that have become a matter of course are also becoming obsolete, such as the possibility of being able to determine the release cycles of all software stacks freely, even below the application layer.
Migrating to S/4HANA – summary
SAP provides many tools for developers to make everyday life easier and to accelerate the development process. Thanks to the organizational and IT openness of the SAP BTP applications and the extensive integration tools available in SAP BTP, scenarios can now be implemented much more easily and quickly. This means that suppliers, customers and other partners can be (more) closely networked with the company’s own data and processes, so that genuine end-to-end processes are available.
Interested in developments on the SAP Business Technology Platform?
Learn more about our wide range of SAP Services now and feel free to contact us. We look forward to hearing from you!