Understanding concurrent licensing through usage data

[Paul_Diop]

I have been asked recently by quite a few large enterprises about how they can optimize their concurrent licensing estate by analysing the usage data produced by these types of applications. In comparison to node-locked licenses (licenses locked to specific machines), concurrent licenses float across the network and are passed from user to user and machine to machine. This makes them harder to track and feels like you were trying to catch a moving bullet. Based on my numerous years of experience in configuring and analysing network licenses, I’m led to believe that there are at least four key factors to take into consideration when you want to understand concurrent licensing and optimize your landscape.

• Determine what usage means for each application
• Understand the correlation between the way the application is licensed and its contractual terms
• Design a model to apply software cost by application
• Design a reporting strategy

Knowing how to determine “Usage” of software is often overlooked and not always understood properly. Although we have reporting tools that can provide metrics such as peak, average, max hours spent or denials, these are not the only elements to be considered. Firstly, we must understand that usage can be read differently for different applications. Some applications are run in batch mode for several weeks, while others will run for a few seconds then shut down and yet another group might be user-interface based that require constant interaction. Although this seems extreme, these different usage patterns reflect the reality of what is out there. Applications with concurrent licenses are often divided into discrete parts called feature. The nature of application usage is then defined by how features are utilized in relation to your contract as well as the type of application usage patterns I mentioned earlier.

Once you are familiar with the application’s usage, you need to look more closely at how it is licensed. You need to read your contract and find the correlation between the usage of a feature or a group of features for the corresponding products in your contract and understand what you are paying for. You also need to understand the renewal frequency for the contract (yearly, quarter, etc.). All these elements define what we call the license model of an application. If the interrelation between these elements is not clear, do not hesitate to ask the software vendor since they are the ones defining it. Fully understanding the license model will allow you to focus your attention on the usage of only relevant features and under what conditions they are being used.

Being familiar with your contracts and applications and how they relate to one another will allow you to design a software cost model. It will allow you to understand how applications are used and how much it is costing you. This model will be based on the type of application, the feature-to - “contract product” relationship and the usage pattern that applies to you. For instance, for an application that is only used through a user-interface, you could be focusing on license metrics such as peak license per day, average denials per day, average time spent on the application for an individual user. Since the ‘peak’ is a complex metric involving users, elapsed time spent on the application and dates, you cannot simply compare that with “scalar” values such as denials or total time. Using averages allows for better comparison since it takes variation over time as well. You will need to get those values for features or groups of features that can be identified in your contract. You will also need to get the proper tools to obtain accurate raw usage data as well as aggregated calculated data.

Now that you understand what application you are dealing with, the relevant type of usage information required and how it is licensed, it is time for you to design a reporting strategy. This will require considering several aspects as well. For instance, do you need to consider extra data sources other than just the raw usage data. Moreover, you will need to understand how to best visualize the data to make it easier for a larger audience to comprehend.  What is the frequency and the granularity of the data to be presented: hourly, daily, monthly, or quarterly, etc? Do you need to look at the data for different time intervals: hours/day, day/month, month/year, etc? How do you want to apply cost? How do you want to archive data and how to retrieve past data? All this will need to be done per application or group of applications if they have similar type of license model.

As you can see, understanding your concurrent license usage implies that you must be able to determine the usage per application. In addition to that, you will need to decipher how the applications are licensed and how they correlate to your contract. Based on that information, you can create a model that will help apply software cost. The model will be based on software usage data. The last step in the process will be to put this model to work and create a reporting strategy in to visualize the data in that model. As you can see understanding software usage is not an easy or straightforward task, it involves having a 360-degree view that goes from understanding the license models to be applied to software all the way down to understanding the data created by the usage of every individual feature.

Having an appropriate solution like Flexera’s FlexNet Manager for Engineering Applications that let’s you enforce the correct methodology will allow you to understand your network license usage. It will allow you to be better equipped for your next license renewal. It is now time for you to start building your licensing eco-system.

[mfranz]

One could argue that this strategy does not apply to concurrent licensing only, but to most software licensing, independent of the metric. Far too often the technical solution is being trusted without actually understanding even the basics.