SAP Cloud Platform Cockpit – Domain Model approach

As you are aware, the unified experience of SAP Cloud Platform cockpit has been well- received by the customers as it provides a multitude of enriching experiences as mentioned in the blog. As a prerequisite, I would also recommend you to glimpse through the step by step guide to the unified experience here. I have been receiving a lot of queries on the approaches towards creating subaccounts and spaces in case of the following Organization setup:

• Multiple teams working on different modules
• Teams from different regions working on different projects

I would like to take the above two use cases and provide the readers my view on the approach that could be taken towards creating subaccounts and spaces.

Most of you would have been already aware of some of the services and capabilities that SAP Cloud Platform offers to support the above use cases. To understand the below approaches, you must know about the following services and capabilities:

• Connectivity Destination services – Guide and Blog
• Entitlements – Guide
• CI CD best practice for deployment – Tutorial

Solving the use cases

These are very common use case where there are multiple teams working on applications in different modules like Finance, Inventory management, supply chain management, etc. Each of these teams would have their deployment and delivery strategy and wouldn’t want to share the entitlements across.

Some of the highlights to be noted in this use case:

• Individual landscapes for each of the teams: Development, QA and Production
• Clear demarcation of applications
• Entitlements to be kept isolated: This is mainly required to understand the consumption of resources by each of the modules
• Members to be siloed/isolated: The other module/project members shouldn’t gain access to the module that he/she is not responsible for
• Quota definition for each of the modules
• Connectivity/APIs differ for the landscapes
• Different identity providers for each of the landscapes

I am sure there are even more pointers that can be taken from such a demarcation. What stands out is the isolation with regards to the applications belonging to the modules and the landscapes.

Let’s break down the highlights/requirement one after the other:

1)    Deployment Landscapes:

The landscape consideration is very important for the modules to operate as well as follow the deployment strategy (viz. CICD). There would also be a case where the APIs/URLs used in each of these landscapes like Dev, QA and Prod might differ from each other.

2)    Isolated entitlements for landscapes:

Each of the landscapes would want to have clear entitlements that were already planned in advance. There could also be a case where the microservices in each of the modules interact with other services that are within the same module as well as other modules in the same landscape.

3)    Identity Provider variety:

The identity provider for each of the landscape might differ. A dev landscape would need to be connected to a local/dev-based identity authentication provider. You can also evaluate the SAP Identity Authentication Service and glimpse through my blog on the user identity management.

4)    User access:

You might want to not only isolate the users from each of the modules but also might have to quarantine from unwarranted access to production/QA landscapes.

It would be easier and maintainable to map each of the landscapes (/environments) to the subaccount. This way, you solve the requirements numbered 1, 3 and 4. Create one subaccount for each of the landscapes (Dev, QA and Prod) as shown below:

Note the subaccount facility that provides the luxury of identifying the services per landscape. Note that only the administrator of the Global Account would be able to create subaccounts.

Once the subaccounts are created, it will appear as in the screenshot above. You can sense the luxury of specifying the region and provider as well, while creating subaccounts.

This is particularly useful when there are teams working in different regions and each of them would be a subaccount in that case. The landscapes in those cases would be demarcated by spaces.

The destinations and the security tabs would be used to solve the requirements 1 and 3.

Once the cloud foundry is enabled for subaccounts, you would be able to create spaces and assign entitlements. At the Global Account level, you can assign the entitlements to each of the landscapes depending on your need and requirement.

Assign the necessary entitlements to each of the landscapes and save per assignment.

Start creating the spaces per module as shown below:

Navigate to the space and create members who are working on that module.

Note the Space developer added to the finance space.

Let’s look at how the newly added member would see the spaces. As soon as the user logs in, the user will see only the Global Account where the subaccount (Development Landscape) and Finance (space) are available.

As the user navigates to the space, the user will see only the space in which the user is a member.

This way, there is an isolation of module and visibility of modules to the individual members.

For those simple use cases where there is no region-based complexity and no module isolation, you can think of having the landscapes like Dev, QA and Prod as just spaces and refer the APIs with different destination services.

Hope you find this approach beneficial!!

Till the next . blog, ciao! 🙂