SAP Cloud Platform Architecture

[sheoshankarchoudhary]

Introduction: In this Blog I am going to discuss on one of the way through which a company can define it's SCP landscape architecture in SAP Cloud and it will help them to follow proper maintenance strategies too.

 

Assumption: I am assuming that people reading this blog has some understanding about the architectural design, which other cloud providers like AWS, GCP, Azure or Oracle are following (At least the VPC and Subnet design part).

 

SCP Architecture: Once a subscription is bought from SAP the customer is getting a Global Account based on it's Preferred Region of the world.

For all the customer who is already using Cloud or has the strategy for moving the ERP Landscape to cloud, defining or selecting a region is equally important and accordingly SAP customers has to select the region for there Global account. This will help in lowering the latency during the latter part when the System migrated to Cloud.

 

There is a similarity if we compare the architecture of SCP with Cloud Providers and the similarity which I find is as follows:

 

1. SCP Global Account->Cloud Provider (AWS/GCP/AZURE) Subscription


2. SCP Region->Cloud Provider (AWS/GCP/AZURE) Region of Server Provisioning and VPC (We can take the Region as VPC as well)


3. SCP Subaccount-> Subnets in Cloud Provider (AWS/GCP/AZURE)

 

Note: The above points are just an assumption for your understanding so that one can easily correlate the Cloud and SCP architecture.

Before one can proceed with SCP Landscape architecture one has to maintain a template through which Business requirement can be gathered and accordingly resources are aligned in SCP. One such decision making flowchart is as follows:

 

 

 

The above flow chart will be more clear if you see one of the many options for the SCP landscape architecture design which is as follows:

 

 

Maintaining budget and costing across different projects in an organization is the most critical work and one can simplify this by choosing right strategy of defining quota as per the Budget of the project. In the above diagram it is the responsibility of the administrator to get all the detail about the Resource requirement (like CPU, RAM, SAAS or PAAS instances) and accordingly define the Quota and get it attached to the Project which is represented by the SPACE in the above diagram.

 

The maintenance/testing strategy will be defined by the Application team. If there is a need for transport path to setup then it has to be done according to the diagram shown above.

 

SCP Integration with AWS ERP Landscape:  Here the following diagram is just for your reference to get a glimpse on who SCP is getting connected with once (AWS) Cloud account:

 

 

The Below diagram talks about how SCP SAP HANA Service is integrated with DataLake service of AWS cloud provider:

 

 

 

Conclusion: I have tried to incorporate the designing and integration strategy together in this blog. If you have any query then please feel free to reach me by asking questions.

 

 

[former_member45421]

Isn't it a better option if I have Subaccounts at the Business verticals level, example:

Subaccount 1 - Procurement team

Subaccount 2 - Finance team

 

and within each Subaccount, I can have SPACES: Dev, QA, Prod.

The way I see it, the benefit would be that Destinations, Quota etc are at the subaccount level.

 

[gregorw]

Dear Rajesh,

no, using Spaces for Dev, QA and Production isn't a good option as destinations can only be defined on a subaccount level. And when you would use spaces to separate Dev, QA and Production all destinations must be defined with different names i.e. S4_DEV, S4_QA, S4_PROD. So when you then develop an app in the dev space and want to deploy to QA or Production you have to adjust the name. If you use separate sub-accounts for Dev, QA and Production you can create destinations with the same same name i.e. S4 in all subaccounts. But this destination connects to the corresponding S/4HANA backend system. That way you can deploy the app from Dev to QA and Production without any additional changes.

Best regards
Gregor

[gregorw]

Dear Sheo,

in one of the diagrams you mention "SAP Cloud Connector (Installed on all SAP Application Servers which need connection to SCP)". I would not suggest to install the Cloud Connector directly on the Application Server. I suggest my customers a separate VM and at least two Cloud Connectors. One for all Dev + QA Systems and one for Production. If you setup a failover solution you need to set it up for both connectors to have the same settings in Dev/QA as well as in Production.

Best regards
Gregor

[former_member363931]

I tend to agree with your recommendation, yet not fully with the reasoning. If it was only about destinations one might argue that you could define them at service instance level and therefore use the same destination name in different spaces.

Best regards,

Tobias

[sheoshankarchoudhary]

Hi George,

If you see the architecture it is talking about the Subnets and not the actual Application Servers. The main purpose of this diagram is to show the data flow direction and not the detailed architecture. Detailed architecture can be incorporated but that will dilute the purpose of this blog, and apart from this the detailed architecture would be different for different cloud service providers (AWS, GCP, AZURE etc..).

 

Hope I have given answer to your query.

 

Best regards,

sheo

 

[sheoshankarchoudhary]

Thanks for giving this insight view.

[sheoshankarchoudhary]

I also agree with you as different customers might have different subscription requirement. If we have a customer who only need subscriptions for SAP provided SAAS or PAAS then absolutely he can explore new design. This is the reason I have written in my blog that it is just one of the many options we can choose while designing our SCP landscape.

Best regards,

sheo

 

[gregorw]

Hi Sheo,

I still would suggest to adjust the comment.

Best regards
Gregor

[sheoshankarchoudhary]

Thanks for pointing me on this Cloud Connector part. I will incorporate the changes very soon. Please let me know if you see any more flaw in this blog.

 

Best regards,

sheo

 

[rogerloe]

Hi Sheo

Please can you clarify why you have placed the AWS Data Lake components inside the SAP Cloud Platform - should this not be in their own VPC's in AWS Cloud

 

Regards

Roger