Is SAP Business Technology Platform Ready for Developing Industry Cloud SaaS Applications?

* Updated section “Tenant-aware Services for Resource Sharing” on 25 June 2022 to remove the reference to Identity Authentication Service as this is no longer applicable.

* Updated section “Frictionless Onboarding of Customer Subscriptions” on 25 June 2022 to correct the understanding of the SAP Help documentation BTP API region limitations.

* Updated section “A Viable Commercial Model” on 20 April 2022.

Introduction

SAP Business Technology Platform (BTP) is at the core of SAP’s Intelligent Enterprise strategy, with SAP encouraging partners to develop public cloud SaaS solutions for Industry Cloud on BTP, to solve business problems that are not addressed by SAP’s core product offerings.  While SAP Industry Cloud has the potential to create significant opportunities for SAP partners and customers, the question I’d like to pose is whether in fact SAP BTP is mature enough to support this?

Architecture of BTP SaaS Applications

Industry Cloud solutions should address common business problems for one or more industries.  It therefore makes sense to build these as multi-tenant applications based on the recommended Producer/Consumer approach as documented in Developing Multitenant Applications in the Cloud Foundry Environment.  The benefits of this approach are:

• Customers subscribe to these applications via consumer subaccounts in the partner’s global account for their SaaS products.  This means that customers do not need to purchase and manage their own BTP environment.  Instead they execute all functions of the solution via the SaaS application UI.

• Resources (such as HANA Cloud) for example are provisioned only in the provider subaccount and shared across multiple tenants, making the solution more cost effective, instead of provisioning individual single-tenant resources.

• It is easier to integrate the solutions deployed on BTP with SAP on-premise and cloud applications using features such as Cloud Connector and System Registration.

I have come across very few SAP partners who have successfully implemented a SaaS product based on the producer/consumer architecture and would be interested to know your experiences and lessons learned in this area.

Requirements for Effective SaaS Application Development on BTP

To provide some context for discussion, in my view, for SAP BTP to effectively support SaaS product development, the key requirements are:

• frictionless onboarding of customer subscriptions
• tenant-aware services for resource sharing
• a viable commercial model

Let me elaborate on these requirements and the associated BTP limitations I have observed as follows:

Frictionless Onboarding of Customer Subscriptions

Ideally frictionless onboarding means that a customer should be able to go to the product website for information, select and sign up for a subscription plan, which then triggers the automatic provisioning of the customer’s account / tenant so that the SaaS product is ready-to-use. In other words, a turnkey solution.  There should be no need for the customer to have visibility or access to the BTP Consumer subaccount.  To enable a consistent user experience, any customer-specific consumer subaccount configuration should be facilitated either through the automated provisioning previously mentioned, or through an admin section in the UI of the the SaaS application itself, both facilitated by seamless integration through the Core Services for SAP BTP API.  However, I have come across the following examples of BTP API limitations:

• After conducting a proof-of-concept, I can now confirm Dinu Pavithran’s helpful clarification in the comments below that the region dependency for the SAP BTP Accounts API mentioned in the SAP Help documentation only relates to the region of execution of the API but does not limit the region in which a subaccount can be created via the API.  Therefore, the following previously stated interpretation of limitations is no longer applicable: The BTP Accounts API is only available in the Central Region (Frankfurt), which means that if the Consumer subaccount needs to be created in any region other than Central Region (Frankfurt), the only option is for the SAP partner to manually create the customer’s Consumer subaccount in the partner’s SaaS Global Account via the BTP Cockpit, which results in provisioning delays and a poor onboarding experience.

• If the SaaS solution is an extension for a cloud product such as S/4HANA Cloud for example , an integration token must be generated to Register the System, as shown in the video Extend S/4HANA Cloud: 02. Register Systems.  There doesn’t appear to be an SAP BTP API to allow the integration token to be generated and returned automatically. Ideally, we would want to create a Register System function in the Admin UI of the SaaS application itself so that the customer can generate the integration token themselves to then complete the S/4HANA Cloud registration in their system. In the absence of a BTP API, the SAP partner must manually generate the integration token in the BTP Cockpit and then communicate this to the customer.  Again, not an ideal user experience.

• The post Multitenant Authentication of UAA Admin APIs by Brian McDonnell illustrates another API problem for the scenario of automating the setup of default role collections and the Identity Provider.  Again, a limitation that requires manual provisioning resulting in a poor onboarding experience.

Tenant-aware Services for Resource Sharing

Ideally, in a multi-tenant application resources should be shared across tenants rather than being individually provisioned for each tenant/consumer subaccount, in order to make the solution more cost effective.  In a BTP context such resources are referred to as “reuse services” but the availability of such services is limited and not well documented, as described in the post Understanding Dependencies in SaaS Provisioning.

A Viable Commercial Model

Anecdotally, and by observation, the SAP BTP Services are not competitively priced compared to other cloud platforms.  Some examples of services which could be more cost effective are Custom Domains, Identity Authentication Service (IAS), HANA Cloud and Integration Suite.  Another good example is described in this post about Operating a multi-tenant solution on BTP CF – 1 GB Runtime = 10 Routes, which highlights the limits and cost implications of the Cloud Foundry runtime.

Furthermore, the existing revenue share based commercial model for SAP partners developing solutions on BTP is not ideal for multi-tenant SaaS applications from both an administrative overhead and financial viability perspective.  It would be helpful if the option of customised commercial models  could be offered, including:

• Subscription
• Flat Fee
• Consumption-based (PAYG)
• OEM

SAP has significantly lowered the barrier to entry for partners wishing to start developing solutions on BTP by offering for the most part cost effective non-commerical licensing for test, demo and development with the PAYG agreement.  You can even take advantage of non-commercial licensing by becoming a member of the SAP PartnerEdge Build Open Ecosystem program until you are ready to take up full partnership for going to market with your product.  This makes it very easy for start-ups and boutique consultancies to adopt BTP for building SaaS solutions.

Unfortunately, it is not so easy when the time comes to commercialise your BTP solution.  Apart from the Partner Edge Build revenue share based commercial model mentioned above, SAP offers an OEM agreement based on the CPEA (Cloud Platform Enterprise Agreement) model.  While in principle this is a very good option because it allows a partner to decouple their commercial relationship with SAP from the partner’s commercial relationship with their own customers, thereby addressing the need for frictionless onboarding described above, the OEM agreement is not as flexible as it could be to encourage widespread adoption.  It requires a partner to commit to a minimum value of CPEA Cloud Credits for a term of 3 years.  The problem with this approach is that when launching a new product, it is not necessarily known in advance what the market uptake will be and hence what the minimum required BTP resources should be for the launch.  The minimum OEM CPEA Cloud Credit commitment is relatively high in this context, meaning that initially, until the product uptake ramps up, the full Cloud Credits could go unused in any given year, and in this situation such Cloud Credits cannot be rolled over to the following year because of a “use it or lose it” policy.  And you are locked in for three years.

What would be a more effective approach to make it easier for partners to commercialise their BTP SaaS applications would be to also offer partners commercial PAYG licensing for BTP with the option to transition to CPEA, in the same way as is currently offered to SAP customers.  This would allow a partner to start small and then scale up with customer uptake.

In contrast, if we consider the major hyperscalers like AWS, Google and Microsoft, it seems to be so much easier to start small and scale up.

Conclusion

The above limitations create onboarding friction and impact adoption, which in turn discourages the use of SAP BTP as a SaaS development platform for SAP extensions and solutions.  SAP BTP has a lot of potential and if it is to become the platform of choice for building SAP’s Industry Cloud, I hope SAP Product Management and their commercial team will seriously take into consideration the points raised in this post, particularly relating to the gaps in the SAP BTP APIs and Partner commercial model.

What do you think?  For those of you have gone down the path of developing multi-tenant SaaS applications on BTP, I look forward to your comments about the points raised above and how you have overcome the issues identified.