The World Beyond the LAN: Collaboration and N > 1

Tom Tabor, CIO, Highmark: “So, what don’t we allow our employees to do? We do not allow access to any Web-based email, instant messaging or Wi-Fi access. We do not see material impact to our employees by restricting access to these. Additionally, we do not allow noncorporate [flash drives, cameras and other personal devices] to be accessed via USB ports on PCs, and only system administrators have the capability to install software on PCs.”

With customers like these, who needs the internet?

For a few years now, I’ve regularly hammered collaborative software vendors for their propensity to design as if it’s 1985 and Netware is all the rage. It’s become something of a hobby for me.

In a world where computing consists primarily of one local area network talking sporadically with another, the design assumption that users are likely to be working off the same instance of the same application is sound. Unfortunately for collaborative software designers, we haven’t lived in that world for a decade or more. This DARPA project came along and accidentally changed everything. Or so I’ve heard.

Unless, of course, you believe that Tabor’s Highmark is the rule rather than the exception. Which most collaboration vendors seem to, to judge by their application design. It’s 2007, after all, and I still have to exchange a half dozen emails to schedule a briefing (though help is on the way). On Exchange and want to coordinate with someone on Notes? Sorry, you’ll have to resort to the lowest common denominator: email. Yes, we know we’ve had 20 years to work on it, but we’ve been busy. And besides, if you come work where we work, inside our firewall, it’s smooth sailing.

Perhaps it’s just that big vendors, like so many of us, see the world through the lens of their own organization. I know Elias posted the following as a joke, but as he says, it’s at least half true:

IBM is so stinking huge that we don’t need to use dopplr. Just like everything else, our internal environment affords us the ability to deploy our own (or multiple) del.icio.us, blogger, facebook, linkedin, hot or not and even dopplr while still managing to create thriving communities, increase productivity, ROI, employee moral and sometimes as far as making a difference in people’s personal lives.

Take Dogear, the del.icio.us alternative contained with IBM’s Lotus Connections product, as an example. Social bookmarking is heavily, almost entirely, dependent on network effects, so in small or even medium sized businesses Dogear suffers greatly at the hands of a publically available tool such as del.icio.us simply by virtue of the limited volume. At IBM, though, with a couple of hundred thousand people to draw on? It’s far more palatable. I assume.

And yet I suspect there are still occasions when IBM’s internal Dogear users might wish that they were able to use the del.icio.us for: functionality to share with users not on their system.

This is not to single out IBM, however, because virtually every purveyor of collaborative enterprise technologies is guilty of this design assumption in some fashion. From Microsoft to Zimbra, the assumption that users that need to work together are already working together seems pervasive. Which is why collaborating is still an excruciating experience, for the most part.

What to do about this? Well, back in July, Joe Gregorio suggested that architects of data storage solutions rethink their underlying assumption that applications are “one box native.” His alternative pattern was that “any system that is scalable, fault-tolerant, and upgradable” be composed of “N nodes, where N > 1.”

My view is that designers of collaborative software should similarly rethink their architectures. More specifically, they should assume that collaborative interactions will feature N applications, where N > 1. That assumption alone would require significant changes in the way collaboration occurred, and that in turn might – gasp – spur some genuine innovation.

Much of the required interaction is theoretically accomplishable through existing standards such APP, Atom, iCal, ODF and so on, but doubtless there will be holes. Rather than fixate on these, however, as some are wont to do, lamenting the disparity between what can be accomplished between internal only use cases vs more mixed scenarios, it would behoove would be solution providers to remind themselves of an important, fundamental reality: users will find ways to collaborate with each other, one way or another.

While Tabor and those of his ilk are convinced that tools not authorized are tools absent from their enterprises, my own experience indicates that such opinions are largely aspirational. As I’ve related to a variety of audiences, several years ago I had the opportunity to speak with a variety of broker / dealer CIOs, IT managers and IT executives about their strategy relative to instant messaging technologies. Facing compliance requirements similar to Tabor’s healthcare business, compliant usage was a common concern. The most common answer? “We haven’t issued those technologies, so I don’t have to worry about that.” Those that had teenage children occasionally knew better, but the ignorance of how much of their business was being transacted over public IM networks was still astounding.

Control, as much as enterprises don’t like to hear it, is very often little more than a pipedream.

More to the point, the cost of control may far outweigh the benefit of freeing users to work more effectively with others in disparate geographies or systems.

To paraphrase Joe’s words, then, when one calls for patterns of collaboration needs of Web 2.0 applications, I would add N > 1 as a prerequisite, regardless of which application you start from.