‘On a scale of one to ten…’ is a classic prompt that has been used to measure just about everything: emotions, the success of a new film or employee performance during reviews. And why not? The scale is concise. It’s simple and succinct. It can capture complex data from a variety of sources into condensed, easily transferable and comprehensible numbers.
Now the ‘one to ten’ scale is helping classify how applications are performing across the WAN via the Application Quality Score (AQS) metric.
AQS provides some basic numbers with big repercussions – numbers that could help businesses build better relationships between IT staff and senior managers, streamline processes, improve customer relations, guide wise investments, minimise downtime, and create some pretty interesting graphs.
What is AQS?
Today there is no standard indicator for application performance across networks – and with good reason: there are very few standard applications. AQS confronts this issue by operating as a composite indicator.
By combining a variety of sub-metrics (such as round trip time, server response time, transaction activity and TCP retransmits) and unique ‘one-way’ network metrics (such as transit delay, loss and jitter), the ‘one to ten’ AQS score is a top level view that reflects the application performance that remote users experience over the WAN.
How AQS can help improve application performance
AQS acts like a compass, pointing IT departments to where an issue lies and then allowing them to find a solution. Poor application performance can be the result of the network, the server or the application itself. By creating a metric, AQS indicates which of these areas, and where within these areas, any issue is to be found.
For example, imagine the AQS indicates that the network is the cause of poor application performance. IT staff would be able to delve deeper. They would be able to answer two related network questions: is the network itself experiencing a fault, or is the network jammed with too much traffic from multiple applications? All this information is contained within the composite parts of the AQS metric.
From there, IT staff could go about finding a solution: if the low AQS score is due to of a faulty network, then the network provider would be responsible for improving it; if the score occurred because of too much traffic over a perfectly suitable network, the IT department would have to unblock the traffic jam.
They may choose to do this by determining which applications are business-critical (such as ERP, CRM, videoconference, etc.) and prioritising them. Applications like YouTube or Facebook may be deemed as non-critical, in which case a company may allow an AQS score of 2 or 3. The same company may want an AQS score for critical applications, like SAP or VoIP, to be at 9 or higher.
To keep with the previous example, if the low AQS score indicated the problem was a result of too much business-critical traffic, then companies would know they need to direct funds towards increasing bandwidth, and better still, they’d have the information to make the business case.
Why IT people need AQS metrics
Conveying IT information about applications to senior officials can often be challenging. KPI, SLM, SLA, WAN optimisation – these are all terms that managers and senior staff may not be familiar with. AQS helps make the language of IT more approachable and even more visually stimulating, owing to the visual nature of dashboards. The metric of ‘one to ten’ is simple and easy to understand.
Without such measurements, it’s difficult to set application-related goals. Under such circumstances, when issues arise, tension between IT staff and management inevitably follows. Management see IT as expensive and not performing well; the IT department is put in the uncomfortable position of being on the defensive.
In contrast, when there is a metric, a clear indicator that simply and easily points to the heart of an issue, it’s much more possible to positively respond to arising difficulties. IT staff have data and information they can provide to senior officials.
Additionally AQS improves user complaint handling. When people do complain, IT staff can see the information needed to help users, even if it is something as simple as being able to describe the problem and tell the customer when it will be fixed.
Consider a non-IT example: an individual misses their train. Not knowing when the next train is set to arrive may cause distress. Conversely, knowing how long the delay will be allows the individual to be proactive rather than reactive. Think of the AQS like a digital train board. Using the advanced information on application performance IT departments can better serve users.