What is Software Normalization and how will it help me?

Software normalization is a SAM process that aims to remove irregularities in software titles so that they converge to a single publisher, product title and version. This will enable you to manage licenses more easily.

Normalizing your software data is essential to getting accurate, quality reports needed for Software Asset Management.

Software Normalization example
Software Normalization example

The problem in software normalization is that there is so much variation in these fields that the normalization process has never resulted in satisfactory results for quality reporting, until now.   

If you’re frustrated by the lack of normalization in tools like SCCM or Lansweeper, or unimpressed by the normalization from Snow of Flexera, keep reading. AssetLabs normalization and categorization is miles ahead of what you might be accustomed to.

AssetLabs Software Normalization, Categorization and License-type identification is available for any tool such as SCCM, Service Now, Lansweeper, Kace, Tanium, Altiris, Solar Winds and more.

Software Normalization Approaches

Today, many SAM tool providers still maintain a one-to-one brute-force method of exact record cataloging. Due to the high variability in software titles, this approach has never achieved a significant level of confidence, and requires costly human effort.  Even today, many of the more-popular SAM tools still struggle to maintain a 50% normalization success rate.

AssetLabs approaches this 20 year old problem of software normalization from a different perspective. We have architected proprietary methods in which every software title has no choice but to be normalized.

Unique to AssetLabs is the Productline. This is a new SAM data element that represents a version-less product title that belongs to a publisher in which all past, present & future versions of a product can fall into and automatically adopt the metaproperties of its parents.  For example, Excel XP, Excel 7 and Excel 2010 are all child versions of the Microsoft Productline of Excel. More importantly, the Productline inherently declares and maintains the normalization requirement for all current and future versions of that product discovered.  As a result, AssetLabs is able to maintain a 100% normalization of all new software titles. AssetLabs’ ProductLine structure was adopted into the ISO-19770-2 architecture in 2012.

Normalization Examples

AssetLabs uses advanced algorithms to correct publisher names, malformed software titles, and extract versions from the software title. The result of our extensive 10-year software catalog combined with thousands of normalization rules results in the best software normalization on the market. Our world-class normalization is available in our Streamline service, available as a free trial.

New product insert process diagram
Fig1. New product Line Insert Adoption Process

Publisher Adoption

A common problem in the SAM world is the absence of key information in the expected fields. For example:


Raw Record

RawPublisherRawTitleRawVersion
 Microsoft Office Professional15.11

If you tried to report on products where publisher=”Microsoft”, you would miss this record (and potentially many others.)

Our engine automatically detects Publisher names in the title field using a catalog of 90,000+ publisher names and 20,000+ publisher Aliases (alternate names, acquisitions, name changes, mutations of names etc.) The publisher name is then automatically filled in to the normalized record and trimmed from the software title.

Normalized Result:

PublisherTitleVersion
MicrosoftOffice Professional15

No Publisher information at all

A more advanced technique exclusive to AssetLabs is the ability to identify missing publishers when the publisher name is absent in the raw record. Given our extensive catalog, we are able to intelligently insert publishers.

Example:

RawPublisherRawTitleRawVersion
 Acrobat18.0
Raw Record

By checking the uniqueness of the product called Acrobat, the product is then adopted by that publisher.

Normalized Result:

PublisherTitleVersion
AdobeAcrobat18
AssetLabs Normalized Result

Version & Model Extraction

Versions are another attribute that are not commonly populated in the expected Version field, or incorrectly populated. We are able to extract any numbers from the product title and version field to create Version Candidates. All version candidates then go through a separate version algorithm which ranks the candidates to eliminate bad or unlikely versions and find the most likely version.

Ex.

RawPublisherRawTitleRawVersion
 Microsoft Office Professional  2013  v15.11 build4a1.00
Raw Record

Version Candidates:       
v15.11  <= High Ranking version
2013     <= More likely a model, but in the absence of a high ranking version may be a version
1.00        <= Unlikely version
build4a  <= build number

PublisherTitleVersionModel
MicrosoftOffice Professional152013
AssetLabs Normalized Result

The resulting normalized title has all version candidates stripped out to provide a clean title name, and the raw declared version “1.00” was changed to the more likely “15” version. In addition, 2013 is inserted as a model number. We can also use the model number as a lookup to insert a version when no version is present because our catalog knows that model 2013 of this Product-Line is version 15.

Vendor Specific Rules

Our advanced normalization even has rules that are vendor specific. For example, Oracle sometimes publishes Java versions as 1.x.yyy  where X is the actual version and YY is the update number. Our engine automatically extracts this information to create proper versions as follows:

Oracle Java version normalization
Instead of an incorrect 3 counts of version 1, you have the correct 2 counts of version 8 and 1 count of version 5

Title Noise

One of the most difficult aspects of normalization is removing “noise” from the title. Noise is considered any part of the title that creates a mutation from the actual title, preventing the title from converging to the proper productline. Examples are foreign language variations, build and revision numbers in the title, and “mojibake” created through the conversion of one type of character set to another (ex. UTF-8 to ANSI text)

In the following example, these 12 raw titles from Altova all converge to a single Product Line after removing the noise.

Software Normalization example Altova

Because they all converge to a single Product Line, they automatically inherit the pre-established meta attributes of the parent:

Software categorization example

Because the title has been normalized, we can add in all sorts of information automatically from our catalog such as license-type information, category information, and even end of support information.

In conclusion, you can see that Normalizing, Standardizing software information results in much better quality data. Better quality data results in better quality reporting. This is KEY in a good software asset management workflow.

About AssetLabs normalization catalog:

Founded: 2010
90,000+ Publishers
20,000+ Publisher Aliases
3 Million+ Software Products
Normalization speed up to 450,000 Records per second
100% Normalization Rate

For additional inquiries or for more information on AssetLabs, please contact us.