I generally like his writing and his viewpoints, but I can’t help but wonder whether John Gruber’s missive against the enterprise’s wariness about iPhones is based more in his overt Apple lurve or in a lack of understanding of the things an enterprise has to manage on the wireless front. Far from his laser-like focus on email, when a large business thinks about services that need to be extended seamlessly to wireless devices, useful email access shares equal space with the ability to use a global address book, the need to access services on an intranet, ties into enterprise calendaring services, centrally-managed security policies, encryption (both of the contents of the device and communications between the device and other services), and the ability for the enterprise to control access on a device-by-device basis. And again, despite Gruber pointing out that some of the email issues can be solved using IMAP, there are few or no ways to solve the other issues, especially not in as unified a way as BlackBerry has done with the BlackBerry Enterprise Server (BES).

Let’s look at a few example issues, and think of how the iPhone would compare to what BlackBerry has in place.

1. A wireless user needs to be able to send an email to a few enterprise users, none of which are in his contact list. How does that user do this?

BlackBerry: in the email app, the user creates a new email, and in the “To:” line, types in the name of the recipient and chooses the “Lookup” option. The BlackBerry queries the global address list, returns a list of matches, and the user chooses the correct one, which is then added to the recipient list.

iPhone: according to articles like this, the iPhone doesn’t understand global address lists to the point where a developer had to write a raw LDAP client for the device (which we have to assume is a web-based app, given that there’s no native API for the iPhone). So the user has to open Safari, navigate to the web page which provides an LDAP lookup of the global address list, look up the user, and either click a mailto: link to start a new email to the user or cut-and-paste the address into the email client. (And while mailto: certainly is easier, it won’t work for multiple addressees without a really slick web app that allows multiple lookups to all be appended to a single link which will then launch the email app and start a new message. And none of this takes into account the fact that a company will have to write the LDAP lookup app in the first place.)

2. A wireless user needs access to an online database that only exists on a company’s intranet. How does the user get to it?

BlackBerry: given that the BES provides web connectivity that can be routed through the intranet, the user only has to open the BlackBerry Browser application and enter the URL, and will be taken to the web page hosting the database.

iPhone: there’s no similar way for iPhone users to route their web requests through an intranet server; iPhones get their connectivity to the internet through Cingular, and as such, are outside the enterprise firewall, meaning that they can’t get to intranet-only web applications. There’s no info on whether Safari on the iPhone will support the use of web proxies, but even then, use of the proxy will have to be open to the entire Cingular network, opening up a whole other host of security questions and problems. So to achieve this challenge, a company has to either (a) choose to host the web app on a server accessible to the internet at large and implement web-based authentication, (b) implement a public-facing webserver which has authentication and proxies requests for the application to the intranet server, or (c) set up an HTTP proxy server facing the internet and figure out how to secure it such that only authorized iPhone users can get access.

3. A company mandates that all wireless devices need to encrypt all information they store in memory, need to auto-lock after 15 minutes, and need to auto-erase the contents of the device after a given number of incorrect password attempts. In addition, the company wants to be able to wipe a device remotely that’s reported as lost.

BlackBerry: the system administrators create a new security policy with those three rules, push the policy out to all the BlackBerry devices registered on the BES, and then restrict access to the network to only those devices which have the new policy in place. All the devices receive the new policy and implement it; any devices which have more lax security settings are barred from accessing the enterprise. When a user reports their BlackBerry as lost, the sysadmins push a command to the device to wipe its memory.

iPhone: the system administrators recognize that (as of current information) there’s no way to encrypt all the information on the device, and no way to force the device to initialize itself after a given number of incorrect password attempts, so they give up on those two. They then send an email to all known iPhone users pleading with them to set their auto-lock times appropriately, and they hope that the users read the email and follow the directions. And given that it’s unclear whether there are any mechanisms of access control for specific iPhones, they continue to hope that the rules are being followed. As for lost iPhones giving up their data, there’s nothing that would allow for remote erasing, so the company also hopes that there’s nothing sensitive on the device.

4. Finally, given that I’m a physician, something that’s relevant to my world: an organization exists in a world which mandates that all electronic communications about patient care are encrypted from end to end, and system administrators are tasked with making sure their wireless devices comply with this requirement.

BlackBerry: the system administrators install the S/MIME add-on and the enterprise security certificate chain on all enterprise BlackBerries. They then have the users install their personal secure email certificate in their chains, as well, and then users can query the enterprise directory for other users’ secure certs and can choose encryption as an option on the email composition screen.

iPhone: from the bits of news coverage and reviews I’ve found, there doesn’t seem to be any encrypted email support on the iPhone, so there’s nothing the organization can do. It’s unclear whether the phone’s mail client can require — or even support — users’ connections to an IMAP server over SSL, so in addition to the actual email, the communications channel over which that email travels might be totally unencrypted.

There are oodles more issues that could be brought up, but the gist of the matter is that no matter how much people in the enterprise crave being able to replace their BlackBerries with iPhones, the support for the devices working at the enterprise level isn’t there. And given Apple’s pretty awful track record when it comes to integrating their other products into the corporate environment, you’d be naive to think that a seamless iPhone experience in the enterprise is coming anytime soon.