- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 09:35 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 10:58 PM
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:
Hope this is helpful.
Best regards,
Casper
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2019 10:58 PM
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:
Hope this is helpful.
Best regards,
Casper
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2019 03:48 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2019 11:10 PM
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