I personally don’t see the issue with multiple instances of Wikis. One central Wiki – integrated with a collaboration platform of blogs, document management etc. – is the optimum solution.

So your A and B points above I agree with. Often though it’s difficult to know how to collaborate. If I have a large collaboration platform with lots of options the paradox of choice can set in. Should I collaborate using online chat, via a blog and comments, via video e.g. Seesmic idea, should I use online documents, should I use the forums or should I use the wiki? The more options that are available the more daunting and difficult making a choice can become.

Businesses facing the problem of multiple installations of wikis from a variety of vendors can be resolved by rolling out a company wide wiki. However, businesses that want them to integrate with other communication vehicles, like blogs, will face the problem with point solutions again. Thus, rather than rollout a wiki, smart enterprises will look for a platform that incorporates wikis as one of the important collaboration tools.

My 2¢

Years ago I turned left at Kookamunga to find an alternative paradigm for un-structured data. I won’t sing my system’s praises here just now but will say this: nobody much cares. The few folk who are actually stressed by the difficulty of dealing with the tsunami of data (the intelligence analysis community comes to mind) are usually too hard-pressed to entertain the possibility of alternatives. And those who are intent on fun.fun.more.fun (alas, the majority … it’s about buzz and page-views, no?) really don’t care. I mean don’t care /operationally/.

When folk are enthralled by their knew hammer it’s hard to get them to think “wrench” … they just go merrily along, driving nails. (Painfully mixed metaphor in there somewhere?)

A. Wikis have helped fuel the appetite for collaboration solutions in the enterprise
B. Wikis alone don’t meet all of the collaboration needs of an enterprise

Wikis are wonderful tools that help us co-create content, which is why we include wiki-style documents as a part of our Clearspace collaboration platform. However, like @skyle refers to, when you scale beyond a team to an entire company, and that company is tens of thousands of people, there are vastly different requirements. And she’s right that there are a lot of companies who don’t see the solution in just a centralized wiki. Perhaps more interesting is the fact that we don’t run into IT leading this charge. It’s typically a C-level or VP-level leader, sometimes in HR, sometimes in the office of the CIO, but rarely is it lead by the IT department. That strongly supports that collaboration is a business problem with many requirements, one of which is technical.

And, @Tim, the telecom executive I spoke *wasn’t* clueless about how to deal with it. They understood the problem and why it happened to begin with, which is why they were looking for options to remove the pain that looked beyond a wiki to a collaboration platform.

There’s an entire side discussion of this post going on in Twitter. I agree with those who argue that wikis, like any other tool, require both technology and process for long-term adoption.

In some ways, the ease-of-use and flexibility of the wiki is both the reason for its rapid adoption as well as the the reason why so many IT folks feel like the situation has gotten out of control.

The fact is that most of us are not super-rigorous organizers (just look at our desks), and that the adhoc-racy of wikis exposes our changing minds.

On the other hand, this doesn’t mean that folks are going to stop using wikis…the forest of rogue wikis exists for a reason–people are using them. But it does mean that we’re going to have to start figuring out best practices for how to maintain, as well as create, our wikis.

Here at PBwiki, we recently set the norm that every month, each person would devote one hour of their time to cleaning up their portion of the company wiki and making it more useful and clearly organized. It’s been working wonders. And that’s just one simple rule.

I also believe that the future of wikis lies with being able to better integrate with structured and semi-structured data from other applications and systems.

Let wikis do what they do best–be easy and flexible. That makes them the perfect glue for holding together the other more rigid processes of the enterprise.

And furthermore (blatant sales pitch), there’s a reason why PBwiki offers enterprise upgrades–to let IT teams bring their forest of free PBwikis into a more harmonious and manageable whole.

“Out of control” as in “it’s time to reel them in!” and make sense of what has been a “trojan horse” (or as Sam puts it…the pink tasting spoon for enterprise social media) tools, harnessing their applicability in conjunction with what new offerings exist, while defining a strategy that works with current offerings.

I’ve heard lots of talk of “a centrally supported wiki”…but in a company with 10k plus people, that makes for a pretty big group to keep happy, not impossible, but a challenge. Especially if it means taking away the wiki they threw up for their specific group. IT usually want to get rid of all the little illegal wikis that sprouted up when the group solved their own collaboration challenges by building one.

As for the quote about IT–that’s in reference to the fear of change and control (IT) and the challenges to adopting collaboration tools. IT is often a barrier to the process of implementation and they certainly don’t like wikis and other tools run off a server under the desk, for example.

Ultimately, this is the reason IT is on board to get rid of them.

Not sure what you mean here, but every IT department I meet with wants to know how to transition from the widely dispersed collection of wikis that have sprouted up to a centrally supported wiki service that keeps all those groups happy while getting rid of the inadvertent silos created by the eagerness to use wikis. I’ve never come across an IT department that wants to know how to get rid of them (there may be some out there; it’s just that I hear from the ones that want to make wikis successful, not squash them).