How an ITAM tool is implemented can help or hinder Software Asset Management
I have worked with HP Asset Manager for almost 15 years and this article was originally written with an HP Asset Manager audience in mind. However, in every ITAM tool/database, the data items have to be organized and categorized in order to manage them. In HP AM this is done using “Natures” and “Models”. This management is called different things in other tools, but doing it well is going to be crucial to all of them since, fundamentally, an ITAM database is a repository of data which we want to be able to use to answer questions. How the data is structured, linked, and related is critical to this usage. Done right it can make answering difficult questions a good bit easier. Done wrong even simple questions can become to answer.
What I am sharing here is a methodology we evolved over the years for successfully managing IT assets using HP Asset Manager. The details are tool specific, but I believe the general methodology has value regardless of the tool set you have in place.
For those not using HP AM, two core terms must be explained first, which are models and natures.
Models are stored in a tree structure, with the higher levels used to categorize the types of the things that are going to manage. The lowest level is for the templates (“models”) of the things being managed. All of the actual assets/items of a particular specific kind would have a common model. For example, where 1000 laptops would each be tracked as individual records, there might just be three different types and therefore three models, with each laptop tied to one of those three models. It is likely that those three models would share a common parent model in the hierarchy which groups all laptops together.
Natures are another level of categorization and every model has a nature which determines how an instance of a model is tracked, what table(s) a record is created on, and how it is allowed to behave. This approach allows models to be defined for physical items such as laptops, servers, phones or furniture, as well as things like contracts, licenses, installations, work orders, and so on.
How the model and nature tables are populated in HP Asset Manager is foundational to how effective the tool will be. The same specifications are likely to be important in any other tool as well. And while important for hardware, they are even more necessary when managing software since it is so multi-faceted. Software Asset Management needs to consider licenses, installations, contracts, upgrades, maintenance and how to tie them all together cleanly. Here is our methodology for doing so in HP AM. I believe this approach makes answering some of those difficult questions simpler.
Structuring Software Models in HP Asset Manager
Since models provide the underlying structure and organization for how objects are stored in the AM database, everything that is tracked must have a model. Items such as portfolio items, assets, contracts and work orders must have a model. The best way to create an effective systemized approach is not always immediately apparent and it can be neglected during implementation or incorrectly optimized for one function or audience at the cost of others. When setting up software models, the typical choices can be problematic for Software Asset Management, requiring a new approach to structuring for software.
The Typical Method
The typical method commonly used to structure software models has a “software” node with a branch below it for software installations and another for software licenses. Each branch further subdivides by category and finally down to individual software titles. Contracts have their own hierarchy with separate branches for licenses and maintenance contracts. At first glance, this basic approach looks good. However, there are often cases where you need to relate and reconcile all the various models related to a particular piece of software to one another: contracts, licenses, installations, and work orders. The common approach has limitations built into that interfere with the pieces together, particularly when building counters.
The main advantage of the typical approach is the easy separation of models by type, but this can be done by filtering on the “Model.Nature” without constraining the model structure. In contrast, the methodology described in this article allows greater flexibility and less maintenance in the structure of the models table in a way which works well with the software assets module
Here is an example of the structure commonly used in many Asset Manager Implementations.
The list above has been filtered to just show Microsoft Office, but all software classed under “Productivity” is most likely at the same level, making the list even longer. Even when viewing the filtered list, the data reconciliation problem this presents can be fairly easily seen: there is no relationship between the license models for a given piece of software and the installation models for it. This means that when queries and counters are created for this software, values will either have to be hardcoded (which makes them static) or N:N relationship tables need to be build and maintained.
An Alternative Methodology
The Golden Ratio methodology developed from an examination of different perspectives on how to structure models. The goal was to identify a structure which would both better fit how clients naturally wanted to organize the data and which also minimized the amount of maintenance work would have to be done. We found that our clients rarely wanted to look at installations or licenses for multiple products at once. Instead, we found that they wanted to look at installations and licenses at the same time for a specific piece of software or a related set of software. Based on that pattern, we came up with the concept of “software title” and “software family” groupings and used these initially organize the our models. All models relevant to a given software title are beneath it where they can be easily found. Then, related software titles are grouped together as a software family. The structure looks like this:
In addition to making it easier to find everything related to a software title, this structure also provides the “missing link” between different object types that were lacking before. Instead of having to manually maintain the relationship between licenses and installations that need to be linked for each separate counter, the relationship is implicit in the software title structure. Licenses and Installations both have a common parent, or as the model was refined, a common grandparent.
Below each software title model are nodes for the various types of objects relevant to that title. Contracts, licenses, upgrades, installations, and work orders each get their own tree, but they can all be tied together by their common software title. The beauty of this is that if you add a new model under one of those trees there is no maintenance needed. The query for rights on a counter is tied to the software title and is going to count all assets tied to a model in the “licenses” tree of that counter (with the correct license type of course). Just adding the new model in the appropriate place is the only maintenance needed. No queries need to be updated and no wizards need to be run to add that model to a counter or counters. Combined with some of the structural changes we have made to how counters function, the operational effectiveness of using Asset Manager to support the SAM function is greatly enhanced.
More on Counters
Another difference between the standard Asset Manager SAM functionality and the Golden Ratio methodology has to do with upgrade counters. In our experience, upgrade counters have two major flaws: added calculation time and visibility limited to the counter results. Golden Ratio’s methodology for upgrades does away with the upgrade counters completely and instead views an upgrade as a two part object: a “credit” record and a “debit” record. If you upgrade a license of “Microsoft Office 2007 Professional” to “Microsoft Office 2010 Professional,” we create a debit license asset with a negative number of rights for the old version and a credit license asset with positive number of rights for the new version. In the example above this is shown with the models “Microsoft Office 2007 Professional Upgrade 1 to 2010” and “Microsoft Office 2010 Professional Upgrade 1 from 2007.” Counters which take upgrades into account sum up any assets tied to models in either the licenses or upgrades trees and thereby include the upgraded rights as part of the counter standard calculation. Totals for the old version are reduced and those for the new version increased automatically when calculated. This approach does have the downside of creating two asset records instead of one, but that can be easily automated and has the benefit of clearly showing the effect of the upgrade if viewed outside the context of the counters. We also tend to advocate using fewer multiple right licenses rather than individual licenses which results in a fairly small number of “extra” asset records.
The thoughts and ideas presented here are examples of how the functionality and usability for Software Asset Management can benefit from careful thought during implementation of tools such as HP Asset Manager. Please use them to start discussions about how to implement to achieve the greatest advantages.