Architectures in SAP BTP: From First Steps to Global Deployment

SAP BTP offers many ways to structure apps and systems. The challenge lies in aligning this with your company structure, plant distribution, local sites, and on-premise IT landscapes.

As described in the article about setting up the global account, there are several ways to structure your architecture in SAP Business Technology Platform:

• Global account: Top-level account used for billing and contract management.
• Directory: Optional hierarchy level. Directories allow you to group subaccounts (see below) and can provide a better overview when you have many subaccounts.
• Subaccount: You can select different cloud providers and data centers for each subaccount. Connections to on-premise systems are typically configured at this level.
• Space: An additional level available in Cloud Foundry environments. Spaces allow you to separate applications within a subaccount.
• Database: Although not a structural element per se, the number of databases and their deployment are important architectural decisions due to their relatively high costs.

To arrive at a sensible architecture, you need to answer several questions. These rarely have universal answers and vary for each company. You should also expect requirements to change over time, which is why it is important to consider the ability of your architecture to scale. Scalability is one of the great advantages of SAP Business Technology Platform. The term not only refers to scaling hardware resources like RAM or CPU but also to scaling solutions throughout the company.

The three most important questions for an initial draft of the architecture in SAP BTP are:

1. Do I need a development system?
2. What are my data storage requirements?
3. What does my rollout plan look like for multiple plants, locations, or departments?

Development System in SAP BTP

Almost every on-premises landscape includes at least one development system. When building your BTP architecture, you need to decide whether you also need a dedicated subaccount or space for development. Like most architectural decisions, there is no one-size-fits-all answer.

The three most common scenarios are:

1. No development system in SAP BTP
2. A dedicated development space in a shared subaccount with a quality assurance / testing space
3. A dedicated development subaccount

Option 1: No Development System in SAP BTP

Many companies, especially when starting their transition to SAP BTP, are not yet developing custom applications. If this applies to you, you can safely omit the development system initially. You can always add it later.

Another factor that speaks against a development system is that all SAP customers have the “same” BTP and therefore also the same technical platform for testing. This means that most developments from third-party providers such as Flexus can be developed and tested on their own development system.

As a result, the on-premises three-tier architecture becomes unnecessary. Instead, applications can be tested directly in the quality assurance system.

Option 2: Shared Subaccount

Each subaccount, especially if it has a Cloud Foundry runtime, involves costs and overhead. To reduce the number of required subaccounts, you can technically separate development from quality assurance using separate spaces within a single subaccount.

Beyond reduced costs, this offers another advantage. Connections to on-premise SAP systems (destinations) are typically maintained at the subaccount level. With this architecture, you can temporarily connect a newly developed software version to the on-premise SAP quality assurance system.

In many companies, data quality in development systems is poor, and new developments can only be properly tested on the QA system. With a shared subaccount, this back-and-forth between development and testing on the QA system becomes simpler.

Option 3: Separate Subaccounts for Development and Quality Assurance

When you are conducting extensive development work, granting external companies access to your BTP system, or working with many internal developers, it makes sense to create a dedicated subaccount.

While costs and internal effort increase, this is completely justified when multiple people are developing software regularly. Separating subaccounts between development and quality assurance not only simplifies rights management but also ensures complete separation from the on-premises quality assurance system.

Flexus recommends starting with a single subaccount for a quality assurance system. If you do some custom coding, you can use a dedicated space within this subaccount as the development system. Switch to a dedicated subaccount only when multiple people are developing regularly for BTP.

How Many Databases Do You Need?

Note: This article and the graphics refer to SAP HANA Cloud as the database. You can also use other databases, such as PostgreSQL. This can impact technical implementations and costs but does not affect the strategic architecture.

As one of the most important and also most expensive components in SAP BTP, the database deserves special attention. A wrong decision here can not only increase ongoing costs but also create a lock-in effect, making it difficult to transfer data from one database to another.

To make this decision, consider these three main variants, which can be further refined in subsequent steps:

1. Database in the same subaccount or space as the applications
2. Database in a separate subaccount
3. No database

Important: Even when a database is used across multiple subaccounts or by many applications simultaneously, the data within it remains securely separated.

Option 1: Database in the Same Subaccount or Space as the Applications

All applications run in subaccounts, and when using the Cloud Foundry environment, additionally in a space within the subaccount. The obvious approach, often used initially, is to create the database in the same subaccount.

This eliminates the need for an additional subaccount that needs to be managed, and you can view all applications and the associated database together within the subaccount’s administration interface.

Within this option, you can further distinguish between having one database for all spaces in the subaccount or a separate database in each space:

When you operate a separate database for each space, costs become very high. This option is not recommended except in very rare cases.

Creating one database per subaccount and sharing it among multiple applications and spaces is a reasonable architecture that offers several advantages:

• Each subaccount also has a selected data center and cloud provider. When the database resides in the same subaccount, you can ensure no significant latency occurs due to the close physical distance to the applications.
• With large amounts of data or heavy database loads, you can ensure that performance for other plants or locations is not impaired when one application creates a heavy load. This allows you to separate databases by plants or locations.
• You can scale the database individually per subaccount.
• Administrator rights can be granted per subaccount, so the database administrator from one subaccount does not have access to another subaccount’s database.
• Individual billing for database usage is straightforward when you use one database per cost center.

Option 2: Database in a Separate Subaccount

With this architecture, a separate subaccount is created in which no applications run, only the database. You could simplify this further by running the database in a dedicated space rather than a separate subaccount. However, in most cases, a separate subaccount is recommended.

This setup works because applications running in other subaccounts can use the database. It requires all participating subaccounts to be located in the same region. Read the article about sharing databases across spaces or subaccounts to learn how to configure this.

While this separation of database and applications creates additional setup effort and slightly higher ongoing costs, it provides opportunities for scaling. The greatest advantage is that there are hardly any limitations on how and to what structure you scale. For this reason, this scenario is particularly suitable when you plan to intensify SAP BTP usage but have not clearly defined what that looks like yet.

For example, you might use a subaccount per plant in the future, a subaccount per “application type,” a subaccount per external service provider, or a subaccount per subsidiary. These are just a few examples showing the many options for what your future BTP structure and architecture could look like.

Regardless of how you scale in the future, this approach can adapt to it. Here are some example scaling scenarios:

• No scaling necessary: Everything stays as it is.
• Some plants have their own subaccounts, but only one runs a database-intensive application: the central database is used by all plants that have low database requirements. For the one plant with high requirements, you create a second database.
• Some subaccounts or individual applications suffice with lower service level agreements or database resources for testing: You can specifically use an additional database for these while maintaining the central one for all other applications.
• • All subaccounts run database-intensive applications: You can add as many additional database subaccounts as needed. Initially, it might suffice to create one database subaccount for Europe and one for America. With even greater utilization, you can use a separate database per country or plant.

Option 3: No Database

Not every application necessarily requires a database. If an application is only used for temporary optimizations or functions that do not need to persist data, no database is necessary.

For example, Fiori launchpads or simple redirects typically do not need a dedicated database.

Rollout Plan for Additional Plants, Locations, or Departments

When deciding where applications should run, the most important question is what your rollout plan will look like. Even if you have not determined the exact plan yet, you should consider early on what is possible and which options do not make sense.

There are several ways to design the rollout, such as:

• Rolling out an application from one location to multiple additional locations.
• Rolling out multiple applications in a test location and then jointly rolling out all applications to multiple locations.
• Individual applications for different locations, making a uniform central rollout impossible.

“Location” can have different meanings in this scenario:

• Each plant can be a separate location.
• Each geographic region (such as EMEA, Europe, or Germany) can be a separate location.
• Separate business units or subsidiaries can also represent “locations.” While not physically separated, they may be very different due to distinct processes, responsibilities, or cost centers.

Depending on your scenario and what “location” means, different architectures make sense. The following graphic shows the three most important options, which you can mix at any time.

Option 1: All Applications in One Space

This is the simplest option, often chosen initially. However, it has a major disadvantage: you cannot start the same application twice. This means an application may need to be shared by multiple locations.

Some applications support this by separating locations (or app users) through accounts. However, one of SAP Business Technology Platform’s great advantages is scalability, which is lost here. The application might be powerful enough for the first two locations but unable to handle a third location’s load. The one space architecture would struggle with this architecture.

To solve this, you can use a separate space per location. This is option 2.

Option 2: One Space per Location

This option creates one space per location, all within the same subaccount. The advantage over option 1 is scalability. The same application can run in multiple spaces, completely separated from each other.

Another advantage stems from the fact that connections to on-premises SAP systems can be maintained either at the subaccount or space level. This option therefore ensures that an application from space A can only access on-premises system A, and an application from space B can only access on-premises system B.

It should be noted that all administration occurs centrally for all spaces in this subaccount. This includes not only creating roles or connecting to on-premises systems but also assigning available system resources.

As your environment becomes more complex, applications need frequent updates. These often require location-specific knowledge, which can become very time-consuming for administrators. Option 3 allows these tasks to be better divided and separated.

Option 3: One Subaccount per Location

This extends option 2 with separate administration. You can define and configure almost all settings at the subaccount level. This makes it possible for many or all of these settings to be maintained directly by people responsible for the location.

This option is therefore always recommended if individual settings or frequent administration tasks need to be carried out for each location. This is especially true when these tasks require location-specific knowledge, such as the best time to restart an application to minimize operational disruption.

Another reason for this option would be separate on-premise SAP systems. If each location has its own productive SAP system, you should always choose this option. Even if you have a central SAP system, this option can offer many advantages, in particular location-specific flexibility and independence from other locations.

Summary and Recommendations

As mentioned at the beginning of the article and described in the three sections, architecture depends on many factors. For this reason, it is difficult to recommend a general architecture. However, practice has shown that the following architecture provides an excellent foundation, which Flexus recommends as standard:

“Standard” means we start with this architecture as a concept and then work through the three important questions:

• Do you need a development system?
• How many databases do you need?
• What does the rollout plan look like?

You can adapt this standard based on the answers to these three questions. Here are a few examples:

• You could remove the development space if you are not conducting internal development.
• You could duplicate the development and testing subaccount for each location if necessary.
• You could add an additional database for the development and testing subaccount if IT guidelines require a database separated from the production system.

Many recommendations and opinions mentioned in this article are subjective generalizations based on our practical experience with many customers. SAP Business Technology Platform’s capabilities are constantly evolving, which is why it is important to regularly question the decisions you have made.

If you need support in getting started with SAP Business Technology Platform, Flexus’s cloud and technology team is ready to help. We have been developing applications for SAP BTP for several years that interact with on-premise SAP and external systems, process large amounts of data, and are deployed worldwide. Through this software development and commissioning with our customers and partners, we have developed many valuable insights and best practices that can also help you.