Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Mapping SAP to CSDM

Paul Santaniell
Tera Expert

Scott,

Excellent work on CSDM Whitepaper 2.0. Very timely and informative.

I'm looking at a couple options for mapping SAP ECC into the CSDM as follows:

  • Option 1 - SAP ECC Production is an Application Service, specific modules and/or key processes are Technical Service Offerings. Rationale:
    • Entry points are clear.
    • Only one service map for the infrastructure supporting and SAP instance.
    • Can map specific user groups/owners to the offerings.
  • Option 2 - The specific modules are Application Services. Concerns:
    • Not clear how to differentiate Entry Points. Aren't they all the same for the various modules?
    • Could lead to redundant service maps.
  • Others?

Would love to hear how others have done this and how well it works in practice.

Thanks,

Paul

 

1 ACCEPTED SOLUTION

CasperJT
Tera Guru

Hi Paul,

 

To be honest, I can only see this working with your ECC system as the Application Service. The ASCS, HANA/DB2 instances and servers are physical CI's whereas the system itself represents the comprised functionality of all those in combination.

If you treat each module like FI/CO or S&D as Application Services you will not only have a lot of data to maintain, but you would also need to maintain that across Dev, QA and Prod instances (assuming you have a three tier landscape).

I would also argue option A fits with the model presented in the initial whitepaper:

find_real_file.png

 

Hope this is helpful.

 

Best regards,

Casper

View solution in original post

3 REPLIES 3

CasperJT
Tera Guru

Hi Paul,

 

To be honest, I can only see this working with your ECC system as the Application Service. The ASCS, HANA/DB2 instances and servers are physical CI's whereas the system itself represents the comprised functionality of all those in combination.

If you treat each module like FI/CO or S&D as Application Services you will not only have a lot of data to maintain, but you would also need to maintain that across Dev, QA and Prod instances (assuming you have a three tier landscape).

I would also argue option A fits with the model presented in the initial whitepaper:

find_real_file.png

 

Hope this is helpful.

 

Best regards,

Casper

Casper,

Thanks, this makes sense to me and is very helpful. The example in Figure 6 had me somewhat confused as I was interpreting the Application Service i.e. "SAP Financials (Prod)" as a module, not as an instance. However, I think the correct interpretation is that this is the instance itself. The "Offerings" would cover the modules.

Paul

I am with you on that. The SAP Financials threw me off as well, but after seeing the ServiceNow version the context made more sense to me. There are companies that have a deidicated SAP Finance, while others have an ERP which contains most of the functions in one system.

I did also see a post (can't find it though), where someone suggested each ServiceNow module (Incident, Problem, Change) was treated like an Application Service, but to me that still brings in a lot of complexity and most likely considerable manual maintenance.

//Casper