One of the most transformative trends we expect to gain additional traction this year beyond its already-healthy start last year is that of BYOD – “bring your own device”, the expectation/permission of employees to provide laptops, tablets, and smartphones of their own choice (and at their own cost) that they then make available to access company resources. The very reasonable challenges employers face safeguarding their company proprietary information on devices that are largely outside their control is well-documented at this point. But savvy employers recognise that their employees are intimately connected to their devices, and that by facilitating work on these devices, they have the opportunity to leverage “micro-efficiencies” in their schedules to accomplish work tasks. Most agree that the benefits outweigh the costs.
For BI deployments however, there are unique challenges that drive BI architects into territories that are not entirely novel, but nonetheless require careful planning. The size of data sets under analysis are far larger than they were in the past, yet the scenario is a familiar one: a decade ago, prominent challenges centered on the capacity of individual workstations to process large data sets. Now it’s concern about the capacity of smartphones and tablets with a few gigabytes of RAM to do the same.
The challenge is that employees’ expectations are being set by two ecosystems that frustrate BI architects’ abilities to mitigate them: the performance of mainstream, non-business apps that stream data constantly (e.g.: Pandora), and the performance of BI processing on enterprise-class infrastructure on their desktops. Employees viewing mobile visualisations on their tablets encountering delays and latency bottlenecks rightly ask, “Why can’t this be faster? Pandora can stream me songs all day long with no skips. And my desktop refreshes these dashboards in two seconds!”
Obviously there’s a big difference between Pandora and a company’s mobile BI suite, and there’s often an even bigger one between her dashboard’s performance at her desk on a hard-wired network versus over the same over 3G or LTE phone networks. The truth is that mobile BI performance is affected by new factors that have seldom if at all been a widespread part of user experience. Network coverage, provider data limits and throttling, even connection quality in buildings can affect that performance that users often simply assume will be identical to that at their desks.
The best strategy here is a hybrid one, mixing appropriate expectation-setting with careful planning of the mobile deployment in coordination with a vendor experienced in mobile deployments. By managing expectations and working diligently to explain that performance on user-owned mobile devices will not match performance in the office, on the network, BI architects can mitigate the problem from one angle. Choosing a vendor with solid experience over time delivering on long-tenured mobile deployments will help the architect mitigate the problem from the other angle by maximising what performance can be delivered and scaling to match increasing demand.
Without question, mobile BI is nothing less than a mandatory aspect of deployment strategy going forward. The fact that it is so heavily expected is all the more reason that architects must plan for it carefully and understand that we have solved these problems before in another form and learn from our old lessons.
DataHub Writer: Douglas R. Briggs
Mr. Briggs has been active in the fields of Data Warehousing and Business Intelligence for the entirety of his 17-year career. He was responsible for the early adoption and promulgation of BI at one of the world’s largest consumer product companies and developed their initial BI competency centre. He has consulted with numerous other companies about effective BI practices. He holds a Master of Science degree in Computer Science from the University of Illinois at Urbana-Champaign and a Bachelor of Arts degree from Williams College (Mass)..
View Linkedin Profile->
Other Articles by Douglas->