for W3c validation

This article was originally published in the May/June 2009 edition of Image & Data Manager magazine.

Archimedes famously told us that with a long enough lever and fulcrum to rest it on, he could move the world. The story of designing next generation intranets that are based on social computing principles, what some call, “intranet 2.0”, is also locked in a similar paradox: in theory just about any Web-based collaboration or information sharing tool has the potential to be a social computing platform, if only we have enough time and budget for its development.

Microsoft SharePoint is a great case in point. Massively successful, the free version of the SharePoint 2007 family, known as Windows SharePoint Services 3.0 (WSS), has slipped into organisations and has found itself embraced by users and IT departments alike. In many organisations, SharePoint may have been the first collaboration solution they had experienced as an improvement to networked file shares and email.

However, Wikis have also grabbed the attention of many organisations. Despite being a decade old technology, it was against the background of the Web 2.0 that Wikis finally appeared on the corporate radar. They offered a revolutionary “every page is editable” alternative to expensive or rigid Web and document management systems. And just like Windows SharePoint Services, there are many ‘free’ wiki software options available as open source.

More recently, Wikis have evolved beyond the core “every page is editable” concept to include other social computing features such as social networking, tagging, mashups, discussion forums, blogging, activity streams and even microblogging. In this respect, some wiki solutions can now defined more as social computing platforms and less narrowly as lightweight Web content management systems (WCMS).

SharePoint as a social computing platform

You might be surprised to hear me question SharePoint’s capabilities when we consider that many of the foundational features in Windows SharePoint Services are intended to support collaboration. Office SharePoint Server 2007 also provides users with My Sites, which supports social networking. But while there is no doubt many organisations are happy with SharePoint’s collaboration capabilities, when it comes to enterprise social computing that level of satisfaction depends very much on how you define collaboration.

For example, ‘conversational collaboration’ is a relatively new phrase to enter the lexicon, but it is reflective of the increased awareness by collaboration specialists that there are in fact many different styles of collaboration – some of which revolve around ‘documents’, while others are more social and revolve around people networks, activity and communication.

In the case of SharePoint, the style of collaboration it supports out of the box is very much a product of its ancestry. SharePoint has evolved through the combination of different products into the platform we know today as SharePoint 2007. In particular, its origins in SharePoint Team Services and SharePoint Portal Server 2001 mean that it was originally architected to be a user-driven environment for document-centric collaboration by ad hoc groups of users.

This is still very evident in the current version of SharePoint. Sites can be created that the system administrator can delegate control over to a group of users without compromising the overall security of the whole SharePoint system. For this to work, SharePoint uses a site collection and site hierarchy model that creates self-contained sites and often further sites within sites. Functionality like blogs, wikis and discussion forums is then available to be deployed within individual sites.

While this is a strength in terms of supporting a user-driven collaborative pattern for teams, experience now tells us that left uncontrolled SharePoint can go wild. This ends up creating both new information silos and a management nightmare for the IT departments.

A critical success factor in large or complex SharePoint implementations is now generally accepted to involve strong system governance that includes templated sites, centralised meta-data and strict controls over what users can actually modify in their site design. Unfortunately, these sensible SharePoint management controls run counter to the emergent spirit of real social computing.

The modular fashion in which blogging, wiki and discussion forum functionality is provided in the hierarchical site framework also tends to fragment conversations and relationships between different types content. Just as file attachments live in document libraries, each wiki page, blog post or discussion thread also lives in its own particular folder type. This again reflects SharePoints’ document-centric architecture.

And while its true that My Sites provides a social networking layer for SharePoint, this does not fundamentally change its underlying anti-social document-centric nature.

Designed for social computing

The first wiki appeared in 1995, well before Tim O’Reilly imagined ‘Web 2.0’ or Clay Shirky coined the term ‘social software’. However, with some justification we can claim that the wiki concept actually helped to define and create the model for social computing*.

More recent interpretations of the wiki concept have taken this model and refined these features, for example rich text editing and adding fine grained security features, or integrated other social computing concepts like blogging, discussion forums, tagging, social bookmarking, social networking, mash ups and microblogging. In some cases, the wiki has matured into what might be better called a social software suite. But fundamentally, even when we add new features, a wiki is engineered to support social computing from the ground up.

Of course, before we get carried away, not every wiki solution is equal either – for example the online wiki comparison site, http://www.wikimatrix.org, lists over 100 different wiki products broken down by different licensing models, technical specifications and functional capabilities.

While we can depend on Microsoft products like SharePoint to work in Microsoft-based environments and take into account enterprise computing requirements, the same does not apply to wikis.

For example, Mediawiki is a popular open source wiki but reflecting its origins and its intent as what we might consider to be pure wiki, it currently lacks a native rich text editor (although they are working towards one) and even the creators will tell you to look elsewhere if you need fine grained access control. Mediawiki also needs an open source database back end to go with it, where as there are other wiki solutions that will work with commercial database products.

The commercial version of the Social Text takes an alternative approach – while Social Text runs on open source technology (e.g. Linux), it is delivered either as hosted solution or a fully managed hardware appliance. Unlike MediaWiki, out of the box Social Text provides support for widgetised dashboards (based on the Google OpenSocial standard), tagging, social networking, activity streams and blogging. Social Text have also been particularly innovative with introducing integrated spreadsheets and microblogging to their wiki (including a desktop microblogging and activity stream client).

Atlassian Confluence on the other hand runs on J2EE and works with commercial databases like Oracle, DB2 and Microsoft SQL server. It is highly customisable and where functionality is missing, it can be extended through plugins that are managed from with the administrators console. Confluence
also supports tagging, blogging and activity streams and social networking. Users can also access powerful macros to customise or add in-page functions like calendars, special formatting and other actions.

Picking the right wiki software is not necessarily difficult, as the options for an enterprise deployment can be narrowed down quickly. However, it is important that the wiki software selected supports the social computing functions you intend to use it and that it can be customised easily for those requirements without breaking functionality.

Customisation is still important

One misconception about wiki software is that you are stuck with the basic layout and raw look and feel that comes with it out of the box. However, the vast majority of wiki software allow some form of customisation to style, layout and navigation, although to a lesser or greater degree depending on the particular product.

While such customisations might be considered to be purely cosmetic and therefore unnecessary, in fact the need to tailor a wiki for an organisation is probably more important than when designing a traditional static intranet site.

Not only do these customisations help to reflect key organisational messages (e.g. branding), but more critically they help to provide ‘scaffolding’ for information and collaboration where users can work. Without them, an out of the box wiki is effectively a blank sheet – people have no idea about what they should be doing in it or where to start.

Tip: If this sound like over engineering the wiki-approach, the overhead and risk of tailoring a wiki is far less that trying to do the same with SharePoint because the underlying social computing functionality and socially-orientated information architecture already exists. Also, once you have established this ‘scaffolding’ you can move quickly to deploy your wiki and work directly with users to finalise the Wiki’s structure. You can read about some read some real life Wiki-customisation case studies in Ripple Effect Group’s project files.

And the winner is…

By now it should be clear that if you pick the right wiki platform, it is by far the superior option for building “intranet 2.0” solutions. It is important to realise that such a wiki is a better choice over SharePoint not just because of the functionality it provides, but because its native social computing architecture lends itself to an customised implementation that can be achieved quickly, more effectively and at less cost.

However to be fair to SharePoint, while its document-centric collaboration capabilities for teams may have opened the door for it into many organisations, it is often chosen for its broader portal capabilities that support transactional business needs like document and records management, business process management and business intelligence.

This may mean that SharePoint is going to be part of your organisation’s information system whether you like it or not. If this is the case, then you are faced with a much harder choice. Either begin down the road of customising SharePoint or allow a wiki to stand side by side with SharePoint. In fact, this is an option where ever a legacy Web-based application or specialised Web-based information management tool exists (like a document management system).

Considering enterprise wiki vendors like Confluence and Social Text are partnered with Microsoft and provide SharePoint connectors, is deploying a wiki along side SharePoint such a crazy idea after all?

*In its purest form, a wiki reflects a collaborative pattern that is: Focused on efficiency and ease of use; Encourages contribution of user generated content and permits the information architecture to evolve overtime through this participation; Maintains content quality and integrity through social, rather than systemic controls; and Manages content in a way that is Web page-centric (and not document-centric).