Business
The challenges of mobile e-business
Howard Baldwin: Getting business applications designed to run on 17-inch screens into PDAs and smartphones is a massive challenge for e-business developers.
If handheld computers like the Palm and the iPaq are just smaller clients, then they should run the same applications your workers can access at their desktops, right? Wrong. The old aphorism "you can't get there from here" truly applies in the world of handheld applications.
"This kind of development is hard," acknowledges Dennis Gaughran, research director for enabling technologies at AMR Research. "It's why the adoption of mobile applications hasn't been as high as the hype was a year ago."
The biggest issue, in Gaughran's eyes, is the gap between a connected desktop application and a disconnected, or semi-connected, mobile application.
"You're going to have to create a new interface that will work without access to the primary source of information. That's one of the inherent challenges." Developers can get halfway to their destination. The database on the back-end and the application servers on the middle tier don't need much tweaking to accommodate both desktop and mobile users. But when they head across the network toward the handheld, developers always reach a chasm that needs to be bridged. They want to send data wirelessly over the chasm, but could end up heading over the chasm themselves like Wile E. Coyote.
On the other side of the chasm is the handheld, a powerful yet problematic device that offers developers four challenges: its interface, its disconnectedness, its seemingly infinite variety of hardware and operating systems options. With some careful planning and research, you can ease your development issues.
The Interface Challenge
There are as many ways to build applications for handhelds as there are handheld platforms. Major application-development vendors such as IBM, Sybase, Sun Microsystems, and Microsoft, have their strategies, as do smaller mobile-specific players such as Aligo, Air2Web, Everypath, and Extended Systems. Throw in the enterprise vendors who've created mobile versions of their applications -- Siebel Systems, Oracle, and SAP, among others -- and you've got some real interface challenges. The paradox is simple: you want external workers to be able to access the same information that internal workers can, but the interface that the road warriors have to work with is much smaller. "You can't take something built for a 17-inch monitor and repurpose it for a Pocket PC device," insists Gaughan. "Some companies use a transcoding engine, and you can do it easily from a development standpoint, but what you end up with doesn't look very good." Transcoding adapts Web content so it can be viewed on a smaller screen; however, there's no guarantee the result will retain the look that the designer intended. "What you'd like to do is reuse as much of your back-end and middle tier code as possible to minimise interaction," says David Shim, vice-president of marketing for Aligo. "Dealing with the front-end will always be a separate development effort. There is no easy way (to separate it out)." As with most deployments, it's likely that the business issues will determine the feasibility of a mobile application. Fundamentally, you want to deliver only the information that an external worker needs to do their job. Having a CRM application running on a salesman's handheld is great, but they still may need access to inventory information, which probably requires another application. "You may have to rethink the process of providing information. How can you make the worker more productive if they sell more, or do more service calls? You have to improve the process before the technology," adds Gaughan. The Connectin Challenge
Beyond the interface challenges, there are the connection challenges. Fundamentally, experts agree, you have to build an application that takes into account that the device won't always be connected. There's no guarantee that a sales rep will still be connected when they're going into the bowels of a warehouse. That's another strike against transcoding, according to Gaughan: "If you're going to build an application that's going to work outside of wireless coverage, transcoding doesn't buy you anything." To account for the idea of being "semi-connected," an application has to be able to store information in anticipation of ultimately being wirelessly connected or placed into a synchronisation cradle. As a result, you also need to ensure the device for which you're developing can accommodate the memory and storage requirements for this semi-connected state. "Footprint and performance are among the biggest challenges we face," says Jim White, a wireless and mobile development manager for Minneapolis-based consulting firm Fourth Generation. "As in the old days, you have to watch over bits and bytes in the application. Sometimes it means going back to the customer and saying, we can't get this gallon of water in this quart jar." The increasing use of Java, and the ability to connect to servers running Java 2 Enterprise Edition (J2EE), along with other standards, is one of the few bright spots in mobile development. "You need a forms-based application built with J2ME (Java 2 Micro Environment) to do local data storing," advises Angus McIntyre, product line manager for IBM's WebSphere Micro Environment. "You use JDBC (Java Database Connector) to call a local data store. Then we use JMS (Java Messaging Services), or our own message queuing, to update the application server." Adds Gaughan, "You're starting to see better support for standard tools, and that'll help the development community." The Obstacles Continue
Nevertheless, the challenges remain. Separating out presentation-layer development is also important because of the number of handheld choices in the marketplace (and that's not even considering the burgeoning arena of cellphones and hybrid devices, which are still in their infancy as data devices). "You have to think about future-proofing your technology," says Aligo's Shim, noting the multiplicity of browsers on Palm and other handhelds. "Are you going to redevelop your application every time a new device comes out, or do you develop the application once and redeploy it on multiple devices?" Though standards and consolidation will eventually ease development and deployment challenges, a new hurdle lurks over the horizon even now. That's the necessarily evil of system and asset management -- that is, tracking handhelds just as you do every other computer system so you know who has what hardware, what's running on that hardware, whether it needs to be upgraded, and how to upgrade it. Several developers of system management software, including Computer Associates, IBM's Tivoli division, and XcelleNet are already tackling the asset management issue, while the Open Services Gateway Initiative (OSGI) standard, supported by IBM and others, is designed to ease the hassle of software maintenance. Stay tuned, because it's clear these concerns will eventually find their way into the application developers' laps. To have your say online click on TalkBack and go to the ZDNet UK forums.
There are as many ways to build applications for handhelds as there are handheld platforms. Major application-development vendors such as IBM, Sybase, Sun Microsystems, and Microsoft, have their strategies, as do smaller mobile-specific players such as Aligo, Air2Web, Everypath, and Extended Systems. Throw in the enterprise vendors who've created mobile versions of their applications -- Siebel Systems, Oracle, and SAP, among others -- and you've got some real interface challenges. The paradox is simple: you want external workers to be able to access the same information that internal workers can, but the interface that the road warriors have to work with is much smaller. "You can't take something built for a 17-inch monitor and repurpose it for a Pocket PC device," insists Gaughan. "Some companies use a transcoding engine, and you can do it easily from a development standpoint, but what you end up with doesn't look very good." Transcoding adapts Web content so it can be viewed on a smaller screen; however, there's no guarantee the result will retain the look that the designer intended. "What you'd like to do is reuse as much of your back-end and middle tier code as possible to minimise interaction," says David Shim, vice-president of marketing for Aligo. "Dealing with the front-end will always be a separate development effort. There is no easy way (to separate it out)." As with most deployments, it's likely that the business issues will determine the feasibility of a mobile application. Fundamentally, you want to deliver only the information that an external worker needs to do their job. Having a CRM application running on a salesman's handheld is great, but they still may need access to inventory information, which probably requires another application. "You may have to rethink the process of providing information. How can you make the worker more productive if they sell more, or do more service calls? You have to improve the process before the technology," adds Gaughan. The Connectin Challenge
Beyond the interface challenges, there are the connection challenges. Fundamentally, experts agree, you have to build an application that takes into account that the device won't always be connected. There's no guarantee that a sales rep will still be connected when they're going into the bowels of a warehouse. That's another strike against transcoding, according to Gaughan: "If you're going to build an application that's going to work outside of wireless coverage, transcoding doesn't buy you anything." To account for the idea of being "semi-connected," an application has to be able to store information in anticipation of ultimately being wirelessly connected or placed into a synchronisation cradle. As a result, you also need to ensure the device for which you're developing can accommodate the memory and storage requirements for this semi-connected state. "Footprint and performance are among the biggest challenges we face," says Jim White, a wireless and mobile development manager for Minneapolis-based consulting firm Fourth Generation. "As in the old days, you have to watch over bits and bytes in the application. Sometimes it means going back to the customer and saying, we can't get this gallon of water in this quart jar." The increasing use of Java, and the ability to connect to servers running Java 2 Enterprise Edition (J2EE), along with other standards, is one of the few bright spots in mobile development. "You need a forms-based application built with J2ME (Java 2 Micro Environment) to do local data storing," advises Angus McIntyre, product line manager for IBM's WebSphere Micro Environment. "You use JDBC (Java Database Connector) to call a local data store. Then we use JMS (Java Messaging Services), or our own message queuing, to update the application server." Adds Gaughan, "You're starting to see better support for standard tools, and that'll help the development community." The Obstacles Continue
Nevertheless, the challenges remain. Separating out presentation-layer development is also important because of the number of handheld choices in the marketplace (and that's not even considering the burgeoning arena of cellphones and hybrid devices, which are still in their infancy as data devices). "You have to think about future-proofing your technology," says Aligo's Shim, noting the multiplicity of browsers on Palm and other handhelds. "Are you going to redevelop your application every time a new device comes out, or do you develop the application once and redeploy it on multiple devices?" Though standards and consolidation will eventually ease development and deployment challenges, a new hurdle lurks over the horizon even now. That's the necessarily evil of system and asset management -- that is, tracking handhelds just as you do every other computer system so you know who has what hardware, what's running on that hardware, whether it needs to be upgraded, and how to upgrade it. Several developers of system management software, including Computer Associates, IBM's Tivoli division, and XcelleNet are already tackling the asset management issue, while the Open Services Gateway Initiative (OSGI) standard, supported by IBM and others, is designed to ease the hassle of software maintenance. Stay tuned, because it's clear these concerns will eventually find their way into the application developers' laps. To have your say online click on TalkBack and go to the ZDNet UK forums.