Mobile BI Design Framework: Making The Case For Small

In mobile business intelligence (BI) design, the “case for small” stems from the need to effectively manage performance and response time for mobile experiences. The concept has nothing to do with smaller screens or device sizes. Instead, it deals with the delivery of the content onto those screens.

One of the common denominators of all mobile user experiences deals with what I call the “patience factor.” Mobile users tend to be less patient about performance and response time than PC users, since they’re on the go with less time to spare.

On the other hand, the unmatched access and convenience of mobile makes them heavy users of the technology that’s largely influenced by their daily experiences with their mobile devices, which is all about ease of use and instant results.

The challenge for mobile design is that many traditional data and analytics platforms can’t handle large volumes of data on wired systems, let alone on wireless networks. Unless you’re taking advantage of the latest technology such as in-memory computing, the case for small remains undeniable.

Let’s take a look at two key areas where the case for small makes sense with traditional mobile BI platforms.

Mobile query size

If you’re going to load data from a traditional database, the size of the underlying mobile query will undoubtedly impact the performance.

  • Use the minimum number of data elements to satisfy your business requirement to define your mobile query. It’s completely acceptable to experiment with large queries during development, but you must clean them up before going live.
  • Optimize your queries at the database level and take advantage of additional features that your BI application may offer.
  • If it makes sense and provides relief, use several smaller data queries instead of one large query.
  • As an alternative to loading all data at once, consider loading data required for the initial analysis.
  • For certain requirements, think about cached data (storing values that have been computed in advance). Although this duplicates original values that are stored elsewhere, the performance gains may be invaluable—especially for certain audiences, such as senior executives.

Mobile BI asset

If you put aside the constraint of the most valuable mobile design property—real estate—avoiding a bottleneck becomes dependent on how the mobile BI asset is designed. Consider:

  • Review the number of underlying calculations that are created inside the report. Are they all really necessary or simply duplicates or leftovers from draft copies that can be eliminated?
  • Can you leverage standard definitions/calculations? If one doesn’t exist, does it make sense to create one as part of your data model instead of inside the mobile asset?
  • How do you plan to deliver the assets: Push or Pull? (Read more on this topic.)
  • How are you configuring the mobile asset in terms of the data refresh? Is it automatic (loads the latest data on open) or manual?
  • Do you have the offline capability, which will eliminate the need for a 24/7 wireless connection and the need to refresh data sets that don’t change frequently?

Bottom line

Mobile BI is about delivering actionable insight—not loading thousands of rows. Such overload won’t necessarily promote faster, better-informed decision making and it’s sure to cause unnecessary headaches for everyone involved.

What are other areas where the case for small can make a difference for your mobile BI initiative?


This story also appeared on the SAP Analytics Blog.