Friday, December 14, 2007

Tis the season to be sharing (knowledge, that is)

By way of Ed Brill's blog, I stumbled upon this from David Gurteen, entitled "Don't let the IT Departments stifle Social Computing as they did Lotus Notes!"Gurteen's premise is that "it was the IT dempartments that effectively stifled Lotus Notes," and warns of the same fate overtaking social networking (wikis and blogs).

Just click through and read it... otherwise the following commentary won't make much sense to you. The "executive summary" is that Notes was quashed due to management for what amounts to control issues, and fears of anarchy in the datacenter and warns against the same fate for other collaborative systems (that's my characterization of it).

He pretty much nails it. The only two things I think Gurteen missed (and that ever so slightly) is 1) that "Notes" is stifled (in some companies it is, but with the latest release that may change, and there's a strong core following), and 2) laying the blame on "IT departments". I'd narrow that down a little to "IT management", and by that I mean at the executive level. Developers and project managers such as myself would have loved to deploy and support Notes in the way it was intended; that being in a way that allows people to use the templates they're given; to create TeamRooms or document stores at need to enable sharing among users, not hinder it. One way I advocate of doing that is to have your corporate apps with the standard development process, sure; but also allow a Domino server with space allocated and proper access rights granted to select departments to allow them to use it creatively and on an ad hoc basis. Need to manage a project? Create a TeamRoom. It takes about 10 minutes, tops, and there's no need for IT to be involved. Then you've got document sharing, a forum, team calendar, etc., all web enabled and with proper security.

As you should've read by now, Gurteen's comments are based on a blog post by Lee Bryant regarding inflexible systems and the incentive for insecure workarounds that they inadvertently promote.

It's a message that does hit home with me. I developed VIC CRM initially under contract to another company, but acquired the copyright and continued development because it was something that I found use for. In designing it I took to heart lessons from Augmenting the Human Intellect, a landmark paper by Douglas C. Englebart (upon which I commented extensively in the July 08, 2007 entry of this blog). It also answers one of the questions that I'm frequently asked about VIC. Unlike many shared systems, VIC CRM doesn't maintain a sales hierarchy or enforce access to specific documents out of the box. Neither does it allow you to mark a document as "Private". The question is, "Why?"

Let me start off by saying that like all Lotus Notes applications, VIC's security is managed through the use of an access control list (ACL) that is integral to the application. So it's secure from outside intrusion as you care to have it. But VIC's primary purpose.... it's
raison d'exister ... is to freely share information among your team members. And what I've found for my situation is that the kinds of document level controls generally placed in the sort of apps that compete in this marketspace are at fundamental odds with the purpose of the program.

What I've generally found for other people is that you cannot reliably predict the controls that they will need in their organization. For example, out of the several OverQuota (Relavis eSales) implementations that I've either implemented or maintained, exactly none of them use the sales hierarchies that Relavis designed into the product. In every case this feature is either ignored, disabled, or modified... and that's even though the product allows a level of customization through configuration! In no event has that been sufficient for my clients... and I'm talking about organizations that range from under ten to several hundred users; from a single office to multinational corporations. Don't get the idea that I'm picking on Relavis: this is incredibly complex software to create, and theirs is robust. I'm simply illustrating why I didn't go down that road.

It's not because it's difficult (document-level security is a relatively uncomplicated modification). It's because it's a waste of time to provide something that I don't need and you're never going to use. But more than that, it's because I'm creating software for a purpose, and the purpose is not to generate revenue for my shareholders via the product itself. I certainly don't worry whether the product meets some IT executive's perception of necessary, which -- often as not -- is based less on actual need than on how completely the product fills in some some magazine's feature matrix.

Steering back to topic a bit; VIC can be secured with ACLs and database encryption, both features are built into Notes. For my needs, I've found no need to complicate the product beyond that. As Lee observes:
The same IT folks who rail about the "risks" of sharing and online social networking are also responsible for creating systems so unusable and inflexible that they lead users to dump entire databases onto CD and lose them. I think it is fair to argue that IT systems that do no understand people are a bigger risk than human-scale web computing that treats people as adults.
There's value in simply documenting work for your own recollection, but when you're sick or on holiday how can the rest of your organization handle your customers in an informed way? What about when you're promoted, or you bring on new team members and want to disburse the work? How do you get these people up to speed? That's the real value of VIC CRM. Knowledge is power for the giver as well as the receiver. Sharing information frees you from being chained to your workplace (or worse, to your position! I know exactly what it's like for the many people who have been stuck in a job because they were "indispensible.") But to reap the benefits you have to be willing to share.


Post a Comment

<< Home