Skip to Content
Personal Insights
Author's profile photo Mustafa Bensan

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

* 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:

  • 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.  An important service missing from this list is the Identity Authentication Service.

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.

Assigned Tags

      22 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Erin Nardo
      Erin Nardo

      Thank you for the feedback and your motivation and desire to see improvements. We are listening and working diligently to make those improvements happen.

      Author's profile photo Murali Shanmugham
      Murali Shanmugham

      Thanks for sharing your experience on this topic. I will flag this to Product experts.

      Author's profile photo Barin DESAI
      Barin DESAI

      Hi Mustafa

       

      Good read.

       

      1. It is important for customer to have their own BTP and not to align to partners. this could backfire in case of heavy extension developments that needs to be retained.
      2. I assume you are refering to centralized IAS for BTP.
      3. Financials is not somethign that I can comment however Erin's comments are clear and that shall be taken care too soon.

      Thank you again for the insight. I hope partners and customers are reading your observations and its helping them decide their future.

      B

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Barin,

      Regarding Point 1, for SAP BTP Industry Cloud solutions, it only makes sense to build and deploy these as multitenant SaaS applications.  SAP's recommended architecture for such applications is to deploy these in the Partner's BTP account because of the needed Provider/Consumer subaccount structure.

      Extensions/applications that need to be deployed to a customer's BTP account would be bespoke solutions specific to that customer.  I would not regard such solutions to be categorised as Industry Cloud because this contradicts SAP's own definition that an Industry Cloud solution "must solve a specific business problem of one or more industries" rather than solving the problem of just one customer as is the case with a bespoke application.

      Regards,

      Mustafa.

      Author's profile photo Holger Schäfer
      Holger Schäfer

      Hi Mustafa,

      nice and very informative abstract about this topic and starting the discussion.

      Here are my 5 minutes of thought on this topic 😉

      We are driving the SAP BTP with an ISV contract and are also thinking about reusing some services via Producer/Consumer.

      In the past, we had multiple situations with issues inside the destination/connectivity service infrastructure, The issues where most times driven by SAP while doing sporadic live updates that break existing solutions and then rolling back their updates.

      For this reason, i am a little bit scared with additional dependencies at the moment. More important are fallback strategies, but the come with addtional costs. Also EU20 as fallback to EU10 is only offered on Azure, but we ObjectStore services implemented with AWSSDK which shows, that not all services are really multi cloud aware and a proxy switcher on top EU10/EU20 supporting custom domains etc. is also not available.

      We are thinking about using our Configuration Service (Schema Delivery, Schema Validation, UI5 Schema rendering) as the first service of this kind, that can be used by dependend SAs.This is nessessary, because ABAP is not able to validate a JSON schema, and this way, we can externalize it using a REST service and the service is able to reach the on-premise systems. Here we have a stable API that would work well for SaaS.

      But we will use this internally in our UDINA BTP Platform, to share the service accross SAs. We do not have the need for Cost/Usage tracking.

      If you need Usage tracking, the API Management is no more available standalone (like in NEO) and only sold as part of Integration Suite, starting with 4.000;- Euro/month.

      Looking at your requirements for effective SaaS dev, this will make it hard, to find a viable commercial model for it, or you develop your own usage monitoring (I know some solutions, that gone this way to skip API Mgmt Costs).

      Concerning the current status quo, i think this is a nice option for SAP offering SaaS solutions to customers, but for partners, you maybe will struggle with the underlying commercial model, because you are also in competition with other solutions running in the multi cloud universe which are maybe available with lower TCO.

       

      Best Regards
      Holger

       

       

       

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Holger,

      Thanks for chiming in with your valuable feedback.  I'm glad to see that the pain points have resonated with you and completely understand the others you have listed.  The merging of API Management into Integration Suite from the prior standalone version does indeed have a significant impact on commercial viability, among other issues.

      Given both the commercial viability and technical gaps in BTP, it will be interesting to see how much Industry Cloud solution development SAP Partners will undertake with the new model.

      Hopefully SAP Next-Generation Partnering listens to the constructive feedback from partners and adapts the partner offerings to encourage adoption and support mutual success.

      Regards,

      Mustafa.

      Author's profile photo Sunil Gupta
      Sunil Gupta

      Hi Mustafa,

      You have rightly brought the issues of using SAP BTP for SaaS application development and provisioning. We have been battling with these issues for quite some time on SAP BTP -ABAP. We are a partner and have been the early adopter of SAP BTP and developed product using steampunk for a dedicated customer. We wanted to take this to SaaS roadmap thro OEM route but apparently facing various challenges. The following points are still not clear :-

      1. Commercialization model
      2. No-clarity and no adequate tools are available for onboarding new customer subscriptions
      3. Consumer tenant-aware services like IAS, backup, application monitoring
      4. Add-on packaging
      5. Packaging of node.js and ABAP applications
      6. Services and linking of object store
      7. Roles based authorization and cataloging
      8. Integration of tenant cloud connector instance of on-prem ECC or S/4HANA
      9. Job scheduling for various independent tenants

      In effect, we are not able to deploy the Add-on package using multi-tenant SaaS application

      I also wish that next-generation partnering listens to us constructively and support on the above issues.

      Regards

      Sunil Gupta

       

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Sunil,

      Thanks for sharing your experiences in detail.  Apart from the technical gaps in SAP BTP you have pointed out, I agree that there is a lack of clarity, alignment and viability for commercialisation through the OEM and new PartnerEdge Build contracts when it comes to developing SaaS applications.

      It will be interesting to watch the adoption of SAP BTP by partners wishing to develop Industry Cloud SaaS solutions.  Like you, I hope that continuous feedback such as the above from SAP Partners  will be taken as an opportunity by SAP Next-Gen Partnering to refine the commercialisation model in a way that maintains the relevance and increases the attractiveness of SAP BTP as the platform of choice for SAP Industry Cloud compared to other PaaS platforms provided by the hyperscalers.

      Regards,

      Mustafa.

      Author's profile photo Kevin Hu
      Kevin Hu

      Taking advantage of this post/topic, do we have some example SaaS applications delivered on BTP?

      I believe there are a few already in my mind, like WorkZone, Cloud ALM.. maybe more.

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Kevin,

      Technically all new SAP SaaS applications are supposed to be delivered on SAP BTP, including the ones you have mentioned.  What would be more informative for this discussion is to get an idea of which partner-built SaaS applications have been deployed on BTP using the Multitenant Architecture.  This metric is more relevant for understanding the progress of SAP Industry Cloud.

      Regards,

      Mustafa.

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Kevin,

      the apps you've listed are provided by SAP. Unfortunately SAP does not give their partners the same possibilities like subscription in existing subaccounts.

      Begards
      Gregor

      Author's profile photo Kevin Hu
      Kevin Hu

      Gregor, for "subscription in existing subaccounts". Does it actually matter? For SaaS application subscription, should it just be as easy as filling a form with my email and password and credit card, then get an email confirmation with the application url to login? End users may not be interested with BTP or SAP itself at all. My 2 cents. I am just imagining the process that I have no knowledge of IT and I want to use SaaS application like Asana.com and pay monthly. Understand in SAP customers SAP customers usually are tech-savvy and have abundunt IT resources in house and the understand BTP or subaccount concept quite well.

      To this point "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". To reach larger audience, it might be ok for partners to invest upfront in each key regions for end users to be provisioned later on. I think the onboarding process can be quite seamless to the end user as I mentioned above, while behind the scence for partners it can be semi-auto, considering there might be some post-provisioning manual activities such as the "integration token for registering the system" mentioned in the blog. It can be fully-auto in the future if the feature is provided by SAP. Btw, the APIs are always available to be consumed with a service user in the old way of integration.

      I think technically it might just be some of the limitation of the multitenant architecture of cloud foundry. In Kyma I believe it is the same. Maybe SAP can share some knowledge on how it deploys for example Work Zone for subscription across multiple regions.

      Assuming if there is no more technical barriers, then comes down to the commercial model. Has SAP work it out yet?

      I remember around decade ago when SAP started the "SAP Store" where partners can put on applications to "sell". It turns out to be more like a marketing website afterwards as no application will be actually plug and play, like the ones on the Apple Store.

      Hope to see more "unboxing" blogs like this. Nice one and great discussion.

      Author's profile photo Sunil Gupta
      Sunil Gupta

      Completely agree with you.

      We are working on SAP BTP SaaS application using ABAP Stack. Hopefully , we will share the experience once it becomes productive !

      Author's profile photo Eik Sunke
      Eik Sunke

      Hi all,

      it is great to see movement in this area. As partner, BTP multi tenancy applications seem to be a good way to sell SaaS application to the clients that already have SAP systems.

      Most of the limitations have already been mentioned above.

      What bothers me in addition is the fact, that I can only subscribe within my global account.

      Let us assume we have the following scenario:

      We, as a SAP partner, developed an CAP based extension app (for SAP S/4HANA onPrem) and want to sell it as SaaS to a client that already has his own global account. He invested in processes around the BTP and might also have the cloud connector in place for data exchange. Now, he will most likely not be willing to connect his cloud connector to my global account (even if it is possible). It would be much easier if he creates a subaccount in his global account and subscribes to our application. That way he has control about the data integration, the user authentication and several other things.

      For me the use case that someone wants to use my application, who has nothing to do with the BTP by himself is not the common. Personally I would not choose SAP BTP as my SaaS platform for clients who have nothing to do with SAP. There are other more convenient platforms out there.

      For me, the unique selling point is the integration into the clients hybrid SAP landscape and the already established trust with SAP BTP.

      Hopefully this also gets resolved in the future.

      Cheers,

      Eik

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Eik,

      as this topic was not yet an influencing request I've filed one: Allow subscription to multitenant apps from subaccounts not part of the provider global account. Please also vote for Support for Multitenany in the Fiori Launchpad.

      Can't agree more with the higher effort that is caused by this missing functionality. Especially as this is available in BTP Neo: Providing Multitenant Applications to Consumers in the Neo Environment.

      CU
      Gregor

      Author's profile photo Eik Sunke
      Eik Sunke

      Hi Gregor,

      thanks for submitting the request. Just voted for it.

      I already voted for the Launchpad topic in October last year. Let us cross our fingers that these things will be available in the future. Whenever that might be.

      Eik

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Gregor,

      I think the new blog post Consumability Across Global BTP Accounts Via Custom Service Brokers is intended to address the scenario of subscribing to "multitenant apps not part of the provider account".  However, I think the service broker approach has significant limitations which make it impractical for multitentant applications.  I've posted my feedback and would be interested in your perspective too.

      Regards,

      Mustafa.

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Mustafa,

      thank you for the heads up. I share your doubts.

      CU
      Gregor

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Eik,

      This is great discussion.  Thanks for contributing.  Please see my further comments in response to yours below.

      We, as a SAP partner, developed an CAP based extension app (for SAP S/4HANA onPrem) and want to sell it as SaaS to a client that already has his own global account. He invested in processes around the BTP and might also have the cloud connector in place for data exchange. Now, he will most likely not be willing to connect his cloud connector to my global account (even if it is possible). It would be much easier if he creates a subaccount in his global account and subscribes to our application. That way he has control about the data integration, the user authentication and several other things.

      You make a valid point about the convenience of using the Cloud Connector that is already configured in the customer's global account.  Nevertheless, I think that for a truly seamless end-to-end SaaS onboarding experience, a customer should not have to be exposed to the PaaS which underlies the SaaS application, whether it be the partner's BTP account or the customer's.  For a coherent user experience, all configuration should be implementable via the SaaS application UI.  Furthermore, if the a customer could subscribe to a SaaS application from their own subaccount, how would the commercials and billing work, especially when there are multiple plans to choose from like "Starter", "Pro" and "Enterprise" for example.  In a typical SaaS onboarding flow, the customer first signs up on the website by choosing a plan and completing the billing preference details such as credit card, invoice etc and recurrence such as monthly or annual.  The completion of this initial step then triggers the provisioning of the customer's tenant.  How would all this be done when subscribing from the customer's own BTP subaccount?

       

      Regards,

      Mustafa.

       

      Author's profile photo Eik Sunke
      Eik Sunke

      Hi Mustafa,

      from my perspective it should work the exact same way. The only difference is that I need to provide the details about my subaccount where the application should be running during the onboarding. It should be a choice if the customer wants the application in his own subaccount or not.

      Eik

      Author's profile photo Brian McDonnell
      Brian McDonnell

      Mustafa,

      Thank you so much for putting together this post. I see you've found a couple of pain points that I helped identify so I'm glad you could include them into this more complete collection.

      In regards to IAS integration, there is another aspect to this that I'm not sure has been captured yet and that relates to the availability of an API to interact with IAS Applications.

      Our multi-tenant application has been live since the summer of 2019 and the pattern we settled into for IAS was to create one IAS application for each SAP BTP subaccount. This works well because it allows us to isolate the configuration on the BTP side within the individual subaccount and on the IAS side within the application.

      The issue with this approach though is that there is no API to maintain applications within IAS like there is for other objects in IAS like groups and users. This means that there is always a manual step required when setting up new tenants as somebody needs to go into IAS and manually create the IAS application. Beyond the creation itself, each application shares some common configuration such as branding, onboarding emails, etc. which means a lack of API means a higher risk of inconsistency in common elements across tenants.

      The good news is that SAP has plans to address this shortcoming in a new API. The details of this are captured in a Customer Influence Improvement Request (login required): SAP IAS - Publish API to Maintain Applications . I'm not hopeful that this will be available anytime soon though, as the original improvement request was submitted in January 2021 and only confirmed in March of this year with the next update to be provided in Q3 2022.

      It's possible that SAP has introduced newer, more streamlined ways of handling this since our original go-live in 2019 but it hasn't been very clear how we'd move to this newer authentication model between SAP BTP and IAS or if it'd confer any benefits. Improved automation would certainly be a reason for us to look into it though.

      Thanks,

      Brian

      Author's profile photo Mustafa Bensan
      Mustafa Bensan
      Blog Post Author

      Hi Brian,

      Thank you for keeping the conversation going.  Your feedback is very timely as I have been investigating the most appropriate approach for integrating IAS with a multi-tenant application, considering whether to integrate with the Producer Subaccount or Consumer Subaccount.  For the reasons you have mentioned I had landed on the Consumer Subaccount approach but not yet tested it, so it's great to have the benefit of your validation of this pattern.

      It's disappointing to learn that there is no API to maintain applications within IAS.  I have voted for your SAP IAS - Publish API to Maintain Applications improvement request, although I am concerned at the low priority SAP has assigned with status "Planned (Long-term)".  Your statement "Being able to automate the process improves reliability of a successful onboarding and consistency across different tenants." is perfectly aligned with the philosophy of "Frictionless Onboarding of Customer Subscriptions" I have described in my post above.

      I have a some questions if I may?

      1)  Do you get any customers asking to integrate their own IAS tenant with your multi-tenant application instead of the included IAS tenant?  If so, why?

      2)  How do you handle the scenario where a customer asks to integrate their own corporate identity provider such as Azure Active Directory?

      3)  How do you manage and factor in IAS usage costs for your customers given that the BTP pricing metric is Number of Logons?  This has the potential to become quite costly.

      4)  With respect to your comment "It's possible that SAP has introduced newer, more streamlined ways of handling this since our original go-live in 2019 but it hasn't been very clear how we'd move to this newer authentication model between SAP BTP and IAS or if it'd confer any benefits.", if you haven't already done so, it may be worth looking into the Identity Provider Management and Security Settings APIs of the SAP Authorization and Trust Management Service API Package as detailed in the Access Administration Using APIs of the SAP Authorization and Trust Management Service help documentation.

      5)  Is your application listed on the SAP Store?

       

      Regards,

      Mustafa.