In mobile business intelligence (BI) design, performance is one of the most critical elements of the mobile BI success formula. High-quality content, reliable data, and mobile purpose are a must. However, none of that matters if the performance is poor—mobile users tend to be less patient about performance. Think about it for a moment. Unlike a PC users who may be chained to a desk, mobile BI users typically access mobile BI assets on the go and with less time to spare.

When we discuss performance in mobile BI, we often talk about two components: availability or up time (more on this in a future post) and response time. Managing response time—how long it takes from the time we launch the mobile asset until it is ready for consumption (data downloaded and user interface is loaded)—is a tricky business because it involves many layers where things can go wrong.

Let’s take a look at several key layers (in no particular order) that impact performance.

Wireless network performance

The wireless network covers any Wi-Fi connection at the time of access.

• It can be the trickiest one to control or manage because some of the services may be offered by an external company, such as an external wireless service provider.
• Others may be more in our control, like wireless access within our offices.
• Other layers may introduce added complexity in managing expectations. For example, our users may complain about slow performance on the virtual private network, when in reality they’re being slowed down by a shared connection at Starbucks or the airport.

Back-end infrastructure performance

How we set up and configure our back-end makes a big difference. We should:

• Observe most of the same principals used in server management practices
• Configure our servers for the needs of our user base and based on the expected volume in our environment
• Start small and design for incremental growth in capacity to avoid costly redesigns or upgrades.

Mobile BI app performance

How the mobile BI app is designed plays an important role in whether this layer becomes a bottleneck.

• Factors like memory consumption directly impact the mobile experience.
• Whether the app can take advantage of advanced features like caching (avoiding repeated inquiries to fetch data) or offline capability (avoiding the need to refresh data for unchanged data sets or reports) makes an enormous difference.
• The result of a build vs. buy decision ultimately dictates how much we can control or change how the mobile BI app behaves.
• We still have an opportunity to work within our constraints to make sure that the app performs at an optimal level whether we buy it or built it in-house.

Mobile BI asset performance

We have the most control over this layer because we get to design these mobile BI assets (like reports and dashboards). We should:

• Build them for our audience since our environment will be unique to our industry, business, and requirements
• Apply the best practices used in traditional BI implementations that apply, such as
  • Building aggregate data sets for summary level information
  • Breaking large reports into smaller chunks
  • Matching the right technology with the right audience.
• Set the right expectation from the start—mobile BI is about delivering actionable insight, and not loading thousands of rows, which won’t promote faster, better-informed decision making and is sure to result in poor performance.

Bottom line

Our mobile users may not fully appreciate or care about how complex and challenging the management of a mobile BI infrastructure can be. But when it comes to mobile BI performance, the perception will dictate the reality. Understanding these layers better will give us the best chance to build and execute a successful mobile BI strategy.

Where do you see challenges in managing performance in your mobile BI initiative?

[hr]

This story also appeared on the SAP Analytics Blog.