SAP Cloud Platform: The Good And The Ugly

Building a cloud solution is very expensive due to the inherent complexity. However, once it is available, the cost of adding a new customer is low. This has multiple obvious consequences:

1. The initial investment in becoming a cloud company is very high.
2. The margin correlates directly with the number of customers.
3. The chosen cloud architecture has a huge impact on the initial investment cost and the per-customer costs. It is like a seesaw – if one is high, the other is low.

The other point to keep in mind when looking at the history of SAP Cloud Platform is the year in which respective managers were responsible for it and the competitive situation at that time.

IaaS: Cloud at server level

Seven years ago, there was no cloud. You could rent a server, install your software, and that was about it. In such an environment, the idea to rent out SAP servers makes total sense. SAP expands existing IT centers, buys servers, installs SAP software and leases them to customers. SAP knows how to host SAP software better than anybody else, after all. Customers benefit financially as well. Instead of every customer having a private SAP team operating their systems, a single SAP cloud team manages all customer systems, which saves costs. This approach is the Neo environment in SAP Cloud Platform.

Outsourcing deals were very popular in the 2000s but fell short from a financial point of view. The customers had to pay more in the end, were less flexible, and the outsourcing company did not make enough profit. If every customer would have been a clone of the same system, then this method would have worked through scaling effects. However, as each customer had their own individual customizing, the cost savings were nowhere near the desired range.

Most of the huge SAP cloud investments went to infrastructure. As said before, for a high margin, a huge number of customers is necessary. However, customers sign up only if the price is attractive enough. This is simple arithmetic, valid for all cloud vendors, with one exception: A cloud provider limiting themselves to just the SAP market doesn’t have the slightest chance of competing with other providers.

SAP spent all that money for nothing. At least we learned something:

1. We can never compete with the hardware costs of hyperscalers (Amazon AWS, Microsoft Azure, Google GCP,…).
2. We need to build software in a cloud-native way to keep a lid on the costs. Installing the software once per customer is way too expensive.

PaaS: Cloud at service level

Fast forward to the year 2016. How about the following idea: All the hyperscalers have their own services and ways to administrate them. SAP adds a layer on top and thus everybody who builds software based on these APIs and services can run their applications everywhere. SAP provides generic interfaces to the cloud. Brilliant!

Cloud Foundry was chosen as the runtime for cloud-native programming. It allows users to write software, package it, and deploy the code in a cloud-native way. One limitation is the maximum program size, but cloud-native means microservice-orientated architectures, anyway. Next, we must define a list of services:

• Most important is an authentication and authorization service. All other services will derive the permissions of the connected user from this service.
• Then database-like services: SAP Hana is an obvious choice but also too expensive to be used for everything. An open source database as alternative and MongoDB as NoSQL database should be available as well.
• For real-time event exchange, RabbitMQ might be a good idea.
• Runtimes for the most important programming languages: Node, Java, Abap.
• A routing service to connect each microservice with the other required programs and services in a secure way.
• Fiori UI programming services.

This is the SCP Cloud Foundry environment, and its first downsides can be seen immediately. While some services will be used by all customers, most of the services exist just-in-case. If a required service is missing, customers cannot add it themselves. Hence this platform has the natural tendency to grow by services which translates into massive costs to keep all up and running.

Surprise, surprise, one year ago the add-on services in SCP got discontinued. They didn’t have enough users to warrant the high inherent costs.

In summary, the Cloud Foundry environment of SCP is too rigid, too inflexible. Meanwhile, hyperscalers provide Kubernetes as container operating and administration environment.

What is left of the idea of SAP providing the generic interfaces to all hyperscaler clouds?

• A generic API across all vendors: Done, the hyperscalers provide it themselves via Kubernetes. No need for SCP.
• Cloud-native software development: Done, containers were invented for the hyperscalers and have all the advantages and none of the downsides of Cloud Foundry.
• Microservices: With containers, all kinds of services can be provided, from a tiny microservice to a huge Hana database. No limitations to just microservices.
• Routing service: With containers that are part of the infrastructure, normal network rules are used. No app router with its overhead is needed.
• Customer-specific services: Sure, the customer can deploy this service as a container themselves, in case it is not yet provided by the cloud provider or one of their partners.

From this point of view, the entire Could Foundry investment of SAP was for nothing. But at least we learned something: Containers rule.

Kubernetes: Cloud at container level

The logical continuation is to add a Kubernetes environment to SCP.

Actually no, it is not. Why would a customer favor SCP’s Kubernetes over hyperscalers’ Kubernetes? There are a few minor points, but none are compelling. While using Kubernetes is the right thing to do for customers, I fail to see an advantage to using SAP’s Kubernetes.

SAP partners and customers are doing the smart thing:

• One company, Linke IT, makes all AWS services accessible via Abap, e.g. a few lines of Abap code and the file is read from the AWS S3 storage.
• My customers place the raw data in the Microsoft Azure Data Lake storage at virtually no costs and are using Hana Smart Data Integration to load the interesting data into SAP BW.
• A few SAP partners have solutions to build Fiori UIs via graphical editors.
• SAP providing infrastructure-services make sense as well, primarily SAP Hana Cloud and SAP Data Warehouse Cloud.

What is the revenue potential of that? SAP’s plan was to rule the cloud world, and now I’m suggesting that providing a few add-on services is a financially equal solution?

Revenue potential for SCP services

To explain what I mean, I would like to look at the Hana Data Warehouse Cloud product and compare it to another vendor: Snowflake Inc.

This company has a market capitalization of 70bn USD. In comparison, at a stock price of 130 euros, the market cap of SAP is 160bn euros. Technically speaking, Snowflake is a poor man’s SAP Data Warehouse. It lacks 80 percent of the features Hana DWH Cloud provides, but it does have three properties SAP is missing:

• Pay per use: Customers are billed for consumed storage and compute time, not for service availability.
• Low price: The overall price is about 1/10^th of SAP’s.
• Entire market: Snowflake is a solution for everybody, not artificially limited to SAP customers.

While this is no direct answer to the revenue opportunity, it is an indication of how much potential the market sees in that single service offering alone. Would SAP have had the chance to do the same? Easily! There were enough suggestions on how to make that happen. Would it have worked? Nobody can tell.

Going beyond SCP

Most other recent initiatives, primarily the heavily promoted Business Application Studio, are solutions with low customer adoption rates. Even if it would do everything it promises perfectly, why would a customer use the Cloud Application Programming Model (CAP-M) when the same can be done with containers? Granted, customers who started with Neo and migrated all their code to Cloud Foundry might migrate again to the CAP-Model until SAP suggests using the new Kubernetes runtime for everything. However, this approach is neither a huge business opportunity nor the source of customer excitement.

Question: Which of the SAP products SAP Hana Cloud, SAP DWH Cloud, SAP Cloud Analytics, Successfactors, Hybris, etc. are built with SCP at their core?

As a customer, I would like SCP to provide key services and help customers build containers for hyperscaler clouds. Would this qualify as a defeat? Probably. Would it allow SAP to finally increase its margin and customer satisfaction? Yes! No more investor press conferences with the repeated message of “We need to invest in cloud in order to bring up the margin in the future.”

Quite frankly, the real value of the cloud business is not SAP Cloud Platform, it is the various SAP cloud applications like S/4 Cloud, Successfactors, etc. SAP is busy enough fending off the attacks of Salesforce, Workday, and others coming from the large enterprise side and Odoo-like companies taking the SME market.

SAP’s plan for SCP – to provide a beautiful development environment, get partners on board, provide an app store, and then take the world by storm – has one single point of failure: There are easier and cheaper ways provided by hyperscalers.