SAM tools automate many of the tasks required to maintain compliance with engineering software licenses, thereby controlling software spending. At the core of compliance and cost optimization is license usage, which, in theory, can be tracked just by monitoring the executable file of the engineering software (the most basic method). But don’t fall for this theoretical trap, because in the engineering world the executable file shows only a fraction of the data you need to get the full picture on license usage. Read on to understand why.
While tracking the executable files provides a certain stream of data and may seem enough in the case of named or node-locked licenses, things get very complicated with the network licenses prevalent among organizations working with engineering applications. Therefore, claiming that simply monitoring the executable file on the end-user workstation SAM tools can give you all the needed information is invalid. The reality is that this method misses out on key data layers, because these tools are limited to just a certain level of data stream and are unable to see the complete picture. There are many reasons why, but we will list only three.
A SAM tool tracking the executable file doesn’t know
- which license level and/or feature the end user has pulled on their workstation;
- which license manager has provided the end-user workstation with an engineering application license;
- which license pool provided the engineer with the license in a multiple-pool environment.
As you can see, the executable file is blind to almost all the relevant data you need to monitor actual license usage; therefore, you are missing out on balancing cost, opportunities, and performance. Let us explain with real-life scenarios using engineering software at organizations.
By monitoring the .exe file, the SAM tool misses out on license consumption
Let’s take Esri’s ArcGIS Desktop engineering application, for example. ArcGIS Desktop is available in three license levels: Basic, Standard, and Advanced. The license levels share the same core applications and user interface, but each license level provides additional GIS functionality and comes at a different price. The problem is that the Esri business model is built around one executable file, argics.exe, regardless of the license level the end user consumes when starting the engineering application. In other words, by tracking the executable file, you can tell that the engineering software is running, but you are missing out on information about the license consumed. That means that without a monitoring solution such as OpenLM, the organization’s engineering license usage (and therefore the license cost) is out of control (in the case of floating licenses).
But there is more. Esri provides apps and extensions for its ArcGIS Desktop suite to streamline engineers’ work. Some of these extensions are free, but others require a license. To start working on the project he or she was assigned to, the engineer launches the ArcGIS software and pulls additional extensions, so in the end he or she consumed three licenses at the same time (the ArcGIS app, CityEngine, and UrbanSuite, for example). Yet again, the executable file sees that the engineering application is running, but it doesn’t know that extensions (and therefore licenses) were loaded into the app; hence, licenses were consumed. That’s alarming!
We have used ArcGIS as an example, but the same goes for MATLABS’s or Bentley’s engineering applications just to name a couple. Since it is built around one executable file, the SAM tool completely misses out on license consumption. The best engineering license monitoring solutions give you an accurate insight into what’s going on within your organization’s network at a glance in an easy-to-understand manner. You need to know exactly what’s going on and who is using what and where. That’s what the OpenLM solution provides.
Compliance concerns
In an engineering environment, it is rare to have just one license manager providing end-user workstations with concurrent software licenses. Add to that a team consisting of hundreds of engineers spread across the globe. So, when an engineer pulls a license, you need to know exactly which license server has provided the end user with that license; otherwise, you may run into compliance issues, which could cost the company tens or hundreds of thousands of dollars in compliance fines.
So, you need to know whether it was taken from the license server of the headquarters – let’s say, London – or if it was from a server located in Beijing. This is highly important information you need immediately because of the engineering license agreements you have with the vendor: some licenses are limited to a specific location, such as the UK, China, or the US, so when an engineer from China pulls a license from the UK pool, you then have a compliance problem.
The .exe-tracking method doesn’t provide answers, because it doesn’t have information about the location of the license server. It checks only whether the engineering software is running, and that’s it. By comparison, the OpenLM solution gives you precise data about which license manager served who and allows admins to set rules based on the license agreement’s geographical locations (and many more options) in order to avoid compliance fines.
By tracking just the .exe file, you don’t know exactly what’s happening
In an engineering environment you need to understand what is happening and react accordingly in an instant. Take the denials issue, for example. As we mentioned above, in the majority of cases, the organization is using floating licenses to optimize their license costs and realize value from their software assets. To do that, organizations often turn to license models called multiple pools. For example, the Flexera network license management system employs license files to track client license inventory. The license file is an account of purchased licensed features, each with respective attributes such as the licensing model, the number of licenses, expiration date, etc. Licenses for equivalent features may be bought separately, thus forming separate “pools” in the license file, each pool determining specific attributes.
So, in some cases, when an engineer runs the software application ArcGIS, he or she might get a denial, meaning that he or she couldn’t get a license from the license pool. This raises questions, which the SAM tool must help you to answer the following questions:
- Did the engineer get a denial because there were no licenses?
- Did he or she get a denial because he or she tried to access a license from the wrong allocation pool?
If you track just the executable file, you will likely see the issue; however, a SAM tool won’t be able to provide you with an answer, because it doesn’t have access to this data layer. So, even though you are monitoring the engineering application, you are left without answers unless you turn to monitoring tools such as OpenLM. The OpenLM system can report license usage levels of multiple pool licenses very well; it locates features that appear in multiple pools and provides all the data you need in an easy-to-use dashboard. Want to learn more about the OpenLM solution? Head to our website or reach out to us via email.
