Why are inventory tools so bad at software asset management?
Our main issue with inventory (audit) tools is that they are being sold as THE solution for SAM and for licence management in particular.

In the right circumstances there is no doubt that inventory tools are of use, but in the wrong circumstances they are a dangerous waste of time, money and resource.

The main side effect of this is ultimately that SAM suffers as a concept and a discipline.

To deal with tool shortcomings many organisations have bought in outside assistance.  Whilst this is a solution it is an expensive one and relies on external expertise.

Wouldn't it be far better if you could get control of these issues yourself without spending more money?

We deal with the solutions in Solving inventory tool issues - the rest of this page is all about understanding the problems you are facing.

So what are the main problems with inventory tools?

  1. Rubbish in rubbish out.
  2. Mind the gap.
  3. Deploying to every machine can take months.
  4. Most tools only deal with installed software.
  5. Metering, usage tracking and licence optimisation is usually a fantasy.
  6. Tool vendors always underestimate the resources required.

The process

Before we look in detail at these problems, let's just describe what you are supposed to be able to do.

An inventory tool collects information about the software that is installed on your machines.  Different tools work in different ways, but they all ultimately scan the software on the machines they are pointed at and eventually report back to a central console.

The idea is that you can then run a report for a particular publisher's products and the tool will tell you what software is out there, therefore defining the licence requirement for those products.

According to the tool vendors' blurb, all you apparently then need to do is match this list of licence requirement to the licences that you have and the job is done.

But in reality it is never that simple, in fact this is so far from the truth it is laughable.

Common reality
What you are actually being asked to do is take a load of rubbish (tool report) and then match it to pile of paper/contracts (licences) that might or might not fit the requirement, depending on how accurately they were purchased and whether someone has maintained the paperwork.

These are the two sides of the equation; the tool report of what is installed and licence entitlement.

We shall leave the licence side for now and focus on the tool issues.

Our first gripe is that you are being asked to deal with a load of rubbish, the tool report.  It is often a load of rubbish because of our first two problems - 'rubbish in rubbish out' and 'mind the gap'.

1) Rubbish in rubbish out
Rubbish type 1 - Too much information
Basically, a tool only reports back what it sees on your software estate, so if there have been no controls with regards to the deployment of your software, there will be a gargantuan amount of information that the tool will dutifully report.

Now a tool vendor would spin this to say "that is exactly why you need a tool, so that you know what is out there and can start to sort it out."

Hang on a minute, they are selling the tool on the promise that it will allow you to manage licensing and all the components of SAM, then at the first step they blame the state of your software estate for it not being so straight forward.

And this is the essential problem with inventory tools, they will only ever report what is there.  Every piece of software that has ever been installed has tens or hundreds of files associated with it of many different types. 

Often organisations are faced with so much information they simply don't do anything because the task is just too enormous.

All you want to know is how many licences your organisation requires, a simple question.  But suddenly the answer is further away not closer.  It can be very frustrating.

The presence of all or some of these files could signify that a licence is required, but it might not.

Rubbish type 2 - What is licensable?
The tools try to split their reports into what is and what isn't licensable.

The more expensive the tool, the better they are at recognising what does count as a licensable installation and what doesn't.

But none of them get it right all of the time and as you will see below there are common faults that quickly call into question the accuracy of all of the information.

This is where the 'audit' tools are better than general inventory tools as the creators of audit tools have focussed more on identifying licensable software.

Even if they are a step closer they still leave a great deal to be desired and a lot of work has to take place to completely filter out the rubbish.

As this is down to you, someone has to investigate whether a particular install requires a licence and what the right licence is.

This is a very time consuming job and one which most people have purchased the tool to do for them in the first place.

Rubbish type 3 - Duplications, now the fun really begins.
If your software applications have ever been upgraded then often traces of the old version are not deleted properly by the upgrade process. 

Tools then pick up these traces and report them as genuine additional installations.

Some tools will report on system restore folders where the filename has been changed (typically from excel.exe to something like a000xxx.exe) but the
tool reads the file header, which has not been changed and therefore reports the file as excel.exe resulting in a report of a licensable installation. Similarly recycle bin files may be included in reports.

The consequence of this is that the tool can report multiple installations as requiring a licence, one of the old version and one of the new, on the same machine.

If you then run a report specifically for that application, you will often have no way of checking to see if duplications have taken place unless you cross reference it with a machine report.

From a licensing perspective the tool is telling you that an extra licence is required when it isn't.

And if a publisher is involved as they could be in an audit, they will only accept the tool report as proof of what is installed.  Unless you have made the right checks and can argue the point that there are duplications you will have to pay for the extra licences.

Rubbish type 4 - Mis-recognition can occur with even the most common of applications such as Office, Adobe Acrobat etc.  If your application installation method has left files in unnecessary places on machines, (e.g. Temp folders) then mis-recognitions can occur which will affect totals in reports.

We have seen this happen on many occasions where it wasn't a genuine installation but the tool registered it as such.  This is particularly common with server products.

Another form of mis-recognition comes with free viewers and trial versions of software.  Free viewers are often tagged in the same way as the licensable edition by the publisher, so a tool cannot tell the difference.

Trial versions will look exactly like the real thing, because the file structure is the same, so an inventory tool reads it as a genuine install requiring a licence.

It is examples like these that produce weird results that cause confusion, expense and time wasted, i.e. what we call rubbish.

Ultimately all you want to know is how many licences does your organisation require.  In reality with all the confusion that can be thrown at an inventory tool, even the good ones struggle to provide a list of what is required without major intervention and management.

Solutions?

There are solutions to these problems.  You basically have a choice between dealing with the issues at the beginning of the information trail or the end.

The tool vendors and their cohorts would prefer you to deal with it at the end of the process, i.e. clean the tool data and configure the tool as you go.

This is a very expensive way of tackling the problem as it will take forever and never actually deals with the root causes.

At SAMsource we strongly recommend dealing with the issues at the beginning of the information trail as we discuss in Solving inventory tool issues.

Before you look at that, let's continue with understanding the issues...

2) Mind the gap
We now return to the licence reconciliation equation, where licence requirement needs to match licence entitlement.

What we are saying is that there is often 'a gap' between what the description of what the tool reports as installed (requirement) and the actual rights granted by the licence (entitlement).

Remember that a licence is a contract, a piece of paper, it grants rights that can require some interpretation as to whether they are valid to cover the installation or not.

What people want is for a tool to say yes or no as to whether a licence is valid for the install in question, but actually this is often a manual process requiring some interpretation.

The problem originates from the point of deployment of the software and possible purchase of the licence.  If your deployment process is not communicating with the purchase process in the licensing context then there will be a gap between the licence and the software installed in terms of description and possibly rights granted.

This is probably the most underestimated aspect of using tools in the licensing context.  It usually isn't until someone has had to manage this issue and find solutions that a full appreciation of the enormity of the task can be gained.

Before getting into the detail, let's describe what you are trying to achieve.

The inventory tool reports on what software is installed.

(We will ignore the rubbish from above for a moment to make this point, but it does exacerbate the problem of minding the gap so we will come back to it).

The inventory then needs to be matched to the licence entitlement that your organisation has so that a licence position can be defined for any particular product.

As people start down this road, they believe that the tool will be able to do all this for them.  A piece of software is a piece of software and a licence is a licence, how hard can it be?

There are two levels at which the problems are caused:
  • Descriptive
  • Rights granted

Descriptive - In reality, what the inventory tool reads as the description of the installed software and the description you might be reading on the licence documentation can be very different.

The problem is that the publishers' developers write software and their licence people write the contracts.  They don't necessarily follow the same standards and the variations can be dramatic.

For example, a tool might report an installation of Office Professional v 11.011234

The corresponding licence documentation might say Office 2003 Professional.

A human being can make the connection if they know that version 11 was actually 2003, but a tool doesn't necessarily know that level of detail until you teach it to do so.

(This is a simple example and the better tools would know this level of detail, but none of them know all of the detail because publishers do NOT follow common standards.  There are moves afoot in the market to change this with ISO 19770 Part Two as we discuss in Solving inventory tool issues but it may never happen).

Rights granted - And then there is the stuff that doesn't match at all, i.e. with downgrade rights an Office 2007 Professional licence also covers the installation of the example above.

No tool on the market can link the 2007 licence to the 2003 install accurately without a human being getting involved and telling it that this is the case.

Rubbish gap

So now you can see that dealing with all the rubbish thrown at you and then trying to bridge the gap to match the rubbish to a licence can be quite a task.

The more software you have out there, the more complex it will be.

Even for estates of 500 machines we have seen tool reports of thousands of lines long.

The time required to sort out what is what can quickly destroy the value in having the tool in the first place.

3) Deployment of the tool
- We have worked with tool vendors and resellers and more often than not they are extremely proud of the speed and ease with which their tool can be deployed.

Once again, working in the real world often causes huge questions to be asked.

Yes we all have wide area networks and good internet connections, but:
  • Machines are not always switched on
  • People go on holiday
  • Firewalls block certain traffic
  • etc

Tools tend to be deployed to 80% of the estate quite quickly and then take months to trickle through to the rest.  Ultimately you are unlikely to reach every single machine unless the scan engine is installed on machines as they are built and you wait three years for the refresh process to circulate right around your estate.

Without 100% coverage you can never expect completely accurate results.  As we have said in Good enough, you should never try to work to 100% accuracy as things change so quickly you would always be chasing your tail.  But when tool customers have invested so much in technology, they expect at least the possibility of 100% accuracy.  What a shame that it is almost impossible to achieve.

4) Limited to installed software - Most tools are incapable of tracking user based licensing models and virtual environments.

More and more systems are becoming user based in their licensing, particularly as SaaS (Software as a Service) services increase in popularity (e.g. Google Docs).

For SaaS it usually doesn't matter because the licensing is controlled by logon details and the service provider.

But for virtualisation that is not the case.  Most inventory tools are incapable of measuring anything within these environments that is of use in the licensing context and that is a critical floor in justifying their involvement.

Added to that, for applications provided over Citrix, for servers licensed on a user connection basis, for servers licensed on a device connection basis, inventory tools are mostly completely useless.

This is ok as long as the customer is aware of the issue when purchasing the tool, but what we often see is the moment of realisation after the purchase that it won't cover anything like all of the software requirement.

The message to the tool vendors is that inventory tools do NOT provide the customer with a complete solution for licence management, far from it, so stop selling them as if they were.

5) Metering, usage tracking and licence optimisation - Tools are sold on the promise of these benefits being delivered.  We are frequently irritated by marketing that says as much, knowing that 99% of the time it is totally unrealistic.

If any of the problems described above exist on your software estate, then software metering, usage tracking and licence optimisation are pipe dreams.

The idea is simple enough and indeed it should be one of the major benefits of SAM that all software customers enjoy.

But if the information going into the tool is rubbish and the tool is not capable of filtering it to make it useful then the next level of management reporting such as licence optimisation is an impossibility.

6) Tool vendors always underestimate the resources required - Whether it be:
  • The server specification that is needed to run the tool
  • Or the licensing that is required for the actual tool
  • Or the time it will take to deploy
  • Or the time it will take to configure
  • Or the time it will take to make any sense of the information or the or the or******

The hidden costs often result in two to three times the cost of the tool being spent over the 6-9 months following implementation.

We have worked on many projects with many different tools in many different organisations. ALL of them had one or more of the issues listed above.  Once upon a time we used to feed back to the tool vendor in question with the difficulties that had been experienced, but nothing changed.

Eventually you accept that the product is the way it is because they can sell them as they are.  There is no real need for dramatic improvements because the market has been very good to tool vendors since the new millennium began.

This market has been created out of the short comings of the work done by software publishers in managing the licensing with their software products - see SAM tools for further discussion if you haven't already.
 
Most of the under estimations listed above are self explanatory, but let us explain the second one for good measure.  Any tool that sits on a Microsoft SQL server and scans every device or deploys an agent to every device in the organisation will require SQL CAL's for every device.

We worked with one tool vendor who didn't realise this, nor did their resellers.  The irony was not lost on the customers that we had to tell when working with them from a licence compliance perspective. 

For the server that the tool ran on to be properly licensed it required SQL CAL's at £75 per seat or a processor licence for the server at £2,500 to be compliant.

That is not an insignificant amount of money that was completely missed in terms of licensing during the specification of the tool costs due to the tool vendor's lack of understanding when it came to software licensing.

Bravo.

Conclusions
Don't take all this the wrong way, tools are important and in organisations of more than 500 machines they should be an integral part of any SAM programme.

The frustrating thing for anyone who works with inventory tools in the real world is that they very very rarely meet with expectations or match the promises of the tool vendor marketing blurb.

Tool vendors have had it incredibly easy over the last decade as they try to offer solutions to bridge a gap that shouldn't be there in the first place.

Whichever way you look at it, there is something smelly about this area of the SAM market which can only disappoint people trying to implement a SAM programme, which is a great shame.

We now look at the great Tool automation myth...