.png)
Grab the full download below—perfect for saving or sharing with your team.
In our first entry we talked about some of the technical limitations of Software Asset Management tools in the software and data discovery of data of your environment. Once you’ve tackled that issue and determined that you have complete and accurate data from your environment, you need to actually DO something with it!
On an average Windows desktop or laptop, opening up the “Programs & Features” panel could easily show fifty or a hundred installed pieces of software. I counted 87 on my laptop just now, and that’s everything from Microsoft Word to Slack to the Windows Calculator app. Now consider that in your environment, you probably have multiple versions of applications so your data set could have lines like:
Multiply that by a few different versions and a few thousand desktops and laptops and you can start to envision the giant mess and piles of data you’ll be dealing with.
This is where Software Asset Management (SAM) tools start to demonstrate real value as they use a process called data mapping to comb through your records and provide useful summaries. Some tools call this application recognition, but it’s all the same idea: taking the various software signatures identified in your discovery process and mapping them back to a singular software product, as well as deduplicating the data.
Most tools that have a feature like this should also have some way to update their data mappings regularly and reliably, so new vendor products or releases are accounted for by the mapping function. This should be one of your critical requirements in sourcing a SAM tool.
Software is constantly changing and evolving, and if your tool isn’t keeping up, then you won’t be able to make smart decisions about your purchasing and mitigate license compliance risks with a high degree of confidence. SAM teams should test the veracity of tool mapping data on a regular basis to determine if any updates need to be made.
As you evaluate SAM tools, you should try and test out the data mappings on your real data or production installations. Have the vendor create a demo environment where you can load some of your live data and ensure that your critical applications are properly captured, evaluated, and reported. In our example above, we’d want our tool to be smart enough to recognize that “word.exe” and Microsoft Word are the same thing, and we only need to see it (and count it) once.
Going even further, I really want the tool to know that Microsoft Office ProPlus is a bundle that contains Word so counting it separately would end up costing me extra money in support fees. Product bundling is an essential requirement for a SAM tool and a challenging feature for vendors to consistently get right since software products evolve at a very rapid pace and product bundles, or inclusions often change. In addition, there could be limited use non-OEM licenses offered in a vendor product (e.g., IBM DB2 offered through SAP R3); however, when used as a standalone product or in support of another application, it would trigger a separate or additional licensing requirement.
You should also consider how easy and important it is to make your own modifications to the data mapping library when your SAM tool falls short. You might have some obscure software titles that the SAM vendor hasn’t seen before, or perhaps internal software that needs to be tracked and reported. Additionally, you should make sure the tool warns or notifies you when there are software installations that it can’t recognize, so you can trigger your SAM process to map and tally the unknown product going forward.
I’ll give you a specific example from a prior engagement that emphasizes “the devil is in the details” premise. I had a customer who had created a custom installer for a certain piece of vendor software and deployed it out to their users. This is a normal function and allows them to do things like set some custom configurations and make sure every authorized user could access company resources. But in the process, they renamed the software to something that was unrecognizable to their SAM tool. Because it wasn’t recognized or tracked, it was able to spread throughout the company without IT and the SAM team knowing that they had consumed all their licenses and then some, leading to significant non-compliance findings. Under a vendor audit situation, they would have been on the hook for all of those licenses and liable for paying millions of dollars in software audit fees.
So now we’ve talked about how to make sure you get all the data we need or ensuring completeness and accuracy of your SAM tool, and of course, how to turn that discovery data into useful information through proper data mapping and analysis techniques. In our next instalment, we’ll discuss what tools should do to turn software deployment data into proper licensing data, aligning to product metrics in vendor agreements.
If you would like to learn more about Connor Consulting and how we can help with Software Asset Management, please contact us softwareadvisoryservices@connor-consulting.com today for an initial briefing or complimentary assessment.
