[SAP BTP Onboarding Series] How to Determine your Account Model

When I meet with customers one of the most common questions I’m asked is ‘what is SAP’s recommendation or best practice for the number of subaccounts I should create in my SAP BTP cockpit?’ My answer is always the same, ‘It depends’.

SAP developed the SAP BTP cockpit as an all-encompassing platform to fit the needs of our vast customer base. The SAP BTP platform empowers YOU as the customer with the necessary tools and features to organize your business in the manner most effective for your business. While this flexibility is wonderful it can also be overwhelming and leave customers feeling like they’re not equipped to make these types of decisions. I’m here to squash those fears by providing you the information needed to ensure you are indeed equipped to make those decisions.

If you’ve read my entire blog series, I’m confident you’ve picked up on the ‘be intentional’ theme. You must know what you’re setting up before you set it up. Any of us can relate to a DIY project in some way, shape, or form, and similarly, before you purchased the required ‘things’ to achieve your project you confirmed what you were working towards. Before creating anything in your BTP cockpit, make sure you answered the following questions:

• Do you have a use case?
  In my onboarding webinars (register for a future session) I talk about how some customers may have no idea why SAP gave them the BTP cockpit and that’s OK. SAP knows you’re going to need to a tool or service at some point in your digital transformation journey, so we wanted to make it easy to get going when you’re ready. For use case inspiration check out the SAP discovery center missions and our use case explorer.
• Do you know which services are required to achieve your use case?
  It’s likely you have an idea which services you need but be sure to check out the SAP Discovery Center for a catalog of all our services. You can filter by commercial model to ensure the service you need is available to you.

The next step is to consider your specific business and the requirements your leadership has in place. Some things to consider:

• Do you have mandatory testing policies in place?
  Some industries, specifically regulated industries, require stricter quality assurance processes than other industries. I’ve seen customers who are required to have pre-QA and post-QA testing as part of their overall QA process. If your company has special requirements, those will need to be considered when determining your account model.
• How many use cases are you setting up for?
  If you’re setting up, for example, an integration use case for your marketing team and an internal employee portal for your HR team you need to determine if they can share subaccounts or if the use case/users/effort etc. is so different that you prefer to keep them separated. The concept of Directories could be used in this case to help separate subaccounts per functional area. For more information see SAP Help: Account Models with Directories and Subaccounts.
• How many BTP services are you using?
  Are you using a single SAP BTP service or a combination of services to achieve data to insight? If your architecture is more comprehensive and spanning SAP BTP services, you may want to consider an account model where you dedicate subaccounts for data isolation and reuse of API Management, as an example. For more information see Account Model 3 in the SAP Help Documentation.
• Does your company have a preferred infrastructure provider?
  Some companies have policies in place where they are required to run on a certain provider or policies forbidding them to run in other providers. It is important to think about who you want to run on and check if your required services are available through that provider.

• Do all the services you require for your use case run in the same region?
  Each subaccount can only run in 1 region/provider. If, for example, your company prefers Microsoft Azure as the provider and your use case is for the ABAP environment, you’ll need to spend some time seeing if an exception can be made to run in AWS since that service is only currently offered through AWS. For more information on services availability visit the service catalog in the SAP Discovery Center.

• Does your company have a central testing process and a centrally managed team for productive environments?
  You could consider having dedicated development subaccounts per use case/team with a centrally managed testing subaccount and productive subaccount. You would want to consider who needs access to the testing and productive environments and what is the volume of work you’re expecting to see if this model makes sense. For more information see Account Model 4 in the SAP Help Documentation.

Answering questions like these and working through not only what is required to build out your use case but considering your companies intricacies in going productive are important in determining your account model.

Some best practices I’ve learned through my work with customers:

• Have a team in place whose job is to manage the SAP BTP cockpit.
  This is especially important for businesses using it for more than one use case. You can quickly have too many cooks in the kitchen. The most successful customers I’ve seen are the ones who have a team focused strictly on administering and governing the BTP cockpit. These people don’t have emotion tied to specific use cases so they’re able to effectively manage costs and expectations as new use cases are requested.
• Put your productive work in a dedicated productive subaccount.
  We’re human, mistakes happen so do the needful to ensure your productive work is handled with special care in a dedicated subaccount.
• When in doubt, the 3-tier account model is tried and true.
  If your company does not have strict policies in place, keep it simple and establish a development, a testing, and a productive subaccount.
• Combining development and testing into one subaccount (a 2-tier account model) is acceptable.
  For example, if you’re doing application development work you could leverage the concept of spaces in the cloud foundry runtime to create a development space and a testing space within the same subaccount.
• If you’re using SAP BTP for an extensibility use case, I recommend you keep the same account model as the system you’re extending.
  For example, if you have S/4HANA on premise with a 3-tier account model, create a 3-tier subaccount model for your work.
• There is no single ‘right’ account model for everyone.
  You are reading this blog because you are empowered to make these decisions on behalf of your company. Do your homework and make an intentional decision with meaning behind why you’re running the way you are.
• There is no limit the number of subaccounts you can create but I caution you to create them with intention.
  Taking the time to plan in the beginning will set you off on the right path and ensure longer term success.
• The decisions you make today are not carved in stone and can be changed.
  SAP understands business needs and priorities evolve (sometimes faster then we’d like) and we created the SAP BTP cockpit with the tools and resources to allow you to adapt quickly and ensure business continuity.

I hope this blog series was helpful in laying the basic decisions that need to be made when you start your SAP BTP Onboarding journey. You’ll hear more from my team and I on this topic – we’re just scratching the surface. In the meantime, feel free to contact us by completing our request form, if you need help getting onboarding to SAP BTP.