Some business intelligence vendors rely on device-native mobile apps while others count on browser-based viewing of reports and dashboards. Here are the tradeoffs of each approach.
In-memory analysis and dashboard software vendor QlikTech did an about face on its mobile business intelligence strategy last month. One of the first BI vendors to natively support iPad and Android devices, QlikTech is now taking a device-agnostic approach, relying instead on browser-based viewing.
QlikTech isn't the only vendor avoiding native apps, it seems. Information Builders and LogiXML, for example, also take browser-oriented approaches. MicroStrategy and specialty vendor RoamBI, in contrast, have native apps for Apple and BlackBerry devices. SAP BusinessObjects has native apps, too, but given that this vendor's dashboards rely on Flash (which Apple does not support), the question for SAP customers is not only which device to choose but also what content needs to go mobile? IBM Cognos uses an app for BlackBerry and the browser for Apple, for now. Actuate uses an app, and Tibco Spotfire has a native iPad app as well.
Why the differences and which approach should customers adopt?
The tantalizing vision for browser-based Mobile BI is that, with help from the latest standards like HTML5, it will work on all devices. That will be great for vendors, who don't want to develop device-specific apps, particularly when tablet and smartphone vendors are still battling for market leadership.
"It's in the interest of the vendors to write the code once," notes analyst Howard Dresner, author of a recent study on Mobile BI.
The browser-based approach also helps customers that have not standardized on particular smartphones or tablets. The other appeal of the approach is that it doesn't require redevelopment: nobody wants to recreate reports and dashboards for every device.
That's the vision. Reality, though, is quite different.
As it stands today, device-specific apps deliver a richer user experience than mobile Web browsing, with faster performance via device-based caching. In theory HTML5 can take advantage of smartphone features like location awareness and local cache, but vendors have yet to exploit these emerging capabilities. QlikView 10 mobile, for example, does not. Instead, it has optimized its current AJAX viewer to be touch-aware. This ensures that iPad users get the full QlikView experience of searching, filtering, changing the chart display, and so on.
In testing the device with QlikView, I found I could not use the iPad gestures to zoom a chart, and the chart quality was not as rich as I've seen with BI products that use native apps. Performance was at the mercy of my network. In part, this has as much to do with QlikView's architecture as taking a browser-based approach. On the upside, the new QlikView app offered the rich searching, filtering and charting functionality mentioned above, and that may be ideal for a tablet user. With Mobile BI, vendors are still contemplating what users want to do beyond simple viewing. I suspect the answer will differ for smartphone versus tablet users.
Information Builders mobile approach uses the vendor's Active Technology along with a Web app. Active Reports are interactive because they cache data locally for offline use and better performance than you'd experience accessing data online.
The arguments for and against browser and device-specific apps will continue to rage. Greater adoption and use of HTML5, which supports device-based caching and location awareness, will intensify the debate. It's too soon to tell, though, how well mobile BI Web apps that use HTML5 will compare to native apps. "HTML 5 is not as effective as a native app for exploiting the device cache," says independent analyst Mike Ferguson, who will discuss Mobile BI at the upcoming TDWI Munich event.
With the technology in a state of flux, here are my recommendations for managing Mobile BI:
Agree on which devices are more important in your company. I won't even say "set a standard" because the tablet market, in particular, is changing too rapidly.
Know what approach your vendor uses today, which devices it supports, and what the strategy is for the future.
Evaluate functional differences between a general browser client, optimized Web app client, and native app. In all cases, focus on the needs of the information-consumer, not the author.
Be aware of development and redesign efforts for rendering content on specific devices.
Be prepared for changes in which devices users want supported, how BI vendors deliver capabilities, and in ways mobile BI is used.
Make Mobile BI a priority. Just because there is change and risk with Mobile BI, it's not a reason to delay or ignore it.