What happens on an end point often stays at the end point! And when those end points are a home Mac, an iPad, or a PC owned by a contractor, it's even less likely you will know about it. In order to deliver a good user experience with BYOD, IT needs lots of visibility into what is happening on an end point.
If a user is unable to access an application, then they will probably try once or twice and then give up. The problem could be because of the device (new phone), or their wireless network (AT&T, Verizon, etc.), or their geography (the upgrade to your load balancer in Japan did not go well), or even the application (SAP did not work). Now one user may not be an issue. But if hundreds of users have the same problem, you will likely hear about it when a few of them are frustrated enough to call your support desk.
What happens if it's a performance problem, instead of a failure? The performance of an application is slower today than it was before. It could be because you recently did an upgrade of the Riverbed appliance for EMEA. It could be because you upgraded Exchange in China. Again, you will rarely hear about it unless tens or hundreds of users see the problem and a few of them call the help desk to report it.
Visibility was not an after thought for us. We designed it into our product from day 1. We had to. In working with past products when we tried to bolt visibility in later on, the results were painful - either too much data was collected causing most databases to fail, or too little data was collected to provide any valuable information, or the data wasn't actionable.
So getting the architecture to collect data right was important to us. We instrumented each one of our clients - phones, PCs, Macs, and tablets - to collect and send every single potentially important piece of data. Who used what application, to access what resource, on which network, in which geography, at what time, how much bandwidth was used, from which device, if there were failures, what was the response time. This data was automatically collected by each client and based on network conditions, forwarded to Workspot Control in the cloud.
Naturally there is lots of data. But searching for problems in this much data is a needle in a haystack problem. So we started making the data actionable. How could we quickly surface errors in a meaningful manner? This meant not just reporting the error, but also prioritizing it by how many times it has occurred, providing tools to block reporting if an error is being resolved, etc. Here is an example of a report summarizing errors seen by our end users at Workspot on 6/22/2015.
Here are some examples of the kinds of performance data we collect. We help you understand the data from multiple different dimensions: device, network, application, and geo. We will spend more time on these in future blog posts.
Our solution also simplifies the end user experience in accessing business applications and data on all personal devices.
Schedule a 15 minute demo to see today's Workspot in action. We're the leader in cloud desktops, and we can have you up and running on Microsoft Azure in as little as one day!