This is the second in a series of posts that address the application use reporting question, “Who is using what application and for how long?” Last week we discussed some of the issues with identifying “who.” This week we’ll discuss the “what is the application” aspect of the question.
We’re focused on applications running on desktop devices, so we’re not going to look at server-centric enterprise applications, databases or SaaS applications.
When an administrator asks “what application,” the context has to be understood. The administrator or analyst typically needs attribute information to answer the question. Let’s use Autodesk’s Revit as the example application. Following are some of the attributes the administrator would like available:
- Autodesk includes Revit in its Building Design Suite
- Revit is available as a standalone Collaboration Suite
- Revit LT is available as a standalone application
- Version: Autodesk makes Revit available in Premium or Ultimate Editions in the Building Design Suite
- Year: The Revit Suites and Versions are licensed as years. A user having open at the same time two different Revit years (2014 and 2016) might be consuming two different licenses.
- Update: What is the update level? Organizations trying to determine stability issues need to know the update history and current update level.
- License type: The license might be a perpetual license coming from a license server
- The license might be a standalone (one desktop) perpetual license
- The license might be a one-year subscription license delivered from a license server
- The license might be a-one month subscription license
- What license was used: Was the license consumed actually the license requested (customers may spread licenses across multiple license servers, and may have multiple versions). With Building Design Suit or Revit LT, if all the LT licenses are consumed, the license server may make a more expensive Building Design Suite license available. While this is good for the specific user, it reduces available Building Suite Licenses.
When trying to answer the “what is the application” question, the administrator needs to be able to report on any of these attributes to come up with a count, comparison, time or location of use. Unfortunately for the administrator (and for us monitoring and reporting tools vendors), the attribute information can come from different locations depending on the license type, year, etc. In addition, some of the license server attribute information is encrypted, requiring the user or reporting tool vendor to come up with other mechanisms to match a license requested to the license consumed.
We’re not trying to pick on Autodesk, but their packaging has made gathering application attribute information difficult. For example, when Autodesk packaged multiple applications into Suites, the individual applications lost their unique Feature or Product Codes. Application licenses are reported from the license server as one Feature code for a Suite. Individual applications within a Suite may not be distinguishable in the log file.
Autodesk charges different fees for different Suites and standalone products, so “what is the application” can have significant economic and application access implications as the number and variety of applications and packages increase.
Each reporting tool started from a different vision of the primary problem it was solving. This vision typically started with where the reporting tool gets its data. Every data access approach has strengths and weaknesses. If the vision was to report use for medium-large companies running licenses from license servers, then the tools are limited to the data coming from server logs. Standalone license use can’t be reported because there is no mechanism to gather standalone use information. Log files will provide information as to whether a license was checked out, but it can’t tell if the application was being used. Reading a registry file can tell if an application is installed (this covers standalone applications), but these don’t account for usage at any given time.
To be able to universally report on desktop usage, a tool needs to be able to monitor use at the point of use – the desktop – and pull supplementary information from wherever that information is available. This approach appears messy and complex. It does offer the possibility of gathering available attribute information, and combining data from different sources such as associating an application requested at the desktop with the license delivered from a server.
If you’d like to learn more about how Cetrus is changing the way to understand “what is the application,” please send us an email at firstname.lastname@example.org, or fill out our contact form. We’re confident that we can cover more of the possibilities than any other reporting tool on the market.