Accurately reporting on historical application use requires granular data. Granular data can be viewed as specific data elements: what application was launched, who launched it, where did the license come from, when did the license stop being used, when the window was re-opened, etc. The greater the number of attribute elements that can be gathered, the greater the ability to answer usage questions. Gathering attribute information typically involves consolidating data from multiple sources to create a mini-data mart. Data marts help ensure usage context information is available to assist in data exploration. Visualizing data in real time, in contrast, requires accessing a pre-defined subset of the data, and also typically involves comparing the data to some pre-set or easily calculated metric.
To support the differing needs of data analysis/exploration and real-time visualization, application use reporting vendors must implement different tool sets. Analysis/exploration tools work with defined data groups to find relationships. These tools typically have elaborate user interfaces to help isolate, define and present specific data attributes. Real-time visualization tools, or dashboards, in contrast, provide graphs, charts and other simple models to allow quick analysis of data. Creating dashboards usually requires understanding and presenting data relationships that range from the very simple to the very complex.
Dashboards typically present two kinds of use cases:
- Status conditions, such as whether a server or process is available, or how many licenses on a license server are consumed versus the total available
- Calculated conditions, such as quantity of license tokens consumed in a time period to date vs. allocated to identify if consumption is within target
Dashboards typically display information in real time, with real time being a relative term. Status conditions often update as soon as a change is measured, whereas calculated conditions tend to be updated less frequently. If data to support a particular measure are updated on a daily batch basis, then real time is one day. Conversely, status changes, such as when licenses are checked out or in updating may reflect events occurring within seconds, and often have additional event or threshold triggers to operational systems to initiate some kind of action. An example would be sending an alert to a manager when 90% of available licenses have been consumed so she could determine whether a problem exists that might impact service levels.
Information updating can occur in a number of ways: scheduled, that is, pulling information from one or more data sources at pre-determined times; or pushing data as a result of a trigger or threshold event. Each approach is independent of additional calculation that might be needed to post or update information to the dashboard. Application vendors are increasingly enhancing their applications with Application Programming Interfaces (APIs) to make it easier to access data elements.
APIs make accessing data easier because the rules for data access, security and format are defined and consistent. In addition, APIs can allow or restrict access to the same information, either on a scheduled/unscheduled or transaction/batch basis. By implementing APIs, application providers more easily enable user organizations to create dashboards, make data available to other applications, or incorporate data into other organizational processes.
Granular data presents a tradeoff for analysis. On one hand, the organization is able to more discretely pinpoint specific status or relationships, such as when a license was active or inactive, or identifying users who are lagging in upgrading to a new application release. On the other hand, granular data increases the total number of data elements that potentially need to be filtered, or aggregated for the analysis at hand.
Cetrus Process Meter provides both APIs and granular use data to support very discrete application use analysis and dashboards for data visualization.
If you’d like to learn more, send a note to firstname.lastname@example.org and we’ll help you understand what information we can provide today, and where we’re going. Our intent is to provide both more data attributes, and more actionable data available than any other application use monitoring solution currently on the market.