Desktop Software as Business Applications: How to fit this into the CSDM?

Richard Lawson
Tera Expert

Desktop software is not usually considered a Business Application, but my question is, why not?  If a Business Application is defined as ‘A purchased or internally developed application used to support a business capability,’ this does not preclude its installation being on a local device as opposed to depending on multiple infrastructure configuration items such as web servers, servers, db instances, etc.  (For example, I might provide design services using AutoCAD installed on my laptop.)  The problem however is that in order to manage it using CSDM, I need an Application Service for it, and in order to create an operational Application Service, I need an entry point.  In effect, every device that the application is installed on can be an entry point, but the administrative overhead of managing every single device that an application or multiple applications are installed on is daunting.  So I was thinking that for all Business Applications that are installed locally, create an Application Service for each, and have all desktop software application services for all desktop Business Applications pointing to a single, generic manual entry point (I’ve chosen cmdb_ci_desktop_software as the CI class for the entry point but it can be something else).  [In the example below, I’ve also added ‘Desktop Software’ to the choice list for Architecture type on the Business Application form.]

 

RichardLawson_0-1682442213958.png

 

The advantage of this is that I have operational Application Services that I can open tasks against for roll-up reporting on the Business Application, and that I can associate with Business and Technical Services and Service Offerings.  I can also incorporate my Desktop Applications into my capability ratings.  One drawback however is that I cannot associate the applications with specific Hardware and Software product models for product lifecycle tracking with Technology Portfolio Management.

 

My questions are, is there anyone else out there doing something similar?  Does anyone else have a different way of handling these use cases that they can suggest?  And of course, does ServiceNow have plans in its roadmap in some future version of CSDM to take Desktop Software into account?

4 REPLIES 4

CMDB Whisperer
Mega Sage
Mega Sage

From where I sit, the answer to this question lies in the scope of your Enterprise Architecture practice.  If Enterprise Architecture has it in its radar, then it should be in your Business Applications, regardless of whether it is Desktop Software or Client-Server application.  And there is still value that comes from managing it as a Business Application even if you don't have any Application Services associated with it.  CSDM doesn't tell you that you must have an Application Service for every Business Application, per se (although there are metrics that measure whether you do).  It just specifies the relationship that Business Applications have with their deployed instances, i.e. Application Service "consumption."  To that end, while I can see the value in managing desktop software as Business Applications, I would limit it as follows: 1) only those applications which Enterprise Architecture has in its scope should be managed as business applications, and 2) if there isn't a network accessible, hosted application running somewhere to support this, then don't create Application Services, because that's either confusing or overkill or both.  That said, Microsoft Office software can be both Desktop and SaaS, and that makes a good case for managing it as a Business Application, regardless (even if we don't host the SaaS solution ourselves).

 

As for the case of submitting an incident, I would say if IT is supporting that application, then enter it as a Business Application, and use the related Business Application list to specify which desktop applications are being used, and use the Desktop itself as the CI, along with the appropriate Service/Offering, to ensure it is properly routed.  That will give you everything you need, without having to have Application Services to manage on top of this, which I think you will find is more of a square peg/round hole scenario.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Robin Chytil
Tera Contributor

Hi Richard and CMDB Whisperer,

I raised this topic 2 years ago and you could have a check at the discussions we had back then (CSDM 2 or 3).

https://www.servicenow.com/community/common-service-data-model-forum/when-applying-the-csdm-how-shou...

What you propose is what we have put in place at a customer site, where about 1000 desktop software are recorded. We however wanted the desktop software (and mobile software) to appear in the cmdb_ci_service_auto (App services) table, but to not mix them with the Application services = instances = systems, we created a custom child table u_application_software. We populated it with the desktop and mobile software used as business applications (not the plugins and utilities), linked to service offerings, so that they could be selected when recording an incident.

Example: 1C Enterprise Accounting (App SW) - used as accounting software (mandatory) in Russia.

 

Application software is version-independent. We linked each record to the Software models, which are version-dependent. But one thing we did not do and I think we should: to link the Application software to all instances of installations on PCs, using CMDB query and Dynamic CI groups.

 

And I do agree 100% with the CMDB Whisperer to focus only on the main Desktop applications, same as you focus on the main Business applications managed by the EA team.


Jim Zeigler1
Tera Expert

You can also populate Application Services using queries(using the Dynamic CI Group class). No Entry Points are required. Dynamic CI Group queries can be applied against any CI class or a DB View.

 

  • I would use an integration like SCCM to populate the CMDB with Computer CIs and update the software installations table(also used by SAMPro).
  • Then I would create a view that includes the Software Installation table and the Hardware table (match the "installed_on" attribute with the Hardware table sys_id).
    • The DB View can include any of the attributes from the Hardware and Software installations tables.
  • A Query or filter can be used to filter the records from the view that you want in your Application Service.

This probably doesn't need a DB view.  It could probably be done using a CMDB Query since those support non-CMDB related tables.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.