This is the final post in this series on Model Management. Previous posts are available here:
- Role Model, or Why Model Management is Important
- Models vs. Model Categories: Model Management, Part 2
- What's in a Name?: Model Management Part 3
- Which Model Is Which?: Model Management Part 4
- What Is Normal?: Model Management Part 5
- Model the Service Catalog: Model Management Part 6
- Field Day: Model Management Part 7
- Model extension: Model Management Part 8
Throughout the series, most of the focus has been on Hardware Models, but there are other Models to manage. The most common (and arguably one of the most important) is Software Model. Software Models are a lot different than the Hardware variety with respect to how you manage them, though:
- Hardware Models are created automatically as part of a discovery process while Software Models need to be created manually or imported
- Normalization can be configured to handle Hardware Models, but should not be used for Software Models because multiple fields identify a specific Software Model
- Both types of Models can be provided by a data vendor like BDNA or Flexera, but Software Models will need to be handled carefully to properly identify software licensing
Software Models identify a specific software title along with version and edition. It represents the level at which you license the software. What this means is that you might have installations of Techsmith Snagit versions 12.0, 12.1, 12.2, 12.2.1, and 12.2.2 in your environment, but you license the major version 12. You would only create a Software Model for Techsmith Snagit 12.
These installations for the different minor releases of Snagit will create Software Discovery Models to create some level of normalization of the installations, but it may be up to you to match up these Discovery Models with the Software Models to help determine actual software compliance. I say "may be" here because if you have the Software Model created, newly created Discovery Models will try to match up based on Publisher, Name, and Version information.What this then comes down to is:
- When do you create Software Models?
- How do you create Software Models?
- How do you match up Discovery Models to the Software Models?
The first question is really import and one that could often be handled better. Many people think, "I need to create a Software Model for every piece of licensed software in my environment." This is true, but you do not need to do it all right away. Let me say that again:
Though the goal is to eventually track all licensed software in your environment, you do not need to create a Software Model for it right away.
When do you create Software Models?
Select the top three to five titles or vendors that you need to manage in your environment and work with those first. This often means Microsoft, Adobe, and Oracle. Create the Models you need to work with this Software first. This will meet immediate needs for the vendors at which you are at a higher audit risk to ensure you have the supporting documentation for your licenses and installations. Then you can expand to the other lower risk titles and vendors. You can use the software installation information from your discovery source to help identify these if you are not sure.
If you have a source that provides you with a lot of Software Models at once, I recommend you still focus on a subset of Software Models to manage as you begin.
How do you create Software Models?
When you have identified the titles for which you need Software Models, then you need to create the Software Model records. There are three ways you can do this:
- Create a Software Model (and optionally a Software Counter) from the Software Discovery Model record
- Import from an existing source (Procurement solution, download from your software vendor(s))
- Use a Data as a Service provider that provides Model records
- Manually create the Software Model record
The Software Discovery Model provides a good source to create a Software Model. Just click the Related Link and adjust the Software Model record as needed to match how you license the software.
You may already have information you could import from your procurement tool or some other solution used to track purchases. Just be aware that this information might need a little cleanup. If you do not have the purchases already tracked, contact your software vendor to see if they can provide you with a list of software titles they sell. This could be a quick and easy way to get this information if you have a lot of titles.
Some vendors that provide Model information include Model records for both Hardware and Software that can help get your environment set up and configured. Just be sure to do some "sanity checks" on the data to make sure it is what you expect when you import it.
With the final method, you simply create the Software Model when you need it.
How do you match up Discovery Models to the Software Models?
When ServiceNow creates Software Discovery Models, it attempts to match it to it to an existing Software Model based on Publisher, Name, and Version.
If no match exists when the Software Discovery Model is created, you can click Match model to have ServiceNow attempt the match again.
If your environment allows you to list edit, the fastest way to match is to go to the list of Software Discovery Models (Software Asset Management > Reconciliation > Discovery Models), and select the Software model field for the records you want to update and apply the update.
That's all, folks!
-Porky Pig
Thank you for reading this series on Model Management. I hope you learned a lot. If you liked the series, please let me know. Did I miss anything you would like to see in a future post?
My next series is going to look at a custom application that extends Asset Management.
4 Comments
