Vous êtes ici

What is a software library and how do I choose the right one?

Written by Matt Fisher On the 0 Comments

In the previous blog post, we talked about the importance of software recognition. We explained how those millions of exe files spread across PCs, laptops and servers in use around the organization need to be quickly and accurately reconciled against the commercial software that’s actually being used (and thus needs to be licensed).

We mentioned that the Snow Software Recognition Service (SRS) is a key component of understanding exactly what applications and other software are on the network. We also highlighted the fact that (as of writing), the Snow SRS supports over 32,000 vendors and 210,000 applications. But what does that really mean? For sure, the numbers sound impressive in isolation.

But numbers alone don’t tell the full story.

What is a software library?

The names used might change according to which SAM solutions vendor you’re talking to, but essentially a ‘software library’ is the database that governs the recognition of software discovered by inventory solutions (some inventory solutions have in-built software libraries, sometimes the software library is actually a feature of the Software License Optimization solution). The primary purpose of the library is to transform raw audit data into recognizable software names so that a SAM manager knows what’s deployed across the network and what needs to be licensed. But how the software library goes about achieving this can vary widely.

  • Software libraries come in different shapes and sizes:
  • Platform-specific (e.g. Windows-only) or multi-platform (covering Mac, Linux, UNIX)
  • Publisher-specific (e.g. Microsoft) or multi-vendor
  • Static (i.e. fixed, updated manually by administrator, if at all) or Dynamic (automatically updated by the SAM solution vendor)
  • ‘Simple’ recognition (e.g. using just exe data) or ‘Complex’ recognition (e.g tying together multiple footprints such as executable meta, registry entries, SWID tag data, package manager details or product specific details gathered by running scripts. Especially within the datacenter products where a more advanced product recognition toolbox is required)

Extending the software library

As per our example in the last blog post, most software libraries worth their salt are capable of transforming winword.exe into “Microsoft Word” (hopefully they will also be able to tell you which version of Word, but not all will!). That’s great, as far as it goes. But imagine you’re managing a multi-site, multi-national network. Do you really want to sift through hundreds of reported “Microsoft Word” instances to find out which versions they are, whether they’re standalone installations or part of an office deployment, or what language editions are installed where. It doesn’t exactly sound like fun. Solutions like Snow License Manager make use of a much more comprehensive software library designed for larger or more complex enterprises. The Snow approach automatically extends the software recognition capabilities to reduce the manual workload of software managers. For example:

  • Automatic grouping of suites and bundles – Snow recognizes where applications are installed as part of a commercial bundle and automatically groups them into licensable suites
  • Automatic normalization of product versions – while Snow recognizes the difference between Adobe Acrobat Standard 9.01, 9.05 and 9.1; in the main interface it presents them all as "Adobe Acrobat 9 Standard", as that’s what needs to be licensed.
  • Automatic population of upgrade rights based on product release dates automatically populated into the software library
  • Automatic management of vendor acquisitions to ensure products that have ‘changed ownership’ are shown under the correct software publisher
  • Automatic categorization of software (according to UNSPSC standards) to highlight potential duplication on the network

It’s not all about the numbers So while the numbers are important, it’s important to see beyond the SAM vendor’s hype and look for the actual capabilities of the software library.

Here are 10 question you should ask your current (or proposed) SAM solutions vendor:

  1. Is the software library tied to a specific inventory solution or can it import, process and cleanse audit data from multiple solutions?
  2. Is recognition based on single-file processing or multi-touch recognition?
  3. Does the library support SWID (SoftWare ID) tags where implemented?
  4. Are applications automatically grouped into suites and families where appropriate?
  5. Can the library suggest appropriate entitlements from the license repository to cover identified software?
  6. Does the library automatically differentiate between similar products with different SKUs (Stock Keeping Units)?
  7. Is the software library updated automatically or manually?
  8. How often is the software library updated?
  9. Can the library distinguish between different editions of the same product?
  10. Are the software library and individual apps automatically updated to reflect software publisher acquisitions and changes?

Only when the SAM vendor can answer ‘yes’ to all the questions above can you be confident that the software library is going to add true value to your Software Asset Management program. After all, what’s the point in selecting a solution with a software library containing a claimed 300,000 applications if it can’t actually help you apply the correct licenses?! So the next time you’re thinking about the software library, perhaps it would be better to look at it not as a simple table of individual files but instead a complex relational database that, if configured correctly, can make a huge difference to your Software License Optimization efforts.

For more information on software recognition and how to optimize software licenses, read our FREE guide: “SAM in an imperfect world