We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Wayne Eckerson Subscribe to this blog's RSS feed!

Wayne Eckerson

Welcome to Wayne's World, my blog that illuminates the latest thinking about how to deliver insights from business data and celebrates out-of-the-box thinkers and doers in the business intelligence (BI), performance management and data warehousing (DW) fields. Tune in here if you want to keep abreast of the latest trends, techniques, and technologies in this dynamic industry.

About the author >

Wayne has been a thought leader in the business intelligence field since the early 1990s. He has conducted numerous research studies and is a noted speaker, blogger, and consultant. He is the author of two widely read books: Performance Dashboards: Measuring, Monitoring, and Managing Your Business (2005, 2010) and The Secrets of Analytical Leaders: Insights from Information Insiders (2012).

Wayne is founder and principal consultant at Eckerson Group,a research and consulting company focused on business intelligence, analytics and big data.

Recently in Mobile BI Category

9-19-2011 5-16-03 PM.jpg

For all the talk about analytics these days, there has been little mention of one of the most powerful techniques for analyzing data: location intelligence.

It's been said that 80% of all transactions embed a location. A sale happens in a store; a call connects people in two places; a deposit happens in a branch; and so on. When we plot objects on a map, including business transactions and metrics, we can see critical patterns with a quick glance. And if we explore relationships among spatial objects imbued with business data, we can analyze data in novel ways that help us make smarter decisions more quickly.

For instance, a location intelligence system might enable a retail analyst working on a marketing campaign to identify the number of high-income families with children who live within a 15-minute drive of a store. An insurance company can assess its risk exposure from policy holders who live in a flood plain or within the path of a projected hurricane. A sales manager can visually track the performance of sales territories by products, channels, and other dimensions.

Geographic Information Systems. Location intelligence is not new. It originated with cartographers and mapmakers in the 19th and 20th century and went digital in the 1980s. Companies, such as Esri, MapInfo, and Intergraph, offer geographic information systems (GIS) which are designed to capture, store, manipulate, analyze, manage, and present all types of geographically referenced data. If this sounds similar to business intelligence, it is.

Unfortunately, GIS have evolved independently from BI systems. Even though both groups analyze and visualize data to help business users make smarter decisions, there has been little cross-pollination between the groups and little, if any, data exchange between systems. This is unfortunate since GIS analysts need business data to provide context to spatial objects they define, and BI users benefit tremendously from spatial views of business data.

Convergence of GIS and BI

However, many people now recognize the value of converging GIS and BI systems. This is partly due to the rise in popularity of Google Maps, Google Earth, global positioning systems, and spatially-aware mobile applications that leverage location as a key enabling feature. These consumer applications are cultivating a new generation of users who expect spatial data to be a key component of any information delivery system. And commercial organizations are jumping on board, led by industries that have been early adopters of GIS, including utilities, public safety, oil and gas, transportation, insurance, government, and retail.

The range of spatially-enabled BI applications are endless and powerful. "When you put location intelligence in front of someone who has never seen it before, it's like a bic light to a caveman," says Steve Trammel, head of corporate alliances and IT marketing at ESRI.

Imagine this: an operations manager at an oil refinery will soon be able to walk around a facility and view alerts based on his proximity to under-performing processing units. His mobile device shows a map that depicts the operating performance of all processing units based on his current location. This enables him to view and troubleshoot problems first-hand rather than being tethered to a remote control room. (See figure 1.)

Figure 1. Mobile Location Intelligence.
9-19-2011 4-49-49 PM.jpg

A spatially-aware mobile BI application configured by Transpara for an oil refinery in Europe. Transpara is a mobile BI vendor that recently announced integration with Google Maps.

GIS Features. Unlike BI systems, GIS specialize in storing and manipulating spatial data, which consists of points, lines, and polygons. A line is simply the intersection of two points, and a polygon is the intersection of three or more points. Each point or object can be imbued with various properties or rules that govern its behavior. For example, a road (i.e., a line) has a surface condition and a speed limit, and the only points that can be located in the middle of the road are traffic lights. In many ways, a GIS is like computer-aided design (CAD) software for spatial applications.

Most spatial data is represented as a series of X/Y coordinates that can be plotted to a map. The most common coordinate system is latitude and longitude, which enables mapmakers to plot objects on geographical maps. But GIS developers can create maps of just about anything, from the inside of a submarine or office building to a geothermal well or cityscape. Spatial engines can then run complex calculations against coordinate data to determine relationships among spatial objects, such as the driving distance between two cities or the shadows that a proposed skyscraper cast on surrounding buildings.

Approaches for Integrating GIS and BI

There are two general options for integrating GIS and BI systems: 1) integrate business data within GIS systems and 2) integrate GIS functionality within BI systems. GIS administrators already do the former when creating maps but their applications are very specialized. Moreover, most companies only purchase a handful of GIS licenses, which are expensive, and the tools are too complex to use for general business users.
The more promising approach, then, is to integrate GIS functionality into BI tools, which have a broader audience. There are several ways to do this, which vary greatly by level of GIS functionality supported.

  • BI Map Templates. Most BI tools come with several standard map images, such as a global view with country boundaries or a North American view with state boundaries. A report designer can place a map in a report, link it to a standard "geography" dimension in the data (e.g. "state" field), and assign a metric to govern the shading of boundaries. For example, a report might contain a color-coded map of the U.S. that shows sales by state. This is the most elementary form of GIS-BI integration since these out-of-the box map templates are not interactive.
  • BI Mashups. An increasingly popular approach is to integrate a BI tool with a GIS Web service, such as those provided by Google or Microsoft Bing. Here the BI tool integrates static and interactive maps via a Web service (e.g., REST API) or a software development toolkit. An AJAX or other Web client renders the map and any geocoded KPIs or objects in the data. (Geocoding assigns a latitude and longitude to a data object.) End users can then pan and zoom on the maps as well as hover over map features to view their properties and click to view underlying data. (See figure 1 above.) This approach requires a developer to write Javascript or other code.
  • GIS Mashups. GIS mashups are similar to BI mashups above but go a step further because they integrate with a full-featured GIS server, either on premise or via a Web service. Here, a BI tool embeds a special GIS connector that integrates with a mapping server and gives the report developer a point-and-click interface to integrate interactive maps with reports and dashboards. In this approach, the end-user gains additional functionality, such as the ability to interact with custom maps created by inhouse GIS specialists and "lasso" features on a map and use those selections to query or filter other objects in a report or dashboard. Some vendors, such as Information Builders and MicroStrategy built custom interfaces to GIS products, while other vendors, such as IBM Cognos and SAP BusinessObjects, embed third party software connectors (e.g., SpotOn and APOS respectively.)
  • GIS-enabled Databases. Although GIS function like object-relational databases, they store data in relational format. Thus, there is no reason that companies can't store spatial data in a data warehouse or data mart and make it available to all users and applications that need it. Many relational databases, such as Oracle, IBM DB2, Netezza, and Teradata, support spatial data types and SQL extensions for querying spatial data. Here both BI systems and GIS can access the same spatial data set, providing economies of scale, greater data consistency, and broader adoption of location intelligence functionality. However, you will still need a map server for spatial presentation.


As visual analysis in all shapes and forms begins to permeate the world of BI, it's important to begin thinking about how to augment your reports and dashboards with location intelligence. Here are a few recommendations to get you started:

  1. Identify BI applications where location intelligence could accelerate user consumption of information and enhance their understanding of underlying trends and patterns.
  2. Explore GIS capabilities of your BI and data warehousing vendor to see if they can support the types of spatial applications you have in mind.
  3. Identify GIS applications that already exist in your organization and get to know the people who run them.
  4. Investigate Web-based mapping services from GIS vendors as well as Google and Bing since this obviates the need for an inhouse GIS.
  5. Start simply, by using existing geography fields in your data (e.g., state, county, and zip) to shade the respective boundaries in a baseline map based on aggregated metric data
  6. Combine spatial and business data in a single location, preferably your data warehouse so you can deliver spatially-enabled insights to all business users.
  7. Geocode business data, including customer records, metrics, and other objects, that you might want to display on a map.

Location intelligence is not new but it should be a key element in any analytics strategy. Adding location intelligence to BI applications not only makes them visually rich, but surfaces patterns and trends not easily discerned in tables and charts.

Posted September 19, 2011 2:51 PM
Permalink | 1 Comment |

Mobile BI Users.jpg

SmartPhones and tablet computers are selling like hotcakes. Soon, a large swath of your employees will have these devices and want to run corporate applications on them, including business intelligence (BI). But before you embark on a major initiative to empower your entire workforce with mobile BI capabilities, you need to answer three key questions: 1) Which types of employees can benefit most from mobile BI? 2) Which BI tasks make most sense in a mobile environment? and 3) Is your mobile BI provider capable of supporting these BI tasks?

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.)

Table 1 - Mobile BI.jpg

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.)

Table 2- Mobile BI.jpg

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.

Table 3 - Mobile BI.jpg

Before diving headlong into the world of mobile BI, it's critical that user organizations take some time to assess user requirements and map them to mobile BI functionality offered by their primary BI provider. Even if you're mobile BI vendor doesn't deliver everything you need right now, chances are that they will soon support your requirements since this space is evolving rapidly and highly competitive.

Posted April 26, 2011 3:10 PM
Permalink | No Comments |


A majority of business intelligence (BI) professionals today believe that mobile BI is an important initiative. If you are one of them, you probably have a few basic questions about how to get started. For instance, "Who should get a mobile BI application?" "What kinds of functions should the application support?" And "What devices should you support and how do you provision and manage them on an enterprise scale?"

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.

Deploying mobile BI in a fast-changing, heterogeneous mobile device market is challenging. The first step is to acknowledge that you will have to support multiple mobile operating systems and run your BI applications on employee-owned devices. The second is to invest in a MDM software to manage the distribution, management, security, and troubleshooting of those devices and your BI application.

Posted April 25, 2011 11:52 AM
Permalink | No Comments |

Thumbnail image for MP900438761.JPG

For the past twenty years, application architects have debated whether to deploy software applications on clients or servers or some combination of the two. This debate has spanned a half-dozen different types of computing platforms, from mainframes and minicomputers in the 1970s and 1980s to desktop and client/server systems in the 1990s, and to the Web and Web services in the 2000s. Today, application architects now have a new platform upon which to wage their perennial debate: mobile devices.

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.

It's likely that the future of mobile BI is some form of distributed computing comprised of of the hybrid applications described above. But whatever the form, it behooves organizations to understand the architectural choice that they or their mobile BI vendor have made and its ramifications on application usability and internal resources.

Posted April 21, 2011 3:43 PM
Permalink | 2 Comments |


Since the successful launch of the Apple iPad a year ago, there has been a dramatic rise in the number of companies seeking to deploy business intelligence on mobile devices. Certainly, the marriage between the iPad and BI is a strong one: the iPad (or tablets in general) is designed for consuming information and BI is designed to deliver it.

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.

There are a lot of things to consider when implementing mobile BI. None are insurmountable. But it will take time to work through all issues. And as always, it's the soft stuff--the political, social, legal, and organizational issues--are often the most challenging of all.

Posted April 7, 2011 3:18 PM
Permalink | 3 Comments |