Solution Partner Models for SAP BTP ABAP Environment

Disclaimer: information provided in this blog post serves as general overview only and does not replace legal agreements between SAP and its contractual parties. As this blog post is updated in an irregular fashion, it cannot serve as single point of truth. Please refer to your assigned SAP account/partner manager for most up-to-date information, especially regarding applicable licensing and pricing models.

Last update: May 2022

When SAP partners want to provide ABAP applications as ISVs to customers, they have different options for how this can be achieved. A well-known and established mechanism is the classical software shipment as on-premise ABAP add-on (often based on SAP NetWeaver or SAP S/4HANA). In this scenario, the partner software is packaged as add-on and then physically shipped to the customer where it is installed. Secondly, as part of the new upcoming “Embedded Steampunk” environment (official name: SAP S/4HANA Cloud, ABAP environment) partners will get an additional opportunity to ship software to customers, with the advantage that this environment will have clearly defined, upgrade-stable APIs to the core system as well as the underlying ABAP stack. Development approach and methodology will be similar to the first approach, but other deployment options apply. A generic comparison of the different extensibility options can be found here.

But the focus of this blog post will be on a different, third option: the development and operation of partner applications as scalable Software-as-a-Service (SaaS) on SAP Business Technology Platform (BTP) ABAP environment. It provides a fantastic opportunity to develop and monetize solutions in the cloud, based on a comprehensive SaaS model, paving the way for a transition from the classical ISV model towards a cloud service provider model. In this scenario, an ABAP partner application uses a side-by-side setup in the cloud and is centrally provided as service to one or multiple customers. It is an important use case which is already anticipated and used by many SAP partners in the market. As SAP’s clear goal is to provide partners with an enterprise-ready setup which caters for all requirements such as architecture, lifecycle management, support and operations including state-of-the-art tools, this causes certain aspects to be considered on the technical, but also the commercial side.

This blog post shall act as a navigator through the different options for the SaaS model partners can choose from. It describes the reference architecture from a technical perspective and shows available paths that lead to commercially feasible and attractive setups. The goal is to equip partners with relevant information they need to start their successful journey with SaaS solutions on SAP BTP ABAP environment.

1 – Assumptions and Boundary Conditions

Given that there are diverse ways and various combinations of how a successful SaaS setup on ABAP environment can be achieved, this blog post focuses on the recommended reference setup only. Furthermore, general development topics (e.g. specifics of ABAP cloud development) are not discussed, more information about these topics can be found in the links section below. Based on that, the following assumptions and boundary conditions should be considered:

Software Delivery Mechanisms

When SAP partners want to offer a SaaS solution on ABAP environment, they can choose between two different deployment models:

1. Deployment via gCTS (git-enabled Change and Transport System): lightweight approach, which is limited to the same BTP Global Account, deployment of solution on production system is done via standard transport mechanisms
2. Deployment via AAKaaS (Add-on Assembly Kit as a Service): approach with more tool support, deployment of solution on production system is done via add-on assembly infrastructure incl. advanced lifecycle management capabilities

Whereas the approach via gCTS is suitable for small use cases where a quick time-to-market is required, and which do not require “enterprise-ready” lifecycle management support (e.g. add-on infrastructure supporting tool-based versioning, patching, CI/CD etc.), SAP recommends partners to adopt the AAKaaS-based approach for their SaaS deployments. This ensures that the development and operation of a SaaS solution is supported by state-of-the-art tools that cater for a stable, resilient, and professional setup at enterprise scale. Due to this recommendation, this blog post focuses on the latter case and leaves out aspects of the gCTS-based approach.

Single tenant vs. multi-tenant mode

When a partner solution is offered productively as SaaS, it is possible to either choose a single-tenant or a multi-tenant mode. Multi-tenant means that a solution can be divided into different tenants, all sharing the same application code line, but accessing logically separate data. This mode is suitable for partners who want to onboard different customers to a single instance of their application to leverage the BTP resources as efficiently as possible. Single tenant means that there is only one tenant, used by only one customer. This mode is suitable for partners who want to achieve maximum resource allocation for their customers (in most cases big customers with lots of users and data, requesting their dedicated environment).

Although the two modes exist, it is not relevant from the commercial perspective if a partner uses single-tenant or multi-tenant mode. Therefore, all information listed in this blog post is applicable for both scenarios.

SAP customers vs. partners

The technical content described in this blog post is also relevant for SAP customers. This means that, technically, customers can deliver SaaS solutions on SAP BTP ABAP Environment in the same way as partners (e.g. to provide a SaaS solution internally). However, the commercial perspective differs, which is why the commercial information presented here is not relevant for SAP customers.

2 – Technical Reference Architecture

Before the commercial aspects are discussed, it is required to analyze the reference architecture of a SaaS solution operated on SAP BTP ABAP environment. The technical architecture has direct dependencies to the chosen commercial model (and vice versa). From BTP account perspective, there are two architectural options a partner can choose from: either placing necessary resources in separate Global Accounts for development and production or using only one Global Account for everything. The reason why there are two options is not a technical one, it lies in important commercial boundary conditions: in the case of partner licenses, currently development and production licenses must reside in separate Global Accounts! This means that if a partner wants to leverage development licenses and initially signs a contract, this generates a Global Account for development. As soon as a partner then signs the first contract for productive licenses, a second Global Account for production is generated. This generation of separate Global Accounts can be avoided if a partner covers all needed resources through production licenses (see chapter 3 for details).

We will take a closer look at both options, including their advantages and involved challenges, in this chapter.

Option 1: Separate Global Accounts for Development and Production

As mentioned before, if a partner wants to leverage special development licenses during the development and testing process, this will generate a separate Global Account for development. Productive licenses which are acquired for go-live of the solution, will then reside in a second production account.

The following figure illustrates a full typical setup for development, test, assembly, and production:

Figure 1: reference architecture and account structure for a typical partner SaaS solution (with separate Global Account for Development)

From a system landscape point of view, all systems which are involved in the development process (e.g. Development, Test, Assembly and optionally Correction) reside in the Development Global Account. This setup can either be achieved by operating all systems in one subaccount or also in separate subaccounts. As soon as the development and testing of a solution is finished, it is packaged as an add-on and shipped to the Production Global Account using the AAKaaS (Add-on-Assembly-Kit as a Service) infrastructure. In the target account, the partner then sets up individual subaccounts for the different customers, from which a subscription to the SaaS solution is triggered. This isolation with the help of subaccounts is needed for customer-specific configuration such as connectivity and identity management, especially in the case of a multi-tenant setup.

Advantages and Challenges

The approach with separate Global Accounts has advantages on the commercial side. Given that development licenses can be used for all development resources, this reduces initial costs. Especially for those partners who have smaller use cases and target markets, this approach lowers the commercial entry barrier. Challenges can occur on the technical side when a partner starts with this approach (e.g. to keep the commercial entry barrier low for development) but wants to migrate to the All-in-one account model later (to simplify the account setup for productive deployments) . As ABAP environment systems can not be moved between Global Accounts, this creates major migration efforts. Furthermore, different Global Accounts also mean redundant work in some areas (e.g. Identity Management), which is not the case if you use only one Global Account.

Option 2: All-in-one Global Account

As part of the second option, everything can be combined in one Global Account. This means that all resources needed for development, test, assembly, and production run in the same account. To leverage this option, it is necessary to cover all resources (e.g. the ABAP environment systems) via production licenses.

Following figure illustrates this “All-in-one” approach:

Figure 2: reference architecture and account structure for a typical partner SaaS solution (with only one Global Account)

The technical process does not differ from option 1 and all necessary steps for development, test, assembly and production are the same. The substantial difference is that in this case also the production system(s) and the subaccounts for the various customers are set up in the same Global Account as the development resources.

Advantages and Challenges

This option has the clear technical advantage that it is future proof in terms of an easier architectural setup. Partners can avoid future challenges in case they start with separate accounts and want to migrate to the “All-in-one” model later. Furthermore, the commercial setup is much easier as all resources can be covered through a single licensing model. The main challenge is that productive licenses often mean a higher commercial entry barrier. Please contact your SAP partner manager to discuss suitable options for this approach (further information can be found in chapter 3).

ⓘ Please note: In both scenarios, all Global Accounts and subaccounts are under the control of the partner. A scenario in which customers can subscribe from their own Global Account to a SaaS solution in the partner Global Account is currently not supported but considered as part of the product roadmap.

3 – Commercial Implications and System Setup

After having analyzed the general account architecture, the following part of the blog post will deal with the different system types, including concrete information about recommended system setup and commercial models. Before we start, it is important to differentiate between the three main licensing models partners can choose from:

SAP PartnerEdge Test, Demo and Development

As the name implies, this model covers licenses which are used for development, test, and demo purposes. Productive use is not allowed. In the case of ABAP environment, it usually covers
development, test, and assembly (and optionally correction) instances and can be used to demo a solution to potential customers (see details). This model is available as Pay-as-you-Go and Subscription (see comparison and FAQ).

SAP PartnerEdge Build, Platform Option

The engagement model SAP PartnerEdge Build serves as entry point for providing and commercializing partner applications. It can be regarded as the low-touch, standardized offering which provides access to Go-to-Market benefits (e.g. SAP Store) and opportunities to leverage a progression journey towards one of the high-touch engagement models (such as oOEM, more information can be found here). It is suitable for partners with smaller use cases and a limited target market. The licensing framework of SAP PartnerEdge Build provides different options for applications to be commercialized, in the case of ABAP environment the “Platform” flavor applies (further information about SAP PartnerEdge Build can be found here).

SAP Outbound OEM (oOEM)

The oOEM program is the high touch model for SAP partners with big use cases and target markets. It requires stronger business commitments by partners and offers better Terms & Conditions and support from SAP, compared to the standard SAP PartnerEdge Build model.

As this blog posts focuses more on the technical aspects, please approach your SAP partner manager or respective pages on the SAP PartnerEdge portal for detailed information about the commercial models.

As next step, following up on the discussed reference architecture, we will analyze the different system types which are required for a typical SaaS setup. From a technical perspective, not all the following systems may be required in all scenarios, optional systems are marked respectively. Furthermore, the recommended system sizes represent the usual setups of our partners. As complexity and adoption of the solution grows, bigger system sizes might be required. The following list can be regarded in the sequence of how systems are usually created as part of the application lifecycle.

Glossary:
ACU = ABAP Compute Unit (sized in blocks of 16 GB, representing Runtime)
CPEA = Cloud Platform Enterprise Agreement (payment based on pre-paid cloud credits)
HCU = HANA Compute Unit (sized in blocks of 15 GB, representing Persistence)
oOEM = Outbound OEM (negotiable engagement model for partners, for productive licenses)
PAYG = Pay-as-you-go (payment based on consumed resources)
PE Build = PartnerEdge Build (standard engagement model for partners, for productive licenses)
TDD = Test, Demo and Development (special price list for partners, no productive use allowed)

Development Systems

Please note: in the following, it is assumed that you choose the commercial model with separate Global Accounts. If you want to go for the “All-in-one” model, the licensing models for the productive system(s) apply to all system types.

1. Development System

Description: Used as initial system to start development of the solution. If you choose the PAYG model, this system can be acquired via Free Tier and later converted into a paid license.

2. Test System

Description: System for testing of the solution.

3. Assembly System (temporary)

Description: System used to package the solution as cloud add-on. This system is needed only temporarily during the assembly process.

Production Systems

1. Production System for Testing (optional)

Description: System used to test and configure productive setup with customers (e.g., test connectivity to customer system landscape). This system type is optional.

2. Production System

Description: System where the productive SaaS solution runs.

There can be cases where additional systems will be needed, e.g. if you want to develop a new add-on version based on a separate codeline. Details can be found here and should be technically discussed with the contacts mentioned below.

ⓘ Please note: From technical perspective, it is recommended to choose a consumption-based licensing model for both development and production environments. In many cases resources are only needed temporarily (e.g. to execute tests or assemble an add-on, test productive setup for a customer etc.), and in these cases a consumption-based model provides much more flexibility while saving costs. For development, this is represented by the PAYG model for TDD (including Free Tier option), for production by the CPEA model.

Further links:

Blog – Sizing options for ABAP Environment
Description of the different options for sizing of an ABAP environment system. If you want to get more information about service plans and their purpose in the context of the SaaS scenario, please refer to the section in the documentation.

Documentation – Getting Started in SAP BTP ABAP Environment
Description of technical aspects to consider if you want to start developing on ABAP environment. This part of the documentation is applicable to development in general, so not only focusing on partner-specifics.

Documentation – Developing and Operating SaaS Applications
Main entry point into the technical documentation of the SaaS model covering the whole application lifecycle including e.g. architectural setup, development, testing, assembly, delivery as well as  operations and support aspects.

SAP PartnerEdge Price List for TDD
Direct link to the partner price list for Test, Demo and Development purposes. A user on the SAP PartnerEdge Portal is needed to access this resource.

4 – Summary & Next steps

Hopefully, this overview has helped you as SAP partner to get some orientation regarding usual account and system setups and their implications on the licensing models. After an analysis of different technical and commercial options, there are concrete steps a partner can take to start the journey on SAP BTP ABAP environment. The following step-by-step guide represents a recommendation on where and how to start:

5 – Frequently Asked Questions

Is there a free option available?

Yes, ABAP Environment is part of the Free Tier offering. You need a Pay-as-you-go contract to make use of it. For SAP partners, the direct way is to sign up for a TDD PAYG contract (on TDD price list, see PAYG prices for the different services here).

Is there a certification offering for partner solutions on SAP BTP ABAP Environment?

Yes, there is an official certification process available. For more details, please contact the SAP Integration and Certification Center. Specific information for SAP Extension Suite certifications can be found here.

Whom can I contact in case I have further questions?

For more information on different topics from this blog post, the following SAP experts can be contacted:

Partner Status und Licensing Models
Please contact either the general SAP PartnerEdge Build helpline or your assigned SAP partner manager.

Pricing Details for SAP BTP ABAP Environment
Florian Wahl, Product Management SAP BTP ABAP Environment

Architecture, System Setup and Sizing
Frank Jentsch, Project Lead SAP BTP ABAP Environment

Stay healthy, curious and take care!