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.
- 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.