Many leading PDA vendors share a common ambition: to sell more PDAs to enterprises. Yet they often complain about the difficulty of doing so, and wonder what more they need to do to make their devices as pervasive in enterprises as PCs have become.

Based on the complaints I've been hearing lately from enterprise users of PDAs, one thing that they need from their vendors is as much a change in attitude as a change in technology. Today's devices are unnecessarily difficult to acquire, configure, deploy, and maintain in the field. To address these issues, vendors need to stop thinking in terms of PDAs--personal digital assistants or, at best, professional digital assistants--and start offering Enterprise Digital Assistants.

So how would an EDA differ from today's PDA? In a lot of ways it would be similar: From the outside you probably wouldn't be able to tell them apart, any more than you can tell a PC loaded with Windows XP Pro from one loaded with the Home Edition until you turn them on. The differences in the operating system would be probably be as subtle as the differences between a desktop operating system designed for the enterprise versus one designed for the home, maybe even invisible to the application user. But an EDA would be designed for life in the enterprise, from the way it's acquired through the way it's deployed and used right through to the way it's disposed of at the end of its useful life.

As an EDA user, you would notice changes as soon as you turn on the device. For one thing, it would demand that you identify yourself, at the very least with a password, perhaps with a biometric mechanism such as a fingerprint reader, or more exotically with technologies that can validate the rhythm of your typing or stylus use. Secured access wouldn't be optional on devices that are as readily lost or stolen as PDAs, yet can contain large amounts of sensitive corporate data or, worse, the ability to connect with corporate systems. It might be acceptable for a PDA to offer the option of password security, but an EDA simply wouldn't permit the user to vary the security settings from those IT mandated.

Security wouldn't stop at the front door, either. Data on the device would itself be encrypted, and connectivity back to enterprise systems would always be secure, for example, with VPN clients and encrypted data payloads when synchronizing.

The inquisitive user also would quickly find other differences. Certain parts of the configuration would be locked down, not subject to user change, such as the IP address of the corporate VPN for secure WAN connections, or the frequency with which virus scans are run. Other parameters would be invisible to unprivileged eyes, such as the device's MAC address or the corporate wireless LAN encryption key. The user might be able to install additional applications if system-management policies allow it, but those applications might be limited in their capabilities (for example, no network access on the company's dime). But in any case, users certainly wouldn't be able to accidentally erase essential applications or system components at the drop of a stylus. Furthermore, all of this ability to control what happens to a device once it leaves the hands of IT would be an intrinsic design element of the EDA operating system, not a patchwork of third-party add-ons.

You'd also see dramatic differences in the way PDA vendors manage the life cycle of their products. It might be OK for personal buyers if all new PDAs ship with version X of the software one day, and ship with version X+1 the next; or if a specific model is discontinued after six months, leaving buyers to hunt down whatever inventory is left in the supply channel. That just doesn't work for enterprises that have critical applications deployed in the field. If an application and middleware stack has been certified on a particular operating system release, it's a significant expense and complication to have to re-certify on the new one. Then they have to run both systems in parallel as long as the old devices--which all too often cannot be upgraded, even if recalling them were feasible and economical--remain in the field. That's even assuming that the application can be immediately deployed to new devices: it's not uncommon to see critical pieces of middleware take weeks or even months to become available after a major PDA operating system upgrade ships.

Meanwhile, field breakages continue and the supply of spares depletes, because the old device and operating system is no longer available. Model churn is getting so bad that some enterprises despair of being able to maintain an up-to-date list of approved devices. Nor is it an adequate substitute for a PDA vendor to offer to back-install the old operating system on new hardware (for an additional fee, of course, as though sustaining the continued availability of a deployed enterprise-computing platform were a special favor and a burden for the vendor).

Operating system releases for EDAs would have overlapping availability as a matter of course, not as a special service, and older EDAs would be available for a reasonable period--at the very least until enterprises have had an opportunity to assess their needs and stock their inventory of spares to satisfy the expected application lifetime. PDA vendors need to respect the deployment life cycle of the EDA the same way they do for PCs and servers.

The EDA is one example of a different approach to computing devices: it lies somewhere between the install and configure anarchy of a personal device and the burned-in-ROM rigidity of an embedded device. It retains the flexibility of a PDA for the IT department to easily provision applications, updates, and configuration changes, yet once it's in the hands of a user it's as reliable and unbreakable as an embedded system. It combines the best of a general-purpose tool and single-purpose appliance (PDAs aren't the only computing systems that could benefit from this philosophy!).

Many of these requirements are achievable today, mostly by adding a complex stack of third-party software to an off-the-shelf PDA, or by paying the costs of a more customized operating system. Some simply require vendors to take a more enterprise-friendly approach to the life cycle. For an off-the-shelf device to deserve the name EDA, these features should be a matter of course, not an aftermarket afterthought. None of this is impossible, once you embrace the importance of the Enterprise Digital Assistant.

Carl Zetie is an analyst with Forrester Research.

To discuss this column with other readers, please visit the Talk Shop.