Software Recognition – What’s The Big Deal?
It is common to underestimate the importance of good software recognition
When I first started out in this industry the FAST certification (a UK based industry body) was quite popular.
Organizations were keen to put the FAST plaque on the wall in reception to prove they were serious about software compliance.
I believe the popularity dwindled when companies recognized that the plaque was not ‘a shield of steel’ against vendor audits and some serious resources were required to sort out their licensing issues.
I remember speaking with one gentleman around 2001 that said he was about to embark on the FAST certification. He anticipated a few quiet hours during the Christmas holidays and was going to ‘Do that FAST thing’ over the Christmas break.
I remember smiling to myself whilst speaking to him on the phone and wishing him a good Christmas and good luck with the project. I promised to follow up in January to see how he had progressed.
When I phoned back in the New Year he had realized the enormity of the project once he started to delve into it and peel back the layers of the onion. Several years later a different company, NCH Europe, were quoted as being the company to complete FAST Certification in the fastest time; 9 months.
I believe this is a common misconception among newcomers to the industry; after all – how difficult can it be? All you have to do is match up installed software to licenses and stick it in a spreadsheet – right?
Why Do We Need Software Recognition Anyway?
When faced with a SAM or audit project it is a common to underestimate the process of collecting good information about what is installed. It’s not unusual for someone to state “We can do that in SCCM” or “we’ve got that data”. In fact most system admins can write or borrow some scripts to collect add / remove program data or details or executable files. The challenge is that the raw list of executable files is a country mile away from what is needed to perform a sensible reconciliation.
Common Challenges
- File Header Information – The titles and descriptions used to describe the software application when the manufacturer compiled it rarely follow any industry conventions
- Add / Remove Program Data – Add / Remove program data is notoriously inaccurate and incomplete
- Normalization – Data needs to be normalized to weed out duplicates such as Microsoft Limited, Microsoft Corp and Microsoft Inc.
- Suite Recognition – it’s sometimes not obvious that a software installation found is part of a suite
- Breadcrumbs – Some application have bundles or OEM arrangements which may leave traces of installations – which at first glance might look like a full installation e.g. a bundled version of SQL
- Type – What version is it? Is it an upgrade, Professional? Standard? English? French?
Enter The Software Recognition Database
Modern SAM tools make use of software recognition databases and algorithms to scan raw files and provide business intelligence on what is installed. The aim is to find a description of software that is closer to what might be stated on the invoice when you bought it in order to perform reconciliation.
Two important points here are a) The ability to make your own modifications e.g. Perhaps you have some in-house written software and b) the ability to update this database over time as new applications are developed. SAM tool vendors usually provide periodic updates or trickle down updates via the Internet.
Road Testing Software Recognition
What is best way to trial how good the software recognition is within a tool? Perform a real reconciliation. Take one product from one vendor and try to perform a trustworthy reconciliation to demonstrate compliance. Software recognition saves a huge amount of time and frustration in manually crunching raw data and interpreting raw executable files or header information. The only way to demonstrate this correctly is in a live reconciliation.
Inventory has become very commoditized and in some instances free but the strength and intelligence of software recognition really sorts the wheat from the chaff.
Related articles:
About Martin Thompson
Martin is also the founder of ITAM Forum, a not-for-profit trade body for the ITAM industry created to raise the profile of the profession and bring an organisational certification to market. On a voluntary basis Martin is a contributor to ISO WG21 which develops the ITAM International Standard ISO/IEC 19770.
He is also the author of the book "Practical ITAM - The essential guide for IT Asset Managers", a book that describes how to get started and make a difference in the field of IT Asset Management. In addition, Martin developed the PITAM training course and certification.
Prior to founding the ITAM Review in 2008 Martin worked for Centennial Software (Ivanti), Silicon Graphics, CA Technologies and Computer 2000 (Tech Data).
When not working, Martin likes to Ski, Hike, Motorbike and spend time with his young family.
Connect with Martin on LinkedIn.
Really good explanation Martin, I think you have explained this issue more clearly than I have seen before.
Very well put Martin. I imagine that this article will prove extremely
useful to help those facing a mountain of a task understand and communicate to stake holders why they need help or appropriate tooling –
the devil is in the detail on these things and management are rarely interested in the detail.
Miss identification of software can
result in huge risks being left, the worst scenario being expending all this effort and still leaving yourself exposed when a vendor
comes knocking…
Nicely put, though I have heard the below several times before:
Add / Remove Program Data – Add
/ Remove program data is notoriously inaccurate and incomplete
We actually did an analysis on a few hundred computers, this was
somewhere around 2004. I’ve done spot checks since then at many customers, and the quality of Add/remove programs is massively better
than the result when working with exe files. Apart of the added workload (tenfold) with exe files, few solutions, if any at all are
capable of tracking exe files correctly. The same main exe files are used across software editions, so you really need to put your
shoulder to the wheel to make exes right.
Over the years, software installation technology has improved. Counting exe files died
with 16 bit operating systems.
So my conclusion is crystal clear: Go with add/remove programs, and make a spot check
(I’ve
spent 6 years as a tool agnostic SAM consultant, and withdrew from that industry in 2008, so I am not touting any specific product
here)
Best regards
Henrik
Thanks for your comment Henrik but I
disagree. Whilst Add / Remove descriptions may have been improved I still feel they fall short by a significant margin.
Similarly
I don’t believe people actually count .exe files – my point is that the descriptions provided by installs is a country mile away from
the data required to perform a reconciliation.
Only one thing to add: Installation based software, and this is what software recognition is able to
analyze, is only a part of the story. Complexity and budget comes from servers and their inventory not metric relevant in most cases. So
from neutral position a tool must be able to handle that raw recognition data, but all other usage data sources have to be recognized,
too.
I would like to see a global standard for marking installed applications for discovery. SW publishers should be held accountable to either add the application to the Add/Remove program or create a universal install log file with the description of the application and version number. If you’re going to audit, make it a level playing field. So many publisher’s see the confusion in SW discovery as a way to increase revenue’s through audits
Hi Chris,
International SAM Standard http://www.19770.org/
In particular ISO/IEC 19770-2 refers to software tags.
See tagvault.org for further info.
Martin