QoS is a measure of the overall performance of a product or service, as perceived by the end-user. In the context of engineering, QoS can be put as the ability to get the right software tool when needed, to perform the work assigned.
Let’s start by looking at some general, real world examples. We are often asked to comment on our level of satisfaction (or dissatisfaction!) at billing counters in supermarkets, while logging out of online services like games, etc. or even through the old fashion pen and paper route at hotels and restaurants.
However, in IT, QoS has a much broader scope. Imagine the plight of an IT manager in an office where the sheer volume of usage by different applications and devices, along with the excessive use of social media platforms, has put the network performance down due to a flood of traffic. Here better QoS would definitely mean that the network is readily available for important work, firewalls have been put in place to stop unnecessary leakage and the engineering team is up and ready to solve any issues.
How does QoS relate to licenses for end-user desktop applications? In the case of traditional licensing, or named licensing, QoS does not apply. Controls are specific to the terminal, and in no way can they affect the activity going on in the network, without somebody putting a check on network activity too.
However, network licenses are different. If there is more than one user on the same network, a network license allows them to share access to product licenses. The Network License Manager controls the distribution of licenses to users. Users can access the licenses based on availability and just like a physical resource, the license pool is shared amongst multiple users.
QoS can be put as the ability to get the right tool when needed. More often than not, the same application has various different versions running across the same network. Some older versions may have been retained due to cost issues, or due to compatibility with other legacy platforms. Newer versions, however, provide a better solution for a similar task.
Now let’s think of a situation. ‘ User A’ needs a license and he pulls one up from the license pool. He pulls up the newest version of the software which has some of the latest features. However, ‘User A’ works in the ‘audit’ department and does not even need the latest functionalities. In the meanwhile, ‘User B’, a senior engineer, gets the license for an older version, which affects his work.
The QoS also comes into play during the actual availability of a license. There may be times where a user asks for a license and does not get one. He gets what in engineering parlance is called a ‘denial’, and this brings the service level down.
On a macro level, if the user is asking for a license 100 times and he is getting it 100 times, we can say that the service level is 100%. Similarly, it will be 90% if he is getting the license 90 times and gets denied 10 times. The QoS is measured for the whole organization per application and not any specific user.
We also need to understand what a ‘denial’ is, and how it affects the QoS. To be put in simple terms a denial occurs when a user cannot procure a license from the pool of licenses that the organization possesses. In engineering license servers, denial measurement is complex, some denials are not a real license denial. There may be different scenarios, let us look at some of them.
Multiple license servers – Many organizations have more than one license pool serving the same application. A request that might be denied by one server might be fulfilled by another. The false-negative (in the case of the denial) might reflect on the QoS. However, platforms like OpenLM will not report such denial as a true denial and hence the service level would not be affected.
There might be a situation when a user tries to open an application multiple times after getting denials after every attempt. In such cases, many denials are reported in the raw data. OpenLM deploys smart algorithms that convert these multiple denials into a single true denial.
Borrowing and License allocations can also contribute to the QoS. Borrowing occurs when users change the network licenses to named licenses and use them (at times remotely). More often than not, they forget to return the license to the pool, preventing other users from using it.
License allocations occur when the IT manager reserves a license for a particular person or a group irrespective of whether they are using it. Reservations need to be done very carefully as there is a possibility of affecting the QoS negatively, especially when other users will get denials when they make license requisitions.
We, at OpenLM, firmly believe that this is the right time to invest in a system that monitors your engineering licenses effectively. For accessing a full-featured 30-day trial version of OpenLM visit us here.
