PC software in the CSDM

[CasperJT]

Hi all,

While reviewing the CSDM White Paper and related papers / videos, something seemed to missing or perhaps just not explicit enough for my understandning.

Let's take a simple example such as Outlook 2016. This is a piece of software that is typically installed on a white collar employees PC's.

My question is, is this considered an application? since it is a deployed piece of software on a compute infrastructure.

If it is an application, how does this fit in the data model/should it fit in the data model.
If it should, is it then part of an Application Service called 'White Collar Laptop'?

I hope the question makes sense.

Thanks,
Casper

[natedickson2]

At my previous employer we decided to add all software to the Business Applications list. We started going down the path of a complicated if/then workflow to determine where it should live but decided it was simpler just to say all unique applications should be listed there.

We used one of the fields such as architecture type to identify it was desktop software.

We did this for a few reasons:

1. We wanted a single location for all Authorized / Unauthorized applications & software
2. We still had financial investments even in desktop software such as support and licensing
3. There still could be duplicate capabilities being provided so it feeds into Application Rationalization
4. We still wanted to document owners of these applications
5. These applications still could have vulnerabilities or security risks against them so we wanted owners to hold accountable in those situations and someone who could talk to the licensing and overall ownership
6. Even for desktop software there was often a need for understanding the technology roadmap such as migration plan from Outlook 2013 to 2016.

In most cases we would create 1 Application Service for a "Global Production Deployment" of that application or software package. Even basic desktop software could be supporting a critical business process so we wanted to be able to track criticality, ownership, and support at the Operational level

This way it could be represented in ITSM processes like incident tickets and change requests and we'd also have the right level of approvals, awareness, and support group assignment.

Nate

[Stig Brandt1]

Would you create O365 in the table or all the specific modules (Word, ppt, outlook etc.)?

[natedickson2]

We had the primary O365 suite which consisted of the basics like Access, Word, PPT, OneNote, Outlook and then we had individual entries for Visio, Project which was mostly driven by licensing models.

Even with the O365 level you can still map out all the Software Models and their versions within the TPM capabilities of APM so you can understand version levels.

I would say start simple and then if you run into a use case to break them apart more you can do that as needed. You also don't need to manage all Business Applications with the same level of detail, you might decide you don't need as many fields populated for Desktop Software, or you might have IT and Non-IT supported applications. You still want to document them but you might not manage them with the same rigor within APM from a data or certification perspective.

Nate

[melissahill]

Hi Nate,

It sounds like your organization is not using Software Models, as some of what you are describing could/should be done at the software model level.  Is that correct?

One of the considerations I really like is the duplicate capabilities.  Even with the use of software models, you would not be able to properly assess capability overlap.

Thanks!

Melissa

[natedickson2]

Hey Melissa,

We used both. We used Software Models for the Technology Portfolio Management capabilities within Application Portfolio Management. We also used them with client software distribution to post to the service catalog and install software.

The Business Application level would represent the owners, financials, etc... We used the "Software Model" reference field to link to the software model that was the current approved standard version of the production.

The Software Model level displayed the actual software products and their lifecycles.

Example:

• Microsoft Access - Business Application
• • Access 2016 would be the Software Model referenced on the Business Application record to show it's the approved standard version
  • This level has the high level Technology and Business owner - Why do we need access and what does it do? Who builds the roadmap?
  • We can rollup any license, application support, software maintenance costs, etc.. at this level
• Microsoft Access (PROD) - Application Service
• • For standalone client software we had 1 production Service representation to show it was deployed in the environment for ITSM processes to reference for application support groups, service operations owner, etc..
• Software Models - Versioning data and lifecycle information such as end of life, end of support, GA. Each of these models would be linked to any application services still using that version. This level also links to actual installations to see where it's deployed and user counts.
• • Access 2003 - N-5 based on "Next Model) We had some legacy applications that had to use 2003 and couldn't move past
  • Access 2007 - N-4 Same as above
  • Access 2010 - N-3 Completed removed from the environment and retired
  • Access 2013 - N-2 Marked pending retirement as upgrades occur
  • Access 2016 - N-1 Standard approved version of the application as referenced on the Business Application record
  • Access 2019 - N Evaluating this model

Unfortunately we didn't have SAMPro so all this detail was manually entered including lifecycle dates but it was maintained in spreadsheets previously so not much net new work.

Nate