Best practice on creating Software Models

[Jason Brough2]

QQ.. What do people generally do when it comes to creating software models? Do you create them automatically as part of entitlement imports, or do you create them manually and link them to entitlement data and discovery models?

Thanks..

[Jaspal Singh]

Well it depends on business case altogether. All engagements I have worked on for this I have recommended them to create it manually & then relate it as each business might have different contracts so better to avoid getting it created automatically by property. This then helps control what is being inserted & updated in system.

Well, if there are many models to be worked with then property approach should be fine.

[Jason Brough2]

Thanks Jaspal. So do you mean it depends on the volume of contracts (entitlements) and models? Is there a general rule of thumb?

[Brian Collins1]

In my opinion, the best way to create Software Models is to let them be created when you enter the entitlement data using a PPN.  The system will automatically create the models for you and fill out the Discovery Map to map to the Discovery models.

Of course, there is no 100% right or wrong answer here.  But I find the data is cleanest when the models are created using the PPN data in the content library.

[Joe Ryder]

Hi Jason. It's not super prescriptive when you create a software model, especially when the content service is turned on (if you haven't done that yet, it's highly recommended). Here are the standards I've put in place for my colleagues:

When we DON'T manually create a Software Model when it's missing:

• When we want ServiceNow to add the PPN to the content service (usually done through HI ticket request).
• When there is an appropriate catch-all software model already in the model table and we don't need granularity to version numbers or sub-editions (with new models comes new maintenance of those models).
• When we determine that a unique software model has no value in our SAM workstream (i.e. a consumable product that is low-dollar, has no compliance issue, and is not tracked over time; this may become necessary later).

When we DO manually create a Software Model when it's missing:

• Where there is internal criteria that separates a given entitlement from the rest of the general entitlements. Examples:
• an attribute of a device CI or a user profile (depending on the license metric) indicates this software model, vs others, should be used (tag, Company/Department, or something else)
• we want to internally separate tracking and requests to a specific OS, even if the entitlement allows for multiple OSes
• The PPN that is used during the purchase is not public, which means it will not be added to the Content Service, and it may change over time, meaning continuity between entitlements may be problematic. This commonly happens with resellers who do not use manufacturer part numbers or create custom packages under a Special Pricing Agreement (SPA).
• The software publisher has no PPNs (usually a SaaS provider who does not SKU their products in their buy book). in this case, we are unlikely to get the Content Service to add anything, so we create a specific product and model that makes sense for the product as it gets ingested during Entitlement uploads (using product/publisher/version/edition/language criteria instead of PPN).

We do not then create custom Discovery Models and DMAPs immediately. If the MID server or other discovery method doesn't create a DMAP>DM>SM relationship automatically, we look for how the install is captured and adjust the current DM>SM relationship and criteria to "direct the traffic". If no installs are captured (SaaS with no connector) or if adjusting current criteria is not working, we then look at custom discovery components.

Rule of thumb: Never create a software model just because it doesn't exist. Mindfully consider if there should be an update to the content service; this ensures the model is maintained by ServiceNow and is more likely to be accurate through normalization between customers using the same PPN. Custom Software Models should be a last resort and should serve an internal purpose.