3

Establishing a Foundation for SAP Business Technology Platform

In previous chapters, you should have understood what SAP Business Technology Platform (SAP BTP) is and how SAP positions it in the Intelligent Enterprise ecosystem. You therefore shouldn’t be surprised to see that this first practical chapter is dedicated to explaining the foundational elements of SAP BTP.

We know that you are eager to have a peek at what SAP BTP is, and we are at the point where things will slowly get practical. We say slowly because we need to establish the terminology and define the essential elements of SAP BTP first.

Don’t forget that this book’s audience is architects; therefore, we will not go into the nitty-gritty of every element—we would like to stay at a level of covering things that architects need to know to be able to design solutions and architectures.

Here, we also consider technical architects whose role may extend to creating a governance model for SAP BTP. But if you are a platform administrator, for example, don’t expect to find all the details you need to operate SAP BTP in this book.

In this chapter, we’re going to cover the following main topics:

• Environments and regions
• Commercial models
• Account model
• Services
• Account administration

Technical requirements

As with many other cloud vendors, SAP provides trial options that make it possible to get your hands dirty at no expense. Currently, you have two options, as outlined here:

• Navigate to https://developers.sap.com/tutorials/hcp-create-trial-account.html, where you can find detailed instructions on how to create a trial account.
• Go to SAP Store at https://store.sap.com to subscribe to Pay-As-You-Go for SAP BTP by placing an order for free. After that, you can try SAP BTP services that offer free tier service plans.

Environments and regions

In the SAP BTP context, environment is an overloaded term. So, when we say it, we may mean two similar but different things. Let’s define the first one: at its foundation, SAP BTP provides frameworks, technologies, execution models, and tools for customers to develop and deploy applications that we refer to altogether as a runtime environment or, shortly, an environment.

SAP BTP has had an extensive evolution since it was first released. In this journey, SAP introduced different environments to provide platform services as well as runtimes for applications. As a result, there are four runtime environments in SAP BTP, as outlined here:

• Neo environment: This was the first and only environment when SAP BTP, then known as SAP Cloud Platform (SCP), was released originally. The technology underpinning this environment is SAP-proprietary and enables customers to develop and deploy HTML5, Java, and SAP HANA XS (JavaScript) applications. In addition, the Neo environment provides many platform services that fulfill an enterprise’s cloud requirements—for example, integration, data, mobile, identity, connectivity, and so on.
• Cloud Foundry (CF) environment: SAP introduced this environment after embracing the open source CF technology. The CF environment makes it possible to develop applications in multiple programming languages and deploy them in supported runtimes, including Java and Node.js. In addition, SAP started to provide platform services on top of this environment while continuing to support the Neo environment. Today, the CF environment is at the center of the multi-environment foundation, where all innovations and new services are released. We will talk about multi-environment soon.
• ABAP environment: This environment is provisioned from within the CF environment and lets customers develop applications using the Advanced Business Application Programming (ABAP) language. If you have been working in the SAP ecosystem for a long time, you may think this is the good old ABAP, which is valid only to an extent, as this environment supports only the cloud release of ABAP, also known as ABAP Steampunk. As you may already know, SAP’s newest enterprise resource planning (ERP) solution—that is, SAP S/4HANA—and some of their other products—for example, SAP Marketing Cloud, SAP Integrated Business Planning, and so on—are built on top of the ABAP platform (not necessarily ABAP Steampunk). Therefore, it may make sense to create extension applications for these products in the ABAP environment.
• Kyma environment: The newest to the game is the Kyma environment, a fully managed Kubernetes runtime enabling the creation of applications using serverless functions or microservices. If this is the first time you have heard of Kubernetes, you’re missing a lot. We therefore highly recommend you learn about it and get yourself familiar with the concepts of containerization and microservices. We wouldn’t be exaggerating when we say Kubernetes is becoming the operating system of the cloud. Kyma, being on top of Kubernetes, provides extensions to streamline the way applications are created and connected by easing some of the hardships of working with Kubernetes.

After releasing SAP BTP initially with the Neo environment, SAP changed its strategy from mainly two perspectives, as detailed here:

• Firstly, SAP embraced open source technologies—first, CF, and more recently, Kubernetes—for heavy lifting at the foundation level.
• Secondly, SAP decided to run SAP BTP on hyperscalers rather than its own data centers while giving customers the flexibility to choose a hyperscaler that best fit their requirements. With this shift in its strategy, SAP could focus more on providing differentiating platform services.

By the way, is this the first time you’ve heard the word hyperscaler? With this term, we mean the cloud vendors that provide the infrastructure as a service (IaaS) on which SAP BTP runs—for example, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Alibaba, and so on; so, IaaS providers.

Now, we come to the second thing we may refer to when we say an environment, but before that, let’s give a short definition of a term we will start using. A subaccount is an account-model element in which you use services and deploy your applications.

Historically, when there were only Neo and CF runtime environments, a subaccount was tightly coupled with one of them. Therefore, subaccounts were categorized with strict reference to the runtime environments—for example, a Neo subaccount or a CF subaccount.

With the strategy change, runtime environments became subordinate elements of the new types of subaccounts. Thus, a subaccount, whichever way it’s managed under the hood, does not have a strict dependency on a runtime environment anymore. A subaccount can now exist with no runtime environment, or it can have one or many of the strategic runtime environments. This changed the basis for categorization because the new subaccounts could not be referred to with a specific runtime environment. So, a new twofold categorization emerged: the Neo environment and the multi-environment. SAP also refers to the multi-environment as the multi-cloud foundation and sometimes the multi-cloud environment.

The following screenshot shows the different SAP BTP environments available:

Figure 3.1: SAP BTP environments

Now that we know about environments, let’s have a very brief introduction to services and then tackle the question of how to choose an environment.

Services

It is better to define another concept at this point to gain a common understanding before we start using it very frequently going forward. So, what is a service in the SAP BTP context? When we use this term, we mostly use it at a generic level. A service is a managed capability provided through the platform to be used as a building block in our solutions—for example, it can facilitate building, deploying, and running applications, creating integration artifacts, storing data, managing workflows, and so on. We will only provide a definition here as we will discuss services extensively in a later section of this chapter.

Which environment?

At this point, you should have already understood that we can consider the Neo environment to be no longer strategic. This shift of focus is not a secret as SAP releases all strategic innovations in the multi-cloud environment. In addition, SAP actively encourages its customers to transition to the strategic multi-environment.

If you are one of the first customers onboarded on SAP BTP, you may already have applications deployed and services enabled in the Neo environment. Don’t worry; SAP continues supporting the Neo environment and will probably do so for a bit longer to protect the investments of its customers.

Important Note

If you have applications and services in the Neo environment, it’s time to consider in your strategy how you will be migrating to the strategic multi-environment. You can get help from SAP on this. For more information, visit https://help.sap.com/viewer/b017fc4f944e4eb5b31501b3d1b6a1f0/Cloud/en-US/aae4e0ae1cdf434b908c3c8cf3ea942a.html.

Suppose you have a presence in the Neo environment and started a migration to the multi-environment. In that case, you will eventually face the challenging question of which environment to use. At this stage, the choice is between the Neo environment and the multi-environment. However, especially if you will be deploying applications on SAP BTP, you will come to a point where you need to select in which specific runtime environment you want to build your applications. We will discuss this in a later chapter.

The suggestions here depend on where you are with your transition and many other factors you need to consider with your strategy; however, we have some points that may help.

We would recommend using the Neo environment only in the following cases:

• If you are looking to onboard a service and if the service is only available in Neo—in this case, check the SAP roadmap to see whether they will soon release an alternative service in the multi-cloud environment. If that is the case, you need to decide whether you can delay your project until the new service is available. If your project cannot wait or if SAP doesn’t have plans to release an alternative in the multi-cloud environment, the only option is to use the service available in the Neo environment.
• If you have heavily invested in the Neo environment and the following apply:
  • What you are looking to implement (an application or a service) is an integral part of an existing ecosystem in Neo.
  • Implementing the new requirement in the multi-cloud environment will introduce an unnecessary cost without a whole migration exercise.

It would be best to consider onboarding services or deploying applications in the multi-environment in all other cases. That said, migrating a single integration artifact or building a simple new application in the new environment without a plan for a complete migration may incur unnecessary costs. So, once you start the migration, it’s also best to complete it as soon as possible to eliminate the administration overhead and reduce the overall cost, and bear in mind that the cost element depends on the commercial model with which you purchased SAP BTP. For example, you may need to align your migration completion date with the subscription contract expiration date to avoid sacrificing the remaining committed investment and eliminate the risk of an unnecessary contract extension.

Now that we know our environment options, let’s discuss where we can run them.

Important Note

In this book, we will focus on the multi-environment as it’s the strategic direction. This is in line with our suggestion for migrating away from Neo, and this way, we can reduce the complexity of the topics we discuss.

Regions

Now that you know the different environment types in SAP BTP, we need to touch upon the concept of regions. If you are already familiar with cloud architectures, this wouldn’t be a new topic, and a region is the same concept as you would see in other cloud contexts.

As should be clear by now, SAP provisions SAP BTP on top of cloud infrastructure. Yet, as a consumer of SAP BTP, you don’t need to know the specifics about the infrastructure except when you are assessing the platform to make sure it fulfills specific requirements and when a service is provisioned directly with infrastructure-level configuration. At the lowest level, the platform is still running on machines in a data center, and for SAP BTP, this can be an SAP data center or one of the hyperscalers. So, the region corresponds to the geographical location of the data center where the infrastructure is running.

SAP BTP is provisioned with a multi-cloud strategy where customers have the flexibility of using it on a hyperscaler of their choice. In addition, customers can also choose to have SAP BTP on multiple hyperscalers—for example, for business continuity (BC) use cases or in line with their own multi-cloud strategy.

So, when specifying SAP BTP regions, we use two elements: a hyperscaler and the data center locality—for example, AWS Frankfurt, Microsoft Azure Netherlands, GCP US Central, and so on. Here, in the context of SAP BTP, your contract is with SAP, and you do not directly deal with hyperscalers.

You may wonder how to find in which regions SAP BTP is available; we will keep this a secret until later in this chapter. Okay—if you are so eager to know, make a detour to the SAP Discovery Center section and then come back to learn more about regions.

Which region?

Now that we know there are multiple regions to choose from, it’s time to discuss the factors you need to consider when selecting a region. You need to think about the following:

• Service availability: A service may be available only in some regions—for example, because SAP has newly released the service and is gradually making it available in regions.
• Proximity: Although the internet is much faster compared to the past, where you run SAP BTP (hence, how close it is to your information technology (IT) estate it communicates with and to your end users) is still a significant factor for performance. It would be best to run SAP BTP as close as possible to reduce network latency and response time.
• Private Link Service availability: We will discuss Private Link Service in a later chapter; however, at this stage, you can think of it as a private connection between SAP BTP and services in hyperscalers. If your IT estate has tight integration between SAP BTP and these services, this may be a factor when deciding on regions.
• Legal requirements: You may need to run SAP BTP only in certain geographies due to specific regulations that countries or industry regulators set. The regulations may necessitate you keeping the data, at rest and in transit, within the boundaries of a single country or multiple countries, such as in the European Union (EU) case. China is a good example here. Due to regulations, if you are operating in China, you most probably need to run SAP BTP in a China region—for example, Alibaba China.
• Existing usage: If you are already running SAP BTP in a region with several applications deployed and services enabled, you can choose to continue using the same region, although a different region may make sense when considering the other factors mentioned previously—for example, this may happen when SAP makes SAP BTP available in a new region. You can plan for migration if the benefits outweigh the cost of it.

Ideally, you may think you should choose a single region where you can have all your applications and services. However, after considering the aforementioned factors, you may end up with multiple regions, willingly or unwillingly. On the other hand, there are cases where having SAP BTP in multiple regions may make sense, such as in the following scenarios:

• You may need a higher level of BC for the application you deploy in SAP BTP. In that case, you may choose to deploy your application in multiple regions, which we will discuss in Chapter 5, Non-Functional Design for Operability.
• As a company, you may have your own multi-cloud strategy, which means you have a presence on multiple hyperscalers. For example, a large enterprise may choose to have the services for one of its business units (BUs) provisioned in Microsoft Azure and services for another BU in AWS or GCP. In line with this model, you can choose to have SAP BTP in multiple regions, coupling each to the same region of the hyperscaler of choice, as mentioned previously.

We have now laid the first tile in our SAP BTP foundation, and next, we will discuss our options for purchasing SAP BTP.

Commercial models

SAP provides two main commercial models for enterprises to purchase SAP BTP, as outlined here:

• Subscription-based model: In this model, customers subscribe to one or multiple services. At the time of purchase, you negotiate with SAP to use a fixed set of services during a fixed term for a fixed price. When the term expires, you can extend your subscription.
• Consumption-based model: In this model, you do not need to fix the set of services you will be using, and you have two options, as follows:
  • If you establish a Cloud Platform Enterprise Agreement (CPEA) with SAP, you make an annual commitment to using SAP BTP over a fixed term with no restriction on which services you can use. SAP gives you a number of cloud credits you can consume by using SAP BTP services. During the agreement term, you can flexibly adjust what you are using by enabling, disabling, or ramping up/down the service utilization as long as you do not deplete your cloud credits. If you spend all your cloud credits, you will be charged with the list prices; you can also choose to top up.
  • If you are not ready to invest a committed amount, you can use the Pay-As-You-Go option. Here, you have all the flexibility with zero-commitment: no fixed set of services, no upfront spend commitment, and no fixed term.

Which commercial model?

After SAP introduced CPEA, many customers went for it due to its flexibility, but if you purchased SAP BTP a long time ago, you might be on a subscription contract. SAP continues providing both subscription- and consumption-based commercial models to give customers options for the sake of flexibility.

SAP handles each commercial model differently, and you cannot combine them under the same agreement. However, there are transition paths from the subscription and pay-as-you-go models to the CPEA model because CPEA represents a well-established engagement with SAP.

Let’s see a comparison chart for the commercial models to highlight what each offers in terms of critical commercial elements. You can view this here:

Table 3.1: Comparison of SAP BTP commercial models

If your use of SAP solutions is not extensive—for example, you use cherrypicked solutions from SAP—it may make sense to use the subscription model. One way of buying SAP BTP subscriptions is through SAP Store. In SAP Store, you can browse SAP BTP services available for the subscription model. You can then make a purchase after you specify a configuration that consists of the quantity—for example, number of users, duration, and start date. If the product you want to purchase has prerequisites, SAP Store will provide you with a warning and let you know what they are. You can see an example of this in the following screenshot:

Figure 3.2: Making a purchase in SAP Store

As you can see in the preceding screenshot, if you want to subscribe to SAP Workflow Management, an SAP BTP service, you need to purchase a minimum quantity of 100 users for a minimum duration of 3 months. In addition, you are also required to subscribe to SAP BTP Portal and SAP Business Application Studio services, and they will have their own purchase configurations.

On the other hand, if you have extensive usage of several SAP products, you possibly have contracts with SAP, and you can get into another one for purchasing SAP BTP with a consumption-based model. Here, for well-established use cases for which you can easily decide the use of SAP BTP services, you can opt for a CPEA contract and benefit from possible volume-based or company-specific discounts. Of course, this requires proper planning to avoid over- or under-commitment. In addition, your CPEA contract can be part of your general cloud agreement with SAP. In that case, there may be another level of flexibility that allows you to exchange your cloud products and change quantities; hence, you can increase or reduce the cloud credits you have for SAP BTP.

Suppose you do not have a CPEA contract and want an enterprise-grade trial; or, maybe you have a CPEA contract but wish to isolate a specific use case from your CPEA consumption (for example, due to intra-company isolation). In that case, you can choose the Pay-As-You-Go model. But don’t forget, with this model, you will not benefit from potential discounts, so you may pay extra in return for the additional flexibility.

It sounds as though Pay-As-You-Go is a better fit for companies new to SAP BTP that want to evaluate it where the confidence level in SAP BTP is somewhat high; for example, the trial is just a step for due diligence. Eventually, the contract can be transitioned to a CPEA contract retaining the global account. If you are an existing CPEA customer, having a separate Pay-As-You-Go contract wouldn’t make much sense unless you can justify it. If you go above your CPEA commitment, you will be charged with the list prices anyway, and if your overconsumption becomes regular, you can top up your CPEA commitment.

Trial accounts and the free tier

SAP provides SAP BTP in a trial environment where users can try to learn about its capabilities free of charge. It is a win-win situation for both the users—for example, developers—and SAP, where users gain experience by using SAP BTP, and this accelerates the adoption of SAP BTP, which in turn is a commercial gain for SAP.

As an individual, you can register to get a trial SAP BTP account that gives you access to many SAP BTP services free of charge for a limited time—that is, 30 days. You can extend this several times until you reach 365 days, after which SAP will delete your trial account. No worries, as you can create a new one after that.

Important Note

SAP BTP trial accounts are for personal use—for example, exploring SAP BTP capabilities—and you cannot use them for production.

Alternatively, you can use free tier service plans where available. This option is available for many services, and SAP plans to make it available for more services in the future. The free tier may eventually replace the trial account option as it provides an experience closer to enterprise accounts.

In the Technical requirements section at the beginning of this chapter, you can find a link to a tutorial explaining how you can get an SAP BTP trial account. In addition, you can also find information on how to subscribe to SAP BTP for using the free tier. The free tier can be used by enterprise customers as well. It may be a reasonable option for proofs of concept where it is possible to upgrade to a paid service plan without requiring a migration. As you would expect, free tier service plans have limited capacity, and support for the free tier is limited to SAP Community.

Monitoring your consumption

Whichever commercial model you are on, you must keep an eye on your consumption. Otherwise, you may overspend your CPEA budget or subscribed amount, and in the case of Pay-As-You-Go, you may see a surprising amount on your monthly bill.

There are different ways to monitor your SAP BTP consumption. Firstly, SAP provides you with statistics and other consumption information on the Usage Analytics page when you log in to your account in SAP BTP Cockpit, as shown in the following screenshot. This page is available for different account-model levels we will discuss in a later section:

Figure 3.3: Usage analytics for a global account

In Figure 3.3, you can see the usage analytics for a global account. Have you figured out the Export button in the screenshot? You can click on this button to download detailed information on your consumption that you can use for further analysis. In the downloaded spreadsheet, you can find which services you consumed from the beginning of your contract period at the subaccount level with month-by-month metered actual usage and the cost. Based on your actual use, you can then make projections for your future consumption, which may signal any potential overspend; hence, top-up requirements. If you need to estimate costs for possible changes in consumption or new services you plan to enable, you can also use the Estimator Tool , which we will explain later in this chapter.

Suppose you need an automated way of retrieving usage data. In that case, you can use the Usage Data Management service and consume its APIs from, for example, an IT spend management or a reporting application. We will discuss how to do this in the section where we discuss services. With this API-based method, you can establish continuous monitoring and integrate your usage data for analytics use cases.

It would be best if you also use these analytics to optimize your consumption—for example, in the report, you can see whether there are services you have enabled but are not actually using. As mentioned before, some services incur costs even though you don’t actually use them because SAP BTP reserves some capacity for them—for example, a Data Intelligence subscription, an Integration Suite subscription, a Kyma environment, and so on.

Account model

SAP BTP’s account model defines how its elements are organized in a structured way for administration purposes. For the primary hierarchy, there are three levels that are containers for other elements: global accounts, directories, and subaccounts.

Important Note

At the time of authoring this book, SAP was transforming SAP BTP accounts to provide a better set of cloud management tools. This new variant is called Feature Set B, and the old variant is called Feature Set A. This distinction will possibly disappear after SAP converts all accounts. In this book, we will assume you are on Feature Set B. If your screens look slightly different from the images here, don’t worry; you will get the new features after SAP converts your account.

Before we start defining account-model elements, let’s have an overview. Why not check it out first and try making sense of each element before reading its definition? Check out the following diagram:

Figure 3.4: SAP BTP account-model elements

Global accounts

A global account is the highest level in the hierarchy, and it corresponds to your contractual relationship with SAP. So, after you purchase SAP BTP, SAP will provide you with a global account and instructions to access it. Depending on your contracts with SAP, you may end up having multiple global accounts.

Global accounts are not associated with regions or environments, and they function as the topmost containers to include directories and subaccounts. In the following screenshot, you can see how SAP BTP Cockpit displays a global account having several directories and subaccounts:

Figure 3.5: Account Explorer page of a global account (trial) in SAP BTP Cockpit

Directories

Directories help organize the account model by simply being containers for subaccounts or other directories. This is an intermediary level where some properties—that is, entitlements and users—can be assigned at a higher level cumulatively for a set of subaccounts before distributing them to individual subaccounts. In addition, because you can set custom properties (tags) for directories, you can use them as an aggregation level for monitoring usage and cost.

Directories are optional and only available in accounts with Feature Set B. Directories can be nested to include other directories, as long as the entire account model has seven or fewer hierarchical levels. As with global accounts, you cannot associate directories with regions or environments.

Subaccounts

We are now at the level where things get concrete, as subaccounts contain your operational SAP BTP elements. Therefore, subaccounts are associated with a region. This means the applications deployed and the services provisioned in a subaccount will be running in the subaccount’s region. As you should remember from earlier chapters, when we refer to a region, it also contains the hyperscaler of choice.

After you create a subaccount, you can enable specific multi-cloud environments you want to use. As we discussed before, you can subscribe to some services with no attachment to a runtime environment, and for others, you need to create service instances attached to runtime environments. One thing to keep in mind about the Kyma environment is that you can choose to run your Kubernetes cluster in a region different from your subaccount’s region.

As with directories, you can assign custom tags to your subaccounts so that you can identify them for particular reasons—for example, ownership, usage type, and so on.

Elements specific to environments

In addition to the SAP BTP account model, the CF and Kyma environments have their own structural models.

The CF environment has two levels for structuring: an organization and spaces under it. In the SAP BTP context, when you enable a CF environment for a subaccount, the organization of the environment is 1-to-1 associated with the subaccount. Then, when you create organization spaces, they become subordinate elements of the subaccount.

Typically, you will deploy your applications and create service instances in spaces; therefore, you need at least one space in your subaccount. CF spaces provide a level of isolation; however, with the overarching account model of SAP BTP, isolation at this level is generally not used. This means you generally have only one space per subaccount.

Similarly, the Kyma environment has namespaces allowing a level of isolation, and you get a default namespace when you enable the environment.

Entitlements

SAP starts metering the consumption of a service once it’s provisioned, and it will cost you cloud credits if it’s not an included service and you are not using the free tier. Therefore, after the structural elements are in place, you may want to set up a mechanism to control the number of services consumed in subaccounts. In order to make this possible, SAP BTP delivers the services with one or more pre-defined configuration variants that primarily define their costs. These variants are called service plans. For example, some services have service plans similar to T-shirt sizes (small, medium, and large).

SAP BTP facilitates the cost-controlling mechanism at two levels. First, with entitlements, you determine which services a subaccount or subaccounts of a directory can use in terms of service plans; for example, you entitle Subaccount A to use Service Plan x of Service 1. Then, attached to the entitlement, you assign a quota that specifies the upper limit of the quantity that service can be used in the subaccount.

As you can guess, at the top, there are entitlements and quotas SAP assigns to your global account that you are supposed to distribute to your subaccounts. If you have a CPEA or a Pay-As-You-Go contract, most of the entitlements for your global account will be unlimited because you can consume as much as you need, provided that it’s within your consumption budget or you are happy to top up.

Setting up your account model

It’s now time for you to shape your own instance of an account model with the given elements. Indeed, you can use them in a way that fits your requirements, and there is always more than one correct way of doing this. When setting up your account model, the first primary challenge will be which subaccounts you need.

There are different factors here, and each of them may require you to add a set of subaccounts, which increases the landscape complexity; hence, administration overhead and the cost. Therefore, when planning, you need to set principles to optimize the number of subaccounts.

Most probably, the first dimension you would want to incorporate in your account model will be your change delivery strategy, which you likely already established for your on-premises systems. This means a separate subaccount for each landscape environment you have; for example, development, test (quality assurance, or QA), and production. This setup is generally the minimum many companies have. Additionally, you can have a separate pre-production environment to further safeguard delivery to the production environment and for activities such as performance testing. You can also have a sandbox environment to let teams explore options without contaminating the development environment. Finally, you can have a training environment that you specifically reserve for training purposes.

The change delivery in some companies may be quite complex, requiring more landscape environments; for example, some choose to have different sets of environments for the project stream and the business-as-usual (fixing live system incidents) stream.

Let’s assume we have a landscape as depicted in the following diagram. This means we should start with six subaccounts:

Figure 3.6: A typical set of landscape environments

Here, for your SAP BTP account model, you can consider choosing not to have a subaccount for some of the environment types. For example, in a setup where you don’t foresee frequent and significant changes, you can plan training activities accordingly in the pre-production environment because the application version will stay stable and similar to production for a reasonably long time.

This is an opportunity for reducing the number of landscape environments. However, there are more factors that may require increasing the number, such as the following:

• SAP BTP environment types: You should remember our discussions about environment types from the earlier sections of this chapter. Suppose you are in the transitional period for migrating from Neo to multi-environment. In that case, you need to have subaccounts for both types until the migration is complete when you can decommission the Neo subaccounts. As we pointed out before, you need to target completing the migration as soon as possible to avoid the cost of running two sets of subaccounts.
• SAP BTP service strategy changes: Because SAP BTP has been in continuous development, there have been cases where SAP released a new service that offered a strategic alternative to an existing service; for example, SAP released the latest Integration Suite service as a strategic alternative to the existing independent integration services. Similarly, SAP released the newest HANA Cloud service as a strategic alternative to the existing HANA-as-a-service offerings. This type of strategy change means a migration within the multi-environment itself. Again, for technical or practical reasons, you may need to create a new set of environments for the migration.
• Technical restrictions: Let’s give a direct example here. When SAP released the Cloud Platform Integration (CPI) service in the multi-environment, there was a restriction on the number of characters you could have for the subaccount’s subdomain property. If you were planning to enable the service in an existing subaccount with a subdomain longer than the limit, SAP’s advice was to create a new subaccount.
• Project/product isolation: There may be cases where you want to manage large or priority projects in a way that requires an isolated set of environments solely used for the project. This isolation can end before production, and the project can deliver to a shared production environment; but also, the isolation may go up to the production environment, which means you are segregating the product.
• Business isolation: Suppose your company has several business units (BU). In that case, you may want to establish one set of subaccounts for each BU due to administrative or business requirements. If you consider doing this, bear in mind that the applications deployed for the BUs will most probably be independent of each other, and most platform services provide ways to isolate the artifacts of BUs. In that case, you may consider using the same set of environments for multiple BUs.
• Regional requirements: You should remember the section earlier in this chapter where we discussed regions and the cases in which you may require having SAP BTP on multiple regions. As subaccounts are attached to regions, a multi-region requirement means different sets of subaccounts.

So, let’s solve an exercise to demonstrate what we have learned so far. How about creating an account and landscape model for a company with the following requirements? There is still some room for interpretations and assumptions; after working on yours, you can check Figure 3.7 to see our solution:

1. Company Alpha has two BUs and requires separation at the BU level.
2. BU 1 has just completed a project and migrated from legacy software to SAP S/4HANA using a RISE with SAP offering. It now needs to set up its global account in SAP BTP.
3. BU 1 plans to build some mission-critical applications; therefore, it needs to provide highly reliable business continuity measures for these applications.
4. BU 1 has many end users and is happy to invest in providing training for these users. Also, BU 1 wants to allow power users and developers to innovate and trial new features without contaminating the change delivery environments.
5. In addition, BU 1 needs a separate set of environments for its Product X because it wants to manage it independently; maybe it is considering commercializing the product. A small team will be developing and operating this product. They are okay with using the development environment for trial purposes and don’t need a different training environment yet.
6. BU 2 onboarded on SAP BTP a while back, and it has a presence in the Neo environment with a typical four-tier model.
7. BU 2 has started migrating to the multi-environment and wants to keep its change delivery model the same, but it wants an additional environment for training end users.

You can see an example landscape for this exercise in the following screenshot:

Figure 3.7: An example landscape fulfilling the requirements in the exercise

In our solution version, we should also note the following:

• In order to fulfill the business continuity requirement for BU 1, we propose two sets of subaccounts in two different regions, Region A and Region B. As the requirement is for BC, there is no need for development and test subaccounts in Region B. However, we have a pre-production subaccount in the second region where BC testing can be done.
• In response to requirement 4, we propose training and sandbox subaccounts in the primary region.
• There is a third set of subaccounts for BU 1 specifically set up for Product X development and operations as per its requirements.
• BU 2 already has a set of subaccounts in Neo. We propose a similar set of subaccounts for the new multi-environment setup, and we added a separate one for training.

With all the aforementioned factors adding new dimensions to your landscape, you may end up having tens of subaccounts, and their administration may become complicated. You may remember that SAP BTP has another element—that is, directories—for grouping subaccounts. Here, you have the freedom of how you want to group, and—most probably—pragmatic reasons will define your choice. For example, you can place the subaccounts in each row in our preceding example under a directory.

Furthermore, within these directories, you can add another level to separate production and non-production subaccounts. Here is a good piece of advice, though: don’t exaggerate and end up with too many directory levels as this may eventually cause more pain than good. There is a limit on how many directory levels you can have anyways. For the entire account model, you can currently have a maximum of seven levels. One is for your global account, and another is for the subaccount level; hence, you are left with a maximum of five directory levels.

After making the landscape decision, you should consider which services you want to enable in each subaccount and with which configuration. We say configuration to take it at a more general level, but this primarily points to service plans and sizing considerations. It is not necessarily the same set of services you have to enable in every subaccount; for example, although you have a four-tier landscape, you can choose to enable the SAP Data Intelligence service in the production subaccount and only in one of the non-production subaccounts. With the two instances of SAP Data Intelligence, all non-production usage can co-exist safely with proper artifact isolation. This way, you can achieve cost savings.

When enabling services, you need to pay attention to which service plan you use because this will impact the cost. For this, you may need to do a sizing exercise where you need to define parameters. Here, you can use numbers from the business or get them from an existing system if, for example, you are moving functionality from on-premises to the cloud. With this input, you can use the Estimator Tool to calculate an estimated cost. We will explain the Estimator Tool later in this chapter.

Services

At the beginning of this chapter, we already defined what a service is: it’s a managed capability provided through the platform to be used as a building block in our solutions.

These can be business services that you can almost immediately incorporate into a business process providing industry-specific or line of business (LOB)-related capabilities, for example, Document and Reporting Compliance, Data Privacy Integration, Business Entity Recognition, and so on. Otherwise, they are technical services that do not directly relate to a business context; instead, you can use them to build technical elements and applications.

What we also need to clarify at this point is that in the SAP BTP context, a service can refer to different technical things, even though all of them are present together in a single service catalog/marketplace. Let’s see them.

Applications and subscriptions

An SAP BTP service can be an application that exists in a different provider environment to which you need to subscribe as a consumer before you can use it. These are like multi-tenant software-as-a-service (SaaS) applications; you have an isolated tenancy in the provider environment where the application runs on a managed and dedicated/shared infrastructure; hence, the boundary between platform as a service (PaaS) and SaaS gets blurry here. In any case, your data and processes are protected with appropriate isolation. Surely, for most SAP BTP services, the provider is SAP itself, and the application is built on top of SAP BTP.

Because you subscribe to a provider’s application, SAP uses the term subscription to refer to your specific use of it. A subscription doesn’t need a runtime environment in your subaccount. Your applications generally connect with these provider applications directly, without the platform’s intervention—for example, a HTTPS communication managed by you and programming models can streamline this interaction.

Integration Suite, Workflow Management, Launchpad, Continuous Integration and Delivery, Event Mesh, and Business Application Studio are examples of this service type.

Your company may be on the other side of the subscription—that is, the provider of an application. In that case, you develop a multitenancy-aware application that, for example, uses proper routing mechanisms, Authorization and Trust Management Service for identity and access management (IAM), and so on. In addition, you can use the SaaS Provisioning service for managing subscriptions to your application.

Runtime environments

Runtime environments are also considered services in the service marketplace. It’s almost as though we are in a circular reference here, right? This is because of historical reasons we touched upon in an earlier section explaining environments.

You need a runtime environment in your subaccount if you want to deploy applications or use non-subscription services, which we will be explaining next. As we explained when discussing the SAP BTP account model, you can enable CF and Kyma runtime environments at the subaccount level. In contrast, the ABAP runtime environment needs a CF space.

When you create a CF runtime environment, SAP BTP assigns to the subaccount a memory quota that applications can use. Because SAP BTP’s current service provisioning model is based on CF, some services become available only after CF is enabled in the subaccount.

When you create a Kyma runtime environment, SAP BTP reserves the infrastructure for running a managed Kubernetes cluster.

Services and service instances

After handling the aforementioned special types, let’s come to the kinds of services that are just reusable functionality reserved for consumption by your applications. To utilize these types of services, you need to create a service instance in an applicable SAP BTP runtime environment—that is, CF or Kyma. The service instances reserve resources in your subaccount, and they are primarily for your applications to communicate with them through APIs. Let’s look at some examples here:

• Backing services: These are the services applications need to use in order to provide their full functionality, such as persisting data (database, object stores, and so on), storing and retrieving credentials, caching, and so on.

For example, when you enable the SAP HANA Cloud service, SAP BTP provisions an instance of the database and the infrastructure it runs as reserved resources by the service instance. Similarly, when you create an Object Store service instance, SAP BTP arranges its infrastructure—for example, Microsoft Azure Blob storage, an AWS Simple Storage Service (S3) bucket, or a GCP Cloud Storage bucket—and through the created service instances, your applications can communicate with these backing services.

• Other miscellaneous services: For example, the Authorization and Trust Management service enables applications to fulfill IAM requirements through the foundational platform components—for example, authentication via the configured identity provider (IdP).

Service instances can be attached to applications by creating bindings that deliver service credentials automatically to the bound applications. If you need to connect to a service instance directly—for example, from an external client—you can create a service key that generates access credentials. These include Open Authorization 2 (OAuth 2) elements, which you need to use for authorization before accessing service instance APIs. For example, the Kyma environment uses service keys to consume services in the CF environment; or, say, you have an IT spend management application that you want to connect to SAP BTP in order to retrieve consumption and cost information using the Usage Data Management service.

Here, after creating a service instance, you can create a service key that generates OAuth 2 credentials. Because the application is external, you cannot use bindings. Instead, the access information needs to be shared manually with the external application.

In Figure 3.8, you can see a diagram bringing the different types of services together. As you can see, there is one single service marketplace that includes all these services. If you are curious about the kernel services, we can say they are foundational components used internally within the platform and are not supposed to be directly consumed by customers.

One thing to note here: SAP’s current strategic direction keeps CF and Kyma environments co-existing in SAP BTP. The current service provisioning model is more aligned with CF, and we don’t yet know if this will be different in the future.

You can view the diagram here:

Figure 3.8: SAP BTP service types overview

Connecting with external environments

You can define external services so that your applications can consume them similarly to SAP BTP’s platform services. For example, after you configure your AWS or Azure account as a resource provider in SAP BTP, you can consume the supported services that are provisioned in the AWS or Azure platforms. Currently, SAP BTP supports PostgreSQL database services on AWS and Microsoft Azure. This way, you can create a PostgreSQL database in AWS or Azure and then build your application in SAP BTP to persist data in that database.

Another approach to achieving external service consumption is using user-provided services. First, you need to create a user-provided service instance that contains access details for the external service. This instance can now be attached to an application with a binding. As you remember, what a binding does is automatically deliver access information to the application to consume the external service. Compared to the first option, this is a less streamlined method.

In the opposite direction, you can also make external environments consume SAP BTP services as well. For this, you need to use the Service Manager service through SAP BTP Cockpit, the Service Manager command-line interface (CLI), or Service Manager APIs. This connectivity option is valid for external Kubernetes clusters as well. Here, you would have an additional option—that is, SAP BTP Service Operator, which streamlines the interaction used by Kubernetes native tools.

Taxonomy

Over time, SAP classified SAP BTP services under different categories. You’ve possibly had a peek through the contents of this book and have seen which categorization we adopted; that is, the high-level use cases for which SAP BTP provides services.

Important Note

There are some applications SAP built on top of SAP BTP, selling them as separate products. These are generally considered under the SAP BTP portfolio, although they are not directly available as SAP BTP services—for example, SAP Analytics Cloud (SAC) and Identity Access Governance (IAG).

The following figure shows a basic categorization of SAP BTP services:

Figure 3.9: A basic categorization of SAP BTP services

Classification is not an easy task, and surely the functionalities of some services span multiple scenarios. In Figure 3.9, we wanted to give an overview and a sample of services for each category. Further listing all SAP BTP services and providing catalog information here would be a waste of space because we will explain most of them in later chapters with examples. Besides, there is a great online tool that fulfills service discovery requirements, and you do not need to wait long as we will discuss this in the next section.

SAP Discovery Center

Who doesn’t like a catalog that functions as a registry and has the following attributes:

• Is always up to date
• Includes a brief and effective summary of items
• Tags items for important attributes
• Provides detailed availability and pricing information
• Lists essential resources to get further information
• Includes guided training to learn more about how to use the items
• Shows a roadmap for the items’ future direction
• Tells about success stories of others who used the items

We cannot see anyone raising their hands. Luckily, SAP provides such a superb catalog for SAP BTP—that is, SAP Discovery Center. So, don’t take just our word for it; go and check yourself as it’s at your fingertips at the following link: https://discovery-center.cloud.sap/.

While designing your solutions, SAP Discovery Center is your best companion to help you find your way among so many platform services. Let’s see this with an example. Bear in mind that the following example is based on the content available at the time of authoring this book:

Figure 3.10: SAP Discovery Center overview page for SAP Launchpad service

As an architect working for Company A, Mary considers using the SAP Launchpad service in her design and needs to gather information. So, she navigates to SAP Discovery Center and searches for or browses the SAP Launchpad Service page. The screen looks like the one shown in Figure 3.10.

The Overview page tells her what the service is about and includes links to resources and tutorials. Next, she gets to the Pricing tab, which is shown in Figure 3.11. Company A has a CPEA contract. So, after ensuring the CPEA option is selected as the commercial model, she can see that two service plans are available: Free and Standard. The design is for a production solution end users will use. Thus, she thinks she should look into the Standard service plan.

Mary realizes there are two sets of pricing information, and it seems the region feature for EU access may impact the cost. Also, she needs to check whether the Launchpad service is available in the SAP BTP region in which her company already has subaccounts. She clicks on the globe button, which shows a map as in Figure 3.12, and it seems the service is available in the region she wants.

You can see the pricing page here:

Figure 3.11: SAP Discovery Center pricing page for SAP Launchpad service

So, how much will consuming this service cost? In order to calculate it, she needs to know the metric by which the service is charged. For the Launchpad service, she can see that it is the number of active users, and from the definition, it looks as though she needs to count anyone who would use the Launchpad service at any time during a month. From the requirements, she knows that approximately 6,000 users will be using this service, so she can base her calculation on this number. Checking the pricing table, it looks as though the quantity of 6,000 active users falls under the fifth pricing tier, which says Up to 20,000, and the price per unit for this tier is 0.79 British pound sterling (GBP)/month. So, for all users, that makes 6,000 x 0.79 = 4,740 GBP/month. Because Company A is on a CPEA contract, this will be the amount withdrawn monthly from the cloud credits balance for consuming the SAP Launchpad service.

Important Note

In contrast to many cloud vendors using cumulative pricing, SAP uses tiered pricing. In this model, you pay the entire quantity with the same price per unit of the tier to which your consumption corresponds. Therefore, once you identify the tier of your usage, other tiers have no place in your cost calculation.

The following figure shows the regions in which the SAP Launchpad service is available:

Figure 3.12: SAP Discovery Center regional map showing in which SAP BTP regions the SAP Launchpad service is available

Estimator Tool

In Mary’s aforementioned scenario, there was only one service. The more services you need to consider, the more difficult it may become. Also, the metrics for some services require a deeper level of sizing exercises, such as SAP HANA Cloud, SAP Data Intelligence, and Kyma environments.

SAP provides a handy tool that helps customers neatly calculate prices. With the Estimator Tool, you can add multiple services and customize the factors that impact pricing. For example, check out the screenshot in Figure 3.13, where we added three services in the estimation. As you can see, besides providing the parameter values for service pricing metrics, we have also customized the estimator to do the following:

• Provide prices for the following:
  • Based on a specific region—that is, AWS Frankfurt
  • In our preferred currency—that is, GBP
  • For a particular commercial model—that is, CPEA
• Incorporate a discount of, say, 10%.

Important Note

You can access the Estimator Tool from within the SAP Discovery Center or by directly navigating to https://www.sap.com/uk/products/business-technology-platform/estimator-tool.html.

Let’s take a look at what the Estimator Tool window looks like with our example:

Figure 3.13: Estimator Tool showing prices for three services

As mentioned before, for some services, you need to have a more sophisticated sizing exercise to determine the cost. In such cases, SAP generally provides an abstract metric—that is, capacity units. By defining sizing-parameter values, a total number of capacity units is derived. In the tool, next to the metric input box label, a calculator icon appears for this type of service; upon clicking it, you will be taken to a sizing screen specifically tailored for the service. Let’s take the SAP Data Intelligence service as an example. Multiple components may impact the cost, such as the number of pipelines, jobs, users, pre-trained machine learning (ML) services, and core ML services. For all related components, you can specify how many you need according to your requirements. In the following screenshot, you can see an example. It may not be a completed sizing exercise because our goal was to showcase different elements in the screenshot, but it should give you an idea:

Figure 3.14: SAP BTP Estimator Tool – calculation of SAP Data Intelligence capacity units

As you can see, after our input, the number of capacity units is calculated as 6087 per month. Now, you can close the sizing screen and go back to the Estimator Tool to enter this number as the metric value.

Next, let’s learn more about account administration.

Account administration

We have talked a lot about SAP BTP so far, and we understand there are lots of new concepts that need to sink in. Undoubtedly, the best way this can happen is when you try it yourself. So far, it has been all about foundational concepts, commercial models, and the SAP BTP account model. Now, let’s look at the options around how you can manage all these. As an architect, you may not need to know the lowest-level details of account administration; however, having a high-level knowledge of it will help. So, we will keep it short and sweet. At the end of the day, you may want to know how to find your way around SAP BTP when designing architectures, and you may need to try things yourself.

You can manage your SAP BTP account mainly using three tools: SAP BTP Cockpit, the SAP BTP CLI, and SAP BTP APIs.

SAP BTP Cockpit

SAP BTP Cockpit is a web-based user interface (UI) that lets users manage SAP BTP account-model elements using screen controls. The UI adheres to the account-model structure, and you can drill down from your global accounts to service instances where each has a dedicated administration screen.

Here, we should remind you of the note we provided at the beginning of the Account model section. Your Cockpit screens may look different from the screenshots in this book, depending on which feature set your global account is on. Also, SAP continues improving SAP BTP Cockpit; hence, changes in appearance over time wouldn’t be surprising.

In Figure 3.5 in a previous section, you already had a peek at the Account Explorer screen, which shows subordinate elements of the global account. As you can see, the screen displays information and contains buttons to make changes to your global account—for example, creating/updating/deleting a directory or a subaccount.

As another example, in the following screenshot, you can see the administration screen for a subaccount. It has a similar structure that displays essential information, and contains buttons for managing subordinate or linked elements:

Figure 3.15: SAP BTP Cockpit – subaccount administration screen

Important Note

If you are stuck when using SAP BTP Cockpit, you can use the context-aware help by clicking the question-mark button. It’s a great facility and provides rich content that will help with the page you are on, including essential information and links to the standard documentation. Try it, it’s impressive.

Another interesting part of SAP BTP Cockpit is the Service Marketplace. Here, you can find all available services according to the entitlements assigned to the subaccount, as shown in Figure 3.16.

The following figure shows an overview of the Service Marketplace.

Figure 3.16: SAP BTP Cockpit – Service Marketplace

SAP BTP CLI

It may look a bit abstract when you manage your account using SAP BTP Cockpit; however, under the hood, your account data is persisted somewhere, and there is an application processing that data.

As a convenience tool both internally for SAP and for customers, the BTP CLI provides a set of commands and other common CLI features for users who prefer working in a terminal.

This way, the BTP CLI enables scripting, which means you can create scripts to automate administrative tasks. Enabling automation is a crucial cost-optimization element in today’s IT landscapes as operational requirements are much more dynamic.

You can use the BTP CLI to do everything you can do in SAP BTP Cockpit; for example, you can log in to your global account and manage all account-model elements.

Important Note

You can use the BTP CLI only for global accounts with Feature Set B.

If you have advanced use cases to manage CF elements of your subaccount, you can use the CF CLI. Similarly, with the Service Manager Control (SMCTL) command-line tool, you can run commands to manage service instances in your SAP BTP subaccount directly with Service Manager. Many SMCTL commands are available in the BTP CLI, though.

SAP BTP administration APIs

SAP BTP provides a special set of APIs that you can use to manage your global account and its subordinate elements, as follows:

Core Services for SAP BTP: The APIs in this package use the Cloud Management, Usage Data Management, and Service Manager services; therefore, you need service instances in your subaccount accordingly. With these APIs, you can do the following:

• Manage your account-model elements—for example, global accounts, directories, subaccounts, and so on.
• Manage entitlements.
• Provision runtime environments.
• Get information about administrative events.
• Manage applications (as a provider) and subscriptions (as a consumer).
• Retrieve consumption information.
• Use SAP Service Manager for managing service instances, bindings, and so on.

SAP Authorization and Trust Management Service: These APIs can be used to manage IAM-related entities, as follows:

• Manage role-based access control (RBAC) elements—for example, roles, role collections, and so on.
• Manage IdPs of the subaccount.
• Manage security settings.
• Manage users and their authorizations.

We have just listed APIs that can be used for administrative purposes. There are many other APIs that you can use to consume the capabilities of SAP BTP platform services—for example, APIs for monitoring, connectivity, transport management, alert notification, and so on.

Important Note

For more information on SAP BTP APIs, you can visit SAP API Business Hub at https://api.sap.com/ and search for SAP BTP.

As you would expect, these APIs are protected for security reasons, and you would need to get OAuth 2 authorization before you can use them. Any idea how you can achieve this? How about if we remind you that these APIs are exposing the functionality of SAP BTP services? If you don’t have an answer, then maybe you should read (again) the part where we discuss service keys.

Summary

We are now at the end of this chapter after going through so many foundational elements of SAP BTP. So, let’s go back to the beginning and fast forward for a summary.

First, we learned which environments you could have in SAP BTP and in which regions SAP BTP was available. Next, we discussed different options to buy SAP BTP and how they compared. Then, it was time to see how SAP BTP components were structured in its account model, and we discussed how to set up your own account model based on an example. In the subsequent section, we had a good overview of what a service meant and also learned about SAP Discovery Center. Finally, in the last section, we briefly discussed the administration tools you could use to manage SAP BTP.

Now that we have laid out the essential foundational elements, we will go more technical in the next chapter and discuss two fundamental aspects you need to consider in your technical designs: security and connectivity.