Taking the Wrong Turn

This past weekend, my wife and I were riding our motorcycles up to the White Mountains of New Hampshire. We choose to go the back roads for the views, and planned our route after looking over our maps. One thing about riding motorcycles though, it’s a little hard to take the map out and read it while you are riding, so when we came across an intersection for Rt. 113 I took the turn, and only found out after traveling about 10 miles or so that we had taken a wrong turn.

Well, it was easy enough to correct. We stopped, looked over the map and found out that Rt. 113 intersected the road we were on two times, and we turned at the wrong intersection. After studying the map a while, we found a smaller road that got us back on track, and even got the benefit of seeing a part of the country we might not have seen otherwise.

After we got back on track, I got to thinking how making a wrong turn based on the road signs available to us at the intersection are very much similar to software procurement decisions being made every day by software asset management practitioners.  Choices are made based on the best information available, but that information is not necessarily up-to-date, complete or accurate. We made our decision based on the road signs available when we made our turn, but the information was incomplete. We were only able to correct our mistake after referring to the map with more information available to us.

The difference between our mistake and the mistakes made by software procurement personnel is that making a wrong decision on the road results only in a few extra minutes on the road, and oftentimes ends up with new discoveries to boot. However, wrong choices made by a software purchasing officer can costs tens of thousands of dollars, or even hundreds of thousands of dollars in unnecessary expenses.  They can also be extremely hard and costly to reverse.

A typical example I run into in my work is where someone makes a request for 100 copies of say Adobe Acrobat for their new graphics team and the software procurement officer asks finance how many copies of Acrobat have been purchased. They also ask IT how many copies are installed, and based on that information they might decide they need to buy 100 new licenses. This was the proper thing to do, but the problem is that this decision is based on raw data that’s incomplete and sometimes not even representative of what needs to be measured. It would be like planning my weekend route to the White Mountains using a map from the 1920’s, or by using the road signs alone with no map at all. Sure, I might get there eventually but no telling how long, or how far off the beaten path I would end up.

Well, basic IT software inventory data is also often incomplete; in addition, it must be reconciled with an up-to-date recognition library to ascertain what titles, versions and editions are installed throughout the estate.  Similarly, basic purchasing data is incomplete if it doesn’t contain product SKUs that identify exactly what has been purchased. And finally, license entitlements must also be taken into account to understand true license consumption. So let’s discuss these one at a time.

Inventory Data
IT asset management inventory tools have been implemented at most large enterprises for years and IT and finance departments have come to rely on this information as the “best available”. So when folks ask, “how many copies of application xxx do we have”, 99% of the time, people will go immediately to an inventory report to get their answers. This provides a certain level of accuracy, but in today’s software landscape, organizations need to consider more details than simple installation counts. The type of inventory details needed include:

  • Application recognition details
    Many inventory tools will only provide raw evidence of file counts, or maybe what’s found in the Add-Remove entry list, but these alone do not always tell you what’s installed, and sometimes can result in double counting. What’s needed is an Application Recognition Library that can reconcile raw inventory details into actual application counts per device.
  • Software installation details
    It’s important to determine not only the list of software titles that are installed throughout the enterprise, but also the specific versions, editions, and whether the application is part of a product suite. Entitlement rights may allow multiple versions of the same application to be installed on one computer, and still only consume one license, for example.
  • Hardware asset details
    Modern server based licenses sometimes rely on hardware details along with software installation information. Oftentimes you not only need to know which systems the software is installed on, but the number and type of processors on the system, or if the system is a on a virtual image or a physical server, as licensing rules will differ in these cases. For advanced use rights, you need to know whether the system is a desktop or a laptop, since many desktop license entitlements come with the right of 2nd use, but only if the second use is on a laptop and the 1st use is on a desktop. This additional reconciliation saved one customer over $1 million at audit time.
  • Virtual environments
    More and more applications are being delivered as streaming and/or virtual applications, or are being installed on virtual systems, sometimes in use and other times not.  In some cases, you must capture information from the virtual server (e.g. Citrix) to understand what users have accessed a particular application.
  • Measurement of non-installed applications
    Using the old paradigm of application installation alone does not provide a count of “non-installed” applications. Some software license entitlements are based on metrics such as usage, and/or access or maybe just how many employees you might have in your enterprise. The most typical example of this type of model would be CALs or Client Access Licenses.

Purchasing Data
Oftentimes people entering software purchasing data into financial databases are the same folks entering all purchasing data, so software to them is the same as a desk or a chair. However software purchases involve many other variables that must be considered to make a competent, optimized procurement decision. Sometimes the data entry person is not entering all of this data into the system, since the system may not have been designed to store the data, or simply because they haven’t been told to capture the data.

When purchasing software key data to collect includes:

  • SKU data
    SKU numbers are unique for each software application instance, including details on how the software was purchased. Obtaining the SKU data will help you reconcile your purchase with the applications reported from the inventory system.
  • Purchase type
    You need to know if a product was purchased as a standalone shrink wrapped product, or under a volume agreement. If a product was purchased under a volume agreement it will typically come with additional rights, such as the right of second use, which when reconciled against an inventory would significantly reduce the license position as compared to the standard inventory count. Also it’s good to know if the purchase was only for an upgrade of an existing product license or for the full licensed product.
  • Maintenance
    Maintenance generally provides upgrade rights, so while your inventory might show newer versions of the application installed, and you might think you need to purchase new licenses, the reconciled upgrade rights will show you your true licensing position.
  • Bundled software
    When software is purchased as a bundle, it needs to be reconciled as a bundle, or else when viewing the raw inventory, you might make the wrong decision and allocate licenses for individual applications instead of applying the product suite license. This, in turn, may lead you to believe, erroneously, that you need to purchase additional licenses.

Vendor license agreements provide entitlements that define how licenses are consumed. These entitlements include Product Use Rights such as upgrade, downgrade, right of second use, and others.

  • License consumption
    An inventory count does not equate to a license consumption count. When measuring what’s consumed versus what’s been purchased, inventory information will only contain counts of what’s installed. While most entitlements indeed provide the right to install, some software licenses will allow multiple installations to be covered by a single license. In other cases entitlements are based on user counts and not device counts, while still other entitlements might be based on user access and not on installations, so you will need much more than just raw installation counts.

Lessons Learned
So how do you solve this problem? Well step one would be to start making sure you collect all of the relevant data needed for license reconciliation and optimization. Step two would then be to obtain a robust next generation software asset management solution. This would enable your IT organization to keep track of what applications are installed and in use throughout the physical and virtual enterprise, as well as what entitlements have been purchased to provide a reconciled license position.  Software asset management practitioners would be able to optimize their software investment, reduce costs, and avoid vendor audit surprises.

So in summary, the lessons learned should be:

  • Start collecting complete and accurate inventory and purchase data;
  • Obtain a robust next generation software asset management solution;
  • Do not use a 1920’s map to navigate to the White Mountains;
  • And probably the most important, don’t be thinking about software asset management problems when riding through the beautiful mountains of New Hampshire.


Leave a Reply

Your email address will not be published. Required fields are marked *