In case you didn’t get the memo, the consumer (as opposed to Enterprise IT) is Microsoft’s customer. They aim to delight their customers, and they absolutely delighted consumers with the iOS Outlook release. By tightly integrating mail, calendar, and contacts, and introducing some innovative inbox management, they have exposed the built-in iOS productivity apps for what they are: afterthoughts that slavishly adhere to design principles like functional containerization at the cost of user productivity and delight. The UE between phone, contacts, mail and calendar should be seamless. Sadly they are anything but seamless in iOS. Outlook for iOS shows us that it doesn’t need to be that way.
The launch of Outlook for iOS came 59 days after the acquisition of key technology from Acompli. If that’s not a record for Microsoft, it has to come close. Huge props to both Microsoft and the Acompli team for that accomplishment (see what I did there?). More importantly, it’s indicative of a massive cultural shift in Microsoft’s product management practices.
It didn’t come without cost though. There was a lot of pearl-clutching from security folks (and competitors). The crux of the issue held merit, but the shrillness of the backlash was pretty silly. There are a number of complaints. Most of them are not quite baseless, but have no impact on real world security. For example:
“Oh heavens! Users can put their email attachments in Dropbox! My stars!”
Anyone who thinks they can actually prevent users from getting their data where they want it to be is delusional. The best way to mitigate the behavior is to grant users the functionality they want using Enterprise File Sync and Share. There’s a ton of options out there, but I’m partial to one in particular – if your users find it necessary to leverage shadow IT, then it’s time to stop antagonizing them and look at your own practices, policies and technologies.
Credential management, on the other hand, has some merit. Apparently Outlook iOS (and Acompli before it) store your credentials in AWS, and scan the mailboxes directly from there. This is not cool – nobody would know that credentials are being sent off site unless they investigated it specifically, and it’s especially uncool that a product bearing the name of “Outlook” would use unconventional authentication methods.
That having been said, calling it a “breathtaking” issue resulting in broken company security is –ahem- overstating it. There’s no evidence that security has been compromised – only policy. Further, there’s undoubtedly good reason for this architecture. “Why not OAuth?” I asked myself. After all, it’s supported, and if apps like Lync and SharePoint can use OAuth to authenticate to Exchange – why not iOS Outlook? And cloud indexing doesn’t appear to be completely necessary for focused inbox functionality (at least on a per mailbox basis) – why not do that within Exchange?
Putting myself into the shoes of the Acompli team, I probably would have done the same thing. OAuth is only supported by Exchange 2013, and while they have a lot of resources at their disposal, I doubt that Microsoft has a time machine to go back and put it into older versions of Exchange, which probably (and unfortunately) represent the majority of the install base. This presents a dilemma for Microsoft. They can either delight their customers, or appease enterprise IT. Clearly they chose the former.
The shame of this is the kneejerk reaction to block the app – very sad to see, but it was entirely predictable. The target demographic (enterprise IT end users having difficulty managing their mail) are the ones most likely to be unable to use the app. I’m not sure what Microsoft could or should have done to prevent that reaction. I suppose you take the risk of running afoul of corporate IT as you pursue consumer-focused app development and extremely rapid release cycles.
It should also be noted that this would not be as big an obstacle if more IT shops maintained reasonable recent releases of Exchange. “If it’s not broken, don’t fix it” is a horrendously irresponsible attitude in IT today. It’s analogous to waiting until you have an accident to service the brakes on your car. It’s a major reason why Microsoft is gunning to get as many people onto their Office 365 SaaS platform as they can. If Enterprise IT shops considered themselves Microsoft’s partners in servicing (rather than controlling) the user, it would remove great amount of friction.
But Microsoft itself bears some responsibility for the slow adoption of new versions of Exchange in on-premises environments. Their preferred architecture does not mesh with enterprise IT strategy – its rigid, silo’d architecture and inability to efficiently scale down inhibits rapid adoption in large and small shops alike. It inhibits deployment of Exchange infrastructure as a service, and implicitly ties new version adoption to capital expenditure. One-off deployments and deliberate ignorance of commonly available QoS technology necessitate the use of arcane tools to validate architectures and unnecessarily delay time to value.
They’ve left it to partners to figure out how to automate the deployment of Exchange on modern private clouds, and by doing so has ceded control of the strategic direction. Simply publishing blueprints and automated deployment solutions for Exchange in virtualized environments would enable their on-prem partners to deploy more rapidly. If I can quickly and automatically deploy a highly available SharePoint farm on Azure, why in the world can’t I do the same with Exchange?