When applying the CSDM, how should incidents be recorded against specific desktop software?

[Robin Chytil]

A customer of mine is migrating to the CSDM and started to create Application services in addition to Business and Technical services they have been using for 10+ years. The plan is to have Application services and Technical services with a Relationship to Business services (Service offerings will come later). For example:

• Business service: Library management (for managing borrowing of books)
• Applications services: Liberty - US, Liberty - Europe, Liberty [TEST]

The plan is going well for software installed on servers. But for software installed on PC, we are stuck on how to apply the CSDM, and more specifically how to record incidents.

The customer is not using ITOM neither Service mapping, but they create software models based on SCCM inventory. they currently have 1000+ software models.

Today, they log all incidents related to desktop software under the same Business service, called "Desktop software". They would like to create 4 Business services for R&D software portfolios, 1 for Finance software portfolio, 1 for HR software, etc. We plan to have 22 software portfolios, i.e. 22 Business services.

What solution can I propose them to be able to record an incident on a specific desktop software?

When using APM, a table exists to link Application services to software models (sn_apm_tpm_service_software_model). This requires APM, for which the customer has a few licenses. That could be a lead to propose a solution.

I considered therefore 3 solutions:

1. create one "Application service" per software model (the software model includes the version number, while the application service would not). This would however mean the creation and maintenance of 1000+ Application services. ==> Application service can be then easily referenced in an incident.
2. Create one "Application service" per "Business service", for all software used in a portfolio, and link this Application service to all software models (using the APM module). ==> But when logging an incident , I won't be able to use the sn_apm_tpm_service_software_model table to select on which specific software the incident occurred, as Software models are not CIs...
3. Use the same table (sn_apm_tpm_service_software_model) to link Business services and Software models? Seems not aligned with CSDM...

Any other solution to propose? 

Thanks

Robin

[bdubz7]

to me, this sounds like what service offering is meant for (and potentially the App Service for the underlying technology)

[Stig Brandt]

Hi Robin

Maybe consider this scenario

Desktop software -> Create Business Application and Software models!

CI -> Then i would consider using "software package" - cmdb_ci_spkg - for each software model, this gives you later on an inventory of all software installations.

Create Service (technical or business)  -> "Desktop Software"

Create Service Offerings for RD, HR, Finance etc. - use "subscribe to by user" - to track which user uses which desktop packages"

• 2 levels: service -> service offering of course, only if the sla and commitment is the same for all users using a desktop package

Consider to create cmdb_ci_group - for each software package and the create ci relation from service offering to group, that contains all software packages.

1: When user then create an incident from the portal:

Short description: "My outlook doesn't work", then you cn use PI to set:

- Affected CI is "software package" outlook

- service offering = Desktop software "Email"

- service is desktop software

2: When incident is created in standard inteface or workspace, consider having rules that sets/restrict the values based on caller - using subscribed by on service offering.

Best regards

Stig

[CasperJT]

To add on to Stig's comments here, you could consider following the TBM framework to model your services:

This will allow you to operate in a cross industry standardized setup.

Source: TBM Taxonomy v4.0 FINAL Documents

Best regards,

Casper

[Robin Chytil]

Thank you @CasperJT  for these documents. I am very familiar with TBM Taxonomy, I like it and use it as a reference to implement cost models at customers.

In your example, the business service is "Productivity" and we would like to be able to specify, in one way or another, when logging an incident, which software is at fault, in the "Configuration Item" field.

The same is true with business specific services which are delivered through a (big) set of desktop-based software and not through business applications installed on servers. This is the case for example for an R&D department that uses many scientific tools to acquire data from instruments, and analyse this data. We can have a "R&D Data acquisition" service, but this should be linked to the many tools they use. How can we log incidents properly (and easily) to be able to report on which software is having issues and act on them?

• Adding one application service per software does not seems a good option to us, as it will add 1000+ application services.
• the cmdb_ci_spkg table looked promising, but if is not updated once SAMPro is set up, it might be an issue. In addition, record in this table include the version of the software that we don't need.
• we are thinking of adding a class of CI "Desktop software" that we can create and maintain automatically, in sync with software models (but without the version number of software models).
• Or should we use another table, available OoB? How is the CSDM adapted to that use case?

Thanks all for sharing your thoughts. It really helps!

Robin