WIRELESS TECHNOLOGY – Will You Still Love It Tomorrow?

CIO Perry Lipe wants his company’s corporate data to be available anytime, 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 $7 billion Troy, Mich.-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 paycheck can rig up a server and write code that gives Palm or BlackBerry users access to information in a particular database. And it is increasingly difficult to resist: A March 2001 Forrester Research survey found that 60 percent of wireless projects at 3,500 global companies were not part of an organizationwide 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 $2 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 San Diego-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.

Meeting Needs

Without an n-tiered architecture, one-off wireless projects can fall into three major traps. The first is the inability to scale. Thomson Financial was just implementing an n-tiered architecture to facilitate Internet data delivery when Scott came on board five years ago. And while he will not reveal all the details of the project, Scott says it cost millions of dollars and took several years to complete.

In the fourth quarter of 2000, Thomson continued its leading-edge information delivery with First Call, a financial information application that lets investors use their wireless devices to tap more than 800 brokerage houses for real-time corporate earnings data from more than 18,000 companies. As a subscription service, it needs to be accessed by as many people as want it?Scott cannot control the number.

A grassroots wireless application built outside the corporate IT infrastructure wouldn’t have scaled because it would not support the queuing needed to handle an unlimited number of data requests. Thomson’s users must establish a new connection for each transaction; a database that could accept only one transaction at a time would be both time-consuming and frustrating.

The middleware layer in the n-tiered architecture can queue requests for data so that a user can stay connected during the second it takes to process his request. Since the middleware was already in place as part of the n-tiered architecture, the entire First Call application cost only a few hundred thousand dollars, Scott says.

The second trap is supporting a wireless application that works only with a soon-to-be-obsolete device. Gartner estimates that by 2004 wireless devices will outnumber PCs, and Ken Dulaney, Gartner’s San Jose, Calif.-based vice president of mobile computing, says the devices that will be on the market then haven’t been invented yet. Accordingly, if a CIO wants his application to last, he must plan for access by multiple devices.

That reality forced Jeff Sutherland, CTO of Brighton, Mass.-based PatientKeeper, a wireless provider for health-care companies, to design a hospital-focused system that would support multiple wireless devices. When doctors visit hospitalized patients, they traditionally record the services rendered on note cards, eventually submitting them to hospital administrators who in turn bill insurance companies. Between lost cards and illegible handwriting, about 10 percent of billable charges?around $1 million for a 100-doctor hospital?go uncollected, according to Sutherland.

With PatientKeeper’s system, doctors can use wireless devices to record the services rendered and update the billing system in real-time. But Sutherland says most doctors already have devices they use for personal information and would rather not be forced to change. He found that an n-tiered architecture was the only way to design a system that would take into account their preferences. PatientKeeper supports front-end application program interfaces (APIs) for PalmOS and WinCE devices. There are more than 3,000 standard interfaces on the back end for integration with legacy health-care systems.

The centralized architecture means that the system will last, and Sutherland has harsh words for the alternative. “I view all of these point and departmental applications as throwaways,” he says. “I am going to want to deploy really useful applications across the enterprise. And to do that I am going to have to boot out all these point applications with a specific device or a specific data source.”

The third potential problem with one-off projects is their inability to process transactions that require data from multiple sources. An n-tiered architecture allows for this kind of interaction. For example, Fenton, Mo.-based marketing services company Maritz hosts travel services for its corporate customers, and the complex interactions it requires, such as travel booking, won’t work without an n-tiered architecture since travel booking also requires several interactions with different databases. Most of today’s wireless applications, such as e-mail, are single-transaction based. That model won’t translate to Maritz’s travel application, which CIO Gil Hoff-man says must request an itinerary, give choices, make a reservation and return a confirmation number as well as handle credit card information. This kind of complex transaction, which requires message queuing available only with middleware, is unattainable with one-off wireless projects that limit interactions to one data source. During the past five years, the company has developed an n-tiered architecture to support high volume, multidatabase transactions, Hoffman says.

When to N-Tier

Implementing an n-tiered architecture is costly. In the case of PatientKeeper, the ROI was obvious. In Thomson’s case, an earlier conversion made pioneering wireless applications practical. However, for most organizations, the still-uncertain character of future wireless usage makes the ROI difficult to divine.

Forrester Senior Analyst Frank Prince says that because of the cost and complexity of enterprisewide wireless, companies that can’t calculate clear ROI are better off delaying an n-tiered implementation?maybe even for a couple of years. “Look at the problems people have just with enterprise-level CRM,” he says. “And now we are going to define a standardized architecture and enforce it over a rapidly changing environment where we are not sure what will happen? The chances of getting it wrong are pretty good.” Prince says that unless a CIO sees an overwhelming ROI, he is better off pursuing carefully controlled one-off applications while wireless matures and APIs improve.

That’s the approach ArvinMeritor’s Lipe is taking. “All we can do is make sure that we are ready when the time comes,” he says. Currently his staff is implementing and evaluating low-cost, low-visibility projects like downloading intranet content to PDAs and a device-resident company phone directory. Neither application requires granting devices wireless access to corporate data, a step Lipe isn’t willing to take until he understands the consequences better. Lipe is particularly leery of consultants and salespeople, the lions, tigers and bears (oh my!) of the wireless world. If you believe everything you hear from wireless vendors and rush in headfirst “you can find yourself in the position where you commit to a direction that you don’t understand,” he says.

In fact, just having an n-tiered architecture isn’t a reason to extend applications to wireless devices. The wireless travel application Maritz’s Hoffman describes is still at least two years away. “I wouldn’t say we are scared, but we are approaching wireless with eyes wide open,” he says. “We’re making sure we do not get in it for the technology’s sake. We need to make sure that we get the best return.” There isn’t yet a demand for wireless access to hosted services like travel booking, and Hoffman says he is going to hold out as long as he can. But he anticipates that in two years Maritz will have close to a dozen applications that will be accessed wirelessly and notes that they will likely replace the one-off applications he has now. In the meantime, he hopes APIs and standards will mature.

Eventually a company running wireless applications will need an n-tiered architecture to support them. “If you are gong to play the [wireless] game you have got to have a good, reliable, scalable back-end infrastructure,” Hoffman says.

A CIO who fully understands the consequences of one-off wireless projects and sets realistic user expectations can certainly pursue those projects until an n-tiered implementation makes sense. But according to Hoffman, a CIO whose company becomes dependent on one-off wireless projects “risks making the same investment over again in just a couple of years.”