A common scenario encountered in many companies is the existence of many different license files from one software supplier with the same software features used by different vendor daemons. For example, a company could acquire software licenses from one supplier for CAD and CAE at different times and at different locations. Software features in all these license files could be identical. In cases like these, it becomes extremely difficult to measure true usage of such software features within the company. Read the section titled Vendor Consolidation using Vendor and Feature Pools below to see how a company can significantly reduce licenses thanks to the tools SAO provides.

Example: Feature Pool

Some software suppliers use variations of feature names for the same feature in the same license file based on the time of acquisition of these features. So a CAD feature like MD could show up as MD_xxx, MD_yyy, MD_zzz and so on. Most software usage tracking systems will provide usage information for each of these features, when in reality software usage of all of these features should be reported as one feature only.
Altair SAO provides an easy way to handle this by defining a Feature Pool called MD that pools MD_xxx, MD_yyy, MD_zzz etc., so the total availability of licenses is the sum of license counts of each of these features. Similarly, one can also create feature pools for the same feature existing in different license files. Altair SAO provides an administration tool to easily define these Feature Pools.

Example: Vendor Pool

Altair SAO provides out-of-the-box functionality to define vendor pools by assigning different vendor daemons to a pool. All of these vendor daemons serve licenses using their own license file. Vendor Pooling is very useful when a company has multiple vendor daemons provided by the same supplier. When different vendors are pooled together for reporting, and feature pools are defined for identical features existing in different license files, the license count for each software feature from each vendor is added up to get a total license count. Altair SAO provides an administration tool to define Vendor Pools.

It might so happen, based on how these vendor daemons are configured to provide licenses, that there could be denials even without exceeding the total available license count in the vendor pool for the feature, because one of the vendor daemons could have run out of licenses for a software feature but would obviously not be aware of the total license count for the feature across all vendor daemons.

Vendor Consolidation using Vendor and Feature Pools

When there are multiple vendor daemons serving licenses using their own license files, companies often attempt to consolidate these into one or two vendor daemons. In order to do this, there needs to be a way to inspect software usage across all of these vendor daemons as a single vendor to evaluate ‘true peak’ usage of each software feature in the license file.
Let us inspect a simple example provided below:
This chart shows peak software usage of a particular software feature provided by 2 vendor daemons, one for Michigan (Eastern Time Zone) and one for California (Pacific Time Zone). The time axis is shown in GMT. The Michigan vendor daemon’s license file has 28 licenses for one feature, while the California vendor daemon’s license file has 16 licenses for the same feature. If the company were to consolidate these 2 vendor daemons using the total licenses from these two vendor daemons, the new license file could have 28+16=44 licenses.
However, upon closer inspection, especially because of the difference in time zones, users in Michigan most often start using the software 3 hours before the users in California. Looking at the consolidated peak usage appearing in GMT, it is clear that in reality, the total actual peak usage is no more than 36! If in fact the company were to consolidate these two licenses and vendor daemons into one, a total license count of 36 for that software feature would suffice, which is 8 less than the total license count this company is spending for today.
Configuring a Vendor Pool with these 2 vendors, and a Feature Pool for this software feature using Altair SAO, enables reporting of ‘true peaks’ for this software resulting in potential savings.

Handling False Denials using Vendor and Feature Pools

In some cases, end users can have software installed on their desktop pointing to a number of vendor daemons in a certain order. When a license is requested, the license path or pointer attempts to check out a license from the first vendor daemon in the list, and if there are no licenses available, it hops to the second vendor daemon till finally either the software is either able to checkout a license from a vendor daemon that has licenses, or a denial is reported. While hopping through these different vendor daemons, a number of denials are generated in a short time span. If the user ultimately gets a successful license checkout from one of the vendor daemons, the earlier denials should not be reported as denials at all because there will be a successful license checkout within a minute or two after getting multiple denials from the vendor daemons appearing initially in the list. Defining a Vendor Pool for these different vendor daemons, and a Feature Pool for all identical features available in individual license files, provides for a way to filter out ‘false denials’.
Stay tuned for the next SAO blog post about Altair SAO’s License Simulator that will enable “What-if” analysis!