Ask Yourself…
Let’s ask you a questions to see if there’s an issue:
Question for those with BTP multi-tier prod/non-prod landscape already
Do you protect your platform users with multi-factor authentication? If not – you are one username/password away from potentially great damage. If you do – you are likely a good candidate to help me here and propose recommended changes to this blog post in the comments!
Question for those without this
Do you know how your Global Accounts and Subaccounts should be set-up and what a minimum landscape should look like? If not, you will likely get an opinionated design of whatever the first consulting group sets up, for better or worse.
Sorting Out the Basics
This is all simply solved, but I feel everyone is in such a rush to get value out of BTP products, that it’s easy to skip over some basic questions to sort out what you truly need.
My initial thought was – Surely someone can just post about this so I posted on x.com the following:
The Request for BTP Basic Set-Up Info
But I quickly realised that either some think of this as Intellectual Property, or that more likely, people are way too busy to put their learnings down in a post.
So guided by a few responses on X, and a few discussions; I decided to put down my thoughts on the steps to get a solid but basic landscape foundation in place, including pointing at the training material that should hopefully get you set-up in no time. The only caveat – The first step to setting up this requires you to have Global Account access and discussions with SAP from a licensing perspective which grinds me to a halt in actually setting this up; so fingers crossed, I get the theoretical steps below correct!
Global Accounts
Unfortunately, Global Accounts are somewhat like Installations in the SAP world. You would think a Global Account is the single entry point for all your sub accounts but that is not necessarily true.
So you may have purchased WebIDE in the past or another cloud platform product. It is most likely that each of these get their own Global Account.
Then there is the real BTP AWS Usage style account you want which is called the CPEA Global Account.
The CPEA Global Account is the one with the power to create Subaccounts, consume your subscriptions//instances, etc.
Now apparently, there is a hybrid way of setting this up, so I’d suggest looking into this, as personally, I would want a single Global Account so I can set up my Subaccounts and manage cloud admins easily (full visibility of everything). Speak to your account exec to discuss the possibilities (I’m guessing it’s hard to do so maybe something SAP try to avoid as otherwise, it seems like an obvious first step).
Final step here – Get access to the Global Account as otherwise, there’s not much to see here.
Subaccounts
I was pointed towards the SAP HANA Academy on Youtube for this and this was awesome (Please note – this link will stop working by the end of the year and you’ll need to search in the SAP Learning hub). Boosters may be useful here, but not necessary for the basics really if you want to learn a bit more how it all hangs together for your first few Subaccounts.
In short, it talks about Directories and Subaccounts better than I could, so let me focus on the Hyperscalers and layout that I expect is a good start point.
So SAP seem to be paying for infra on your behalf here, so unless your company has a big preference, I’d probably stick with AWS Cloud Foundry instances in your appropriate region (checking your company’s data at rest and transit policies) since AWS seems to have all services available – though there are probably nuances here that would be good to get feedback on in the comments (I’ll update this section if so).
Anyway, let’s talk name and number of Subaccounts:
I’m going to go with the RISE with SAP non-production landscape set-up as a default first.
e.g. Dev, QAS and Production
Side note – We’re dealing with Cloud Computing, so standing up and down additional non-prod landscapes is straightforward!
The majority of services that make sense in that aspect should be added. I’m thinking that these Subaccounts should mostly be identical.
But wait, there’s more:
Your first Subaccount should probably be a “Services” Subaccount. This is to hold your Identity Service (IAS) (non-prod and prod) instances and any other ALM or similar related services (though from memory, you might need to contact SAP to arrange specific naming and assignment – I’d reach out to SAP with your desire to set the solution up right and see what they say). Note – if you are subscribed to SuccessFactors, I believe you get a prod and non-prod IAS available to be used included (at least a prod version for sure).
BTW – I would have hoped that BAS could sit on this Services Subaccount, but you might need to make things a little peculiar and put this on your Dev Subaccount for access to the Dev Space (see below) and to access your on-prem dev systems via Cloud Connector (see below).
Other Subaccounts you may want to consider in the future:
- A HANA Cloud instance with multiple tenants – Basically to avoid paying for 3 depending on usage
- A specific usage set of tenants (for example, to handle different security aspects (e.g. External Facing).
Realistically, a good start point is to set up Dev, QAS, Prod and Services as a default.
Note – Having the ability to set-up a Playpen Subaccount on demand to try out new offerings, could be a reasonable idea to keep your main Subaccounts clean too…
Spaces
Not really a requirement at this stage (and a Dev, QAS, Prod Subaccount means you probably only need 1 “dev” space in Dev, QS and Prod Subaccounts initially and note – Dev here means – “your stuff” – thanks to Mustafa for getting me to clarify this in his comment below), but I will come back to this post in the future and update my thoughts around app boundaries, isolation,etc; and when you should stray away from 1 Space per Landscape Subaccount.
BTP Identity Services (I know it as IAS as Authentication used to be in there too)
So this is the most important part to get right. This is the glue to give people a seamless authentication experience across the landscape. Plus it helps your developers/admin manage user access across different BTP (and just as importantly, other SAP Cloud products) much more centrally.
There are 2 parts to get right:
- Setting up connectivity for Business Users using your own SAML2 solution like Microsoft Azure AD (now known as Entra ID)
- Locking down Platform Users (like S-ID’s) with some level of MFA
For Part 1: If you have Azure AD for your corporation set-up with good MFA access controls, then this set-up has been documented well in this video (shows all aspects since usually MS Azure access is not give to SAP Administrators) – It’s worth understanding how SAML2 actually works, but this video doesn’t even require you to do that. Not much else to add here at this point – Job done
For Part 2: There is the ability to start adding additional requirements for platform users. It might be as simple as using specific IP address ranges as trusted (which is at least something), but you can also set-up your Authenticator app in here too which I’d recommend as a better start point. I’ve set it up in the past to access the IAS instance, and unfortunately, I’m just assuming we can get this in place for all BTP related and IAS connected solutions. The set-up is pretty straightforward, but it is at this point, you do start to worry about locking yourself out of the system (though seems very straightforward).
SAP Cloud Connector
This is a fundamental piece for the On-Premise world connecting to BTP. Like the rest of BTP, it’s really easy to set-up but in fact, can be quite dangerous if not set-up appropriately.
I won’t go into detail about it here except to highlight the following:
- Not a bad idea to set it up to use authentication against your AD/LDAP and AD Groups (so you can use Identity Management for access
- Good idea to have non-prod and prod for this
- Consider redundancy as BTP becomes more critical in your business
- Deliberately expose only what you need
- This application, while small and straightforward, gets patched frequently, I assume mainly for cyber security reasons, so be prepared to manage that. It’s easy but will be a critical part and might be tricky if you don’t have an outage window due to criticality of BTP solutions in place – e.g. Customer facing interfaces.
- Don’t forget about it or have only 1 person who knows about and has access to it!
- A feature of the Dev, QAS, Prod Subaccount is that you want to have Production Cloud Connector connected to your Prod Account, and not Dev and QAS; as otherwise your Dev clients would also have access to Production and yeah – We don’t want that…
Next Step Complexities to Consider
While the next steps for something like SAP Build should be straightforward with the above – I have to deal with SuccessFactors tenants not using IAS and how to convert them; or SAC on NEO and how to get principal propagation working for things like SuccessFactor Story Reports; plus general conversion from NEO to CF – but this is where your friendly consultants come into play. I just want to make sure the basics are set-up to begin with, so hopefully the above is a good template for us to run with.
Agree/Disagree???
Please comment in this post everything I’ve gotten wrong (or right) or any intricacies/recommendations you can detail – This is your chance to sell yourself and your company here as an experienced BTP architect/hands on administrator which will win you future work – The stuff above – It’s just the basic friction that every customer should be past before you are even engaged in my opinion – otherwise you get people like me delaying you from starting as I want to be sure that BTP (and on-premise connected systems are protected, structured well and will accommodate where we might end up in the future!