July 2, 2007 (Computerworld) Enough about the iPhone. For a product that's barely launched, the sheer volume of commentary on the interface, the shape, the merits of touch-screen dialing, its voice and data-network compatibility, and virtually every other aspect shows that Steve Jobs really is operating in the proud tradition of P.T. Barnum: It doesn't matter what you say about the iPhone, as long as you spell the name right. Good on 'im.
What's bothersome is the nonsense put out by analysts declaring -- sans experiential data -- that the iPhone is unsuitable for business use, essentially because it does not look like what came before it. That kind of talk is good for getting your name in the newspapers, but there are two problems. The first is that IT analysis and pundits seem to have forgotten that suitability is closely related to the notion of technical standards, and that standards are not products. The second is that some technical aspects of any device are unknown without practical use; they can't be judged by the specifications alone.
Out on a limb
Since AT&T Inc. confirmed that it will market the iPhone to business users, analysts have been speculating about how potential buyers will probably use an almost-untried device once theoretical IT crews integrate them into tomorrow's infrastructure. That's a critically high percentage of speculation. Some things just can't be determined before a system is in production or a device is in hand. It's one thing to express concern that a popular new device may require some adjustments. It's really another to scream about the sky falling.
And everyone's piling on. Gartner Inc.'s Ken Dulaney makes three claims in that company's report: "You'll have e-mail in a place that's unsecured. There are no firewalls on the device. There's no ability to wipe [information from] the device if it's lost."
Let's take those claims apart, just for practice. The first statement is probably false if one uses secured Internet Message Access Protocol (IMAP), which they should be doing anyway (more below). The second is almost a nonsequitur for Unix users familiar with turning off unnecessary services. And the last is an unresolved issue of management software in the enterprise, not a basis upon which to criticize a soon-to-be-managed endpoint device.
At least that sort of speculation is reality-based and fairly specific. The broader the statements I saw at and immediately before launch, the more unreal they were. For instance, Tony Rizzo, director of mobile technology at The 451 Group, is quoted as making the nonsensical statement that "it doesn't have any features that would make it successful as a business tool." Barring Rizzo's prescient knowledge of application development -- and contrary to many things already known about business documents and communication -- that comment is out of line in regard to any general-purpose configurable or modifiable computing device, and brings into question the logic and foundation of his firm's other analyses.
It's particularly irritating to see unfounded criticism of any new device or service because of perceived incompatibility with Microsoft Exchange or Lotus Notes. Exchange is the most popular corporate e-mail system, while Notes still has a lock on the very largest companies. Both dominate the scene with fat-client implementations for e-mail and calendaring data. However, the protocols they use are outmoded one-off, vendor-specific legacy technologies, in no way suitable as a metric for whether a new device or service is suitable for the future of an organization.
I've grown used to enterprises saddling themselves with proprietary protocols just because everyone else is using them, locking themselves into client applications as a result. Imagine my pleasant surprise earlier this year when I joined a project with some of the very best security professionals from lives past. Without a second thought, they had set up a mail access using IMAP over Secure Sockets Layer. They didn't have to specify client platforms, software or modes of use -- as long as we chose standards-based tools, our business communications just worked.
Why, they reasoned, would anyone suffer through the vagaries of remote procedure calls over HTTP, for example, just to enable basic communication? And if one needs connectivity to synchronize with an organizational calendar, why use both a proprietary protocol and a fat client instead of open standards and a small cache?
Protocols, not applications
The obstinate will claim that Exchange is a "standard." Not so. Exchange and Notes are common and pervasive, but these don't qualify as "standard" in a technical sense. A good definition includes the notion that standards are a "universally agreed-upon set of guidelines for interoperability."
Those who use their Windows Mobile phones to access Exchange over IMAP will have little trouble with the iPhone, while those who click through the ActiveSync setup wizard in Exchange will think it's incompatible. No, they just chose incompatibility. The funny thing is that we're still free to use Exchange, Outlook, Notes and the like, but the perceived interoperability problems are already solved if we just care to look for a standard protocol.
This precludes the notion of any particular program as a standard. It's the same concept that makes security administrators wince when access rights are requested for a new hire based on another person rather than a (standard) role. Only a protocol for interactive operation or format for data readability -- a layer of abstraction -- allows the required flexibility without making a mess.
We choose standards because products and platforms change -- and if nothing else, for purely monetary reasons, it's handy to be able to switch technology vendors. An oft-ignored but common situation in many organizations is a change in business and functional requirements without a concomitant upheaval in the security level requirements. For example, a medical products company may choose to become a service company, radically changing its communication-use cases without any decrease in the sensitivity of data handled by the technology. If such an organization's communications infrastructure were tied directly to business function, the company would likely face a major reconfiguration or rip-and-replace event. An organization communicating with open standards such as IMAP and iCal, on the other hand, might only need to reconfigure clients or obtain new endpoint software.
Experience trumps specifications
Much as I rail on about poor decision-making in which opinion is mistaken for requirements, metrics and objectivity, there's always a place for plain old empiricism. Ironically, when the carrier for the iPhone moved corporate offices some years ago, I watched as its new data centers were built and moved into production. There were facilities on the ground floor of each of three adjacent buildings, with large cable conduits between them. As the building completion date approached, the data center construction staff ran the allotted number of copper and fiber cables through the conduits, capped the ends in each building's basement, and filled the conduits with gluey, water-resistant foam.
Needless to say, this didn't seem like such a good idea a few months later as the backhoes rolled over the just-bloomed delphiniums and dug up five figures' worth of now-useless conduits. Anyone who has worked through a data center move or two knows that a new facility isn't mature until you've installed systems and cabling, then ripped them out and reinstalled them -- a couple of times. Only then are capacities stabilized, the techs sure of the right lengths of cable, systems relocated to account for cooling idiosyncrasies, new people drafted to reboot test systems because they're a floor closer to the facility, and so on.
Technology must adapt or die, just as people adapt until they can't. Computer input is a good example of that. DVORAK keyboards never caught on, no matter what key shape or feel; voice recognition is marginalized for text input because most people neither think in complete sentences nor work away from the voices of others. Yet Palm taught us the Esperanto of penmanship with Graffiti, and T9 became the spouse finishing our words. We worried that smart-phone keys would be too tiny, too weird, or that new interfaces would be too flat, but in each case, a little refinement of the implementation worked well as long as the underlying convention -- QWERTY or alphabetic sequences in this case -- wasn't tossed aside. Stray too far from what people expect, and a technology falls off the event horizon. On the other hand, if Apple decides integrate 3G and an iPhone screen for a touch pad in the next batch of iBooks, friends may yet find me filthy and disheveled, camped out for days in line at an Apple store.
Always prepared vs. always stunned
How will corporate denizens make use of the iPhone's adaptation of technology? Will they find it easier to use Sidekick-style, always-loaded remote applications and minimal synchronization so that the impact of loss is minimal? Or will they load it full of documents and offline applications like many Windows Mobile users? Honestly, we just don't know yet. We'll just have to see how the profile of user activity shakes out. In all likelihood, it'll be something we don't expect, not because Jobs has finally coded the reality distortion field into a killer app, but because the next big thing hasn't happened yet. Next is always in the future.
I'm not saying there aren't legitimate queries, stemming from experience, about where the iPhone fits into the corporate picture. One big unanswered question comes from BlackBerry and Sidekick phones' means to limit information loss in the event a device goes missing. Will iSync-based iPhone management tools allow me to iSuck the data back from my device and disable it? Will the next point release of OS X for the iPhone include FileVault data encryption? We won't know what direction Apple will take until there are a few data points from which to draw a vector. You can argue that this sort of thing could have, maybe should have, been addressed already. That's another example of a nice theory falling down in the real world.
If we've prepared ourselves reasonably well, we can be confident that whatever comes along will integrate just fine as long as it covers the standards we're using now -- the actual standards, not the forces of habit or idiosyncrasies of the moment. Kindergarteners may make up their own language and then criticize others for not knowing it, but like the flow of linguistic change, you can always accept new technology without disruption if your syntax is predictable. I may not know what will be said next, but I can be confident that I'll understand it.
Jon Espenschied has been at play in the security industry for enough years to become enthusiastic, blasé, cynical, jaded, content and enthusiastic again. He recently left Symantec Corp. (@stake) to be a principal at Leviathan Security Group Inc. in Seattle, where his advice continues to be ignored by CEOs, auditors and sysadmins alike.