Types of Users

It's not too hard to identify who might need mobile BI capabilities: any employee who spends a good portion of their time away from a desk and needs to check data several times a day is a good candidate for a mobile BI application.

The traditional poster boy for mobile BI is the jet-setting executive who wants to check the status of key company metrics while traveling to and from customer sites and work locations. Traveling salespeople are also good candidates because they need up-to-date information about customers prior to making sales calls. Line managers (e.g. store managers, factory floor managers, school principals) are also target users since they need timely information to manage resources and staff but also need to manage by "walking around" -- interacting with customers and employees -- not sitting behind a desk looking at numbers.

Interestingly, operational workers offer fertile ground for mobile BI. These include field technicians who monitor and fix company infrastructure (e.g., rail lines, pipelines, roadways, and airplanes) or who install or repair products at customer locations (e.g., heating and ventilation technicians, plumbers, elevator repairmen, etc.) They need to check their own performance against their peers and log information about inventory and customer interactions. Other candidates include workers who are on call 24 hours a day and need to troubleshoot problems remotely, such as IT professionals or military personnel.

Not a Candidate? Employees who spend most of their time behind a desk don't need mobile BI. In the BI world, this includes business analysts, statisticians, and report developers. These folks are traditionally deskbound and the work they do--intensive crunching of numbers and report/model creation--is best done with high-powered desktop computers, not on the current generation of mobile devices.

Some argue that mid-level managers need mobile BI because they spend a lot of time in various conference rooms running meetings, facilitating the exchange of information, and monitoring follow-up tasks. But most mid-level managers already have laptop computers that they can easily carry to conference rooms, plug in, and connect to a high-speed network. In my opinion, the only reason to give these managers access to mobile BI capabilities is to help them aspire to the executive suite.

Types of Tasks

Robert Hylton, vice president at Transpara, a mobile BI vendor, offers three criteria for evaluating the types of tasks that make sense for mobile BI:

1. Here and now? Do the tasks need to be addressed immediately?

2. Small and intangible? Is the information about the tasks easy to digest?

3. Perishable? Does the information lose value if it's not acted upon right away?

Asking the above three questions at the outset of a project can help clarify what BI applications make sense to deploy on a mobile platform. "Many decision makers are surprised once they go through this process," says Hylton.

What's left after weeding out applications that don't meet these criteria? Two types of dashboard applications. One enables executives to monitor key performance indicators across the enterprise, and the other enables operational workers to monitor operational activity. Both display performance status according to plan and enable users to drill to view a time series chart and select filters to view detailed data. The best mobile dashboards support an action framework that enables users to attach a chart to an email message, link to another dashboard or view, or trigger a workflow or database update.

The data for mobile dashboards usually comes from a data warehouse or data mart and consists of both summary and detail data loaded on a daily or weekly basis. However, if the dashboard tracks operational activity, then the data either comes from a real-time enabled data warehouse or directly from operational systems via real-time queries.

Hylton defined his criteria with two-inch screen smartphones in mind. But the advent of tablet computers, such as Apple's popular iPad, that support eight-inch, high resolution screens, change the equation. Many mobile BI providers now say that they can easily run any self-service BI application on a tablet computer. Mobility in 2011 knows virtually no BI bounds.

Mapping Devices to Functionality

One way to evaluate the range of BI functionality available for mobile devices is to classify functionality by types of users. At a high level, there are two types: information consumers who use information to do their jobs (e.g., executives, managers, front-line workers,) and information producers who create information for others to consume (e.g. business analysts, report developers, statisticians). (See table 1.)

Smartphones and tablet computers exhibit slightly different footprints in the functional hierarchies depicted in Table 1. Smartphones let users "View" KPI charts or lists and "Navigate" predefined drill paths to view additional details. A few mobile BI vendors enable Smartphone users to "Modify" existing views (e.g., toggle between tables and charts and rank, sort, calculate, visualize or create new columns) as well as "Act" on information by updating remote applications or databases or triggering workflows. Some may even let users "Personalize" screen displays by changing color schemes and fonts, selecting favorites, or saving bookmarks.(See Table 2.)

Tablet computers give mobile BI designers more breathing room to support the full range of consumer-oriented BI functionality. On a tablet computer, users can "Modify" data in columns, "Explore" data in any direction (versus being limited to predefined drill paths) as well as "Act" on information via a variety of mechanisms, most notably email and annotations. Tablets even enable information producers go beyond personalization to "Assemble" simple dashboards and reports from a library of existing parts and components. The remaining "producer" functions are still best done on a desktop computer linked to a high speed network. (See Table 2.)

Final Mapping

If we put it all together, we might create a map like the one represented in Table 3. For each type of user, the map defines the mobility requirements, types of tasks, and data requirements. The mapping concludes that users with a high need for mobile BI functionality are executives, outside salespeople, and line managers (e.g., factory floor managers, school principals, store managers.) Field and inhouse technicians have a moderate need, and mid-level managers have minimal need.

A Cornucopia of Devices

Let's start with the easiest question first. What devices should you, as a business enterprise, support? If you are an IT professional, you won't like the answer.
All of them!

Unlike computing devices of yesteryear, smartphones and tablets are first and foremost consumer devices that your employees are buying for personal use and then seeking to use for business purposes as well. It would be foolish to make users carry a second, corporate-issued smartphone or tablet. And suicidal if the users happen to be your members of your executive team. And each user is going to purchase a different device and mobile operating system and then expect IT to support it. Clearly, the future of mobile computing is personal and heterogeneous!

That being said, many companies have already made a commitment to Blackberry smartphones, which are geared to business users. RIM offers an on-premise, enterprise server that integrates the devices with corporate email, calendaring, and phone systems and enables administrators to provision, configure, secure, troubleshoot, and audit all Blackberry devices, whether owned by an individual or issued by the company, from a central Web console. All this is sweet music to an IT manager. (We'll talk more about this type of mobile management system below.)

Unfortunately, the Blackberry's grip on mobile devices, both corporate and personal, is slipping away. Although RIM has shipped more devices than any other maker, Apple's iOS recently pulled ahead with 28.6% market share compared to RIM's 26.1%, according to Nielsen market research. Astonishingly, despite Apple's superior branding, it now is being outpaced by Google's Android operating system, which runs on a host of devices, often at bargain-basement prices, which probably explains its recent surge in popularity. When you look at sales in the past six months, Google's Android has a commanding 40.8% share compared to 26.9% for Apple and 19.2% for RIM. Meanwhile, Microsoft has re-entered the market with a revamped Windows Phone 7 and a fresh alliance with Nokia. Finally, a host of new tablet manufacturers, including RIM, which launched PlayBook in April, promise to stir up the market further.

The only certainty in the mobile device market right now is change. It's safe to say that IT departments won't be able to pick a winner any time soon. Not that it matters, because IT can no longer can dictate the mobile technology that employees use. The only exception might be line managers or field technicians whose work environments require ruggedized devices that are resistant to heat, vibration, water, dust, or humidity. There, employees will be happy to carry corporate-issued devices if only to preserve the longevity of their own.

Mobile Data Management Software

Given the heterogeneous nature of the mobile device market, IT managers should focus on administrative tools for managing mobile devices and applications rather than the devices themselves. These toolsets go by the name of mobile data management (MDM) software, not to be confused with master data management software, which is very familiar to most BI managers. Mobile MDM software is used to manage a heterogeneous portfolio of mobile devices and operating systems, often through "over-the-air" technologies. Specifically, MDM software performs a number of critical tasks:

• Provision and configure mobile devices, including password controls and other settings and parameters.
• Distribute applications and configure based on device properties.
• Communicate device errors and settings, including applications, security, to assist in troubleshooting.
• Manage applications, including controlling which applications users can install and use and removing unwanted applications.
• Remotely lock and wipe a device of data and applications.
• Maintain an audit trail of device usage.
• Set thresholds for usage, for voice, data, and SMS.

There is even a standards group, the Open Mobile Alliance (OMA), that has specified a standard for managing mobile devices, called OMA Device Management, which is standardizing the interfaces for delivering many of the features listed above.

Many companies provide MDM software. RIM offers Blackberry Enterprise, but this only manages Blackberry devices. Heterogeneous MDM players include AirWatch, MobileIron, Sybase, and Tangoe. But not all MDM providers offer equivalent service and features. One BI manager who is in the process of deploying dashboards to his iPad community was forced to switch MDM providers after the first product lacked key features and required users to be involved in part of the device configuration process. "It seemed like the software needed to go through a few more development cycles before going prime time," said the BI manager.

Mobile devices resurrect the notion of "fat client" that had largely disappeared with the advent of Web-based computing. Fat clients generally offer fast performance and superior user graphical interfaces, while Web-based applications--which execute application code on a remote server--generally simplify development, deployment, and administration.

Over time, fat and thin client architectures generally blur into distributed architectures where application processing is spread across clients, application servers, and databases. In fact, a good portion of many Web-based applications today execute on the client via browser-based Java applets, Active X controls, DHTML and AJAX, or Flash plug-ins, making so-called Web "thin" clients a tad "heavier" than is generally known.

Vendor Debates

As a new application platform, mobile devices pose a stark architectural choice for organizations that want to deploy mobile BI applications. They can either build exquisite-looking, native BI applications for each mobile device, or they can build a single browser-based application that runs the same on all devices.

During the past year, every BI vendor has had an intense, internal debate about which mobile BI architecture to adopt. Some vendors, such as MicroStrategy and Mellmo (makers of Roambi), believe that users will demand feature-rich, device-specific mobile applications, while others, such as Transpara and QlikTech, are betting that browser-based mobile applications will eventually steal the day. Many others, including IBM Cognos, have decided to hedge their bets and produce offerings in both camps.

User organizations need to carefully evaluate the mobile BI architecture adopted by their mobile BI vendors. They need to understand the ramifications that their vendors' chosen architecture will have on ease of use, adoption, deployment times, maintenance, and total cost of ownership, among other things.

Let's take a look at the two mobile BI architectures and then examine their hybrid offshoots.

Native Mobile Applications

There are three main advantages to running native mobile applications: 1) performance 2) user experience and 3) offline access. Performance is exceptional with native mobile applications because the data that comprises a report or dashboard is downloaded and stored on the device. Fast performance makes applications very responsive and highly interactive.

The user experience of native applications is also superior. This is due in part to fast performance but also because native applications exploit unique features and functions inherent in the devices, such as touch screens that support hand gestures or an accelerometer that lets users rotate the device to switch between a portrait and landscape view. Anyone who has ever used an Apple iPhone or iPad understands the unique experiences these devices make possible. Having tasted paradise, most don't want to go back.

Finally, because native applications store data locally, they work even when the device is not connected to a network. Offline access is critical for executives who spend a lot of time in the air or salespeople whose districts don't offer reliable network connections, or plant managers who might lose connectivity in the bowels of a manufacturing plant.

Browser-based Applications

Conversely, browser-based mobile BI applications have three unique advantages: 1) portability 2) data consistency and 3) security.

Rather than write an application for each individual mobile device, developers can write a single HTML/Javascript application that runs the same on any device that supports a browser, virtually unchanged. Although there are slight differences among browsers that must be accounted for during development, in general, developers can build once and deploy everywhere, and this includes desktops, laptops, and conference room or operation center flat-screen monitors. This is sweet music to developers and IT administrators who would rather maintain one application than a half-dozen variants, one for each type of device.

In a browser-based mobile BI applicaiton, the application and data reside on a remote server, which means that nothing is downloaded to the device. This prevents data from getting out of sync or the creation of analytic silos. Individuals all access the same server-side reports and data. Additionally, it is easier to enforce security since all data, code, and passwords are managed centrally. If a device is lost or stolen, hackers can't walk off with sensitive corporate data.

Downsides and Hybrid Solutions

Interestingly, the advantages of each architectural approach represent the downsides of the other approach. Not surprisingly, given the market potential for mobile BI, vendors are quickly plugging the gaps in their defenses and delivering hybrid solutions that maximize the benefits of their preferred architectural approach and minimize the downsides.

Hybrid Native Applications. BI vendors that have opted to ride the native mobile BI application wave have already made great strides in improving their applications' portability, data consistency, and security. For example, some now offer universal application templates that can be compiled into the native languages of all major devices without changes. This means developers only have to create an application once to run it on any device.

To improve data consistency, some vendors now configure native mobile BI applications to download fresh data upon startup or on demand. And they've given remote administrators the ability to selectively wipe device disks if a device is lost or stolen to prevent unauthorized access to sensitive data and require users to log in when the application is used offline.

Hybrid Web Applications. Browser-based mobile BI developers have created workarounds to improve the performance and usability of their applications. For instance, some now cache small amounts of data on the device (e.g., a report) to improve application responsiveness. Others are extending their browser-applications in the short-term by writing to a mobile device's application programming interface (API), which enable browser-based applications to exploit some unique mobile features, such as touch screens, accelerometers, and gyroscopes. Of course, this also creates a new version of the Web-based application that developers have to maintain. In the long-term, these vendors are betting that HTML5 will deliver these same features using industry standard HTML.

Among the many highlights from last year's survey, the research shows that there is a difference in BI success rates and satisfaction between departmental and enterprise BI deployments, small and large BI vendors, and small and large user organizations. The obvious conclusion, to quote the 1960s classic by E.F. Schumacher, is that "small is beautiful."

Here are some highlights from last year's summary that all survey participants receive:

• Scope. Business benefits are more likely to be achieved if projects go live quickly. There is a steady fall off as initial roll out times rise. The small number of projects that took more than two years to roll out achieved few business benefits.
• Small Vendors. Customers of small or niche vendors, such Board, Jedox, and Cubeware, had the highest benefit ratio scores.
• Benefit Keys. Companies wishing to maximize benefits should focus on 1) support quality 2) implementation time 3) query response time and 4) breadth of deployment, in that order.
• Goal Achievement. Customers of large BI vendors are less likely to achieve project goals than those of small vendors, with the notable exception of IBM TM-1. For example, fewer than three percent of SAP BW/BEx Suite and SAP BusinessObjects WebI users report that their projects had exceeded goals. Microsoft customers reported the highest levels of goal achievement.
• License Fees. There is little correlation between license fee expenditure and achievement of BI project goals.
• Product Complaints. SAP BW customers reported the most product complaints, especially with query performance, while Bissantz and IBM Cognos TM1 had the fewest. Qliktech had the fewest complaints about slow queries.
• Evaluations. Microsoft SQL Server Analysis Services and Reporting Services and IBM Cognos were the products most likely to be evaluated. Larger companies evaluate more products from larger vendors.
• Implementation fees. SAP BW/BEx customers had median implementation fees of $127,000 followed by Oracle Hyperion with $85,000, IBM Cognos with $66,000, and Microstrategy at $53,000.
• Win Rates. In competitive evaluations, TARGIT had the highest win rate of 82 percent, followed by Pentaho with 77 percent. At the other extreme, Oracle OBIEE had a win rate of 37 percent.

But there are all kinds of thorny issues involved in deploying BI--or any corporate application for that matter--on a mobile platform. The most widely discussed are security, selecting a mobile platform, designing for the mobile form factor, identifying appropriate mobile use cases, and selecting an application architecture (i.e. browser-based versus device-specific). These all represent significant challenges. But one issued that hasn't been discussed much yet is whether an organization should deploy corporate mobile applications on personal or company-issued devices.

Personal or Corporate?

This is a tricky issue. Since many employees already have an iPad or other mobile device, it would be difficult to ask them to carry a second one just for business. Since these are consumer gadgets, it's inevitable that organizations are going to have to accommodate the mobile devices that employees already own. But how do you secure and support personal devices that contain a mix of corporate and personal applications and run on different platforms and versions?

The IT department is used to purchasing, configuring, securing, and maintaining computers for employees. Mobile technology undermines this process and threatens IT administrators, whose job is to maintain a stable, secure, error-free compute environment. How can they do that when they don't own or control the devices?

It's clear that the IT department is going to have to adapt. They'll need to purchase corporate devices to support development and testing and give devices to employees who don't own them already. But they'll also need install corporate applications on devices which employees already own. But how are they going to do that? Send them to iTunes or another app store? (Do you really want a corporate application on a consumer shopping site where people can download the application and uncompile it?) Require them to bring the device to an IT administrator who will physically install the mobile application and requisite security software and test to ensure everything works? Or have users install the software over the wire from a corporate mobile application server?

Lost or Stolen

But these are small hurdles. The biggest issue is non-technical. What happens when a user loses a personal device with a corporate application installed on it?

If your mobile application is browser based, you only have to worry about data cached on the device, which is there to optimize performance. Ideally, your security software automatically deletes the cache every hour or so, which minimizes (but doesn't eliminate) the risk. If you've deployed a native mobile application in which data resides on the device, you'll not only need to clear the cache, but wipe the hard drive as well, which your security software can perform remotely. (Of course, this only works if the device is turned on and connected to the network. Sophisticated thieves will hijack the data without connecting to a network.) In all likelihood, you'll need to apply all these strategies to secure sensitive corporate information.

Whoops! But there is a potentially bigger issue. What if you wipe a personal device that the business user later finds or recovers? If the device contained valuable personal data (e.g., thousands of dollars worth of music or personal photos) who is liable? Does the company have to reimburse the employee for the lost data? One company I spoke with had mobile users sign legal documents absolving the company of responsibility for lost data, among other things.