Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
liz_cawley
Advisor
Advisor
**Updated December 29, 2023**

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

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(s). 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.

  • Subaccounts: What holds together your applications, services and subscriptions and allows you to organize and structure your global account. Think of a subaccount as 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?

  • 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.



With the house analogy in mind, it is your responsibility as the customer to determine what kind of house you're building. Are you just getting started and a rancher house with 3 rooms is sufficient? Or do you have multiple projects in mind and need to build something much larger? When thinking about access and roles, what kind of separation will be required? Will that factor into how many rooms you'll have?

In my role in Onboarding I often meet with customers seeking advice from SAP on how to best set up their 'house'. We of course have best practices but what makes BTP so exciting is we built it for you and made it flexible enough for you to adapt to your business. Every company is unique and we want you to be able to build up your BTP account in the best manner for your organization.

Below are some things to keep in mind when determining your account model:

  • 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. The SAP discovery Center has missions and the service catalog to help you make these decisions.

  • 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 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.

  • For those using a consumption based model leverage the SAP Discovery Center to estimate associated costs for your projects
    SAP BTP as a platform offering provides you close to 100 different services. These services are individual products and have their own way of charging for use. It's not one size fits all and for some, there could be cost considerations that would play into your account model.

  • Determine who from your organization needs access to which subaccounts/projects. 
    At this step you may see that creating Directories has advantages for you. Some companies, for example, operate as one large organization with mini organizations underneath. For those customers using Directories allows them to create separation between teams.


After you've made these decisions, have them written out and agreement from your teams you're ready to start setting up your BTP account.

  • 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 consumption based commercial model for 2 concurrent projects. One for application development using the SAP Build Suite - Build Apps, Build Process Automation and Build Work Zone Standard to keep the core clean on their S/4HANA implementation. The other project is for an SAP to SAP Integration use case between SAP S/4HANA and Ariba. They've also decided to create a Sandbox subaccount to trial new services that could be beneficial to them free of charge using free tier. In this example, they are trialing cloud transport management and SAP Datasphere.

With this structure in place the global account admins are able to maintain governance and control over what services and which people are assigned to each.


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.
1 Comment