ceronio.net

Where OCM has the edge over ECM

While sitting in a meeting today, my mind wandered (as it sometimes does during meetings) to the way people collaborate in an enterprise environment, and specifically on a project, as opposed to in the open source world. This week I play the role of the cynicist (I just Googled that word and I am not sure it is a real word; at least the spell checker does not recognize it).

OCM (Or Open Source Collaboration Model – an acronym I just made up for the purpose of this post), I realized, has a significant edge over ECM (the Enterprise Collaboration Model – another acronym I made up; yes, when your ego catches up with your age you can simply make up acronyms like they really exist).

Specifically, it’s like this: In an enterprise environment, say, like on a big project, collecting and preserving knowledge is a huge challenge. Big companies are burdened down by the regulations imposed by processes, policies, procedures and project methodologies. This dictates a highly structured way of documenting systems (oh yes, we are talking information systems here, sorry) that more often than not requires capturing information in specification documents where the templates were the result of many people’s contributions.

The result, sadly, is that mostly the documentation never really captures the essence of the systems they try to document, nor are they in a convenient format for future users to read, with the result that the next wave of maintainers will more than likely just try figure out what is going on by looking at the system, rather than  refer to the documentation. (Yes, there are expections, but honestly, how many times have you gone back and read the technical spec for the program you have to maintain or the documentation for the configuration you are about to change?)

That’s just one aspect of it. New team members on large projects are in the beginning often completely bewildered by the overflow of information. It takes them a while to settle in, sometimes weeks, before they feel their comfort levels are high enough that they are confident of actually being able to contribute.

The difference in the open source way of doing things, I believe, has largely to do with the fact that developers are often spread out geographically, seldom, if ever, speaking to each other directly. As a result of not speaking to each other directly, most information related to open source projects is captured in blogs, forums, wikis and other forms of persistent storage.

In a large company, valuable information goes lost because verbal discussions held in meetings or at the water cooler or over the phone disappear into thin air and is then lost, the results remaining only in the minds of the people who took part if they are not written down. Other valuable information is related through e-mail and is then limited to the persons who exchanged it.

I am a big believer in wikis. A wiki is a dynamic, growing body of knowledge. If you can convince members of a team to contribute, you can quickly build up a valuable information base that will serve newcomers as well as old-timers in their work. But I notice that the value of a wiki is very easily missed by minds focused on highly structured, templated and tabulated information, where, if information is not placed into a container that makes both entry and retrieval unpleasant and is not surrounded by many layers of bureaucracy, then it cannot be deemed good. Either that, or the thought that knowledge can be unstructured and subject to edit by anyone scares them to death. Such a pity.

So getting back to the point I was actually making: in the open source world, primarily, I believe, due to geographic separation requiring, often, offline exchange of information, that information is mostly persisted in systems that can be accessed again by newcomers. In a corporate environment, where there is the convenience of face-to-face exchange, and immediate discourse through means such as telephone or meetings, much information goes lost, leading to the large overhead of getting new members on the same page as everyone else.

Well, that is actually merely the point I wanted to make. I still think wikis are pretty neat though, and if I were in charge, I would make sure that there is a wiki for the whole project, and that, as part of their induction, newcomers are introduced to the wiki as the source of introductory information and a place to share. And not Microsoft Sharepoint wikis. No, that is too primitive. Something like MediaWiki is still the best choice, in my opinion.