Giving Users What They Want

Reading David’s post on not being able to use his favorite apps at work, I thought, “It’s little wonder we have the term ‘IT Nazis.'”

That attitide in IT made sense when enterprise IT lead innovation over consumer IT. But, now consumer IT is where all the innovation happens, and has happened, for the past few years. This means that if you follow the old model — IT department driven IT instead of user-driven IT — you fall behind the times.

If only Google would charge for GMail and GCal, and thus be accountable when things go wrong, they’d be a viable option for enterprise messaging. Sure, it wouldn’t be a 1:1 mapping to the feature charts (from Exchange, Notes, etc.) that exist today — no shared folders — but that’s a huge part of the point: it’s just what you need.

And then with locked and enrypted access to thinks like PBWiki, information workers would have a quick and light-weight platform that was secure and didn’t require anything buy a montly paycheck.

It’s Not Really That Easy

There are several things missing from the above drool-fest:

Trust

As Steve noted, RedMonk would probably be using GMail and GCal if only we could pay for it. RedMonk has had such a troubled past with hosting providers, that we like to make sure there’s as much leverage for complaining and getting support as possible. Free services don’t offer warm and fuzzy feelings for that type of paranoia.

IdM

The main thing that’s missing from that big switch is identity management. For example, if you were using GMail, PBWiki, and any number of other public web apps to run your business, how would you easily revoke access when you fire an employee? Granted…without spending a lot of money, it’s just as hard behind-the-firewall as beyond it. But, at the very least, you can cut off the employees access to the network, making it much harder for them to use their behind-the-firewall accounts.

Data Control

Culturally, people still want complete control over their data. If they’re using an online wiki, they want a way to pull out the entire wiki instantly if needed. They don’t want their SaaS providers holding their data hostage: the freedom to leave.

ODF for Export

As a side note, I heard an intriguing suggestion recently: using ODF as the generic format for exports. I don’t know the ins and out os ODF as well I should, or as well as Steve, but apparently ODF can contain multipule “documents” of a variety of formats. That is, while ODF can represent a single document, it can also act as a container for multiple documents such as word processors, spreadsheets, presentations…and wiki pages.

If that’s true — and if ODF is simple enough — it seems like it’d be the obvious export format for most hosted sites, solving the “I want my data” problem.

The Synchronized Web

Desktop application are actually quite handy for many information applications. I put it that way, because I used to be a web-bigot: if it wasn’t a web only application, it seemed dumb to me. Once I got on OS X, I understood how well a desktop application could work. More importantly, when your desktop application is a front-end for the web (like ecto, my blog editor), things go better.

What most desktop applications lack now-a-days are features that are fully web-enabled, in a bi-directional sense. Take Apple’s iCal for example. It can suck down iCal calendars from GCal, but you can publish calendars up into GCal. Zimbra seems to be even more limited when it comes to iCal interaction (I downloaded the Zimbra syncer, but it didn’t install; I need to follow up on that; hopefully I’m being unfair, meaning, it’ll work for me).

Now, I can already hear what many people are saying with those two examples: something like, “actually, [iCal|Zimbra|my favorite app] has that ability built it, but so and so doesn’t work with it because they flipped the booty-bit and/or the whoopty-do.”

Exactly. I don’t really care why these things don’t work together. What’s more important to me is the fact that they don’t. Generalizing it, the reason IT departments go mono-platform with Exchange or Notes is because it all just works together without any excuses about whose booty-bit or whoopty-do is in the wrong place.

The point is this: all of the people who want to fill the space of enterprise messaging with consumer apps needs to get together and cooperate. Working with as many other applications, outside of your only silo, should become a bragging right, not an annoying feature on the backlog that’s always coming “next release.”

The thing is, that sort of interop is the primary competitive difference between the web-based consumer app world I’m talking about here and the enterprise world. The best way to achieve that interop is to write to standards. But, if that takes to long, simply working with other vendors is a good stop-gap while still hammering out the standard.

For Enterprise Tech

Reversing the attention stream a bit, all of this thinking, esp. the last part applies to current enterprise messaging people. From a user’s perspective, it’d be great if Exchange and Notes “just worked” with GMail, Yahoo! Mail, MSN, and their respective calendars.

In speaking with vendors on this topic, I often get the reply that they’re working on a standard for it. That’s great. But as either Steve or James recommended last time we had this discussion, why not just contact, for example, Google, and work on calendar interop right now? Sure, there are standards in development, but in the meantime, if you’re doing cross-silo scheduling, you have to use email.

Indeed, it seems like there’d be fewer better ways to practice emergent standards than that.

Disclaimer: Microsoft and IBM are clients.

Technorati Tags: google, calendaring, email, zimbra, ical, synchronizedweb, consumertech