Software license and asset management is not successful if the data and results it produces are full of errors and gaps. In operational software asset management (SAM), a big part of the work revolves around importing and processing diverse data, which are also dependent on one another. The industry best practice to deal with this challenge is a database of specialized information about software licenses and technical identification criteria. The purpose of combining the different and complex data sets into one cohesive master catalog is three fold:
- Capture, record and, if necessary, correct or complete information related to software license purchases, contracts, and product use rights
- Identify and normalize software products installed and used across enterprise networks
- Map the software products to the licenses to measure compliance and assist demand planning
As with all complex processes, abstract concepts with ambiguous definitions are a mainstay of software asset management. The “catalog,” also called “SKU catalog,” “part number catalog,” “library,” “software recognition database,” “software catalog,” and “fingerprint catalog,” is undoubtedly representative of this confusion. The concepts associated with this terminology are numerous and oftentimes fall short of the requirements for software asset management. Rather than be surprised by mismatched expectations, read on to learn about the pitfalls to watch out for and what the “catalog” really is.
Software License Information
The most basic interpretation of the “catalog” concept is a simple table where license data is collected and re-used if the licenses are re-used. In this case, the database does not go as far as to automatically generate license records from purchase data, correct errors, or to complete incomplete records. Furthermore, the content in the table often comes from various people with different functions and, thus, differing interpretations of quality and completeness, so even the most rudimentary requirement such as consistency cannot be fulfilled.
A master catalog designed for software asset management is the exact opposite of this. The master catalog should be a fully integrated component of the SAM process and provide high quality information about all the software publishers and products used by your company.
Development, maintenance, and customization of the master catalog are delegated to responsible people. These people must be able to fully concentrate on their jobs because there is no industry standard for defining how software is licensed or identified after installation. There will always be new products, new license metrics, industry specific and in-house developed software, and previously unidentified data which will always need to be integrated into the existing database. Therefore, 100% coverage of all the software within a large organization is impossible and the master catalog must be treated as a continuous improvement process.
Another variation of the “catalog” concept can be categorized as the “SKU or part number catalog” where acquired licenses are referenced against a collection of commercial stock keeping units (SKU). Here, a proprietary selection of numbers such as reseller SKUs or a company internal master set is used as the reference point. Ideally, routine license management operations such as recording license purchases should be automated and easily processed based on these reference codes. Unfortunately, in most cases, the reality is far from ideal and it’s not uncommon for “unique” reseller SKUs to mistakenly be linked to two or more different products. Thus, consistency in the reseller numbers or internal master set cannot be guaranteed and the user cannot rely on there always being a 1:1 relationship between the reference code and the license.
This problem can be easily solved by using the worldwide standardized manufacturer article numbers. Because the manufacturer articles are supplier independent, it does not matter where in the world or from which reseller or supplier the license was purchased – these reference articles make it possible to uniquely identify licenses without problems.
While I’m on the subject of articles, they should not be deleted from the master catalog. It’s important that all information is kept historically intact so that older licenses can still be referenced and traced back even after publishers consolidate or change their product portfolios. Plus, many enterprises use software whose licenses were purchased 10 or more years ago – these articles need to be in the master catalog to ensure the highest possible coverage rate.
Another type of “catalog” is defined as a library or collection of license entitlements or product use rights. The collection can be of many publishers’ products or publisher specific. Now, if you take a look at the update cycle of the library, some worrisome practices come to light. Often, updates are coupled with an upgrade of the underlying tool. If you’re lucky, updates come once or twice a year. In the meantime, the user is forced to manually rework and complete missing or faulty information in the library, which isn’t conducive to consistent, accurate data. Even if the collection is updated more frequently, the fact that the tool is involved makes things complicated from an architectural and technical perspective.
To shield users from this burden and the related risks, the master catalog should be updated on a regular basis, independent of the SAM tool’s upgrades and release cycle. In other words: all the information required to correctly record licenses and product use rights, normalize software installations/usages and measure compliance should be in the catalog. If a software publisher introduces a new license metric and measurement formula, this information should be updated in the master catalog and be immediately utilized by the software asset management tool without having to adapt the technology.
Software Identification/Recognition Data
For software identification and recognition, you will find many “software catalogs,” “software recognition libraries,” and “fingerprint catalogs.” The caveat with this kind of “catalog” is: for what type of inventory/discovery data does the catalog provide reference information? The answer will make a big difference in the quality of the processed data and the results the user can expect for software asset management. For example, if registry or add-remove-program (ARP) keys from Windows® programs are the only reference information provided, then identification fails if/when these keys are internally modified during packaging and distribution. This causes gaps in the resulting software inventory and inaccurate compliance measurements.
The master catalog should provide signatures for ARP data as well as information for MSI, WMI and file names, file paths and sizes, ISO 19770-2 tags and company specific identification features. By using multiple data points organized into recognition rules, the master catalog allows practically any inventory tool to act as a source for software installation and usage data. This is especially important in enterprise environments where different platforms and countless different discovery tools are used.
Relationship Mapping and Documentation for Software Audits
If a catalog claims to support the licensing and product use rights as well as the software recognition aspects of software asset management, then a closer look behind the curtains is worth the effort. There are significant challenges ahead when a closer look reveals that the “catalog” comes in two or even three parts: one for the license purchase references, one for the product use rights, and the other part for software recognition. In these cases, you can forget about a consistent and documentable method for mapping out the complex relationship between article/SKU, product use rights, and software installation/usage. What’s more, maintaining separate catalogs is an administrative nightmare and can spell out disaster for even the best designed software asset management processes.
A robust master catalog contains all three data sets in one piece, making it the central link to map out the relationship between purchase data (article), license (product use rights) and software installation/usage (signatures). With a single catalog the validation, recording, and compliance processes are not only automated and accurate, they are easier to document, which is key in a software audit.
Quantity or Quality?
A decisive question that often comes up is whether quantity or quality should be given top priority for the catalog. Of course, in a perfect world, a catalog covers 100% of your license purchases and software inventory data with an error rate of 0%. But this is the real world, which equally forces the catalog provider and the user to set priorities. When it comes to the master catalog, quality is most important. After all, when quality is the priority, you can trust the data and the results. If quantity is the name of the game, you can’t trust anything, except for the fact that you have a lot of (useless) data.
In any case, it’s worth being clear about your definition of quality. Quality means that the catalog contains:
- All information associated with the license including the purchase article, license metric and its measurement formula, upgrade information, downgrade paths, product use rights, maintenance elements, languages, version, edition and platform
- Software recognition rules, utilizing more than one type of data to ensure accuracy and the capability to differentiate software suites from stand-alone products
Service Approach to SAM
Finally, one can say that a purely technical approach will lead to ruin, whether a SAM vendor offers a master catalog or not. As I said in the beginning, the master catalog is a continuous work in progress, which means new products and customer specific data must be incorporated on an ongoing basis. If this is not done, incalculable compliance risks accrue and controlling software spend remains a pipedream. A service concept should be offered by the catalog provider to (1) accommodate the ever changing landscape of software and licensing and (2) to ensure the continuous adaptation of the master catalog to customer specific purchase contracts, side agreements and software distribution packages. Without the service-based approach, the user must figure out the intricacies of the licenses and inventory data on his own—and isn’t this the problem the catalog should help solve?