Wireless network not practical: In some cases, the installation of a wireless network to support mobile applications just simply isn't practical. Yes, even a guy like me who's a wireless advocate admits that wireless isn't always best. I ran upon this scenario when developing a delegate tracking system for the World Economic Forum, which convenes in the remote area of Davos, Switzerland, each year. The Forum is actually a collection of meetings that occur simultaneously throughout a couple dozen meeting halls and restaurants in Davos. Whenever a delegate such as Bill Gates and other familiar people enter a meeting, a clerk must scan a bar code on the delegate's name tag. This identifies the person, ensures that the delegate is registered for the meeting, and that the person has paid appropriate dues.   At first we thought of managing the data over wireless networks, mainly because of the extreme logistics of transporting all of the data collectors periodically to a central location, and manually synchronizing data with the server. The cost of installing the wireless infrastructure, nevertheless, was cost-prohibitive. At the time, there were no other existing wireless data systems in place. So, we had no choice but to go with a batch solution.

Security issues: Because no data is transmitted over the airwaves, batch solutions are inherently more secure than wireless counterparts. You can implement authentication and encryption for wireless networks, but completely avoiding the transmission of data over airwaves simplifies the needs for security controls. If policies or regulations prevent the use of wireless networks, then you're developing a batch solution whether you want to or not.

Limited battery power: Batch processing of data is much easier on user device batteries than on wireless batteries. Even with power management on the user device and radio card, you'll sometimes find it difficult to make battery life fit user needs. With one of my previous clients, I had implemented both a batch and wireless version of a mobile application. We found that the batch client devices would operate for up to three times longer than the same wireless units. This made a huge difference in the usability of the application from the user perspective. With batch, users can make it through an entire eight-hour period without recharging batteries. The need to swap and recharge batteries with the wireless solution would put a big dent in the productivity gains of the application.

Tight budgets: Batch systems are generally less expensive to initially deploy because there is very little network infrastructure. Only a serial or USB cable is necessary for synchronizing the data. There are no needs for access points, network cabling, and security components. If funding is limited, then batch may be your preferred alternative. However, be sure that you consider the total cost of ownership of a wireless solution as compared to batch. Gains in efficiency for a wireless network may offset the additional cost of a wireless network infrastructure.

 

Imperative real-time access: Consider the toleration of time delays when moving data back and forth between the user devices and the server. In some cases (such as web browsing), wireless may be an easy choice because users need the ability to continuously surf from site-to-site. Most control applications (such as sending guidance information to roving robots in a hospital) also require immediate updates sent over a wireless network. If the movement of data is needed in minutes and seconds, then wireless is the answer.

Cable breakage issues: In batch solutions, you're relying on the use of cables when synchronizing data. This may lead to higher support costs because of cable breakage. One of my clients (a major retailer) had spent more than a million dollars each year replacing data cables between hand-held data collectors and printers mounted on forklifts. After installing a wireless network and converting the batch application to wireless, this retailer was able to achieve a return on investment in less than one year with tremendous reductions in support costs. Now that's a compelling reason to go wireless!

High data volume: In scenarios where there's too much data to store on the user device, or the data changes too often, wireless makes sense. I've spent time in the past developing price-marking applications for retail stores. Given the size of the current memory cards for batch devices, there sometimes wasn't enough room to store descriptions of every possible type of product. As a result, wireless was a better solution because the application could retrieve pricing data from the server for a particular product only when needed.