Let’s talk about Product Models. This is going to be a short intro to a bigger point.
The root table of all CMDB objects is naturally called CMDB. It contains 47 attributes, and one of them is Model ID. This is from where all CIs inherit their Product Model reference attribute. Imagine how important the Product Model concept seems to be for ServiceNow!
The Product Model is an object that manages the lifecycle of something (e.g. Application, Hardware). It also relates multiple logical elements like versions, Business Applications, Service Instances, and Model Components (think of applications that are components of a bigger application).
Product Models are vital for HAM and SAM.
Every CI is supposed to have a reference to a Product Model in its model_id attribute. That way the CMDB will keep information on what kind of hadware/software is used in the company, warranty, license, lifecycle, vendor information. It will allow grouping of CIs based on Model (quite helpful to estimate financial or security impact, for example)
As it is obvious already, this topic is vast so let me limit the scope of what is covered in this article: SPM and DPR usage of Product Models in the context of CSDM.
It is impossible, and frankly quite impractical, to cover all CIs from a UNIX hardware server to an accounting software as a single Product Model. So ServiceNow created multiple Product Models that are more suitable to specific objects.
Let’s focus on couple of these models. The Application Product Model is being created when you add an application/product in DevOps/DPR. It is what you refer to in your Agile Development under the Product attribute of epics, features, stories. It will also be created by ServiceNow Discovery when a new type of software has been discovered.
ServiceNow describes it as “version agnostic” which means it doesn’t carry version information. It is needed to keep some general characteristics of a product that don’t change with their version. Example would be the name or the vendor.
Since we are ignoring the version, we will need another object (yes, it’s another Product Model) to store that information – it’s the Software Component Model. This is a change compared to CSDM v4 where Application Product Model was linked to Software Model, now left manly for SAM.
Let’s briefly setup some products and their structure. Our top product is called Geekbooks. It contains few included products. We might want to release them in bulk or separate, but we’d like to keep their version information in the CMDB.
When set in tracking mode SPM will visualize the roadmap of the product by also displaying the percentage of completed work.
In DPR the Product will have its:
Status
Releases
Included Products
and Versions which in fact are Software Component Models. This Model is also used to link to the Service Instance that is running it thus closing the loop from Planning through Development to Deployment.
The above logical structure allows for depicting real life scenarios like which product is running in what environment, what are the components of the product, when where they released. It links the Epics, Features and Stories used to develop them, the test plans, code commits, the change requests used to deploy them (manually created and also triggered by CI/CD).
As Product roadmap is planned in its version agnostic form where the product is represented as an Application Product Model and then is developed and deployed as a specific version (each version is represented as a Software Component Model), it will reach the Operations world in the Service Instance. The model ID of the Service Instance is the Service Component Model representing the deployed version and is conveniently backlinking to the change and the release.
It is a good idea to trigger ServiceNow Discovery with the appropriate Change Request phase to validate the deployed version and automatically close the Change.
Understanding the Product Models and how they form the core of planning, both from strategic and product release sides can be vital to the success of ServiceNow implementation in these areas.
Writing this article made me think about other Product Model perspectives, like Life Cycle Stage and Life Cycle Stage Status and how they define the existence of a Product Model. I guess this sounds like a good topic for my next article.