The great advantage of semantic web over efforts such as the now defunct Application Lifecycle Framework (ALF) is that it requires no agreement between vendors (beyond using semantic web technology). The weakness of efforts such as ALF is always that they demand buy-in from the main tool vendors. A substantial number need to agree to develop and support the new standard.

Certainly semantic web is no panacea, but at least if Vendor A chooses one semantic representation of CM information and Vendor B chooses another they can still communicate by creating a correspondence rule set between the two representations (a little like XSLT can transform one XML into another — only a little though, semantic web has much more to offer).

So vendors need to agree to use and provide semantic web representations for CM information? No, not really. Most tools provide APIs that would allow this information to be interpreted from, or added to, any existing tool. Certainly a non-trivial effort, but one that is at least feasible. Better still, if multiple implementations are created for any tool these can again be consolidated using semantic web techniques.

The real power of semantic web technology comes from two sources; the abstraction of information semantics, and the ability to draw inferences from this information. Once you have an ontology, some inference rules and semantic relationships between ontologies, your inference rules will work across ontologies — neat. What does all the gobbledy-gook mean? It means that if Vendor A develops an ontology with a set of inference rules (rules for extracting more information from the underlying information) then Vendor B can map their ontology onto Vendor A’s and use Vendor A’s inference rules too. Actually it’s even better. User X can extend the rules and have them apply to Vendor A and/or Vendor B’s information sets equally, even if the original inference rules were designed for only Vendor A.

Brilliant. Problem solved then? Sadly, no. Although this all offers promise of a way forward there remains a lot of work to establish these semantic descriptions and, as many have discovered before, agreeing on the precise meaning of each semantic element is nontrivial in its own right. Not that this should stop us attempting the task.

Received wisdom among many development team with whom I have worked over the years is that a development wiki is a good idea. Experience suggests that this is not a universal truth and on some projects the wiki may actually be harmful.

The main benefit, and problem, with Wikis is that they are maintained by technicians who are expert in their field but not necessarily good at presenting written information. Most wikis are opened when the project is young and these technical people find they have time on their hands before the heavy lifting on the project starts. Creating a wiki seems like a useful way to employ their time until the project proper kicks off. As the project progresses the wiki is maintained less and less as these technicians become increasingly involved in the project and have less time to maintain the content of the wiki.

Failing to maintain a wiki is worse than not having one in the first place. If the information cannot be relied upon then this devalues the wiki and people will tend to be distrustful of anything on it. This in turn means people are increasingly unwilling to update the wiki because no one wants to spend time maintaining something that is not used.

When wikis work, they work well. Providing a useful communication channel for project information.

Wikis work well when:

• Contributors are all, at least, competent at communicating through writing. (We don’t need Tolstoy, just clear concise writing.)
• The project experts have time to both create and maintain the wiki content.
• Someone is assigned to ensure that key project information on the wiki is always available and accurate.

Wikis won’t work when:

• They are nothing more than a collection of notes.
• They are not maintained.
• They are not clear and concise.

Should you use a wiki on your next project. Definitely, providing you realise that it takes some effort to maintain it as a useful tool.