Barreling Toward the Consumerization of IT

I've been doing what I do for a long time, by which I mean writing about technology. But the one thing that always amazes me, in a good way, is the feedback I get from readers. I do get a regular stream of feedback via email, good and bad, both of which are generally instructive and helpful. But the humbling bit comes when I explicitly ask, even in a relatively off-handed manner, for feedback. I did so last week, and the results were overwhelming. Thank you for that.

If you missed it, the question I asked was about the so-called consumerization of IT, a trend where IT organizations, increasingly, are giving in to the demands of their users and allowing them to bring their own iPhones and other personal devices into work. Generally speaking, there is a range of restrictions that businesses can place on such devices, from total to none. But while the general trend is toward less restrictive, I was curious to see where things stood in your own businesses.

Not surprisingly, it's all over the map with a nice centrist majority. Some small minority of businesses wield total control over devices, and don't allow any non-sanctioned technology behind the kimono. Some, mostly very new and very small businesses, have no policies along these lines whatsoever. But most establish some middle ground with a baseline of requirements. And it is the formalization of certain policies that has, I think, really enabled the consumerization of IT to really take off.

I won't name names, of course, either of the respondents or the companies they represent. But the insights into how their companies handle this issue are, I think, enlightening. And they come from all walks of life: The government, big business, education, health care, and more.

Here's what I was told.

First, stepping back a bit, it was RIM's Blackberry that blazed the way for mobile device acceptance in IT, and because RIM supported secure policies early on, it gained a stronghold in a market that, frankly, should have been Microsoft's for the taking. (I've always considered RIM's now largely redundant Enterprise Server to be the greatest scam in server history, a buggy and hard to manage middleman between Exchange and your devices. But there's something to be said for success, and certainly BES has been hugely successful.)

Blackberry is still a big deal, sort of, but one gets the notion that its time is passing, thanks largely to the iPhone and, later, a legion of Android phones. There are a few exceptions: the federal government, where devices are almost always locked-down Blackberries, and some of the bigger, more protective enterprises for which there's only Blackberry.

Elsewhere, iPhone and Android rule. But just being nicer looking and friendlier wasn't enough, though even the first circa-2007 iPhone garnered enough excitement that CEOs and other executives immediately began pestering for access. Over time, Apple realized that the key to mass market appeal with smartphones, as with the PCs that preceded them, would need to include businesses. So they began adding support for the important corporate policies that form the baseline today.

These policies include:

Basic Exchange ActiveSync (EAS) support or, for those environments that bleed black, BlackBerry Sync support. This functionality enables the remaining policies discussed below, but at its heart, EAS is simply about server-to-device sync, in this case for Exchange Server information: email, contacts, calendar, and for those clients that support it, tasks. It works over the air with push, supports offline usage, and has gotten steadily more capable over the years.

Remote wipe. While lost and stolen laptops are an under-reported story for obvious reasons, few will have a hard time imagining how easy it is to lose something as small and valuable as a smartphone. And when that phone contains sensitive corporate data, such as email, you're going to want a way to ensure that thieves or anyone else who comes across the device don't luck out any further. And one of the various ways you can ensure this is via remote wipe, where you can remotely erase all of the relevant data from the phone from a central location.

Auto-lock and passcode policies. In the same vein, you also want to ensure that your users are adhering to various passcode policies--minimum passcode length, complexity requirements, and so on—and then have the phone auto-lock after a set, configurable time period when it's idle.

Encryption. You can require that device storage is encrypted so that it can't be read by plugging it into a PC. This can include on-device storage as well as any storage card.

Those are the basics, and virtually all of the respondents who allow their users to utilize consumer-oriented smartphones at work that adhere to these basic rules. And not coincidentally, all of today's major smartphone platforms support these and other EAS capabilities. (The one exception, currently, is Windows Phone 7, which does not have any encryption policy support.)

Many take these policies a bit further. Some companies do not allow the devices to join internal corporate network via Wi-Fi, for example, and require public Wi-Fi network access only. (Governmental devices are often stripped of Wi-Fi access all together, based on a few respondents' reports.)

Given the recent evolution of the smartphone market, with Android now outpacing iPhone, RIM sliding somewhat, and one analyst even predicting huge Windows Phone successes down the road, I was curious to learn how these changes are impacting businesses. And sure enough, I heard a lot about the mix of devices that are now making their way out into the world courtesy of corporate overlords. But I'm out of space. Next time, we'll take a look at these devices, and discuss how they stack up with regards to EAS feature support.

Related Reading:

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.