10 Steps to Mobilization

Some shops develop mobile applications the way a Boy Scout rolls his sleeping bag: fold, press air out, roll, press and repeat until you can stuff it in the nylon sack and tie the pull-string tight. Companies likewise take a desktop app, remove all the white space in forms, rearrange fields to fit tiny screens, shrink the database and jam the package into a mobile device. In this case, though, it's not a pull-string but a noose they're pulling tight, damning the application project to a slow, painful death at the hands of its own inflexibility and dearth of usability.

Repeat after us: Mobile applications are not the same as desktop applications. Mobile application deployment cannot be compared with rolling out the latest version of Microsoft Office to PCs on the corporate network. Mobile applications feel different, the hardware is smaller, and connectivity is limited and sporadic. Unfortunately, as we discuss in "Mobile Version of the Valdez", the mobile-application ecosystem has been thoroughly polluted by the consumer-focused character of wireless carriers. It isn't easy for an enterprise to completely meet its needs without assembling the parts itself. Never fear: Here's a 10-step road map to ensure a successful rollout.

1. Analyze The Process

Sure, you know what process you want to automate. But deploying a mobile application won't simply accelerate existing business procedures. Inevitably, mobilization leads to change--in the process, in communication patterns, in how employees interact and serve customers. Slavish adherence to process replication will not take full advantage of the mobile application's ability to save money by increasing efficiency.

Say technicians use paper work orders to identify daily appointments. At close of business they file completed forms to accounting, which generates invoices manually. A mobile application could convert a work order into an invoice, e-mail it to the customer while the tech is on-site, even let the customer pay immediately with a credit card. The customer benefits by having an immediate copy of the work order and eliminating a future statement and resulting payment cycle. The organization benefits by having an accurate capture of the service work and a lower accounts receivable balance. But to realize maximum benefits, the process must change, in this case by reducing or redeploying accounting staff.

2. Know Your Audience

Identify the mobile workers who will use your application, gather their activities and profiles and ascribe ROI values to each group.

Four broad categories can be used: field-service workers; remote salespeople; day-extenders/knowledge workers who check e-mail, retrieve voicemail and review status reports during off-hours; and extended enterprise employees or partners who regularly work off-site, such as auditors, consultants, contractors and their employees.

Once group profiles and typical activities are identified, you can tally the ROI of a mobility application and finalize a budget (see "Make Your Case").

The mobility-assessment team should comprise a cross-functional group of people from multiple business and IT groups, including security. Business users provide IT with insight so it can correctly scope the project and develop an open architecture for anticipated mobility, while IT educates the business side on the realities of mobility applications.

A multidiscipline team also may help avoid a classic mistake plaguing mobile applications projects: underestimating the complexity related to a new mode of operation--a different UI, different processes, the logistics of deploying and supporting users and devices, integration with back-end systems, to name a few gotchas.

The application must be designed to tolerate intermittent access, so it usually requires local storage and data replication to a subset of the complete data set. That's an uncommon set of functional requirements compared with the typical desktop application.

Another mistake is to work around a specific mobile device. Users will want choice, and the device you like now may not be available in six months. Product requirements, such as screen size, wireless interfaces, keyboard availability, size, weight and ruggedness, are all reasonable parameters, but building an application that requires support for specific APIs or special buttons will guarantee mobile device lock-in and restrict application enhancements, because moving to another device will break a function that was a core component of the design.

Scalability must remain front of mind as well. Demos turned into pilot projects may perform well, but don't build an application and infrastructure that can't scale. Middleware vendors we spoke with recounted horror stories where a great application concept failed because it didn't afford the flexibility or interfaces to grow with the organization, requiring a complete rewrite.

3. Know Your Friends

Corporate desktops require a variety of applications and agents to keep them in line, and mobility deployments are no different. Antivirus software, application management, configuration and security policy management, VPN clients, the list goes on. Consider the vendors with whom you'll partner: Device and asset management by the likes of iAnywhere Solutions and Research in Motion (RIM) keep track of your stuff. Because native security provided by device manufacturers is insufficient for the enterprise, you'll need mobile security vendors such as Bluefire Security Technologies, Credant Technologies, Mobile Armor and Pointsec Mobile Technologies (read "Security on the Road", for more security advice).

Unless you standardize on RIM BlackBerry or a Windows device with ActiveSync, you need a product that can do PIM/e-mail synchronization against the corporate groupware platform. If the application is not being developed from scratch, you need middleware, such as iAnywhere, Intellisync's Mobile Suite or Motorola's MotoPro Mobility Suite.

Clearly, a fully fitted mobility deployment can become a little weighty. The reality is, few organizations put it all on. Rather, they leverage the fact that each component has a bit of another--for example, middleware products might perform some on-device encryption, while the PIM sync product can run inventory reports. Sybase subsidiary iAnywhere recently launched its Information Anywhere Suite, which bundles its own products and those from previous acquisitions to essentially wrap up all of the above. For more on the vendor landscape, see "How We Got Here".

4. Be The Policy Police

Creating a set of policies to address your mobility project is just as critical a component of the road map as choosing hardware or a primary mobile data provider. In "Don't Get Burned" page 28, we discuss building policies; some recommended items include a power-on password, wake-up password after 30 or 60 seconds of idle time, automatic wiping after several unsuccessful login attempts and encryption of important data.

The group supporting the mobile application must commit to automated and consistent application of security policies, and these policies must be defined up front, certainly before device selection. Your chosen security-management system may support only a subset of devices, or maybe only select devices have the security features that the mobile application requires. Mobile policies will aid the device-selection process and dictate guidelines in how employees purchase such devices.

Provisioning is another piece of the mobile-policy puzzle. Who decides which people have access to the mobile application, and is a sign-off required? How does the employee acquire the device, and how does he go about receiving the application? Does device provisioning and application deployment happen over the air, or at the user, department or IT group level?

What's your support policy for the device, mobile data service and mobile application? The first two may well be outsourced because they're relatively generic, but if the application is hosted on-site, the IT department will likely be involved. If the application is outsourced, sometimes the vendor manages all three. In any case, this must be decided beforehand, clearly defining which aspects are managed by whom, taking care to plug any perceived gaps.

5. Articulate Your Apps

Buy or build? As in any IT project, the application could be a best-of-breed amalgamation of OS, mobile device management vendor, mobile security solution and software development platform. Middleware vendors such as iAnywhere bring a lot of this together, but you must decide if the features provided by certain components are complete enough or whether you need further add-ons.

Alternately, many CRM and ERP vendors, such as Oracle, Salesforce.com, SAP, Siebel and their partners, offer mobile extensions for their products. An interesting example from Salesforce.com is AppExchange Mobile, the result of its acquisition of Sendia. Like all of Salesforce. com's offerings, AppExchange is fully hosted, but that doesn't prevent data exchange between the enterprise and the CRM app; in fact, the Salesforce.com API is used by more than 50 percent of transactions. Also unique are AppExchange Mobile's many prepackaged apps that use Salesforce.com's back end, but run on the most popular hardware, namely Windows Mobile, RIM and Palm.

A third option is to purchase applications targeted for specific verticals. Many organizations assume they need to develop software from scratch, only to discover later that something appropriate has already been built. One conundrum of the mobile application market: It's relatively small overall, yet it sports hundred of applications, often very obscure, each with a tiny customer base. RIM alone offers hundreds of applications covering a dozen verticals through its "Alliance" partner program. Palm, Symbian and Windows CE/Mobile also host online Rolodexes that assist in identifying potential applications.

Mobility management providers such as Traq-wireless also maintain relationships with application vendors, and wireless carriers have forged similar partnerships tied to their own consulting and integration services. Sprint's recently formed Enterprise Mobility subsidiary, for example, offers consulting, analytical tools and experience in certain verticals.

Purchasing a ready-made app is not without gotchas. Any given application will run on only a subset of the popular devices, and customization will be limited. But if you're willing to limit device selection, forgo extensive customization and follow the product development lifecycle of a vendor, this can be an affordable option.

While enterprises will want to limit device options for support reasons, to limit yourself to just one mobile OS is probably a shortsighted mistake. By using a middleware product, you'll be able to take advantage of new devices that might be cheaper, faster or lighter, without rewriting the application from scratch.

The fourth track--internal application development without middleware or mobile database tools--has complexity and cost levels such that only the largest of mobile deployments can justify this route. Maybe if you're the next FedEx or UPS; otherwise, not likely.

6. Select Your Host

Going relatively hand-in-hand with application sourcing is the decision of where to host the app. In-house hosting provides the comfort of physical proximity to what could be sensitive data. Middleware such as Dexterra Concert, iAnywhere and Nokia Intellisync support this choice. If you purchase middleware, you have just added another tier between your mobile devices and your application; add the cost of requisite servers to address design tiering, scalability and redundancy. Factors to consider include extra cooling, power, OS licensing and management. For a smaller deployment, building redundancy and load-balancing may require just two servers, but if you need to scale it up, you'll need to add iron accordingly.

If you decide to build the application yourself without the benefit of middleware, it's important to extensively simulate and perform live testing to confirm that the in-house choice supports not only average loads, but also peak demand and anticipated growth.

Mobility application outsourcing can happen at several layers. Most obviously, the application can be built by independent software vendors and companies such as Dexterra or Antenna Software. Unless the application is absolutely basic, budget at least $50,000 to $100,000 for Version 1.0. The next level mixes application development, integration with back-end systems and application hosting. This might mean you continue to operate the back-end systems, likely serving desktop users, but let a third party operate the mobility piece.

One step further, the service provider actually hosts the application, à la SaaS (software as a service). On a small scale, myServiceForce.com does just that with a hosted version of QuickBooks and mobility application development tools by E-Tech Solutions. On a much larger scale, Salesforce.com's AppExchange Mobile offers a hosted mobility platform for its own hosted CRM suite for $50 per user per month.

Outsourcing--of application development, the mobility piece, or the whole enchilada--can be attractive because the hosting provider has expertise with the software, which should result in fast development. It also will have the resources to scale, implement best-practice security measures, provide redundancy as required, transparently maintain version levels and convert what would normally be a capital expenditure to an operating one.

7. Pick Your Pieces

It's somewhat artificial to separate them from the middleware, application and hosting choices because they are in many ways so intertwined, but form-factor, device, platform and connectivity selections remain.

A mobility application doesn't necessarily presume a cellular-data-supported PDA. Some deployments might use regular laptops; even smartphones with small user interfaces and no QWERTY keyboards support simple applications for short-character communication or simple information retrieval.

As mentioned, middleware vendors help smooth out the differences among back-end databases, mobile platforms and device features. Nevertheless, certain platforms have greater attractiveness than others. RIM applications only run on RIM's own BlackBerrys, while Microsoft Pocket PC and Mobile are offered across several hardware lines. Despite the popularity of RIM's e-mail app, the BlackBerry application development environment is relatively closed compared with Microsoft's Windows CE and Mobile platforms. Symbian, popular in Europe, is available from several handset vendors and has a strong affiliate program and software application choice.

Palm OS continues to idle at Garnet (version 5.4), while Cobalt remains unused. Japan-based Access Co., which owns PalmSource, has introduced the Access Linux Platform, which claims to run native Palm OS applications for backward compatibility.

Many apps were developed for Palm OS, of course, with the Treo 650 and Treo 700p the most popular devices. The Treo 700w, which runs Windows Mobile 5.0, demonstrates that Palm is diversifying its offerings in case Palm OS falls by the wayside.

As for connectivity, cellular data services from major wireless carriers--CDMA-based technologies from Verizon Wireless and Sprint, GSM-based technologies from Cingular and T-Mobile--are the almost de facto choice for device connectivity. A recent Network Computing cover story on 3G broadband data offerings revealed that, though throughput far exceeds speeds of yesteryear, they come with price tags to match; see specifics at "Taking Advantage of Wide-Area Wireless" . Larger organizations can negotiate volume discounts or per-megabyte pools.

Metro Wi-Fi offerings in select areas promise good prices and higher speeds. Most offerings are $20 to $30 per month for roughly 1 Mbps of access, which will offer consistently higher speeds and lower latency at half the price of cellular data services from the likes of Cingular and Verizon. But because they lack nationwide service they're really applicable to only a subset of mobile application deployments. Mobile WiMAX services, announced by Sprint, could in the future offer carrier-class service in large swaths, but it will be several years before small-form-factor devices sport radios with the battery life necessary to make daily use possible.

No matter the back-end connectivity, the application should be designed to perform consistently in both speed and behavior. Inconsistent "page turn" times, time-outs and failed data retrieval are sure ways to alienate end users. The application should function transparently no matter if it's tethered or has good wireless connectivity; background database synching shouldn't require end-user input unless there is an egregious consistency problem. Local data stores that contain an appropriate subset of data are almost a must.

8. Pilot The Application

Even if your organization has deployed a mobile app before, best practices dictate piloting the project to a subset of the entire group. Look at what Toshiba America Medical Systems, a provider of medical imaging systems and customer of mobile systems vendor Antenna Software, was able to do. Dave Croteau, project leader, says it took an average of 13 days for employees to finalize repair jobs. Rather than identify employees with the longest close times and try to overcome process issues, Croteau chose a small pilot team with an average close time of 8.5 days. Antenna Software developed about 75 percent of the app, then Croteau deployed and provided some training. After six weeks, close times were down to 3.9 days, but more important, the pilot team provided valuable feedback for development of the last 25 percent of the app.

9. Deploy Your System

Don't overwhelm users with new hardware, new software and new procedures all at once. Toshiba's Croteau says employees needed time to adjust to the BlackBerrys his team had selected for this mobile application, so where possible he deployed the devices well in advance to be used for phones and/or mobile e-mail.

Only the smallest deployments will be complete in one shot. It's more likely you'll take a staged approach, targeting certain user groups or geographical areas to give the helpdesk and project manager time to get functionality or stability issues resolved and any surprise scalability concerns addressed.

Croteau performed training using WebEx. He also identified another reality: Not every technician uses the mobile application. Whether due to personnel idiosyncrasies or data coverage, 100 percent penetration may not be a reasonable goal.

10. Hold A Postmortem

Completing a mobile application deployment really means the beginning of regular assessments of the deployment's effectiveness. Functionality that was missed in the pilot stage must be worked into future releases. At this point, you'll learn how effective your infrastructure is in supporting application changes. Business processes will morph over time as mobility evolves how users interact with customers and internal staff. Organizations that fail to adjust will not obtain the full benefit of their investments, so set dates one, three and six months out to get your team together for ongoing evaluations and monitor the helpdesk for trends.

Frank Bulk is an NWC contributing editor. He works for a telecommunications company based in the Midwest. Write to him at [email protected]. Security On The Road

Despite all the benefits of mobile applications, concerns such as security, effectiveness and policy are hindering movement. Desktops are hard to lose, laptops, less so--just read a newspaper! Smaller form factors take the risk of loss to a new level: When a database containing intellectual property or PII (personally identifiable information) on employees or customers is in the wind, no one cares whether the data resided on a laptop or a Blackberry.

And because the person using the mobility device is essentially traveling in hostile territory without benefit of a firewall, mobile devices themselves need to be hardened for protection against viruses and worms lest malware come back to the organization, either remotely over a VPN or physically into the office network via a USB cable.

Security best practices mandate power-on passwords, wiping the device after a given number of failed password attempts, specifying connectivity modes (disabling Bluetooth, for example), and the requirement that all confidential information remain encrypted. Because security practices delay or annoy employees, the temptation is to turn them off; put agents on these devices to record those changes or enforce policy to restrict them. If you're implementing NAC, incorporate mobile devices.

Closely related to security is device management. As the number of supported hardware platforms grows, it becomes increasingly difficult to enforce policies and execute code releases. Standardizing can reduce costs considerably. On the subject of cost, note that the device itself is the least of your worries: Although high-end mobile devices approach the price range of a low-end laptop, the annual cost for mobile data can easily exceed hardware costs, and that doesn't include application development, back-end integration and related maintenance, future enhancements, or helpdesk support. Some mobility projects offer more hard-dollar ROI than others to offset these expenses; for information on selling a mobile application project see "What's in It for the Biz?". --Frank Bulk

Mobile Version Of The Valdez

Despite recent acquisitions and mergers (see "How We Got Here"), the mobile enterprise ecosystem remains thoroughly disintegrated from the enterprise, says Daniel Taylor, managing director of the mobile enterprise alliance. Enterprises have existing applications, but only the largest CRM and ERP vendors routinely build in mobility components, and precious few applications were designed for mobility from the ground up.

We see wireless operators pushing devices and connectivity, but not tying them back to the needs of enterprise customers, a losing proposition in the long term. And hardware vendors primarily target the larger and more lucrative consumer market with such mobile devices as the Motorola Q and RAZR. This leaves major distributors such as Ingram Micro and Tech Data in a vacuum, selling only a subset of major models and forcing enterprises to deal directly with carriers, find a local retail outlet or work with hardware vendors directly.

Device management is not an integrated part of most mobile platforms, save RIM's BlackBerry servers and to some limited extent, Microsoft's Windows Mobile. This means that, especially for heterogeneous deployments, mobile device management products need to be installed on top of all devices ... where the back-end management system may or may not integrate with middleware or the application.

The middleware market has made more progress, as it provides the glue between multiple device platforms. Middleware offerings may include a device management component and some application connectors.

Application vendors, eager to gain market share, cultivate relationships with the top wireless carriers, but this leaves little time for them to work with system integrators such as Accenture, Hewlett-Packard and IBM. In an ideal world, starting from the hardware side, technology vendors will work with distributors who in turn will take their array of products to resellers that can sell complete mobile application solutions to all-size enterprises.

Progress is being made, but it's slow going. Part of the problem, as it relates to mobile devices, is that the wireless carrier provides an incentive for the enterprise to purchase from it directly or though one of its agents, where it offers the device at a heavily subsidized discount for a term contract. If we could disaggregate that subsidy for the enterprise market, then devices could be sourced from other locations, including VARs and ISVs. And then, voice/data services from the wireless carrier would be appropriately priced. The idea is to let each member in the value chain do what it does best. --Frank Bulk

What's In It For The Biz?

There are plenty of hard and soft benefits to mobilizing an application. For knowledge workers or field representatives, having information at one's fingertips, on demand, as needed, without lugging around a laptop or attaché case of manila files, can dramatically increase productivity and responsiveness.

There are plenty of use cases: A Network Computing editor was recently blindsided while driving down the road, resulting in damage that made her vehicle unsafe to drive. The auto insurance adjuster came to where the vehicle was parked, avoiding having to tow it to a claims location. He evaluated the damage, used his laptop to retrieve case details and confirm repair estimates electronically, then cut a check and issued all required paperwork on the spot, without even a phone call to the office.

Warehouse personnel can fill orders without using paper picking tickets by relying on skid-loader-mounted ruggedized PDAs. Service technicians can retrieve diagrams and manuals for all supported equipment rather than rescheduling calls or having someone in a call center walk them through the work. The list goes on.

Mobile applications also enhance communications among employees, customers, products and assets. For example, Pro Mechanical Services, a commercial refrigeration specialist, implemented text messaging and dramatically reduced its cellular bill because it has reduced voice minutes. If a customer calls in to the main office and gives some special instructions, the dispatcher can attach it to the work order and push out an update to service technicians in the field. Sales representatives, who must be responsive to customer inquiries, can take advantage of mobile e-mail so that they can appear to be at their desks, no matter where they are.

At one time, field-service workers would travel to central dispatch to pick up their day's paper-based appointment schedules. If a service call arose that was of higher priority, an on-call person was dispatched from the main office or a call was made to pull someone off a job. Now, with mobile applications, appointment schedules can be adjusted dynamically.

Ready access to data, enhanced communications and dynamic workload scheduling all lead to enhanced efficiency and hence savings. Many mobility project leads find the necessary ROI by calculating how many minutes will be saved per day, per person. As little as 10 minutes per day could mean three more jobs completed per month, leading to higher levels of productivity with the same number of people. Mobile applications may be cheaper than hiring staff.

Improved data accuracy and integrity can be yet another benefit of mobile applications. Because the mobile device is always handy, it can be used to enter information at the point of service while the person's mind is fresh. The appointment or service request can be converted into an invoice to leverage existing contact information. Forms, with requisite checkboxes and drop-down lists, help eliminate the requirement to type in standard information and can be combined with business rules to validate the entered data. Completed forms with all important details can be sent back electronically to the main office within minutes or hours.

Some companies are starting to deploy mobile applications because they see it's giving their competitors a competitive advantage. Ellen Daley of Forrester Research has seen this in the pharmaceutical industry, where mobile devices are used to share information and take on-the-spot orders. The justification is that if the mobile application has value for the competitor, it probably does for the company, too.

With mobile applications in a nascent stage, assisting perhaps only 7 million of the 700 million potential employees worldwide, it's likely that the mobility projects identified at this stage are the ones that generate the most benefit in spite of the relative costs. --Frank Bulk

How We Got Here

First-generation mobile applications tend to be point solutions, tactical and as such, opportunistic in nature, says Eugene Signorini, vice president of Yankee Group's wireless/mobile enterprise solutions group. A particular department or business unit sees a potential to, say, dramatically increase productivity or more carefully track expensive parts. They project dramatic ROI and pitch the plan to management. The solution could be as simple as using spreadsheets with Pocket Excel and synchronizing them on a daily basis, or as complex as custom-developing software, but there was no long-term strategic vision to tie into a broader enterprise architecture. And policies? Those were created as the department or IT group encountered issues or significant support events, such as assisting a key person in the organization using a non-standard device on a Sunday evening.

These first-gen projects shouldn't be pooh-poohed, however: Executed well, they were financially responsible decisions that often continue to generate ROI for the business unit or company.

Take two...

Second-generation mobile application deployments have taken the proverbial bull by the horns. Mobility applications become a strategic initiative, not just of the business unit, but the company as a whole. Because the majority of applications are not mobile-ready, an architecture is set in place to support the whole enterprise and be expandable to other lines of business. Rather than function-specific solutions, a more open framework based on middleware offers the flexibility to change the end-user application and interfaces to back-end systems as needed without dispensing blank checks to consultants. And policies relating to device selection, hardware and application support, and security settings are hammered out long before the solution goes live.

This second generation of mobile applications and associated maturation of enterprise mobility requirements has led to some consolidation in an attempt to more synergistically address some vendors' feature gaps. Most significantly, middleware market leader iAnywhere, a subsidiary of database-vendor Sybase, purchased Xcellenet's Afaria for its device management and security, AvantGo for its end-user data and news delivery and Extended Systems for its e-mail and development tools. Nokia purchased mobile sync vendor Intellisync, and mobile e-mail vendor Good Technology has purchase JP Mobile for its device-management capabilities. While no equipment provider, carrier or vendor is a one-stop shop, these events confirm that customers are seeking a more complete mobility solution. --Frank Bulk