Business Application versions

[Russell Abbott]

I have a story from the CMDB team to "Please change the Application Services table so that the Version syncs from the Business Applications table' I looked on the Business Applicatioins table and the 'Version' field is custom and was added by the ServiceNow deployment contract team that we used.

Am I correct however in thinking that this should not be done? That a Business Application should be the base application, and that the Application Service is an instance of that Business Application, and version? For example

Business Application >

Microsoft Outlook (no version should be listed)

Application Services >

Microsoft Outlook 2016

Microsoft Outlook 2019

etc..

[EricDohr]

Do you happen to have Application Portfolio Management (APM) entitlement?  If so, there is a table that is introduced, Application Service Software Models [sn_apm_tpm_service_software_model], which allows you to correlate one or many software models to one or many Application Services.  This allows you to pursue Technology Portfolio Management concepts where you can see what is the primary version on an environment, EOS/EOL risk, and build a plan.

If you create a model category for Business Applications, you can then correlate Application Models to the Business Application via the model id field.  The Application Model can have one or many software models underneath.  

As an example, let's say you had the Business Application of ServiceNow Platform with a corresponding Application Model linked via the model id reference field.  You could then have software models for Quebec, Rome, San Diego, Tokyo, Utah, etc. with the appropriate dates.   You could then correlate those software models via the Applicaiton Service Software Models table to then see TPM lifecylce. 

*mock dates for instructional purposes

[Russell Abbott]

@EricDohr  thanks for your reply. We don't have that entitlement, our CDSM, CMDB is not at that maturity level yet. For the sake of the Story I have, going forward, to ensure future compatibility with maturity, do you think it's good policy to have the u_version field on the Business Application table? Or should I be pointing them, for now, in the direction of storing version info on the Application Service table?

Thanks for the info and I'll be sure to read more about APM and Models

[EricDohr · Accepted solution]

@Russell Abbott In case my note caused confusion, you do not need to have APM to leverage Application Models and Software Models.  

Note, the Application Service records can also be related to Software Models via the model id field.  Make sure you set up model categories for the various Application Service classes as the population method differs.  

I am unable to answer your question.  Ultimately this depends on the persona and your process.  Things that would be key to consider

• Product Models include concepts such as Application Models and Software Models out of the box
• Application Models can be correlated to Business Application records via the model id field once a Model Category is created for the Business Application table
• Application Models can have lifecycles holistically
• Software Models can be created that roll up to Application Models
• Software Models can outline different versions and lifecycles
• You can associate an Application Service to a product model via the model id reference field
  • Make sure to create model categories for the different Application Service tables as there are different population methods
• A Business Application could have multiple software models in play in the environment.  For example, if ServiceNow Platform was an application model, you could have software models such as Rome, San Diego, Tokyo and Utah.   One environment could be using Tokyo and others still San Diego.