You need visibility for BYOD. Lots of it.

by Amitabh Sinha on Jul 2, 2015 8:00:00 AM

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  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 the architecture to collect data was important. 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.

Screen_Shot_2015-06-22_at_11.35.37_AM Screen_Shot_2015-06-22_at_11.35.54_AM

Our workspace also simplifies the end user experience in accessing business applications and data on all personal devices. Click on the thumbnail below for a quick demo video to get a preview on just how easy it is to access and navigate the Workspot Client

Want to know more about Workspot today? Click the image below to download the solution brief:
Azure DaaS

Subscribe To Our Blog

author avatar

This post was written by Amitabh Sinha

Amitabh has more than twenty years of experience across enterprise software, end user computing, mobile, and database software. Amitabh co-founded Workspot with Puneet Chawla and Ty Wang in August 2012. Prior to Workspot, Amitabh was the General Manager for Enterprise Desktops and Apps at Citrix Systems. In his five years at Citrix, Amitabh was VP Product Management for XenDesktop and VP Engineering for the Advanced Solutions Group. Amitabh has a Ph.D. in Computer Science from the University of Illinois, Urbana-Champaign.

Connect with Amitabh