Skip to main content

The balance of proactive and reactive technologies

In my role, I frequently interact with IT professionals and learn about what keeps them up at night. I learn about how they juggle projects, stay ahead of the curve and meet the needs of the organisations they support. 

What I find most interesting - regardless of the size of the organisation or the number of admins and engineers on staff - is there is often a lack of balance between the proactive and reactive. Specifically, I am referring to the balance and difference between monitoring and diagnostics.

I’ll examine these two critical elements as they relate to IT visibility and how organisations consume the data and information to successfully navigate each discipline. Monitoring is often categorised as a luxury. It’s a job function that may have a dedicated staff, or perhaps is something given lip service, but not the time, energy and focus it deserves. 

At its core, monitoring is about being proactive. It’s about observing and checking quality, and includes important supporting elements such as security, alerting and reporting. Diagnostics on the other hand, is a reactive task; something performed when you are in jeopardy. 

It is a methodical process - a troubleshooting exercise - that involves the identification of symptoms and ultimately a determination of causality. In the world of end-points, specifically around security, meeting expectations, performance and end user experience, diagnostics is something everyone must be prepared for. 

After all, it is not a matter of ‘if’ things may go pear shaped, it is a matter of ‘when.’ Ironically, few invest the time up front - in fact, only those who have suffered (or are currently suffering) truly understand the need to mitigate the risk and put themselves in the best possible position to react accordingly.

What does this have to do with end user workloads? 

When we look at the different approaches that provide for next generation desktop workloads, we are talking about technologies and platforms such as RDSH, VDI, published applications, terminal or remote desktop services, etc. 

In short, we are referring to the movement of end user workloads from the employees’ desks to the data centre. Of course this shift comes with profound operational and end user benefits. But the shift also comes with an increase in complexity and, ideally, a more thoughtful and strategic approach to support and meet user experience expectations. 

From a monitoring and diagnostics perspective, these elements and the balance between proactive and reactive tasks, is a bit of a “cause and effect” relationship. That is, the more focus placed on proactively monitoring the environment, the less you are at risk; and the less reactive you will need to be for events out of your control. 

That is not to say you will entirely avoid the need to reactively diagnose in an effort to minimise downtime. Remember, you still must plan and be prepared for unavoidable issues that will ruin some random Tuesday. On that very specific note: one of the greatest points of interest I find when speaking to IT professionals is how little attention is paid to diagnostics versus monitoring. 

Monitoring is relatively easy to understand and conceptualise. The risk in your monitoring choice is very low (as compared to your diagnostics choice) and many of the user interface and features decisions are subjective. Further, monitoring is a bit easier to sell to leadership. 

It’s easy to bring a sexy dashboard to life on that big monitor in the network operations centre. And tasks such as end-point security, alerting and reporting will go a long way to getting the appropriate head nods with management. But how do you ‘sell’ diagnostics? How do you cost justify the opportunity to be prepared, to minimise downtime and keep users productive. It’s a lot like trying to cost justify insurance. 

Don’t wait for downtime to react 

The easiest way to justify a purchase is when you have no other choice. Wouldn’t it be amazing if you could purchase car insurance after you’ve had the accident? I can share countless stories of organisations and top-notch engineers who were unable to dig themselves out of an end user issue.

It’s unfortunate, and very common, to find professionals who have spent countless hours looking at server, storage and software architecture details gleaned from an existing monitoring platform, to only chip away at a major issue – or, more commonly, never get to the point of identifying root causality. The ability to diagnose and visualise cycles and trends in a user-centric manner is relatively new. 

More importantly, this ability is more difficult to accomplish than monitoring and fraught with far more risk. And, unless you’ve lived to tell the tale, it’s extremely challenging to bring this important point to life. When choosing a solution, be sure to understand the proactive and reactive tasks it will support. 

Typically a solution is geared to support a discipline such as monitoring or diagnostics, but not both. When employing a monitoring tool to diagnose, for example, it is typically possible to examine issues on a one-at-a-time basis. Problems and alerting issues all seem small and insignificant. 

The fact they were missed would come as no surprise to any IT pro. The failure, however, is a lack of end-to-end visibility to support diagnostics. Planning for the reactive need to troubleshoot, diagnose and determine root cause cannot be done after the train derails. Having the necessary metrics and trendable details is necessary to identify and place your organisation in the best possible position for when catastrophe strikes. 

The skills, tools, and ultimately the visibility required to proactively monitor versus reactively diagnose are very different. I have witnessed this first hand. I have seen organisations invest in a monitoring platform - placing a significant emphasis on features such as alerting, reporting and dashboards - only to be left out in the cold when they are in jeopardy.

That’s not to say monitoring features are not important; only that the effort must be balanced, with an emphasis on minimising risk and planning to react.

Kevin Cooke is a product director at Liquidware Labs

Image Credit: Enzozo / Shutterstock