E-mail for road warriors: here's what you need to know about mobile messaging.

FIVE YEARS AGO, few users had PDAs--they were reserved for technophiles and executives with a penchant for new toys. Today, PDAs and smart-phones are common-place business gear for users across multiple levels of the enterprise. New innovations have loaded these devices with lots of memory and rich features, and driven prices down. Many new PDAs come with integrated or plug-in wireless network cards, not to mention that the features, memory, and applications available on most new smart-phones are right on par with most PDAs.

Chances are good that in the weeks after Christmas, you received more than a few calls like this: "I just received a new PDA for Christmas. How do I get my e-mail wirelessly like the guy in the TV commercials?" Many IT departments find themselves in reactive mode, scurrying to find quick-fix solutions. The problem is, with the wide variety of products and services available--and each with their own twist--the potential to disappoint rather than impress important internal clients is high.

Three customers I recently worked with were in a panic over what to do with users demanding mobile e-mail. Two had already completed poorly planned pilots with hastily acquired solutions and were disappointed with the results. Both of these deployments resulted in lost dollars, lost time, and loss of credibility for the IT departments involved.

On another job, I was called in to help troubleshoot the chronic crashing of a corporate mail server for an organization that had chosen to flatly deny support of any mobile or wireless devices. Of course, this didn't stop an intrepid employee from trying to program his local mail client to forward a copy of each new message to his wireless device. This action eventually set more than 40MB of e-mail looping through the server, jamming all other services before crashing the box entirely.

Understand your business requirements

It's important to have a clear understanding of what your user community wants and needs. To do this, you must complete a thorough needs analysis. Expect to come up with a mixed bag of requirements based on user group roles and departments.

Make sure you ask the right questions, including:

* Which of my users truly need wireless messaging? And, whose needs can be satisfied with a basic mobile (as opened to wireless) solution?

* From what locations will my wireless users be accessing my services? What type of coverage do they need? Which user groups frequently travel, and to where?

* What are my expected initial and recurring costs for these new services? Be sure to consider hardware, basic airtime, and SMS messaging fees (table 1).

* Are my requirements limited to messaging? Are there other systems or information it makes sense to deliver in a mobile and/or wireless format?

Your current e-mail platform

Complete a full review of your current e-mail platform infrastructure and any limitations it may have in delivering a mobile/ wireless solution. Your needs will be quite different depending on whether you're running a centralized or decentralized messaging infrastructure. Which platform you currently use will also have an impact on the type of solution you can deliver. Microsoft Exchange, Lotus Notes, Novell GroupWise, and many IMAP/POP3 environments all manage information differently. Plus, many third-party products required to support a mobile/wireless solution are product-and/or technology-specific. Check to see if it makes sense to upgrade or consolidate your current messaging environment before extending mobile or wireless services.

Mobile and Wireless messaging components

There are essentially three components to a mobile or wireless messaging infrastructure extension. There is the connectivity infrastructure, which determines how and when new messaging information is made available to users; there are the network services to consider and connectivity software; finally, there are the mobile/wireless devices that will receive the information.

Connectivity architectures

The connectivity infrastructure you use determines how and when information is made available to the user community. You can categorize those types of infrastructure into the following types: push delivery, network- or desktop-based pull synchronization, and online Web access.

Push delivery is for people who need to receive information in real- (or near real-) time. Even though this is the kind of connectivity you see on TV commercials, the need to be this connected is pretty rare. The advantages of a push solution are that users receive and send information dynamically--typically with a less than 15-minute delay (the time it takes to relay information between the push server and the corporate messaging server). As long as the user remains within the appropriate coverage area, he doesn't have to take any action to receive his e-mail. The limitations of such a solution at this time are that any single piece of connectivity software only supports a limited number of devices. In fact, until recently, push solutions were pretty much limited to RIM Blackberry and SMS- (Short Message System) enabled devices.

In late 2004, a couple of vendors started offering a push-based solution for Palm and Windows Mobile devices. The solutions work by keeping an IP connection open between wireless devices. This is a nice innovation, however there have been reports that this can seriously impact the battery life of the device. Given the novelty of these solutions, it's wise to proceed with caution. To close out 2003, RIM and Palm announced their intention to deliver a solution that lets devices running Palm OS access BlackBerry Enterprise Server (BES). This is expected in Q3 of 2004.

Unlike a push solution, a pull-push solution requires the user to initiate a connection with the server to pick up or send new messages. Although you can configure some pull-push synchronization solutions to activate on schedule, simulating a push-only solution, battery drainage is still an issue. The advantages of this type of solution are that it's quite robust and it lets a single PDA client connect via a variety of modes (wireless, wired modem, LAN-based, etc.) saving money on communication costs, and providing some redundancy. And, unless real-time notification is required, it usually satisfies the bulk of user requirements. The limitation here is that the onus falls on the user to connect; however, this solution will probably meet the bulk of your users' needs. These network-based synchronization solutions are the bread-and-butter connectivity model for PDAs, so there are a number of excellent, market-proven products available to support this type of solution (table 2). Desktop-based synchronization solutions--cradle-based syncing--are still available; however, I don't suggest these for enterprise-level deployment. These solutions completely decentralize your messaging infrastructure and, in the long run, cost you more in support and maintenance costs.

Online Web-access solutions use thin-client technologies such as HTML or WAP browsers to browse a Web-enabled mail server. Because these solutions are driven on the server side, they typically require very little configuration on the device. And, given the generic standards-based technologies used, you can usually extend connectivity to a wide variety of devices.

Because they don't store data on the device, thin-client applications are more limited in functionality than PDA client applications. You usually just get the basics, such as the ability to send and receive. In addition, a wireless connection is absolutely essential to access e-mail and the onus is on the user to initiate the connection to the server to check for new messages. However, this type of mail client is perfect for B2C environments where you have little control over the devices your users utilize and they need only basic services, minimizing support and maintenance costs.

Connectivity software solutions

Mobile middleware is the heart of a stand-alone mobile infrastructure. This software sits between the device and the corporate messaging network, and coordinates the exchange of information between the device and your corporate mail server. When the first middleware packages came out, most of them supported only synchronization and were intended to support PIM-based applications. Some have evolved to include application access.

Most of the middleware solutions also offer handheld management capabilities that allow device inventory, application deployment, security setting enforcement, and access to a range of database types. There are few limitations to using mobile middleware. However, it's important to consider products and services based on scaleable technologies and that could integrate with enterprise systems other than e-mail. The only time I would suggest a solution that doesn't use mobile middleware is when and enterprise portal is an option.

Another connectivity solution is to run your wireless services as an extension to your enterprise portal. The role of a portal is to provide tailored information and access to corporate systems from a central access point. A portal solution groups information through a single access point; so, it makes sense to consider your wireless project as an extension to the portal project--not just for e-mail, but for all corporate systems. If your company has a portal solution in place or in the works, it might be worth it to think about extending it to mobile and/or wireless devices. The advantages of such a solution--if your portal is already in place--is that you only have to provide the wireless front end. This could save you precious time and effort, while avoiding bilateral access to your corporate systems. However, if your portal isn't already in place, you may just have bought yourself an 18 month implementation plan. In other words, you've linked your mobile project to a much more complicated project, probably significantly delaying mobile messaging deployment.

Wireless carrier services

Most major North American wireless service providers have completed major network upgrades over the last few years. Solid GSM/GPRS and CDMA/1XRTT networks are now available across all major population centers. At 56kbps, they provide a decent user experience.

Coverage limitations

Make sure your users understand coverage limitations. We've all heard the adage of "anywhere-anytime" access (heck, I've used it a couple of times in this article), but you should take this phrase with a grain of salt. There are still many regions where cell signals aren't available or remain unreliable (across major geographical boundaries, outside dense urban centers, within hospitals and clinical environments, or even in major cities in tunnels or along subway systems). Consider a land-based backup option if you think your users will be frequently affected by any of these situations.

Is it possible to have a single carrier?

There are basically two wireless connectivity protocols in use in North America.

These are GSM/GPRS and CDMA/1XRTT. Within these two technologies, different cellular service providers offer varying levels of coverage, depending on their own infrastructure capabilities and those of their partners. Evaluate your needs in these three categories: local coverage in and around your business centers, continental coverage for cross-country travel, and international coverage for inter-continental business travel.

As soon as you leave North America, GSM/GPRS is the dominant protocol. CDMA/1XRTT isn't available in a usable way in outside North America. However, using GSM/GPRS [isn't a free ticket to international coverage. Your local carrier must have a partnering agreement with other national and multi-national carriers for you to access their networks.

Review your security architecture

Data security is definitely a concern when distributing data outside your organization. However, it is important that you keep these concerns in perspective. Ensure basic network encryption and authentication is enabled and consider using third-party tools to secure locally stored data on your mobile devices if you aren't satisfied with those provided with the OS. See John Vacca's article, Smartphone Security, in the December/January 2004 issue of MOBILE BUSINESS ADVISOR for more information on this topic.

Policies and support

Don't forget to re-evaluate your messaging and hardware procurement/ownership policies before your deployment. And, don't underestimate the importance of a solid user education and support plan. Despite the fact that PDAs are relatively easy to use, a comprehensive training plan will maximize your investment in the long run when it comes to support and productivity issues.

Next steps

I've said it once, I'll say it again: Complete a thorough needs analysis before you turn your attention to devices and services. The following questions will help you isolate your solution requirements and deliver a solution that meets the needs of your users:

1. Why do your users need wireless messaging? Knowing what the business drivers are will help you understand your solution priorities.

2. Do your users need messages to be pushed to their devices? Do you have mixed requirements? Do some of your users need push solutions and others only pull-push synchronization? The answer to this question will help you determine which type of solution architecture to deploy.

3. Do all your users need the full compliment of services you've identified as requirements, or can some be satisfied with less? What is the overall project budget--initial and long term? Knowing the answer to this question will help you segment your requirements and save you money.

4. Do your users need to access any other information in mobile or wireless mode? Answering this question helps you align your solution infrastructure with needs beyond basic messaging.

5. What happens if wireless services are unavailable? You might consider a second redundant connectivity option or a desktop synchronization solution.

6. Do your users need to access their e-mail from a range of devices? Do you need to keep support to a minimum? A thin-client solution may the choice for you. The beauty of this option is that you can support almost any device with the appropriate browser. You can also easily extend other applications via this solution.

Despite the many challenges of working with emerging technologies, you can successfully extend corporate e-mail to mobile and wireless devices. The trick is treating this project with the same care and planning you would any other IT project. It's all about staying focused and making sure you're deploying technology with a purpose, not just because it's cool.

Initial and long-term considerations

When extending mail to users you must budget for devices, wireless data coverage, middleware licensing, and hardware for the middleware. To give you an initial budget price for this kind of project, table 1 shows the material costs of a 10-user deployment of a wireless e-mail solution. Table 2 shows you some middleware capabilities.

Table 1: Cost estimates--Be sure to take "hidden" costs into
consideration.

CATEGORY                 UNIT COST                     COST FOR 10
                                                       USERS FOR 12
                                                       MONTHS

Devices                  $500 per devices retail       $5000

Wireless data coverage   $50 per month                 $7,200

Middleware licenses      About $250 per user for       $2,500
                         10 users, scaling down to
                         approximately $100 per user
                         after 100 users

Hardware for the         $5,000                        $5,000
middleware server
                                                       $19,700

Table 2: Middleware product comparison chart--Mobile middleware
has evolved past offering just PIM synchronization.

PRODUCT             PUSH         PULL-PUSH
                                 SYNC

Pumatech            Yes          Yes
Synchrologic
Mobile Suite

IBM WebSphere       Yes (SMS)    Yes
Everyplace
Access

Extended            Yes          Yes
Systems One
Bridge Mobile
Groupware

RIM Blackberry      Yes          No
Enterprise Server

PRODUCT             BROWSER           DATABASE
                    ACCESS            INTEGRATION

Pumatech            Yes               Yes
Synchrologic
Mobile Suite

IBM WebSphere       Yes               Yes
Everyplace          (possibility to
Access              take pages
                    offline)

Extended            Yes               Yes
Systems One
Bridge Mobile
Groupware

RIM Blackberry      No                Limited
Enterprise Server

MOBILE BUSINESS BENEFITS

Unlike most other core user services, the demand for corporate mobile and wireless e-mail is most often user-driven. This can start wireless projects off on the wrong foot, focusing on all the wrong priorities. Approaching mobile and wireless with a discussion of the real business needs and technology capabilities will start you of on the right foot.

DOs and DON'Ts

1. DO NOT let users drive the project.

Many organizations start out on the wrong foot by failing to treat mobile and wireless projects with the care and attention they would any other IT project. This is often the case when the pressure to deliver comes from users at the top, as mobile/wireless messaging demands often do. For example, IT neglects to ask even the most basic of questions. Why is does the company need this technology? What are the full requirements for the project? Instead, IT jumps directly to this question: How do we do this (and deliver it yesterday)?

2. DO NOT put the cart before the horse.

A common mistake on mobile and wireless projects is to plan the solution based on the selection of a wireless device. This is often the case when the main project user is a gadget-hound. Because many wireless devices come with some type kind of service contract, you're instantly stuck with a specific carrier/ protocol. You then have to find an infrastructure that works with both the device and the required protocol. This is akin to buying a server before knowing the software specification and the application that will run on it. On any other project, hardware is the last component selected. Why should a wireless project be different?

3. DO make sure you pilot the right solution.

Another common mistake is with the pilot. Not that the concept of a pilot is bad thing; the issue is that many pilots come too early in the process. These are often thrown together without taking the time to fully assess your requirements; you may well end up piloting the wrong solution. Many projects collapse at this phase as pilots fail to meet even the basic project requirements.

Lessons Learned

1. Set realistic expectations!

Some people want everything and will be satisfied with nothing less. Offer real-time wireless messaging, and they'll expect to be able to edit Word documents and presentations on their device, which must, of course, be the size of a credit card. Help them understand reality: Technology has improved a lot, but a handheld won't replace a desktop (although it might just replace a laptop for users with low-level requirements).

2. "Anywhere-anytime" access equals "anywhere-anytime" support.

One of the first things I learned from extending mail to wireless devices is to be ready to extend support along the same scale. Now users can work anyplace and anytime--and guess what? They will! Keep in mind this often includes your most nomadic, most senior, and coincidentally most demanding user groups.

3. Understand your resources.

Keep in mind that you are working with emerging technologies; therefore, you won't find people with 10 years of experience with these technologies. You might even have a hard time with vendor support where front-line people are limited.

4. Be the customer for a day.

Walking a mile in your users' shoes will help you understand the conditions they work under, and put you in a better position to address their needs.

5. Start now.

Your users are bringing new devices into your company every day. The longer you wait to start your mobile projects, the more heterogeneous your environment will become.

Martin Lauzon has been working in the field of mobile and wireless business solutions since 1998. He leads Imagina's wireless practice and manages Imagina's messaging consulting team. His experience and expertise provide real-life practical solutions to Imagina's customers. Imagina Technical Solutions has been offering IT-related consulting services since 1984 and maintains a dedicated mobile-wireless solutions practice, http://www.imagina.ca.