Objective
Think of the SAP BTP Account Model as a large, hierarchical filing cabinet system for your entire organization's cloud resources. Its primary purpose is to provide a structured way to manage billing, resources, security, and users across different projects, departments, and geographical regions.
This lesson contains the following topics:
The SAP BTP account model ensures that organizations can safely and efficiently manage who gets access to what, how much they can use, and where their applications and data physically reside, all while keeping the commercial aspects separate from the technical development work.
When looking at the resource model of SAP BTP it is helpful to start with the following concepts:
The Global Account is the highest level in the hierarchy. It represents an organizations commercial relationship and contract with SAP.
Directories are an organizational layer that exists between the Global Account and Subaccounts. They help large organizations group and manage subaccounts more effectively.
The Subaccount is where the actual work happens. It is the technical and deployment environment where you run applications, enable services, and manage developer access.
A region represents a geographical location (for example, Europe (Frankfurt), US East (VA), Australia (Sydney)) where resources such as applications, data, or services are located. Regions are provided either by SAP or by their Infrastructure-as-a-Service (IaaS) partners Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Alibaba Cloud. The partners operate the infrastructure layer in the regions, whereas SAP operates the platform layer (discussed in the previous lesson) and the Cloud Foundry runtime environment (to be discussed in a later lesson). Some things to note about a region:
SAP BTP Account Model functions are executed using the SAP BTP Cockpit. The cockpit is the central tool for operations including administration and development.
Depending on an administrators geographical location (i.e., America, Europe, Asia) they can choose the SAP BTP cockpit gateway closest to them to maximize performance. Irregardless of which gateway is chosen users can always perform all administrative / development functions in any subaccount irregardless of the region that subaccount is located in. The three SAP BTP Cockpit gateway access URL's are:
It would be okay at this point if the interaction of the different components in the SAP BTP model is a little bit "fuzzy" on the part of the learner. The following few bullet points may help in understanding how they all work together:
Different organizations will have different need and thus will setup their account model differently. Let's take a look at a few examples. These examples are not all inclusive but help to give an idea of the thought process companies could go through in setting up accounts.
In this first example, a directory approach is used. The directories are structured by region (Asia-Pacific, Europe, Americas) and the subaccounts assigned to the directories are structured by business function (operations & sales). As mentioned previously directories are used to manage subaccounts and subaccounts in turn are assigned to regions and thus host resources such as services, applications and data.
Next to this, labels are used to add meta data information to the structures. This meta data is additional information like a cost center for better cost management, owner contact details, or whatever you need, as labels are free text key-value pairs.
In this second example we have an account setup based on a staged development environment. In this scenario three subaccounts setup each of which is used for development, testing and production respectively. Among the reasons this can be advantageous are:
In this third example an organizations creates a dedicated development subaccount per project (three in the example). Using this approach the Continuous Integration and Continuous Delivery service (CI/CD) can be used to consolidate, test and publish apps in one single testing and one single productive subaccount. Although one testing and productive subaccount is indicated in this example additional testing and/or productive ones can be created if deemed necessary.
In this fourth and final example a scenario of separate development, testing, and productive subaccounts for each division is outlined. This scenario would enable the distribution of subaccounts for development, administration, and operations to several teams. This is very helpful in large scenarios where multiple projects are running in multiple divisions of a company. It's recommended to make use of directories and labels to better structure the accounts and to review costs on a finer level.
Earlier we talked and defined the terms region, global account, subaccount and directory in the context of the SAP BTP account model. We now continue with the next set of terms crucial to understanding SAP BTP. These terms are:
Imagine you're a general contractor building a custom house. You don't do everything yourself; you hire specialized subcontractors:
Let's now go a little bit deeper:
These are the actual runtimes that live inside a subaccount. You must enable an environment within a subaccount before you can deploy applications to it.
We’ve mentioned several times that SAP BTP services eventually will be provisioned and consumed. So how exactly does this happen? Depending on the service in question this will happen via a "Subscription" or a "Service Instance". Both lead to the same result (provisioning and / or consuming) but get there in slightly different ways. SAP BTP Services that operate on more of a "shared" model (where multiple users access the same service) tend to use a subscription based approach. Using the SAP BTP Cockpit the administrator will subscribe to the service once (and once only). Every user then who needs access to the service will use the same method of access which is almost always a shared URL. SAP BTP services that use this approach are sometimes referred to as "subscription based services". While technically speaking SAP BTP operates at the PaaS layer, subscription based services operate similarly to their counterparts at the SaaS layer (e.g., SAP S/4HANA Cloud, SAP Ariba, etc.).
With other SAP BTP services on the other hand the provisioning and consumption is based on instances of the service being created (similar to a cookie cutter being used to make cookies). As an example let’s say an application is being developed and the data for the application is to be stored in SAP HANA Cloud ("Database as a Service"). Multiple SAP HANA Cloud service instances based off of the SAP HANA Cloud service will need to be created. Subsequently a "service key" containing all the necessary information including credentials to access the instance will be created. Through a binding the application can access these credentials (and thus the service instance) and in doing so consume the service.
Applications are created by using tools and programming models and deployed to environments. As mentioned through bindings they can access service instances and thus consume SAP BTP services. In addition they can be administered and if necessary connect to both cloud and on-premise systems.
So as they say "let’s put it all together". Let’s say a customer is using SAP S/4HANA Cloud along with SAP BTP for several use cases. One of those use cases is a custom application they need to design and build. Let’s walk through their implementation of this use case using all of the terminology introduced in this unit to make sure we have a clear understanding of the terms and how they are used.
The customer purchases an SAP BTP license pursuant to a contract and in designing some custom applications several SAP BTP services are identified as necessary.
Walking through a "flow" which uses the terminology discussed in this lesson we could say the following:
An understanding of the SAP BTP account model is fundamental to working with the platform. It represents the building blocks for organizations to purchase, manage, and consume capabilities.