There’s no question: Wiki is officially a corporate buzzword… and as with most buzzwords, a lot of people will say they need one without understanding what makes a wiki a Wiki.
So… what makes a wiki a Wiki?
What ties all of this together is a change in viewpoint: a wiki is a tool… but it is also an ecosystem of collaborative and open knowledge sharing… and just like any ecosystem, if one piece of it is changed, the rest of it must also fundamentally change, or it will die.
For example, creating multiple wikis means that the automatic linking will cause people editing pages in one wiki to unintentionally create pages that duplicate or present different content from that in another, more authoritative wiki… so it fails because people cannot find what they’re looking for and feel like they’re doing duplicate work. Or, if there are “two versions of the truth”, people may make good decisions using the information they can see, and yet must do rework to solve the problems that misalignment created.
Simply put, SharePoint Does Wiki. Period. No question. And it’s pretty darned good at it. But it can’t protect you from the business decisions you may make which decrease the value of the functionality offered. SharePoint will do what you tell it to… for better or worse… and you have to understand the technical, political, and sociological impacts that come with that decision.
IMPORTANT NOTE: In the SharePoint 2010 product, the “Collaboration Portal” template has been removed. This was the “biggest bang for the buck” starting point for an intranet-style deployment… but it was complex to brand and sometimes facilitated some not-so-great decision making. In 2010, the best option is the “Publishing Portal” template, which is easier to brand (as is the purpose of all publishing portals), and you can relatively easily build in all of the functionality that was previously available in the collaboration portal. What I would NOT recommend (and was the driver for this post) is the use of the “Enterprise Wiki” for an intranet homepage. The needs of the intranet are generally not a wiki… but fairly controlled presentation, approval processes, separation of roles, ease of content creation, page layouts, etc… these are not wiki elements… they’re web content management elements… and the two should not be confused. It would, however, be perfectly plausible to create an Enterprise Wiki at the root of the portal that anyone can edit together… and this is a strategy I would strongly support. :)
Aren't wikis more of a tree, both with regard to content and permissions? I don't get the "wikis are flat" thing.
When you interact with a wiki, it might feel like a tree... where the page you're looking at is a "branch" and the links take you down other "branches". However, physically, every page in a single wiki is created in the exact same folder at the exact same level... they are peers of each other. They may link back and forth every which way, but they are all lumped together... there are no sub-wikis or folders within a wiki... and if you try to create these things, you literally break the wiki.
For permissions, it may be possible to have distinct permissions on each wiki page, and this may not directly break the wiki... but it does violate the wiki ecosystem... especially if I can't see that a page exists. I may create a wiki link to a page (by putting it in [[double-brackets]] ) and then when I click the link, the system will attempt to create the page... but will fail because the page exists. I know of systems that get around this by creating distinct pages... so I can have multiple pages all discussing the same topic... but that then breaks the "one view of the truth"... and therefore breaks the wiki ecosystem also.
Have you used TechNet Wiki? We had already launched it when you wrote this.