In first grade, we all learned that 1+1=2. In our family 1+1 = 4. That’s 1 wife plus 1 husband resulting in a family of four. Luckily for us, software doesn’t quite reproduce the same way, though I’m sure we might think so as we start to look at software install counts versus what we were expecting, in say a virtual environment. Take, for example, two installs of a piece of software that consume 4 licenses because the software is installed on systems with two processors, and the license for the software counts license consumption based on the number of processors. In that case 1+1=4. The process of counting installations, determining the correct number of licenses required and comparing to software purchases is often called software license reconciliation, and that’s a subject for a separate blog.
In another example, what about an IT asset management inventory that says there’s one copy of Adobe Acrobat on Steve’s Laptop under the Program Files Directory, and evidence of another copy of Adobe Acrobat in a different location, but there really is only one copy of the software with evidence being counted twice. You might know that Steve only has one copy of the software, but the software inventory says there are two copies. So, in this case 1 + 1 = 1 as long as you can reconcile the two pieces of inventory evidence correctly.
So just how is software counted, and how can the count sometimes be more than we expect (1+1=4), and sometimes less (1+1=1), and how can we resolve these issues to come up with an authoritative count we can use?
What are we counting and how are we counting it
The problem is not always the addition or reconciliation; problems can often occur in the counting well before any addition takes place. In addition, just what does it take to determine that an instance of Adobe Acrobat is actually installed, not to mention verifying the version and edition? It’s really a question of just what are we counting and how are we counting it.
So how do we assure we are counting correctly? For illustration, let’s take the example of the age old promotion retail stores do— placing a huge number of items, like marbles, in a jar and asking passersby to count them. Counting the marbles while in the jar is almost an impossibility, even if you use complex mathematical formulas (you can equate that to counting software on systems not connected to any network for example— you might as well just make a wild-eyed guess); there are just too many unknowns and variables like how large is the bowl, are the marbles all the same size, did the retailer put any fillers in the bowl. But even if you take all of those marbles out of the jar, then ask different people to count them you still might get different answers. Each person might use different methods to count and verify such a large number, and since the task is very monotonous, they will probably develop some scheme to make their job easier. So each starts using different methods to count, and no matter how accurate they are, chances are, they still could get a different number.
But then ask them not only how many total marbles there are but how many of each type there are. Chances are the variance will be huge when you start to compare the different counts for the different types. That’s because different people will have different ideas on what types of marbles there are, and as a result, one person might say they counted 285 cat’s eyes, while someone else might give you a number of 492 cat’s eyes. How, you may ask will two different people give such widely diverse answers? Well it comes down to what each person thinks a cat’s eye is.
Well, believe it or not, the same thing applies to counting software installations in your environment. Ask someone from IT how many copies of Microsoft Project are in your environment, and they will give you one number. Then ask someone from your help desk how many copies of Microsoft Project are out there, and you will probably get a completely different answer. Chance are these two employees are using two different sources to determine their answer, and each source will have its own idea of just what constitutes a copy of Microsoft Project being associated with a user or machine.
Then you need to consider that these two employees probably have a different understanding of just what you mean when you ask to count Microsoft Project. Is it the full install of Microsoft Project; the latest version of Project; and should we count editions of Microsoft Project separate from Microsoft Project Server components; or does the count include the free version of the Microsoft Project viewer as well. So your first problem is trying to come up with the definition of just what you mean by Project. Even if you were specific enough to say “How many copies of MS Project 2009 Professional do we have” you still might get two different answers because these two employees probably use two different resources to find the answer to the same question. One might use a raw inventory count, while the other might be using a reconciled count provided by some centralized help desk system or CMDB. Again, too many variables when trying to answer one simple question.
And don’t even get me started about asking Accounting how many copies of Microsoft Project they think you have in your company. Let’s just keep focused on counting how many copies of a particular software application you may have in your environment.
So the key here is to understand what you are asking for, and to make sure the people tasked with providing an answer also understand the same question. In this blog, we are trying to address the issues around counting the software installed in an IT environment. This includes the scrubbing of the raw inventory data using an application recognition library and also takes into consideration hardware characteristics.
Keep things simple
So what can we do about the task of counting what software is installed in the organization? Instead of using something like MS Project, let’s start with something easier like the operating system, and let’s just use one source for our question, in this case IT. When we ask IT how many copies of Windows XP operating system we have (our standard for all end-user systems), they might look at their inventory report and answer simply 4,982. So should we believe them? Is this the number we should provide to Microsoft when they come in for their annual true-up? How do I know if this number is even close and how can I verify it. Especially if you remember that just last week, you asked IT how many end-user computers they managed, and they gave you an answer of 5,250. So in this case 1 + 1 doesn’t always equal 2. 5,250 computers with one OS each should equal 5,250 copies of Windows XP, but it doesn’t. So where does the discrepancy lie. Well the first thing to realize is there’s not one answer to the question of why your numbers often times don’t match.
If IT tells us we have 5,250 computers they manage (we are going to ignore servers to keep this easy), then logic tells us we must have 5,250 copies of the standard OS we manage as well. If Windows XP is the standard for our world, then we must have 5,250 copies of Windows XP. So we go to our inventory and the latest inventory report tells us we have 6,384 computers and only 4,982 copies of Windows XP.
So you need to verify the count before talking to Microsoft. Once you start digging a little further, you may find several different items that can change this simple logic such as:
- Oh, we forgot about the 800 systems we just ordered that we included in our count of computers, but that haven’t been inventoried yet.
- Also, we have about 500 or so older computers that we never upgraded to Windows XP because they were fine with Windows 95, and we didn’t want to risk crashing the systems with an upgrade.
- And then there’s a bunch of systems in the closet that have never been inventoried by our new inventory tool.
- Oh, and then there are the 400 systems that development uses for testing that they loaded Linux on
- And the list of variances continues on and on the deeper you dig.
Solution part 1: A central Hardware and Software Asset Management Repository
So how can we solve this problem that seems to get worse and worse the more you dig into it? To start, you should put in place consistent measures of software that utilize proven methods of reconciling all of the variances and discrepancies that arise in counting software. It’s also important to note that no matter what method of counting you use, you are always dependent on the source of the original count, which in most cases is an inventory tool or multiple tools of some type, so it’s always a good practice from time to time to run comparisons on the inventory counts from different systems. For example, how many computers does the helpdesk monitor, vs. how many computers is the inventory system reporting, and how many computers does accounting tell you that are currently on the books. Also, you should put into practice the process of comparing the electronic inventory with a regular physical inventory to help clean up systems that simply are no longer found in your environment.
In addition to putting in place standards for counting and measuring your systems and software, you should also implement a central Hardware and Software Asset Management repository. It should have built-in reconciliation algorithms, including application recognition based on known libraries of software and have the ability to reconcile varying sources of inventory data into a single count. The system should also take into consideration the hardware portion of the equation— which systems are active, which systems should no longer be counted, and which systems are double counting themselves for some reason and hence should be discarded.
Well, since I’m about to get off the airplane, we’ll continue with Solution Part 2 next time. Meanwhile, happy counting, and please don’t tell my 1st grade teacher that 1+1 doesn’t always equal 2. It would break her heart.
