SAM tools: what can go wrong during data upload and how you can overcome the challenges
The key to your SAM tool success lies in an exercise outside the tool: your software entitlement analysis. Nevertheless, it’s not enough to keep track only of your software product names, quantities and metrics. Instead, you should have a clear understanding of all the conditions that govern your software products. I covered this topic in another article: SAM tools: the power of a solid entitlement management process. Next, I would like to cover what can go wrong during the entitlements upload into the tool, what can be done to overcome these challenges and to what degree the SAM tools interpret all your contractual terms and usage rights.
Know your tool
Populating a SAM tool with entitlements data is far from a smooth process. During the upload itself, different errors may appear. Some of them can be related to data formatting, while others are related to the tool’s capability to interpret your entitlements and contractual rights & restrictions. Before starting the upload process, it’s important to have a clear view on your tool’s characteristics. Knowing how your tool works can anticipate some of the errors you may encounter during the upload and configuration process. This means you should have a clear view on what steps are required to perform the upload, what are the templates to be used, but also how the data is manipulated, standardized and normalized by the tool.
In general, most tools provide detailed documentation with regards to the upload itself and the templates to be used. Typically, this documentation is embedded within the tool, often under the ‘help’ function, and describes most of the tool’s user interface (UI) features, including the description of different upload methods available, upload step by step procedures, templates’ description, etc. So, doing your homework before the upload itself contributes to a successful upload.
On the other hand, most tools are not that transparent with what happens ‘behind the scenes’: how is the data manipulated during the upload or how is the data normalized by the tool? To be able to register a software license or to recognize an installed software application, the tool makes use of the so-called software recognition library, also known as application recognition library or repository.
Software recognition libraries determine your entitlement position’s accuracy
The software recognition library is the brain of every SAM tool. It stores information with regards to publishers, products, versions, editions, metrics, metric definitions, usage rights, recognition rules, etc. Every time an application is discovered within your environment, it is normalized based on the information available in the software library. And every time you register a license record in the SAM tool, you will map it with an existing product and its associated usage rights and conditions (if any) as stored in the software recognition library. This means that the software libraries store pre-defined license intelligence related to software products. But how complete are these libraries?
Many tool vendors will claim hundreds of thousands of license records are stored in their library, but eventually it all comes down to what they are counting: evidences, versions, editions and releases.
As most tools originate in the desktop computing era, in general, their libraries store good records for desktop publishers that use stock keeping unit (SKU) or part numbers for selling their products. Even though the software library is constantly updated by the tool vendor itself with new products, editions, versions and new patches, it simply does not store records for all the publishers/product categories, the biggest gap remains related to enterprise publishers/products.
This means that the tool does not allow organizations to set up an entitlement record correctly, affecting the quality of the entitlements in the tool. But to what degree?
Remember from my previous article that the entitlement analysis process should not be a copy-paste activity from your contracts into an excel spreadsheet, but an in-depth analysis of all the conditions that govern the usage right of the software? Without going into much details, these conditions refer to what legal entities are entitled to make use of the software products, what usage rights (full use or restricted use) are granted within a software product, if and what speciﬁc products/components require separate licenses, and what the included products and components are that come with your purchased products.
Although the upload completeness and accuracy will vary by organization, being directly influenced by the size of your license estate and the publishers in scope, in our experience on average more than 40% of the products and conditions from the entitlement analysis are excluded during the upload process. This means that the tool is not always able to recognize your software products or the included products, some of the restrictions cannot be mapped and metrics might be simplified or missing. Let’s take some clear examples.
Products not available in the software recognition library
As mentioned, the software recognition library contains license intelligence for multiple publishers and products. Some of the tools vendors talk about hundreds of thousands of license records stored in their library. Although it sounds extensive, during the import you may learn that some of your (mainly enterprise) products are still not part of the software recognition library and hence cannot be registered into the tool. If this happens, there are few actions you can take: either update the library on your own (if you have direct access to it) or ask the tool vendor to update their library with your products.
License metrics simplified or not aligned with your contracts
If we talk about the most supported license metrics by SAM tools, then these are the user type metrics such as ‘users’, ‘concurrent users’; device type metrics such us ‘number of installations’, ‘devices’, ‘machines’ and processor type metrics such as ‘processor’ and ‘processor core’. Although supported by most tools, organizations should not always rely on the tool when it comes to the metric definition. SAM tools may simplify the metric definition, or your contractual definition for some of these metrics may be customized and therefore not aligned with the one within the tool. As the metric definition dictates the usage and deployment configuration within the tool, it is essential to validate that the metrics supported by the tool, whether they are user-, or device-based, are defined in accordance with your contractual definition. If the metric definition is not aligned with your contracts and the tool has the capability, you might be able to customize the metric definitions as per your agreements. You should however be aware that a customized definition will require manual data collection, most of the times outside the tool.
License metrics not recognized
Similar to the product recognition challenge, SAM tools have gaps when it comes to reporting all license metrics for all products/publishers and using the right license model that you are entitled to.
During the license upload, you will learn that some of the license metrics you signed for are not part of the standard license metric list supported by the tool. To solve this limitation, most SAM tools allow you to create custom metrics. As mentioned already, a custom metric or definition, will require manual data collection, most of the times outside the tool. This means that you will not be able to report automated compliance from the tool. Instead, based on the metric and metric definition, you first need to determine the data required for a complete and accurate compliance position, and then most probably find alternatives of collecting it outside the tool. In such a situation, you can still use the tool to identify the machines or servers where the products with custom metrics are being installed on.
Most conditions such as general, product and usage cannot be mapped in the SAM tools. For instance, you may be allowed to use a piece of software only on a certain type of hardware configuration. Some of the tools cannot reflect such information, while others require extensive manual configuration when it comes to software allocation. For a complete and accurate compliance reporting, you should be able to manage all the rights and restrictions of your software as listed in your agreements, not just to reflect the ones managed by your SAM tool. It is therefore recommended for situations in which the tool does not report all your important conditions, to perform a compliance reporting outside the tool so that you make sure you have a complete and accurate view on your software usage.
To summarize, the completeness and accuracy of the software recognition library determines the completeness and accuracy of your entitlements in the tool. As you have seen already, there is always a gap. The question you should ask yourself is: what gap level is acceptable to your organization? Do you accept partial entitlements’ details in the tool? Or do you want to have full control of your purchases? In the latter case, you might want to consider entitlement management outside the tool as well.
Interested to see if the software library influences the compliance reporting too? Then stay tuned, as the next article will explain how SAM tools deal with compliance management.
Ana is one of our project managers who helps customers to overcome their SAM challenges. Ana joined the SAM world in 2011 when she started working as a Technical Analyst within Oracle’s License Management Services (LMS) team and currently uses her diverse SAM experience to support customers during the implementation of our SAM Managed Service solution. Ana holds a master’s degree in Accounting, Audit and Information Systems Management from the Academy of Economic Studies of Bucharest.