A technology platform, better described as a dynamically interpreting runtime environment for services, is for many software producers a state-of-the-art instrument for flexibilising the possibilities of communicating with their application. What a wonderfully unwieldy phrase, which basically only means that the actual application is additionally supplied with data by a browser or another real-time interpreter and returns its responses via the same medium.

Often, the use of a technology platform is combined with a shift of the application to distributed systems via service-oriented architectures (SOA) or to the cloud. Standardised applications and services are thus quickly cloud-enabled and can be consumed by users. The influence on functionality by the user or even IT specialists is minimal. Questions from customers, which could often only be solved by individual adaptations of standard software, are offered for consumption as an app or service in such architectures by the swarm intelligence of the software manufacturer with the help of experiences and assumptions. The “works-as-designed” often used by developers for individual developments and their quickly correctable misunderstandings are thus entering the standard. If there is a misinterpretation of the experiences and assumptions, these are either tolerated, corrected with one of the next versions or made acceptable. Furthermore, the user must rely on the fact that the apps or services will be further developed in his or her sense – i.e. that the assumptions and experiences will also fit the business in the future.

In previous articles, I had repeatedly emphasised that SAP in particular has designed its applications to be very cross-sectoral and thus, despite the lack of a dynamic runtime environment, already comes very close to a technology platform in the past. Through the further development of SAP cloud technology and increasing independence from the client-server structure, this is becoming increasingly clear nowadays. According to the above derivation, will SAP be a technology platform in the future? That is a clear yes, because the application itself is still classically divided into customisable modules, but the interpretation to commodity services in the public cloud is oriented towards a standardised business process. This approach makes it easy for consumers to enter the SAP world and the approach of being “midmarket-compatible”, which has been pursued for decades, now seems to be within reach for new customer business. Through partnerships with other cloud services such as AWS or Azure, so-called microservices located there can also be shared and corresponding additional computing power can be accessed.

But what happens to the industry-specific or customised versions of SAP applications that have grown over decades? In the private cloud version, SAP will provide a configurable system with various migration paths. However, SAP will not be guided by industry-specific ideas here. The first model companies are being discontinued in Walldorf, others are so generic that customers will continue to need individual developments. Nor will it be possible to migrate all of the customer’s previous individual developments without problems. So on-premise versions, i.e. those that the customer runs himself outside a cloud infrastructure, must remain available for such customers. In the future, SAP partners will need to think ahead in terms of industry, process and technology and be able to serve a corresponding portfolio from on-premise to private and public cloud. This is a challenge that not every partner today will be able to meet.