Skip to Content

Understanding Accounts within HCP


In recent months, as more and more organisations are taking an interest in the broad capabilities of SAP HANA Cloud Platform, I’ve noticed an increase in people moving from the free trial accounts to licensed, productive accounts.  This is great news for SAP, the HCP community and the world of SAP generally as we see the platform and its adoption mature and grow.  The increasing number and range of complex topics covered in blog posts in this SCN space alone are testament to some of the really cool stuff that is being built.

I’m also noticing an increasing number of questions as well as having a lot of discussions online and IRL, around some of the basic topics that users of the trial landscape won’t have faced whilst using their free accounts.  One area that seems to rear its head more often than others is how the general landscape and architecture of HCP works in relation to on premise systems – understanding how accounts work on HCP is fundamental to getting your build and operate model correct.

What’s Changed?

In a cloud world, the tangible & physical servers (ok, and virtual hosts) that we are all used to disappear from our grasp, as SAP owns, runs and manages the infrastructure for HCP.  Instead of servers or instances, we work with accounts.  With productive HCP, we get access to a global account that has all of the services and capabilities that we have licensed available.  This quickly leads to the most common questions I get asked:

  • How do we set up our landscape to work with our on-premise DEV, QA & Prod systems?
  • How many accounts can we have?
  • How many do we need?

In the old on premise days, the answer to this is pretty straight forward (in terms of design at least) in that we create an instance per tier.  So if we want a pretty standard development, quality & production setup, we create 3 instances (forgive the massive over-simplification for the benefit of this post.)  Most people in the SAP space will expect a similar 3 tier landscape when working with cloud solutions too.

Let’s quickly look at the 3 questions above and get a simple & concise answer within the context of cloud, PaaS and specifically HCP.

What does a HCP landscape look like?

As mentioned, when you invest in a production HCP account you essentially end up with a single account.  I recommend you use this for two things:

  1. It is the tangible representation of your contract with SAP
    You will use it as the main container for any support interactions with SAP as well as the main point to manage how you assign the resources you are paying for
  2. It is a logical representation of your HCP landscape
    Consider an on-premise solution where you have a server room with your three DEV, QA & PROD servers sited – consider your global HCP account as the cloud version of this

With this in mind, no doubt you are wondering how you create the cloud version of your DEV, QA & PROD servers?  HCP has this covered with the concept of sub-accounts.  Your main, global account can be used to create as many sub-accounts as you need.  So logically, you would create 3 sub-accounts to represent your 3 tiers.  You would end up with something like this:

HCP Accounts 1.jpg

As a slight segue, here we see a massive showcase of the power of cloud – back with our physical server room if we wanted to add another instance, say for regression testing, we’d face the usual lead times and delays associated with acquiring hardware and installing operating systems and software.  Not so with HCP.  A simple click of a button from the HCP Cockpit and a further account is spun up and available in seconds.

I’ve highlighted below just how simple this is:

HCP Accounts 2.jpg

Here I’m showing a productive HCP account that has 4 sub-accounts created, each representing a different instance in a landscape.

It is important to remember that each sub-account is completely separate and independent from all others against your global account.  This will be important when you begin to consider security, user management, data migration & management, integration and various other topics as you build up your HCP landscape and overall architecture.

How many accounts should I have / do I need?

If we stick with the normal 3 tier landscape then the simple recommendation is to create 3 accounts as above.  However due to the power and flexibility of HCP, you don’t have to think in such formal ways.  As you are completely in control of your own accounts, you can choose to have as many or as few accounts as you need.  Often, the complexity of your landscape will be driven primarily by your individual use case.

Many of the cloud products and platforms I’ve worked with in recent years work with a simple Sandbox & Production, 2 tier landscape:

HCP Accounts 3.jpg

If you are simply working on a single custom application using HCP and maybe only have simple integration requirements, this could well be enough for you and your team.

At the other end of the complexity scale, you may well have a landscape that needs to support the following scenarios:

  • HCP acting as an extension platform for your on premise S/4 HANA landscape, which has 4 tiers (DEV, QA, IST & PROD)
  • HCP enabling the development of 2 custom app’s that you are selling through the SAP App Center
  • HCP supporting an extension against your 2 C4C tenants (SANDBOX & PROD)

In this scenario, you have a couple of options. Let’s assume your 3 scenarios are all independent so we can create essentially 3 landscapes within your main global account:

HCP Accounts 4.jpg

You now have a total of 9 sub-accounts sat within your global account.  If we had decided to create a separate “landscape” for the two custom apps we would end up with a further 3 sub-accounts in our overall account structure.

Some Further Considerations

Hopefully it will be clear that you are in complete control of what your HCP landscape and account model looks like.  This, in my opinion, is an area open for some improvement from SAP with respect to how the HCP accounts are represented within the cockpit.  For instance, in the complex scenario above, there isn’t anything obvious (other than the account name) that points out to the user what type of account each is – other than the person who defines these accounts, how do other users know which are the production accounts, which are dev, etc.  I’d like to see some way of tagging or indicating this sort of information in the HCP cockpit – maybe SAP will implement some way for users to add custom tags against accounts, so that it becomes easier to identify and group different sub-accounts?


Very quickly you can setup and manage your HCP landscape to ensure it represents and enables the complexity and flexibility you need for your own scenarios.  Very likely, you will move from the simple 2 tier landscape to a more complex one over time.  Again, this is where we see the power of cloud supporting rapid agility.

The next thing to consider once you have your landscape modelled is how to assign and deploy resources across the landscape to support your development and runtime needs.  This depends on the target runtime and the scenario being deployed, and warrants a blog post all of it’s own…

Update 13.09.2016 – I changed the images as the originals were shockingly bad in all grey and really annoying me!

You must be Logged on to comment or reply to a post.
  • Hi Gareth,

    This is very good information especially for someone coming from a on-premise world. Thanks for posting this. Looking forward to your resources blog as that's where more fun starts - Pankaj

  • Hi Gareth,

    Great overview. This is one the more complex things to understand when dealing with SAP HANA Cloud Platform and maybe not well explained in the help documentation.

    However it is worth mentioning that with setting up the tiers you are also dependent on your available compute units in your account. When dealing with a Java application (I noticed your screenshot contains one as well) or underlying HANA database you can be limited by your licenses and not able to setup a "real" 3-tier. For HTML5 only apps it's a great option. Thanks for sharing.



    • Thanks Leo,

      All good points - I'm working on a follow up post (or two) to get into the details of resource allocation, to try and get to a picture of a fully working landscape.


    • One way to "save" on compute is to use the subscription concept. For e.g. have a single Productive account for all Java apps and then subscribe from that account. There could be challenges ofcourse in terms of destination, etc but this is one way we have found to overcome the limitation.

      • Hi Chris,

        It was mainly because of the compute units available for Java apps. With a Pro Quota of 2 only 2 accounts could serve a Java app. Have to admit this was almost 1 year ago. So not sure if the subscription concept was already available at time. I will have a look into this again now for future purpose. Thanks for the link!



  • Great Blog Gareth!!! Reflects what we are practicing as a partner with several products and each product has several customers.

    We are using subscription concept heavily and one challenge that comes up is that if we update one central account, all subscribed accounts - QA or PRD get affected. In clud world, we cant have multiple code base on subscription as that defeats the purpose of a cloud deployment. Would be good to know your perspective if you have any experience and suggestions. Look forward to your next set of blogs.



    • I'd suggest that you look to what SAP does in this instance - SAP SuccessFactors have two sets of servers - Preview and Production - for each region. Customers can subscribe to the one they want (generally Test to Preview and Prod to Prod). Offer different uptime for preview. you'll want to push changes to customer's QA environments before you push it to their prod environments.

      I have 3 tier - Dev (no customers connected), QA/Test and Prod



      • With subscription there is no "push", it gets inherited automatically in each tenant. The cloud model implies that customers should be ready to test quickly and move to PRD. We cannot have traditional methodologies and timeframes  - for e.g. some customers follow quarterly cycle whereas cloud might be updated monthly or even fortnightly.

        Second aspect is extensions done to standard code. For e.g. new screens / validations which might get affected due to the change. This also needs to be tested thoroughly / adapted if required.

        The other aspect which we should not forget is about transports for on-prem systems. For e.g. changes to ABAP RFCs / Odata services.

        Its a new perspective and need to learn and adopt on both sides - ISVs and Customers. For simpler apps, i think agility might not be a challenge.



  • Great article.

    From the account management point of view. Will the administrator of the global account has visibility to all sub accounts created?

    I notice that user will not able to see other sub account created by other user if he/she is not a member of that account.

  • Hi Gareth,

    thanks for the great article.

    Just one question regarding the Subaccounts of a global Account, can these be Accounts belonging to our customers?

    Lets say we as a SAP Partner want to host applications for different customers and connect the subaccounts to the respective customer cloud connectors.

    Would that be a valid scenario?




  • Hey experts! I hope you are fine!

    I need a help. Can you help me?


    I'm trying to create a java application (eclipse neon) to be able to test my sap cloud connector (RFC) connection and the following error was reported:

    "Unable to start application scctest: Cannot start application 'scctest'; there is no compute unit quota for account 'xxx'.
    What are these QUOTAS about? How can I proceed to minimize my mistake?




  • HI Gareth,

    First thank you for such a great blog. I have one question like if we have dev, qty and prod sub account but what about HANA DB. We have one HANA DB for our main global account. Need to divide this into dev , qty and production DBaaS and linked to the respective account