CSDM 5.0: Mapping between service instance and product model

[Stijn Verhulst1]

Hello everyone,

I have two questions related to the mapping between a service instance and (a) product model(s):

1. Is it correctly understood that a service instance would logically have one of the following relationships dependent on its architecture?
   
   
   • 1:1 with a software product model or software component product model? - Example: the service instance represents a ServiceNow instance.
     
     Which is the best product model type to use? CSDM states the software product model must be used for Software Asset Management (SAM) purposes and version-specific applications, while ServiceNow's Digital Product Release (DPR) uses the software component product model out-of-the-box for an application product model managed as a product in DPR?
     
     
   • 1:N with software and/or hardware product models - Example: the service instance represents an LDAP Server/LAMP stack/...
     
     
2. Must a service instance be related to (a) product model(s) if the Enterprise Architecture (EA) product is not used? I assume not because the tables that must be used to store the relationship are EA-specific?
   
   The tables:
   
   https://www.servicenow.com/docs/bundle/yokohama-application-portfolio-management/page/product/applic...
   
   https://www.servicenow.com/docs/bundle/yokohama-application-portfolio-management/page/product/applic...

[david_legrand]

Hi Stijn,

I'm not the most expert on Product Models but I'll try to give my views before gurus come in.

The target is to have a product model for every single CI. I have never achieved this, I don't know how to achieve this specially when the products aren't piece of software or piece of hardware but that's the target.

In theory, in my opinion, this is too time consuming but the idea is great. If the Service Instance is a SaaS/PaaS/aPaaS solution, such as ServiceNow it's rather easy. you should have at the minimum Business Application/Digital Product "ServiceNow Platform" linked to a Product Model "ServiceNow Xanadu" with its lifecycle being replaced by "ServiceNow Yokohama" with its lifecycle and so on. So when you upgrade PROD to Yokohama, you update the Business Application from product model Xanadu to Yokohama and when Xanadu is deprecated, you update the state.

Then you have the Service Instances, PROD/TEST/DEV/DEMO and so on, similarly after each upgrade, you update the product model on each Service Instance so you know that PROD is on Xanadu which will be deprecated on xx/xx while DEMO is already on Yokohama. Again, you can select the granularity level to have product model for each patch but that's an overkill in most situation (maybe some healthcare, aerospace, military companies need a full granularity). You can have the patch on the Service Instance "version" for example.

It's also possible to have sub-BA / Service Instance for each ServiceNow product Line / Application / ..., for example you want to know that Legal Service Delivery which is upgraded via Store App is in the release x.x.x on the Xanadu platform.

You mention which "product model" class to use, I believe (grain of salt here) that Software product model are for "applications" (cmdb_ci_appl) being installed somewhere (your premises or cloud) with licenses... while the Application Product Model should be more for this use case "Business App" layer. The Software component product model is at a lower layer for firmware and stuff.

Then you mention the Business Applications made of a stack. You still have one product model per CI, so you have a Business App / Product model "LDAP" with the servers and software beneath it with their own product models and the good thing would be to keep the Business App / Product Model at the top updated so the EA can decide if we want to invest or replace a legacy LDAP stack by Microsoft Entra ID for example.

I hope this helps a bit and that gurus will contradict/fine tune my explanation.

[Stijn Verhulst1]

Thank you @david_legrand! I truly appreciate the insight and it did help to clear up some blockers 🙂