Whither the Enterprise Rugged Device? (Part 2)

In Part 1, I discussed the pros and cons of enterprise rugged devices.

Here in Part 2, I will compare and contrast the enterprise rugged devices with the leading consumer devices available today.  I’ll focus on the potential of consumer devices for use in industrial scanning applications like TrackAbout.

Consumer Devices for Industrial Scanning Applications

Let’s briefly touch on why we might be interested in leveraging consumer devices, specifically modern smart phones and tablets.

  • They’re powerful, cheap, and ubiquitous.
  • They have full-featured web browsers that are every bit as capable as desktop browsers. In fact, the devices today have processing power that rivals desktop computers of just a couple years ago.
  • They have cameras, GPS, and are laden with all kinds of sensors (gyroscopes, altimeters, barometers, compasses)
  • The software development tools are great and getting better all the time.
  • There’s a high degree of developer interest in building apps for these platforms.
  • There’s a huge application ecosystem, and third party applications like Google Maps can be leveraged to enhance the value delivered to the enterprise

And the biggee:

  • Customers expect vendors to take advantage of and deliver solutions on these platforms.

The Device Lifecycle and Inherent Costs

Several new devices (phones and tablets) launch each and every month. In less than two years, “old” devices become generally unavailable except in gray markets (think eBay). It frequently happens that devices are released with major bugs that take weeks or months to iron out, if at all.

Rapid turnover, mediocre quality control and shrinking availability over time are not terribly attractive qualities for driving enterprise adoption. Recycling your device fleet every two years is expensive. In addition to replacing the devices, there’s the re-buying of extended batteries, screen protectors, rugged cases and other accessories. A greater expense is retesting and recertifying that all aspects of the required software work as expected across all your users’ varied devices. There may be retraining and updating of manuals, processes and procedures. In some cases, recertification by a government agency for regulatory reasons might be required, at enormous expense.

On the flip side, the base hardware (just talking about the device itself, here) is considerably cheaper than enterprise rugged hardware. Workers are generally already carrying phones, why not make them smart phones? When purchased from a cell carrier with a 2-year contract, the carrier significantly subsidizes the actual cost of the device; it might even be free! Consumer devices are being manufactured in much higher quantities than rugged enterprise hardware, so there’s considerably more stock available. For about $7/month per device, the carrier will even insure the device against most damage.

Speaking of insurance and damage, accidents happen.  If a broken smartphone means you can’t SMS that lolcat to your BFF (no can haz!), hey, no great loss.  But, if a broken smartphone means at 10 AM your driver can’t deliver product to your customers for the rest of the day, that’s a much bigger deal.  With cheaper hardware, you might be less concerned about providing a backup device to your critical users.

What Does “Platform” Mean?

The device’s platform comprises the operating system, the development tools, the ecosystem supporting the devices, and the policies and restrictions levied by the creators of the platform and maintainers of the ecosystem. We’ll see how that last part can bite you in a little bit.

Every platform requires a different set of developer tools and skills.  There are few mature options that let you write an application once to run on iOS, Android, Blackberry and other platforms.  Few companies have unlimited resources to invest in rewriting the same app over and over again for multiple platforms.  Therefore, we have to make difficult and informed choices.  We have to try to pick winners.

An enterprise wants to hang its hat on:

  1. a proven, stable platform that
  2. is open, extensible, and easy to develop for,
  3. is well supported by both the manufacturer and the community,
  4. has a long predicted life,
  5. and has strong developer interest in order to
  6. maximize its investment in technology, development effort and software developers.

Google’s Android

Android Logo

The word “fragmentation” is frequently uttered when discussing the current state of the Android ecosystem. Phone and tablet manufacturers are free to customize, innovate and compete on top of the Android platform. This has been generally great for consumers, but less so for developers.

A minor annoyance, the manufacturers whimsically re-arrange the order of the four main Android buttons from one model to the next.

The devices come with different screen sizes, aspect ratios and resolutions, making it very difficult for a developer to achieve a consistent user interface for their application that works well across all devices. This makes developing software that “just works” on any Android device a complicated and more expensive endeavor than it really ought to be.

Each device manufacturer attempts to add their own “secret sauce” to the device by customizing or “skinning” the user interface of the device. This introduces variation and complexity that users must contend with (see HTC Sense UI, Motorola Motoblur, Samsung TouchWiz).

The secret sauce impedes the manufacturer’s and the carrier’s ability to push out updates as fast as Google can deliver them.  This frustrates consumers who would like to be running the latest/greatest version of the Android operating system but are instead left waiting months for updates, or receiving none at all. But in the enterprise space, we like consistency, so fast and furious updates aren’t usually in our favor (unless they fix something we need fixed, right?).

Google recognizes the fragmentation issue. In March 2011, news broke that Google had started cracking down on manufacturer customizations. While this will frustrate manufacturers by limiting their ability to differentiate their products, it should lead to a more predictable platform as a whole for software developers.

Overall, and fragmentation notwithstanding, Android provides a very attractive enterprise platform. The Android operating system is open source and has grown stable and extremely capable over time. The software development toolset is excellent and is always getting better. You can do just about anything you want on the platform. Frankly, I’m amazed we haven’t seen a single large vendor making enterprise rugged devices using Android as a base. Hint hint, vendors.

Apple’s iOS

Apple LogoYou can’t talk about mobile without talking about Apple. From an enterprise software developer’s perspective, the most important thing to talk about is that Apple maintains incredibly tight control over the ecosystem. The primary (but not only) method of distributing apps is Apple’s own App Store. Apple is infamous for removing some apps from the App Store, seemingly on a whim, and without advance notice to the publisher. Imagine investing substantial time and money to develop a killer app only to have your launch delayed arbitrarily, or to have your burgeoning business stalled because Apple pulled your app.

In April 2010, Apple modified their developer license agreement in order to forbid developers to use the tools of their choice in the development of applications. From their agreement at that time:

3.3.1 – Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This move was widely believed to be a spiteful attempt to hurt Adobe, who had created a tool that let developers use Adobe’s Flash to write iOS apps. Many other tool vendors were caught in the crossfire of the ongoing Apple/Adobe feud, raising the ire of the developer community. Apple has since gone back on the policy but certainly could change their stance again.

Actions like these have made it abundantly clear that iOS is a closed platform, and you can and will be shut out if you fail to measure up to Apple’s standards. The uncertainty and lack of control when developing for the iOS platform is a bit chilling.

Yet obviously, tens of thousands of eager developers are not dissuaded by Apple’s behavior. There persists a gold-rush mentality around apps today, and according to recent data, for iOS apps considerably more so than for Android apps.

It must also be mentioned that Apple has a fairly comprehensive enterprise offering. Using their mobile device management tools, it’s possible to deploy software to iOS devices without using the App Store, thus mitigating some of the fear and risk inherent in Apple’s iron grip on that channel. Coupled with the fact that Apple generally only produces one new major device per category per year, and you do have a relatively stable and remarkably powerful platform for innovation.

We’ve seen some game-changing businesses and technologies emerge on the iOS platform such as the ingenious Square payment system and Apple’s own Apple Store Point-of-Sale (POS) system built using Infinite Peripherals’ Linea-Pro device.  The latter, a barcode and mag-stripe reader plus battery booster, looks great for our needs.  It must be noted however that, the device was built to operate in an indoor, temperature-controlled POS environment, and, according to its specs, does not appear designed to survive the rigors of the great outdoors.

Regardless of the impressive capabilities of the iOS platform, I regard it somewhat warily for enterprise applications as it remains a tightly controlled, closed platform. Apple has a vision for its products, the vision is generally consumer-facing, and if your vision does not coincide with Apple’s, you must be willing to negotiate the risks.

The Rest

Platforms that owned the market just a couple of years ago are now struggling to survive or are disappearing altogether. New platforms are finding it incredibly difficult to beat iOS and Android.

  • The once-mighty PalmOS which ran our beloved Palm Pilots, Handsprings and Treos is long since dead.  HP acquired Palm 16 months ago.
  • Last week, HP sounded the death knell of Palm and its last-ditch effort webOS platform, shelving all plans to bring phones and tablets to market.
  • RIM, maker of Blackberry and once king of the enterprise hill, finds itself struggling to maintain relevance as its market is eroded month after month by iOS and Android.
  • Two months ago, Nokia abandoned Symbian and went all-in, signing a deal with Microsoft to build Windows Phone 7 phones.
  • Microsoft is struggling to gain market share with Windows Phone 7, even though by all accounts it’s a great platform.

The consumer device space is extremely fluid and subject to rapid change, making it very challenging to pick winners and losers for enterprise application investment.  The current kings of the hill, iOS and Android, didn’t even exist just four years ago.

Hardware Considerations

Let’s assume we can get onboard with either Android or iOS, as they seem to be the dominant platforms today. What else do we need to think about? Let’s go back through the same points I used to discuss the enterprise rugged devices in Part 1:

Support: Apple is renowned for their customer support and satisfaction. Manufacturers of Android devices, not so much.  Neither is willing to offer the kind of long support horizon that the enterprise manufacturers do (3-5 years minimum).

And what if there is a fatal flaw in the device that is preventing you from successfully delivering your application?  What recourse do you have to get something like that fixed?  Practically none.  You can try complaining in the manufacturer’s community forum or support system, but you have no leverage and no guarantees that your issue will be addressed in a timely manner.  You are just a voice in the crowd.

Rugged: Can consumer devices be made more physically rugged? Most definitely, yes. Check out some of the cases made by Otterbox.

But will a case allow a consumer device to withstand the extremes of temperature that an enterprise rugged device can withstand? This depends only on the device, and not at all on the case. Regardless of the case, given enough time, all devices will eventually reach ambient temperature. On the cold side, occasionally screens can crack. On the hot side, devices will freeze, shutdown or crash, especially when charging. Put a case around a device, and you’ve made it even less capable of dissipating heat. Choose wisely and check the specs.

Physical Keyboard: Some consumer devices have them, most do not. Probably no iOS device will ever have a physical keyboard. A physical keyboard means the introduction of moving parts. Moving parts of any kind result in a higher MTBF (mean time between failure), and a more costly device to own over time.

Screen Technology: As mentioned earlier, most consumer devices today sport capacitive screens, increasing touch sensitivity and accuracy but negating the ability of the user to wear gloves. Humorously, it was reported in February 2010 that in Korea, sales of snack sausages increased by almost 40% during the winter, as people would use the sausages as a stylus to navigate their capacitive touchscreen devices. It should also be noted that styli (pens) exist that can be used with capacitive screens in lieu of rodent-attracting meat-flesh.

Signature capture is trickier with capacitive screens.  Most users expect to use a pen or stylus to sign, not a finger.

Screen quality and brightness is all over the map in consumer devices. Some screens can’t be read in direct sunlight, which is a major problem.

Screen toughness is another consideration. Some devices are being marketed as having screens made with Corning’s “Gorilla Glass”, which means they’re tougher than other kinds of screen glass or plastic.

High Capacity, User-Replaceable Batteries: High capacity, user-replaceable internal batteries are available for most consumer devices, unless the word “Apple” appears somewhere on the case. No current Apple iOS device has a field-replaceable internal battery, although snap-on battery extenders do exist.  Snap-on extenders do not exist for most Android devices probably because of the wide variation in Android device shapes.

Android devices tend to be power hungry, more so than iOS devices.  Since iOS devices are engineered purposefully to not allow the user to access the battery, Apple was able to squeeze in a larger battery than otherwise would be possible.  Many Android devices cannot last a day under moderate to frequent usage, making a higher capacity battery a good idea.  If you do buy a high capacity battery for your Android device, you’ll likely need an extended battery cover. However, once clad with the extended cover, you will not be able to find a good rugged case to fit your newly-embiggened device.  Catch-22.

Finally, replacing the battery of a consumer device is a chore, especially if you have a case. You must properly shut the device down; pry off the case and battery cover; replace the battery; and restart the device, which can take several minutes to boot. Contrast this with the typical enterprise rugged device whose battery can be hot-swapped in mere seconds. Time is money for the worker in the field.

Some consumer devices can have their battery swapped if they’re plugged into a charger at the time the battery is removed. My HTC EVO 3D, sadly, cannot.

Manageability: Here we have a practical dead heat. Most of the device management suites and tools have grown to support iOS, Android, Blackberry and Windows Phone 7 devices quite well, as these devices are commonly deployed in the enterprise for use as phones, email, calendar, etc.

Removable Storage: This is something I didn’t mention in the previous post. In TrackAbout’s existing enterprise rugged software, we backup all the application data regularly to an SD card.  Many of the devices we support do not have always-on data connections, and so they operate in batch mode, storing data to be synced later.  Should a device in the field become damaged, the card can be pulled and the data salvaged. If a consumer device does not provide removable storage, we lose this very important safety feature.  Apple’s current iOS devices do not support removable storage.

Scanners/Readers: Several of the consumer device platforms now support scanning barcodes with the camera, usually with the addition of a third party app.  If you’ve ever tried to use this in practice, you know that it’s pretty slow and clunky.  It’s fine for an occasional scan, but not for high volume.

Furthermore, consumer devices do not have a dedicated hardware scan button in a convenient location (let alone multiple locations) like enterprise rugged devices do. Rather, it’s necessary to clutch the device awkwardly in one hand as if applying a Vulcan nerve pinch whilst simultaneously fumbling for the on-screen scan button.

Compared to enterprise rugged scanners, there is no contest.  You simply cannot scan with the same speed and precision using a camera as you can with a purpose-built, integrated scanner.

This leads us to a very important discussion regarding how we can effectively get scans into these devices. TrackAbout’s software is all about scanning, and any scanning tech we bring to the table needs to be rock solid and bullet-proof. I’ve already dismissed the device camera as a viable method of scanning. The next best mechanism for scanning is a Bluetooth (BT) scanner.

Here’s where our journey into consumer tech takes a mighty nose dive:

  • BT scanners must be paired to a device. Pairing is cumbersome, confusing and error prone. This is a big hurdle for our users. There’s some promise that the introduction of Near Field Communication (NFC) technology could make pairing as simple as bumping two devices together. But that’s years off and may never come to scanning devices.
  • BT scanners can start cheap ($300) and become very expensive ($1000+). The cheap ones are not rugged. The expensive ones can significantly eat into your ROI for going with consumer tech. Many are not rated for extreme temperatures.
  • A BT scanner is yet another device and charger to carry, battery to monitor and charge, and one more thing that can break in the field.
  • If you want to scan both RFID tags and barcodes, you’re going to have to take up juggling.
  • Provided the scanner and device both support it, there are options for connecting a scanner to a device with a USB cable. This eliminates the Bluetooth headache, in exchange for a cable management headache and increased risk of accidental (or intentional) strangulation.


There’s a lot to like about modern consumer devices, but they are insufficient to fully replace the enterprise rugged device for industrial scanning applications like TrackAbout.  To make use of the technology, we’d have to define a subset of features that could deliver enough business value to warrant the investment in development.  In my next post, we’ll explore what that subset might be.

Larry Silverman
Chief Technology Officer
TrackAbout, Inc.