Managing the Mayhem of Mobile BI & QlikTech's New Approach

In-memory and dashboard vendor QlikTech did an about face on its mobile BI 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 the browser.

QlikTech isn’t the only vendor avoiding native mobile apps, with Information Builders and LogiXML sticking to their more browser-oriented approach. There are, however, some notable differences, and indeed, QlikTech is one of the few to have changed its mobile strategy.

Then there are other BI vendors, such as MicroStrategy and specialty vendor RoamBI who have native apps for Apple and BlackBerry devices. SAP BusinessObjects takes a similar approach but with their dashboards relying on Flash (which Apple does not support), the question with SAP becomes not only which device and which approach, but also, what content. IBM Cognos uses an app approach for BlackBerry’s and a browser approach for Apple, for now. Actuate also uses an app approach. Tibco Spotfire offers a native iPad app as well.

Why the difference and what should a customer do?

The tantalizing vision for browser-based Mobile BI is that it works on all devices. That’s great for vendors who don’t want to develop device-specific apps when tablet and smartphone vendors are still battling for market leadership. As Howard Dresner, author of a study on Mobile BI said, “It’s in the interest of the vendors to write the code once.” It’s also a help to customers who lack smartphone and tablet standards. The other appealing aspect is that nobody wants to develop reports and dashboards for every device.

That’s the vision. Reality, though, is quite different.

What’s good for vendors is not always best for customers. Currently device-specific apps promise a richer user experience, with faster performance via device-based caching. In theory, an HTML5-based solution could take advantage of smartphone features like location awareness and device-based caching, but they don’t necessarily do this. QlikView 10 mobile, for example, does not. Instead, it has optimized its current AJAX viewer to be touch-aware. This certainly means that an iPad user gets the full QlikView experience of searching, filtering, changing the chart display, and so on. I could not, however, use the iPad gestures to enlarge a chart, and the chart quality was not as rich as 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 with its browser-based approach.

Information Builders mobile, for example, leverages the vendor’s Active Report technology along with an optimized WebApp based on HTML5. Active Reports provides users with interactivity while caching data locally for offline use and better performance.

As for the whole theory of not having to redesign reports for particular devices, i think it's currently a false hope. Tablets and smartphones have such drastically different screen sizes that report authors have to take that into consideration. Ideally, mobile BI apps (or optimized webApps) will sense the device and re-render the same report for that device, but again, that direction is still a work in progress for most BI products.

The arguments for and against browser versus device-specific apps will continue to rage (see last year’s blog). Greater adoption and use of HTML5, which supports device-based caching and location awareness will add intensity to the debate.  It’s too soon to tell, though, how well mobile BI WebApps that use HTML5 will compare to native apps. Independent analyst Mike Ferguson who  will be speaking on Mobile BI at TDWI Munich, says, “HTML 5 is not as effective as a native app for exploiting the device cache,” due to the smaller size of the cache and how its managed.

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, for which devices, and what their strategy is for the future
• Evaluate functional differences between a general browser client, optimized WebApp client, and native app. In all cases, focus on the information consumer role, not the author.
• Be aware of development and redesign efforts for rendering content on specific devices
• Be prepared for change.
• Make Mobile BI a priority. Just because there is change and risks with Mobile BI, it’s not a reason to delay or ignore it.

Have you taken this year’s Successful BI Survey yet? Tell us how important Mobile BI is to your BI success here.

For QlikView customers, to take advantage of this new mobile approach, you need to upgrade to QlikView 10. QlikView has stated it will continue to support the current device-specific apps for those customers who have deployed them.  For more information on QlikView 10, purchase our in depth product review here.  

Sincerely,

Cindi Howson, BI Scorecard

Comments

[Donalddotfarmer]

Great post Cindi, and quite fair.

I certainly agree that users will get best results if documents are formatted specifically for the target device.

As for the choice of browser vs native app, I think it is important to bear in mind that native apps must be delivered through native app stores. This makes it slower and more difficult to deliver updates and fixes - and it's less reliable to ensure updates are applied.

With BI becoming ever more mission-critical, being unable to push an update to users promptly seems to me a tough price to pay for the prettier UI of a native app.

Donald Farmer
Product Advocate
QlikView

(Views are my own and do not necessarily reflect QlikTech policy.)

[Mark Montgomery]

Good advice here -- hope people are doing their homework. I particularly appreciate "what's good for vendors is not necessarily good for customers", and "be prepared for change".

It's a very fluid market that appears to be in the early stage of technology driven convergence, not to be confused with market consolidation, meaning fewer acronyms needed in the enterprise, although given the guilds we can expect aggressive hype, defense, and protectionism to continue.

Good work.

Mark Montgomery
Founder & CEO
Kyield

[Cindi Howson]

Hi, Donald,
Thank your for the comments. To clarify, though, native apps do not "have" to be distributed via itunes (or BlackBerry World). That they can be is of course a benefit for customer-oriented apps. I also do understand from a vendor perspective that Apple's 30% cut of revenue for these apps may seem unfair. I could argue both sides of the fence here about monopolistic tendencies vs maintaining tight control so we don't get into the mess that we have with Windows viruses and security issues.

However, when an app is not distributed via itunes and is only distributed internally at a company, the apps does have to be digitially signed to be enabled to work with the device. I have not heard that this causes a delay in the distribution and development process.

Regards,
Cindi

[Donalddotfarmer]

Thanks again.
For iOS, native apps can be delivered in-house using an Enteprise AppStore if they are developed in-house and signed, but external apps cannot be distributed this way. There is an ad-hoc distribution model, but only to 100 users or fewer.

And yes, the 30% cut is painful. But I don't think any BI vendor would get rich from AppStore anyway. :-)

Nevertheless, I do agree that there is a good discussion to be had about whether open or controlled distribution is appropriate. I certainly sit on either side of that fence.

Mark rightfully points to your comment that "what's good for vendors is not necessarily good for customers." Very true. However, as both a vendor and a customer, I am sure that software that cannot be easily and effectively serviced is not good for anyone.

It is generally a good practice to "follow the money" when looking at a vendors' decisions - and you're doing a good job of keeping us all honest. But in this case, serviceability and manageability is really important too.

Donald

[Wayne Eckerson]

It seems to me that the future of mobile BI architectures is hybrid.... with processing distributed across all layers (client, server, database). This is similar to the client/server battles of the 1990s when apps came out on desktops, then the Web (with thin clients) and now we mostly have client/server apps with either desktop or "thick" Web browsers (with lots of Javascript or applebts) running against remote servers.

Anyway, most native app providers are making their apps more universal in nature. (Mellmo compiles to any device operating system), while Web app vendors are making their apps more performant and user friendly with native features delivered via the OS through the browser or HTML5 or both.

In the future, your mobile BI architecture will be more a matter of historical orientation than feature/functionality.

[Jmichel_franco]

This is a very balanced and brilliant article with a much wider coverage than the title suggests
A topic that I would add in favor of native apps is the push mode. I think of one the key benefits of Mobile BI is to propagate alerts (although I'm unsure that the tools in general have done a good job in this area at that time).
To manage that properly you need at least a little bit of code running continuously on the mobile