Getting a wireless program to work today is no problem. Living with it tomorrow is another matter. Here's how to do it.

Reader ROI

- Find out why many of today's wireless projects are throwaways.

- Learn the benefits and drawbacks of an n-tiered architecture for wireless applications.

CIO Perry Lipe wants his company's corporate data to be available any time, anywhere for employees and customers alike. To achieve that, he plans to use wireless devices. But rather than invest in soon-to-be-obsolete technology or force a costly and premature architecture implementation, he's giving himself until 2006 to figure it out.

Lipe's experiments with wireless projects began in July 2000 when auto-part makers Arvin Industries and Meritor Automotive merged, creating ArvinMeritor, the $US7 billion Michigan-based company. By 2001, wireless access to corporate data was one of the core components of his five-year strategic plan. However, that component of his plan is intentionally vague - particularly as it relates to architectural changes. "Building the application isn't rocket science, but we don't know about the impact on the infrastructure or the expenditures we will have to make to support the right middleware," Lipe says.

As Lipe suggests, functional wireless applications can be easy to build. At first glance these applications are a cheap and easy way to make mobile workers more efficient - any programmer worth his paycheque can rig up a server and write code that gives PDA users access to information in a particular database. And it is increasingly difficult to resist: a March 2001 Forrester Research survey found that 60 per cent of wireless projects at 3500 global companies were not part of an organisation-wide wireless plan but were one-off applications designed to address a specific need, linking one type of device with one data source.

The business benefits of these one-off applications, however, rarely equal their hidden cost, and the irony of most of today's wireless projects is that their success will eventually lead to their downfall. Wireless applications, whether for sales-force automation or e-mail access, make mobile workers' lives easier, and thus will be popular. But one-off wireless projects have problems: they won't scale, support multiple devices or handle complex transactions. As the applications attract more users, their flaws will be exposed.

The best way to support enterprise-level wireless applications is with an n-tiered architecture, which is a multilayered architecture complete with middleware for queuing and delivering data to any device. "The n-tiered architecture makes it easy for us to adapt to wireless and be flexible without putting additional strain on our back end," says Jeff Scott, CTO of New York City-based Thomson Financial, a $US2 billion financial information company. "If a company is going to build a wireless delivery mechanism into its architecture then it needs to be n-tiered."

But converting to an n-tiered architecture is neither cheap nor easy. Larry Mittag, vice president and CTO of California-based systems integrator Stellcom, says that depending on the size of the project, an n-tiered implementation can run into the millions or potentially tens of millions of dollars, and it could take anywhere from six months to several years to complete.

Numbers like those create a serious hurdle - one that most companies aren't in a position to clear at the moment. But as the benefits of wireless applications become clearer and wireless technology itself matures, business needs will demand an n-tiered architecture to support enterprise-level wireless applications. However, a CIO who doesn't understand the implications of the wireless applications he builds risks having to convert to an n-tiered architecture before he is ready or, worse, could end up supporting obsolete wireless systems for years.