This is part 1 of a 4 part series of posts focused on rightsizing software license inventories at a company.  Modern software is expensive, costing thousands of dollars per seat, and usually offered as a shared license pool.  These posts will discuss the needs, requirements, and analysis leading to optimized license inventories. 
Background
Many companies use sophisticated and expensive software systems to conduct their business.  There is a variety of software used by enterprises for design, analysis, factory automation, resource planning, finance and so on.  Software vendors typically offer a shared licensing business model where users access software subject to availability of licenses for a given software feature, as opposed to named-user or node-locked licenses prevalent many years ago.  Companies purchase a pool of licenses for required features intended to be shared by a group of users.  It is quite difficult to track who is using what software, when and for how long for the hundreds of software features used by companies.  Many companies use some software usage tracking system to track software usage.

Companies need to have enough software licenses that allow them to do productive work.  Not too many, not too few.  For interactive software, too many available licenses result in no denials attributed to lack of licenses.  Too few available licenses result in a high number of denials.  For batch jobs that are executed on an HPC, the job scheduler will not execute the job unless there are licenses available.  If there are no licenses available because all are in use, the job scheduler checks for licenses after some time.  The penalty for batch jobs in case of inadequate licenses is time spent by the job in a queue.
What triggers the need to inspect Software License Inventories?
Following are a few reasons why administrators inspect software inventories and utilization metrics:

1. Annual license renewal
2. User complaints about license denials
3. User complaints about waiting time to get a license
4. High software bills for some features

Methodology
For achieving optimized license inventory, one needs to follow a systematic approach as outlined below:

1. The first step is to measure software usage for all software used by the company.
2. The next step is to analyze usage of every software feature with objective performance metrics aggregated over a time period of a number of months
   1. Total usage typically measured in token-hours of usage
   2. Capacity utilization based on total maximum token hours available through the time period
   3. Frequency of use or the number of times a software feature was used
   4. Total number of distinct users
   5. Maximum saturation or maximum Peak usage
   6. Sustained Maximum Peak as a % of the total time period
   7. Denial of service incidences
   8. Probability of getting a denial defined as the % of checkout requests denied due to lack of licenses for all checkout requests
   9. Waiting time to obtain a license after receiving a denial
3. The third step is to use these performance metrics and historical software usage data to evaluate the most suitable license inventory for each software feature bought by the company
4. After applying changes to the licensing inventory recommended by this analysis, these steps need to be repeated every 3-4 months because of the following potential changes:
   • Users could change their behavior in response to any instituted changes to license availability or policy
   • Software suppliers could change their licensing models
   • There could be changes in project loads for different user groups

Factors influencing Software Usage Performance Metrics
Software types, licensing models and user behavior influence the right-sizing approach.

• Interactive Software

Interactive software has a GUI, and a user interacts with such programs in real time.  Some examples are CAD, PLM, CAE pre-post processing software, spreadsheets etc..  These programs check out a license only when they are invoked, and check that license back when the session ends.  When the license is in use, that license is obviously not available for any other user.  Interactive software is checked out during office hours and checked back in when users go home at the end of the day which is the expected behavior.   These programs see little or no usage during week-ends and holidays either.

For interactive software, the intent is not necessarily to have 0 denials.  That would most likely be very expensive to maintain and justify.  There should be some denials.  The tolerance level of denials will vary from company to company.  A good objective metric to check is the Denials Probability.  This can be calculated as the number of denials for every 100 license check-out requests.

Total Waiting time can be used to judge if the current license inventory is adequate or lacking.

Maximum session length allowed for a user

Some users forget to close the software session some of the times, and the license remains checked out and not available to anyone else.   Licenses for interactive software are not efficiently used when the user does not interact with them for long periods of time (Idle time).  If a license is not available for an interactive software, the user asking for a license gets a denial from the license manager.

Unless the license manager and the software using the license manager support a timeout function, it is not possible to control the maximum allowed session length for a software.  The effect of controlling the maximum session length for a software is measurable.

Maximum concurrent sessions allowed for a user

If the licensing model checks out tokens or licenses for every software instance (unlevelled licenses), number of concurrent sessions for any user will consume more licenses and will result in more denials in the system.

It is feasible to control the maximum number of allowed concurrent sessions for a user by creating a launching script.  It is possible to measure the effect of limiting the maximum number of concurrent sessions granted for any user.

• Batch Software

Batch programs typically run on servers rather than user’s desktop machines especially because of extensive resource requirements.  Batch programs do not need a user in attendance.  A user sets up the batch program inputs, and could either run it on a local machine or submit the same to a compute cluster managed by a Job Scheduling System like Altair PBS, Oracle Grid Engine, IBM Platform LSF etc.  The job scheduler checks if a required license is available and starts the job.  If a license is not available, it retains the job in the job queue.  The licensing system will generate no denials for the software because the job scheduling system will not start a job unless there is a license available.

For batch software, the principal License Utilization goal is maximizing Saturation, or aiming for 100% software licenses utilization.  This is almost impossible to achieve with Interactive Software, however, very high license saturation is possible if a company uses Job Scheduling Systems for batch jobs sent for execution to HPC clusters.  In case of scheduled batch jobs, the total turn-around time increases because of jobs waiting in the queue.  A job spending time waiting for a software license is similar to getting a denial, or a series of denials when the job is held in a queue for lack of a license.

Sustained Peak Index is a good measure to evaluate for Batch jobs.  It’s synonymous to evaluating the % of time saturation was 100%.  Achieving close to 100% saturation most of the time is a good objective, however it can come at the cost of total waiting time.  If there are more licenses, Sustained Peak times will reduce, and total time spent in the queue will also reduce.  Reducing licenses will increase the Sustained Peak times, but will increase total wait times.  The level of license inventory needs to be balanced using these performance metrics.  One could opt for achieving high Sustained Peaks for 70 or 80% saturation.

To recap, Performance Metrics described above are influenced by the following control parameters:

1. License or Token Counts – more licenses reduce denials, less licenses increase denials
2. Timeout or maximum time a user is allowed to use the software in 1 session – a shorter session makes a license available for someone else.
3. Maximum number of concurrent sessions allowed for any user – for unlevelled software, limiting the number of concurrent sessions for a user can make licenses available to other users.
4. User counts directly influence performance metrics. More users using the same number of licenses will increase denials and waiting time.

Setting Target Expectations
It should be noted that for interactive software typically used during an 8 hour shift, the maximum practical capacity utilization will be about 30%.  The only way to increase utilization is to stagger users into multiple work times.  For batch software on the other hand, capacity utilization of over 80% is easily feasible using a 24x7 high performance computing infrastructure.
In the next post, I will discuss a possible solution to enable evaluating various performance metrics predictions using a What-If simulator for different license counts, timeouts and maximum concurrent session constraints.