here’s no lack of innovation going on in the wireless area and the technology is maturing fast. But still, the vast majority of developers have avoided taking the wireless plunge. That’s going to change, and soon. But why? What’s really going to drag developers off the wires?

Devices.

Wireless devices are proliferating. Not so long ago the term “wireless devices” meant cellular phones. That’s no longer true. Wireless devices are becoming ubiquitous, and the lines are blurring between traditional wireless devices, such as cell phones, and newer wireless devices such as wireless enabled-PDA, smart phones, tablets, and even PDA-phone hybrids (see sidebar “Inspecting the Ranks“). Beyond that, advances in wireless network technology are turning traditionally wired devices such as laptops into full-fledged wireless clients. These advances herald a new use for wireless devices—corporate applications—and that means the number of developers tasked with creating wireless applications is increasing sharply.

As devices become more capable, approaching that of traditional desktop systems, developers and IT departments will be squeezed between users’ and organizations’ needs. Both will apply pressure, albeit for different reasons, in an effort to acquire applications that improve employees’ mobility, make using remote applications more convenient, and improve customer contact and response time, all of which will work to increase sales and cut costs. Gartner research director Theresa Lanowitz says that wireless applications are “going to creep to the top of the priority list, for the enterprise, for the IT department, and they’ll make up more than 85 percent of the new development effort in the next three to five years.”

That’s a bold statement. To understand why Lanowitz feels such a radical shift will occur, you need to understand the driving forces behind the push to wireless.

Who Wants Wireless Applications?
Why do users want wireless applications? Well, how many wireless devices do you use? Two? Three? Five? At the Gartner Wireless Access and Mobile Business Solutions conference in Los Angeles last month, the average among attendees seemed to be three, although a few claimed to have up to seven devices. Even the low end is probably far higher than average, but you can assume that most mobile professionals have a cell phone, and some also have PDAs or RIM Blackberries; therefore, the number of wireless devices among this group probably alreadyoutnumbers PCs.

These numbers clearly point out that mobile professionals not only want remote connectivity—after all, up to this point, they’ve probably bought the hardware themselves—but also that they’re rapidly becoming dependent on working in an always-on-always-connected manner. Users may initially buy devices because they want to be able to make personal phone calls from their car or because they like the interactivity and entertainment value of wireless messaging and gaming, or because they want to send and receive emails or manage their contacts while not in the office; but as the devices grow in functionality (and that growth is happening exceedingly fast) users increasingly expect to be able to take advantage of a greater subset of their devices’ capabilities. And rightly so.

Why do organizationswant wireless devices? Providing wireless access to applications solves many corporate mobility problems, saving employees’ time, improving real-time access to information, and, ultimately, directly affecting the bottom line.

Employees and corporate managers know that the devices they use now to make phone calls manage their contacts and play Tetris could very easily be used to check their corporate email, update their calendars, and access many of the applications they use every day at work—at least, theoretically it would be easy. The hard part—designing and developing new applications suitable for these devices or adding wireless connectivity to existing applications—is where you come in.

What Corporate Wireless Applications Are Available Now?
So far, most wireless application programming efforts at the corporate level have been directed toward building special-purpose machines for vertical applications. Such efforts have been under way for several years. Among the companies showing vertical applications at the Gartner conference were United Parcel Service, which first armed its delivery personnel with analog mobile technology more than 10 years ago, but has since built special-purpose wireless digital devices, and is incorporating Bluetooth and 802.11b technology into its next-generation systems.

Other companies are capitalizing on wireless in completely different ways. With the advent of cheap and easy Wi-Fi access points, Starbucks (via T-Mobile) now offers HotSpot connectivity at many of its stores, letting users reach the Internet, send email, and chat while sitting in comfort and buying more coffee. In addition, Starbucks managers, who typically manage several stores and travel between them, are able to communicate with employees, get reports, do paperwork, and generally work more efficiently by taking advantage of those same access points.

But building special-purpose devices, or simply providing wireless access to employees and customers is not going to be enough to bring wireless into the mainstream. The next wave of wireless innovation will capitalize on ubiquitous connectivity and general-purpose devices in the same way, and for the same reasons, that companies adopted personal computers, networks, and the Internet—the technology has become inexpensive and powerful enough to be an asset.

One early adopter is the city of Bellevue, WA, which is giving city employees wireless technology that improves customer satisfaction. But it is having unexpected side benefits as well. For example, city parks employees are able to shut off sprinkler systems remotely during rainstorms—providing both water cost savings to the city and convenience to the employees.

In the corporate world, it’s easy to imagine how the newer, more powerful devices and capabilities can affect the bottom line. Paul Whitaker, Program Manager for the Nokia Content Syndication Program, recently gave us an example: Insurance adjusters often visit automobile accident sites to investigate the causes of accidents and estimate the damages involved. Till now, if they wanted to document the scene visually, they’ve had to carry a camera or hire a photographer. They take notes and make diagrams, and then they typically go back to the office to write up a report. But now, using a smart phone with video capability, they can fill out the report, take pictures to document the accident situation, and upload everything directly to the corporate database.

In other words, the device gives these people the capability to combine both the on-site and off-site tasks into a single on-site operation while improving the organization’s response time. The time-savings also let adjusters visit more sites in a single day. And all this increases convenience for the adjusters, who no longer necessarily have to travel back to the office to do their paperwork. The result is huge cost savings for the organization.

If it hasn’t already, this kind of logic will eventually sprout roots in your industry, and it will quickly travel down the chain to squeeze some wireless products out of you.

Why Hasn’t the Shift to Wireless Already Happened?
Given that these capabilities are already available and that users are ready to consume the functionality, why hasn’t this need for wireless applications happened sooner? (See the sidebar “Holding Wireless Back: Top Failures of the Wireless Industry“.) There are several reasons:

Perception. IT departments and organizations, while often tolerant of PDAs and phones, haven’t assumed responsibility for them as they have with traditional PCs. That’s a mistake, because these devices are not just phones or contact managers any longer—they’re full-fledged computing devices, with the attendant support and security risks, and should be treated as such.

Accessibility. Wireless coverage has not, until recently, been available in many areas of the country, and it’s still spotty. Gartner Vice President Nick Jones says that “you should expect to have multiple sorts of wireless networking in your organization,” and that “50 percent of organizations will find themselves using at least five different types of short-range wireless networking by 2007.” Wireless providers have, so far, not delivered the access and bandwidth to back up the wireless hype. “Through 2007,” Jones says, “WAN capabilities will continue to deliver improved data throughput and location precision, but advertising and hype will cause service providers to fail to meet user expectations for speed, cost and capability.” That’s backed up by UPS’s experience. Rolling out their wide-area delivery applications required a large number of contracts with wireless providers across the U.S. and Europe to get the coverage it needed.

Speed. So far, wireless hype has promised more than it has delivered; still, the bandwidth available for wide-area wireless connectivity is moving beyond the current abysmal speeds. Although access to high-speed connectivity is currently both limited and expensive, it can support full-featured applications as opposed to simple text messaging. For applications that need only short-range mobility, WLAN connections provide 11Mbps of bandwidth or more. (See sidebar “WLAN Quick Start: Getting up to Speed on 802.11 Wireless LANs.”) While that’s considerably slower than the typical 100Mbps corporate network, it’s fast enough for all but the most demanding applications.

Applications needing wide-area connectivity are burdened by slower-than-dialup wireless data connections. That means you still need to design applications differently when clients can’t connect to your network through a WiFi hotspot. But there’s hope. Faster connections are slowly coming online, although they’re still very limited in coverage—for example, you might be successful with a wireless application within a specific city or portion of a city, but you may not be able to count on that provider to supply the same level of coverage or service across a state.

Standards. Standards, while improving, are still in flux. Although the network protocols—wired or wireless—should have only minimal impact on developers, they have a huge impact on application performance and interoperability, because the different standards provide different coverage ranges and speeds. The time when developers can ignore the protocol in use is still a distant dream.

Cost. The price of wireless data transmission is dropping but is still high compared to wired applications. Worse, there’s no standard billing plan, so users who cross from one provider’s coverage area into a different provider’s coverage area, for example, may pay different prices for the exact same service. On the flip side, if you’re planning to sell (rent) application functionality to the end-user market, there’s also no standard billing model for users to pay for them, and their access costs are also high. (See the article “Value-based Billing for Wireless Java Applications.”)

Downtime. While wireless networks are improving, they have a long way to go before wireless connectivity is as consistent and dependable as wired connectivity. Weather, distance, physical barriers, device failures (such as loss of battery power), and connectivity failures (as simple as driving through a tunnel) all conspire to make wireless applications less robust than wired versions. For critical applications, you must design your applications to expect failures, and implement an alternative way for remote workers to submit and receive data, even if that means creating a paper-based fallback plan. According to Gartner Research Director Bill Clark, critical wireless systems that don’t have a fallback “are a recipe for disaster in 2003.”

Device Capabilities. Until recently, wireless devices have been relatively slow with limited capabilities. Organizations implementing corporate wireless applications have relied on specially designed hardware used for vertical applications. However, as the computing, display, and connectivity power of wireless devices increases, they become commensurately more able to support corporate applications. The newest devices are just now reaching that point. Device capabilities are still a barrier to general purpose applications, but that barrier is diminishing rapidly.

Development Tools. The tool sets haven’t yet reached the point at which developing for wired and wireless devices in tandem is completely transparent, but that’s changing. The split between the wireless and wired worlds is going to disappear, and, in fact, we’re already seeing clear signs of that happening. For example you can create both wired and wireless applications in VS.NET (see “Developing Mobile Applications Using the Microsoft Mobile Internet Toolkit” and “Developing Pocket PC Applications in Visual Studio.NET“), in JBuilder, in WebSphere, and in other major development environments. All these, to some degree, hide or simplify the differences between the various client devices.

Audience Positioning. The wireless industry has focused the vast majority of its marketing effort on consumers and ISVs. While there are certain obvious strategic reasons for doing so (mainly the size of the audience and the accompanying size of the revenue potential), the effect is that wireless development has not reached the corporate IT mainstream as quickly as it should have.

Despite these problems, the need for wireless applications by users and organizations is steadily increasing, and your job, as a developer or application planner, will be to deploy wireless applications while accommodating their inherent restrictions.

Choose Your Target Devices
A large number of devices are available already, and you can expect more to appear in the future. Nick Jones says you can expect devices to change roughly every 18 months. And these devices don’t all have the same capabilities—they’re targeted for different tasks. The current situation, where organizations standardize on a few desktop and laptop computers and where developers focus primarily on desktop applications, is changing. You’re going to have to consider all the devices in play in your enterprise.

The low end of these devices is enhanced cell phones, which can display a few lines of text. While they may be adequate for sending and receiving text messages, most corporate developers probably won’t have to get intricately involved with supporting these devices; the best choices for deployment here come from the consumer market and ISVs. The newer devices, such as smart phones, PDAs, and the newest of all, hybrids between the two, are a much more appropriate platform for running corporate applications.

While powerful, they don’t match the capabilities of desktop or even laptop machines. And they vary widely in display capabilities. So, you have to start thinking about alternate ways to input data (voice input, one-handed operation), ways to slim down your fat desktop client applications (splitting screens, eliminating rarely-used features), and ways to write applications that are conducive to intermittent connectivity (local data-caching, better error messages, fallback plans). And, of course, there are new and serious security concerns.

Alternate input brings new data types into play. Suppose, for example, your users need to fill out a form. A text-based cell phone is not an ideal medium for inputting text manually; such applications will work better with voice input. Similarly, small form-factor devices, even when equipped with keyboard input, usually work best with one-handed input. Neither is conducive to entering raw text. Instead, you need to let users select from lists and do abbreviated one-handed typing and selection.

Finally, you want these applications to run on the same back end as the current desktop applications—and users need to be able to move seamlessly between them. Therefore, the data that you collect from these mobile devices needs to be compatible with the data you already have; you need to be able to translate voice data into text data and vice versa.

As multimedia applications and location-enabled (GPS) applications come into play, you’ll need to be able to translate GPS location information into an appropriate data type, for example, using an employee’s location to display a map containing new route information. The point is that the proliferation of devices and their new data capabilities are causing new interoperability needs for data, as well as for applications.

Fat desktop applications just don’t fit on the small screens of mobile devices. The need to separate UI from application logic is more imperative now than it ever has been. For example, displaying a grid containing the contents of a database table might be simple on a full screen desktop application, but translating that directly to a smaller screen, perhaps by breaking the display into multiple pages, simply causes problems for users. You need to think about alternate ways to preserve the functionality of the application while delivering a user interface appropriate for a smaller screen.

Just as developers’ techniques had to change to move from standalone computing to client server computing to Web-based computing, they are going to have to change to take wireless connectivity issues into account. First, you need to consider how your application responds when users aren’t connected, and second, how your application responds when connectivity is suddenly interrupted.

Sudden loss of connectivity is not a new problem—developers had to address this issue more than five years ago when Web-based applications became mainstream, but there is a difference. Users have learned to work around failures in their wired Web applications; when connectivity is lost from a wired client browser, users generally know what’s happened and what to do to proceed. With wireless applications, it can be far more catastrophic when connectivity is suddenly lost—the devices often require a reboot to continue—and it’s far more confusing for users to pick up where they left off.

To do all of that, you need to understand what the devices are and how their varied capabilities affect what you write. So what devices do you need to be concerned with, as a corporate developer?

• Smartphones
• PDAs
• PDA/Phone combinations
• Wireless-enabled laptops
• Tablet PCs
• RIM Blackberry

See the sidebar “Inspecting the Ranks” for a representative sampling of the device marketplace today.

Choose the Appropriate Platform
Choosing the appropriate devices for your applications is only the beginning of the challenge. Not only are there several categories of devices, but they also use different, and incompatible platforms. For example, in the SmartPhone arena, Nokia, Symbian, and Microsoft all offer different application platforms. In PDAs, Microsoft CE/PocketPC devices and Palm OS-based devices are the market leaders. Palm was first out of the gate, and still has approximately 50 percent of the total PDA market, according to Gartner, but the number of CE/PocketPC devices is growing rapidly. (See the sidebar “Examining Developers’ Artillery.”)

Even in their current versions, developers familiar with common languages such as VB and C++ can write for CE/PocketPC devices, and with the advent of the .NET Compact Framework, which will ship on the next generation of PocketPC and CE devices, the difference between targeting a desktop or PocketPC application becomes largely a matter of designing the proper interface.

The emerging Linux-based PDAs may also become a target for corporate developers (see “Sharpen Your Java Wireless Skills with the Zaurus SL-5500 PDA“). But developers may have problems writing applications that run consistently across Linux-based devices, even when those devices have similar display and interface characteristics. Ken Dulaney, vice president and research area director for Gartner, says: “The problem with Linux is that there are so many of them.”

Dulaney lays the land like this: The Pocket PC offers the most platform consistency, which makes it very attractive to many enterprises. Microsoft, he says, “gives you what you want—they give you development tools, they leverage your programmers, they look like a PC.”

As Microsoft’s new .NET CE framework becomes standard on PocketPC and CE devices, it will provide a common platform across all these devices, reachable with a growing number of languages—and because it’s a subset of the full .NET framework, porting existing Windows applications will be considerably simpler than translating them to other platforms.

“[Microsoft isn’t] above criticism at all,” Dulaney says, pointing out that, for one, the Pocket PC has not delivered the equivalent of RIM’s functionality for email. “But it’s the only place today where you can go today to find a wide selection of industrial devices and consumer devices of different shapes and that’s particularly attractive to the enterprise.”

Linux is at the opposite end of the spectrum, with a large number of variants that each require custom development and optimization.

And Palm, he says, “is a mixture. If you go from a Handspring device to a Palm device they’re fairly similar, but they’ve chosen different email systems and different constructs inside to make them a little bit different. They’re trying to improve that because they realize enterprise buyers want that [conformity].”

Palm is going through a lot of changes right now that are making some enterprises wary, he said.

Laptops and the Tablet PC both run various flavors of Windows, a platform for which there’s alreadyan army of experienced developers available. RIM, which is currently far and away the leader in wide-area email messaging, shows promise, but needs to build its platform, its tools, and its developer base. Dulaney said that what he most often hears from IT professionals is that they want a hybrid Pocket PC/RIM device. And the onus is on RIM to change its business model to open itself up to third-party software.

“The good thing about RIM,” says Dulaney, “is that I think they’ve understood the transition they’re going through. And they seem pretty responsive. Definitely I would regard RIM as a promising vendor but they have to reinvent themselves to be a dominant player. That said, they have a strong customer base and a very happy customer base.

Symbian is also a strong but still-evolving platform, which, for now, is targeted primarily at the consumer market. Dulaney, said: “While I think their development tools and framework are particularly good for consumer applications, I don’t think they’ve met the test for enterprise class certification yet. They’ve got to restructure Symbian and provide more enterprise class certification and rigidity of design in order to move forward.”

It seems Symbian, Palm, and RIM are all in the position of needing to evolve rapidly to have a chance at matching the attractions of the PocketPC/CE platform, which is already reasonably mature, quite stable, and available on a wide range of devices, from smart phones to PDAs to ultra-portables. But more important, each is in a good position to deliver on that challenge.

Both Java and .NET developers will have a reasonably familiar platform for which to develop wireless applications, but the many differences among wireless devices ensure that there are plenty of problems beyond choosing a platform. According to Theresa Lanowitz, the problems developers encounter will be similar to those they’ve encountered while building client-server and Web applications.

Choose Wireless Application Candidates Wisely
Despite the similarity of the problems to those involved in other development efforts, Lanowitz maintained that developing for wireless devices is fundamentally different from developing traditional wired applications because the devices are potentially always-on, always-connected, have different interfaces and different display requirements, are used in different settings, and application errors affect users in a much more negative way than do errors in traditional applications. She stressed that developers must, more than ever before, know the users, know what they need, and know how they plan to use the applications. “Not all applications can be usable in a mobile environment,” she said. “Many organizations will want to port all of their apps to the mobile environment, just as we saw a few years ago everybody wanting to port allof their applications to the Web. You don’t need to port all of them.”

So what kinds of applications are good candidates for wireless applications? You might approach the decision by looking at what people do and the provider/client model you’re using to deliver them. Clark characterized these applications (and their users) into several categories.

B2C (Business to Consumer): Consumers will primarily use applications such as SMS, Voice over IP (see the sidebar “VoWIP Quick Start: Getting up to Speed on VoIP on 802.11 Wireless LANs“), and games.

M2M (Machine to Machine): Wireless access built into machines will become more common. For example, a coin-operated drink machine, rather than requiring periodic checks by a human, could notify an organization or a mobile worker’s wireless device when they need refilling or maintenance.

B2E (Business to Education), B2B (Business to Business), B2G (Business to Government): This category encompasses the bulk of mobile workers, which Clark subdivides into three groups:

• Road Warriors: People such as executives, sales, knowledge workers, fleet, delivery, field service, and others who travel outside the workplace need true wireless applications; however, the coverage areas and data volume plans required may vary by job or by individual. For example, some maintenance personnel may only need to enter a check mark next to a machine identification number each time they check a machine. A worker might make hundreds or thousands of such single-data-point transactions per month, yet transfer only a few megabytes of data. In contrast, an executive who consumes spreadsheets, database reports, and live documents may need to transfer hundreds of megabytes per month. Similarly, some mobile workers work within a single-coverage area, while others may require coverage across cities, states, or even internationally.
• Micromobile Workers: These people move from one location to another at the workplace, but don’t need wide-area services—for example, health care workers, teachers, students, site security personnel, and warehouse workers can all benefit from wireless connectivity, and are excellent candidates for applications delivered over WLANs.
• Office-centric Workers: People who move between offices and telecommuters probably need wide-area coverage, but often stay continuously connected once they’ve reached a work location.

Employees who access workplace networks from home offer an additional security hazard—they may be running their ownWLANs, but theirs may not be as secure as the office LAN. Any data they access or store on their own machines is subject to the same eavesdropping and access security problems as data on the organization’s network, but is rarely as well-protected.

Mobile Devices Pose Security Hazards
Mobile devices pose significant and increasing security hazards. Organizations must learn to treat these devices as full-fledged clients, and create and apply the same sorts of security policies that they’ve devised for desktop and laptop computers. Randall Nichols, CTO of Infosec Technologies and George Washington University, says that organizations tend to adopt PDAs informally, and that lack of formality can have disastrous consequences.

To minimize the security threats from loss or theft of the device, organizations must mandate the use of power-on passwords, and put remote-destruct policies (which erase data on the device remotely) in place. He advocated random audits to check for compliance, and severe penalties for breaching the security policies. Nichols stressed that organizations cannot rely on users to provide their own security. Even common operations, such as synchronization and simple file transfer have the potential to circumvent current network security and disrupt operations, bypassing network-level virus-checkers, for example, or allowing employees to leave the premises with devices containing sensitive information.

If such policies seem overly draconian, there is supporting data that should scare you. Gartner Vice President and research director John Girard writes that “Through 2005, 90 percent of mobile devices that contain enterprise data will have insufficient power-on protection and storage encryption to withstand casual-to-moderate hacker attacks.” Further, “at least 5 percent of enterprises in every major industry segment will expose sensitive information to a competitor through mobile, wireless, and user-owned devices.”

To rein in the gargantuan task of managing enterprise requirements on a vast sea of devices, Gartner recommends that IT departments adopt a three-tiered “Cafeteria Plan” that gives organizations a semblance of control over device support while still giving users some choice over what devices they can use. (See the sidebar “Making a Cafeteria Plan.”)

We Know Where You Are
If the network coverage, device and platform proliferation and versioning problems, disparate user profiles and needs, and security hazards aren’t enough, some of the more advanced capabilities of wireless devices offer unique opportunities—and hazards. An increasing number of devices offer built-in digital cameras, voice recorders, and GPS capabilities. Organizations can use these features to improve services and efficiency, providing directions to delivery personnel or letting a dispatching center know exactly which mobile unit is closest to the scene of an emergency for example. Video and audio capabilities also show promise, letting experts talk beginners through procedures, or letting field workers send or receive detailed pictures that may help them solve problems, or show specific situations to remote experts.

Unfortunately, such capabilities can easily backfire, because they also give people using the devices the capability for capturing images or recording conversations more easily than ever before—possibly in locations and situations where the organization might not wantthem to take pictures or capture audio. Employees may, either intentionally or accidentally, send images or capture audio that cause problems for the organization. Employees and unions may object to the privacy intrusion inherent in GPS tracking. Even worse, there are no legal precedents for some types of problems.

For example, suppose a consumer using a GPS application gets the wrong directions and misses an important appointment, or worse, gets injured while following those incorrect directions. The legal ramifications of such possibilities are not yet clear, nor are the social or workplace controls in place to limit the use of knowledge about a person’s location at any given time.

The uncertainties involved in wireless development should change the way you approach your design and implementation.

• Choose projects that truly need wireless capabilities and that will have an immediate bottom-line impact on the organization.
• Plan for security as part of the application—don’t rely on built-in security standards such as WEP to protect your data.
• Bring users into the process early, create a pilot project, and listen to users’ needs and reactions.
• Plan for frequent change—wireless applications built in 2003 will be volatile, due to upcoming changes in networking, devices, and users’ expectations.
• Capitalize on the lessons learned from agile programming—break large applications into small modules, use small focused teams, use unit tests to ensure that all code changes meet requirements.
• Give developers access to users, and give both users and developers the training they need to build and use the applications. Make sure every wireless project has a management sponsor, someone who will champion the application even through early-stage implementation and rollout problems.
• Control the devices—and test on all supported devices throughout the implementation/change cycle.

It is easy—and understandable—to feel daunted at the prospect of enabling a wireless enterprise. There is much to do and nearly ever step is couched in an ugly cloud of risk and uncertainty. But there is another way to see it as well—as an exciting and nascent opportunity to do what developers were born to do: tread unspoiled ground in information technology, blazing a path for new possibilities in computing.