Looking for guidance on Structuring SAP - ETD (Enterprise Threat Detection) in CSDM

[12Fred24]

Hi everyone,

I’m currently setting up SAP - ETD (Enterprise Threat Detection), which is connected to several SAP applications, and I’m looking for the best way to structure it within Common Service Data Model (CSDM).

Here’s the setup I’m considering so far:

• Technical Service: Monitoring and Detection Services
• Technical Service Offering: SAP - ETD Service
• Application Service: SAP-ETD - Production

Does this structure align well with the CSDM taxonomy, or are there any adjustments you would suggest? I’m a bit unsure about how to organize the different layers to best follow the model’s recommended practices.

Thank you in advance for any advice or suggestions!

Fred

[12Fred24]

To add some details, my vision is that it is not useful, in my case, to create SAP-ETD as a Business Application.

Indeed, ETD will be connected to several SAP apps to get some information like threats, but won't be offer to our customers on our Portal it will be used only internally by the Support Team.

Am I right on this one ?

[Mathew Hillyard]

Hi @12Fred24,

If it is software then to complete the CSDM service view you need a Business Application connected to the Application Services for each SAP ETD environment (Dev/Test/Prod). The fact that it not offered to customers is fine - that is typically the nature of a Technical Service (indeed certain technology consumers may request access to a Technical Service when building out their own services). This is essential so that you have mapped out your application landscape and accurately document your business app inventory to understand your app technology position by category, technology, platform, business process, business capability etc.

If it is a standalone app then a Business Application on its own is fine, however if it is an app that is part of a wider platform (or indeed hosts other applications) then you need a Platform Host/Platform Application model in the Architecture type field on Business App, or related to a relevant Application family (SAP "something") - and you should also consider linking the SAP apps via App Service to App Service relationships (Sends data to::Receives data from). 

The setup you've proposed makes sense, however we generally don't include "Service" in the name of the Service Offering.