The Zurich release has arrived! Interested in new features and functionalities? Click here for more

CSDM/CMDB - How do you model & manage software versions for a Business Application?

sondrefaane
Tera Contributor

4 weeks ago

I have a Business Application (BA) that represents a program (let’s call it “ExampleApp”). There are many versions (e.g., 2022, 2023.1, 2024.x), and different users/projects run different versions across many devices. I’m looking for a simple, mostly OOTB way to version this software and tie the pieces together.

What I need (management/overview only):

  • Declare “current version” for the BA.

  • Mark older versions as deprecated/retired.

  • See all versions of the product in one place and who/what is on which version.

  • No mass CI edits and no forced upgrades—just governance/visibility.

  • Prefer OOTB (Xanadu/Yokohama), no paid add-ons.

Questions:

  1. Where should “version truth” live—Product/Software Models vs CIs vs Application Services?

  2. How do you tie it together: BA ↔ product model ↔ version models ↔ installs (software packages)?

  3. Best OOTB way to get a central overview (reports, Query Builder, related lists)?

  4. How to record exceptions (e.g., Project #31 stays on 2022) without touching every CI?

  5. Any gotchas/patterns to avoid (e.g., using service status as a version flag, free-text version fields, etc.)?

If you have a clean pattern that works well in practice, I’d love a brief outline of tables/fields/relationships and how you surface the “current version” to stakeholders.

  • 310 Views
1 REPLY 1

Mathew Hillyard
Mega Sage

3 weeks ago

Hi @sondrefaane 

This is a good question. ServiceNow defines the Application Product Model as the version-agnostic representation of the application, which would lead you to believe the Business Application should contain a version. However it's not an operational CI and that would quickly lead to Business App inventory bloat and unmanageable structures. In addition there is no "Version" field on the Business App table.

 

At the lower level typically the Version is captured within SAM, so at the Software Product Model level (Publisher, Product, Version, Edition). This would be linked to an Application CI, which connects to an Application Service (Service Instance in v5) which connects to the Business Application.

 

However, the App Service should represent an instance of the deployed stack referenced by the Business App, so it doesn't make sense either to capture this at the Application CI level. It seems unworkable to have two different versions of the same App being part of the same App Service. You would logically put them into separate App Services.

 

Therefore the most logic place to record the Version of the Business App is in the App Service/Service Instance - then you have a single visible line of sight between a Business App and all versions and environments it is deployed upon. The "Version" field is also OOTB and is populated with the demo data in my PDI, so it seems to verify this is the right location (see attached screenshot below).

Service Instances.png

 

 

As always, ask ten architects for an opinion and you'll get twelve opinions, so other people may have a different view 🙂

 

I hope this helps!

Mat