[SAP BTP Onboarding Series] Account Structure and Decision Making

**Updated April 13, 2023**

If you’ve been following the SAP BTP Onboarding series, then you should now understand:

• BTP is a platform consisting of many services and we’re focusing on onboarding specifically to the SAP BTP cockpit
• The BTP cockpit can be compared to your own personal hardware store
• The types of commercial models SAP offers and which one(s) you’re licensed for
• Who is designated permission to login to the cockpit, how to add more global admins, and how to check entitlements

With this understanding, you’re now ready to start building out your account model. An account model is how you’re going to structure your project. To start, I want to define the key building blocks of your SAP BTP Cockpit. To illustrate this I’m going to use a house as the analogy 🙂

• Global Account: A representation of your contractual agreement with SAP. Think of a Global Account as the structure of a house. When you walk in the front door there are no rooms and no floors, just a wide open space.
• Entitlements: The services you are permitted to use based upon the contract you signed. Some services are included automatically with no additional charge when you purchase an SAP BTP account. Others are specific services you license, either through a subscription or consumption-based agreement. Think of entitlements as the stuff you get to put into your rooms. For now they are all just sitting on a shelf waiting for your to organize your house.
• Subaccounts: What holds together your applications, services and subscriptions and allows you to organize and structure your global account. A subaccount is a room in your house. How many rooms you decide to have and what you put in those rooms is up to you.
• Directories: Allow you to organize and manage your subaccounts based on business and/or technical need. Think of Directories as the floors in your house. How many floors do you need in your house?

When deciding what your global account is going to look like, the following decisions need to be made:

• Determine which services you need to achieve your use case
  Regardless which commercial model you selected, this step has very likely been done for you. In some cases, you’ll be determining new use cases as your digital transformation project unfolds, in which case it’s always a good idea to pause and detail the specific services you want to use and where you want to provision them. The SAP discovery Center has missions and the service catalog to help you make these decisions.

• Determine how many subaccounts you need for your use case(s)
  This decision is subjective. There is no right or wrong answer to how many subaccounts you should create for a particular project. There is the traditional 3-tier dev, test, prod account model that we see for on-premises landscapes, but it’s not required. For example, some industries require more rigorous testing and need a pre-test and post-test account. Some industries/use cases are much simpler and only require a 2-tier account model where dev/test are combined in one subaccount and prod is on its own. The only real best practice when it comes to account models is you should have a dedicated productive account. Take the time to sit with your team and leadership to determine what account model and policies your use case and company requires.
• Determine the provider/region you want to run each subaccount from
  SAP offers services from various providers (Alibaba, AWS, Microsoft Azure, Google Cloud, and SAP) and some companies have a preferred vendor they need to use. Align with your team and leadership to determine if you have a requirement to follow when selecting a provider. From a region perspective, you need to think about which part of the world you’re going to build and run your project from. Some of you are global companies and may have a team in the US west coast building an application to be run out of EMEA. The SAP Discovery Center Service Catalog shows you where each service has availability.
• Determine naming convention for subaccounts
  This is another subjective decision with no right or wrong way to do it. I advise that you be intentional in what you choose and make the name informative. Maybe you want to name your account model after a specific project name, or maybe you’re providing different departments with subaccounts for their various projects. Examples could be ‘ProjectA_Dev’, or ‘Integration_Test’ etc. Whatever you decide here should be a best practice continued through your company as you expand your SAP BTP usage.

• Create subaccounts
  Global administrators have the access to create subaccounts and as the creator are inherently assigned as subaccount administrators. To create a subaccount, you’ll need the following mandatory fields:
  • Subaccount Name – this name will automatically be used to create a subdomain. A subdomain will become part of the URL you use to access the applications you subscribe to in this subaccount.
  • Region – Infrastructure provider and geographical location.
  • Parent assignment – this will be assigned directly to the global account unless you are using directories, in which case you can choose if the subaccount should reside within a directory.

You also have the following optional fields you can fill out

• • Description
  • Used for production checkbox
  • Enable beta features checkbox
  • Custom properties – a way for you to further organize and identify your subaccounts.

• Assign entitlements to subaccounts
  Entitlements are provided on the global account level and it is the customers decision to determine how those services are allocated. After you’ve created your subaccounts, you need to specifically assign the paid for entitlements to specific subaccounts. The subaccount can only consume the amount of entitlement that you delegate to it. If you purchased the subscription model and run out of entitlements to assign you’ll need to contact your SAP account team to purchase more. If you’re using the consumption based commercial model you’ll have ‘unlimited’ defined as the quantity for applicable services, meaning there is no limit.

• Determine and assign subaccount administrators
  These will be the people who are provisioning the service entitlement you’ve allowed and adding the team who will execute the technical tasks associated with the project.

Below is a high-level diagram showing an example of what the SAP BTP Cockpit could look like for a company who just made the decisions discussed in this blog. The global account is using the subscription commercial model and is entitled to 5 services meant for 2 projects. Each project was designated a directory where their subaccounts were assigned. Directory A decided on a 3-tier account model for entitlements A, B and C while Directory B decided on a 2-tier account mode for services C, D and E.

In the next blog, I’ll cover some of the more common account models we see and discuss what you should consider when creating your companies account model.

If you don’t have time to wait for more blogs, remember to check the SAP BTP Events page to see what webinars we’re running this month and register to join us.