Architectures in SAP BTP: From initial tests to global deployment

There are many ways to structure your apps and systems in SAP BTP. The challenge is to adapt this to the company structure, the division of plants or local sites and the on-premise IT landscape.

As described in the article on setting up the Global Account there are several ways to structure the architecture in the SAP Business Technology Platform:

• Global account: Top-level account through which billing and contracts are concluded.
• Subaccount: You can select different cloud providers and data centers for each subaccount. The connection to the on-premise system is also often set at this level.
• Space: Another level that is possible in CloudFoundry environments. This allows applications to be separated within a subaccount.
• Database: Even if this is not a means of structuring, the number of databases and their use is an important architectural decision due to the comparatively high costs.

In order to arrive at a sensible architecture, you should clarify several questions. These can rarely be answered in general terms and are different for every company. It is also to be expected that requirements will change over the next few years, which is why it is important to take this into account in all aspects: Scalability is one of the major advantages of the SAP Business Technology Platform. This not only means scaling hardware resources such as RAM or CPU, but also scaling solutions within the company.

The three most important questions for a first draft of the architecture in SAP BTP are as follows:

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

Development system in SAP BTP

There is at least one development system in almost every on-premise landscape. When setting up the architecture in SAP BTP, the question arises as to whether a separate subaccount or space is also required for development. Like most architecture decisions, there is no general answer to this question.

The three most frequently used scenarios are as follows:

1. No development system in SAP BTP
2. Own development space in shared subaccount with quality / testing space
3. Own development sub-account

Option 1: No development system in SAP BTP

Many companies do not yet develop their own applications, especially at the beginning of the changeover to SAP BTP. If this is the case, the development system can be omitted at the beginning without hesitation. It can be added at any time later on.

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.

In many cases, it is therefore no longer necessary to map the on-premise three-tier architecture after development. Instead, applications can be tested directly in the quality system.

Option 2: Shared subaccount

Each subaccount, especially due to the CloudFoundry environment within it, is associated with costs and effort. To reduce the number of sub-accounts required, it is technically possible to separate the development of quality tests with separate spaces within a sub-account.

In addition to the reduced costs, this has another advantage. In most cases, connections to on-premise SAP systems (destinations) are maintained at sub-account level. With this architecture, it would also be possible to connect a new development to the quality SAP on-premise system for a short time.

In many companies, the data situation in development systems is inadequate and new developments can only be tested correctly on the Q-system. With a shared sub-account, you can simplify this back and forth between development and testing on the Q-system.

Option 3: Separate sub-accounts for development and quality

Especially if many developments are carried out, external companies have access to them or many internal developers are involved, it makes sense to create a separate sub-account.

Although the costs and internal effort are increased, this is fully justified if development is regularly carried out by several people. The separation of sub-accounts between development and quality not only facilitates rights management, but also ensures complete separation from the on-premise quality system.

Flexus recommends starting with a sub-account for a quality system. If it turns out in the further course that you carry out your own developments, you can use a separate space in this sub-account for this. You should only switch to a separate sub-account when several people are developing for the BTP on a regular basis.

How many databases are needed?

Note: In this article and the graphics, SAP HANA Cloud is always mentioned as the database. It is also possible to use a different database, e.g. PostgreSQL. This can make a difference for technical implementations and also in terms of costs, but not for the strategic architecture.

As one of the most important and at the same time most expensive building blocks in SAP BTP, you should pay particular attention to the database. A wrong decision at this point can not only increase running costs, but also create a lock-in effect where it becomes difficult to transfer data from one database to another.

To come to a decision, you can consider the following three main variants. These can be specified in more detail in a further step:

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

Important: Even if you use a database in several sub-accounts or from many applications at the same time, the data in it is still securely separated from each other.

Option 1: Database in the same subaccount or space as the applications

All applications run in sub-accounts and, when using the CloudFoundry environment, also in a space within the sub-account. The obvious approach, which is often used at the start, is that the database is also created in this sub-account.

This means that no additional sub-account is required, which has to be paid for and managed. In addition, everything can be viewed within the administration interface: all applications and the associated database.

With this option, you can differentiate again whether there is one database for all Spaces in this subaccount or a separate one in each Space:

In particular, if a separate database has to be operated for each space, the costs are very high, which is why this option is not recommended, or only in very rare exceptional cases.

However, creating a database for several applications and spaces in the subaccount is a sensible architecture that offers several advantages:

• A data center and cloud provider is also selected for each sub-account. If the database is located directly in the same sub-account, it can be ensured that there are no large distances to the applications.
• If there is a lot of data or a large load on the database, it can be ensured that the performance for other plants or locations is not impaired if a large load arises due to an application. The database can therefore be separated by plant or location.
• The database is individually scalable per subaccount.
• Administrator authorizations can be distributed per subaccount, which means that the administrator of the database from one subaccount does not have access to those of another subaccount.
• Individual billing for the use of the database is simple if you use one database per cost center.

Option 2: Database in separate sub-account

With this architecture, a separate subaccount is created in which no applications run, only the database. This could be further simplified by not running the database in a separate subaccount, but only in a separate space. In most cases, however, a separate subaccount is recommended.

This is possible because the database can also be used by applications that run in other Spaces or subaccounts. How this can be set is described in the article on Sharing the database in other Spaces or subaccounts described.

Although this separation of database and applications results in additional setup work and minimally higher running costs at the start, it does offer opportunities for scaling. The biggest advantage is that there are hardly any restrictions on how and to which structure you want to scale. For this reason, this scenario is particularly suitable if there are plans to intensify the use of SAP BTP, but it is not clearly defined what this will look like.

For example, in future you could use one subaccount per plant, one subaccount per “application type”, one subaccount per external service provider or one subaccount per subgroup. These are just a few examples to show that there are many options for what the future structure and architecture of SAP BTP could look like.

No matter how you want to scale in the future, you can respond with this approach:

• No scaling necessary: Everything remains as it is.
• Some plants have their own sub-accounts, but only one runs a database-intensive application: the central database is used by all plants that have low database requirements. A second database is created for the one plant with high requirements.
• Some sub-accounts or individual applications require lower service level agreements or database resources for tests: you can use another database specifically for these, while the central database remains in place for all other applications.
• Many database-intensive applications run in all sub-accounts: Any number of additional database sub-accounts can be added. To start with, it may be sufficient to create a database sub-account for Europe and one for America, for example. For even greater workloads, you can use a separate database for each country or plant.

Option 3: No database

Not every application necessarily requires a database. For example, if you only use it for temporary optimizations or functions that do not need to persist their data, a database is not necessary.

Even Fiori launchpads or simple redirects do not require their own database in most cases.

Rollout plan for other plants, locations or departments

When it comes to the question of where which applications should run, the most important question is what the rollout plan will look like. Even if the exact plan has probably not yet been determined, it is important to consider what is possible and which options do not make sense right from the start.

There are several ways in which you can design the rollout, such as

• Rollout of an application from one location to several others
• Rollout of several applications in one test location and subsequent joint rollout of all applications to several locations
• Individual applications for different locations, which would not allow a standardized central rollout

“Location” can have different meanings in this scenario:

• Each plant can be a separate location.
• Each geographical region (e.g. Europe, EMEA or Germany) can be a separate location.
• Separate business units or subgroups can also represent “locations”. Although they are not physically separate, they are very different due to different processes, responsibilities or cost centers.

Depending on the scenario and what a “location” means, different architectures are available. The following graphic shows the three most important options, although you can of course mix and match them at any time:

Option 1: All applications in one space

This is the simplest option, which is often chosen at the beginning. However, it has the major disadvantage that only different applications can be started here. This means that, in case of doubt, an application can be used jointly by several locations.

Some applications also offer this, but one of the great advantages of the SAP Business Technology Platform is its scalability, which is lost as a result. The application may support the first two locations, but can no longer cope with the load of a third location. With this architecture, this scenario would pose a problem.

To solve this, you can use a separate Space for each location. This is option 2.

Option 2: One Space per location

With this option, one space is created per location, with all of them being in the same subaccount. The advantage over option 1 is scalability. The same application can run separately and completely separately from each other in several Spaces.

Another advantage is the connection to on-premise SAP systems: These are maintained at subaccount or Space level. This option can therefore ensure that an application from Space A can only access the on-premise system A and an application from Space B can only access the on-premise system B.

However, the entire administration is carried out centrally for all Spaces in this sub-account. This includes not only the creation of roles or the connection to on-premise systems, but also the allocation of available system resources.

Especially when this becomes more complex, applications have to be updated more frequently and there are regular changes that may also require knowledge from the site, this can become very time-consuming for the administrators. The following option 3 makes it easier to divide and separate these tasks.

Option 3: One sub-account per location

This extends option 2 with separate administration. Almost all settings can be defined and set at sub-account level. This would make it possible for the persons responsible for the location to maintain many or all of these settings directly.

This option is therefore always recommended if individual settings or frequent administration tasks need to be carried out for each location. Especially if these also require specific knowledge of the location, such as when the end of a shift is in order to restart the application.

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. But 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 recommendation

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

“Standard” means that we start with this architecture as a concept and go through the three important questions based on it:

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

Depending on the answers to these three questions, this standard is customizable:

• For example, you can delete the “Development” space if you are not carrying out any internal developments.
• For example, you can duplicate the “Development & Testing” subaccount for each location if necessary.
• For example, an additional database can be added for the “Development & Testing” sub-account if the IT guidelines stipulate a separate database from the production system.

Many of the recommendations or opinions mentioned in this article are subjective and generalized based on the practical experience we have gained. The possibilities of the SAP Business Technology Platform are constantly evolving, which is why it is important to regularly question the decisions made.

If we can help you get started with the SAP Business Technology Platform and provide advice from past projects, the Flexus Cloud & Technology team is ready to assist you. We have been developing applications for the SAP BTP for several years, which interact with on-premise SAP and external systems, process large amounts of data and are used worldwide. Through these developments and the implementation with our customers and partners, we have been able to develop many good ideas and best practices that can also help you.