There are all kinds of intranets. Good ones and bad ones. Intranets that are strictly communication vehicles with maybe a smattering of other content. Intranaets that are nothing more than static repositories of policies and handbooks. Others are mostly application-driven, loaded with tools like benefits enrollment, budget planning, expense reimbursement, and the like. Some are balkanized fiefdoms of departmental sites that have little relationship to one another. Many began as grassroots efforts that were later cobbled together into a sort of federation of sites. And some have been carefully planned as the hub of an employee’s workday.

Whatever shape they take, intranets are, at their core, the Internet captured behind the firewall. That definition embraced the suite of TCP/IP protocols, not just the http protocol that drives the web. It also allows the intranet to perform all manner of functions, from communication to collaboration, from streamlined online work processes to the archiving of static information in a hierarchical, navigable format. No single platform can contain all of the purposes a class-A intranet can fulfill.

I mention this because of a podcast I heard the other day. I was catching up on a backlog of podcasts and blasting through the always-worthwhile Blogspotting show from Stephen Baker, the BusinessWeek reporter who also co-authors the blog of the same name. One of the sessions featured an interview with SocialText CEO Ross Mayfield. It was a solid interview with some great information. Mayfield is a savvy guy and always worth listening to; I’m a regular reader of his blog. But I stopped short when Mayfield talked about one SocialText client who was so enamored of the wiki technology that they were in the process of converting their entire intranet to it. The suggestion was then made that all intranets could migrate to the wiki platform.

Tell it it IBM.

The notion of wiki-as-intranet is based on ease of publishing. It’s the same motivation that leads the folks at some blog software companies to claim an intranet could be reconfigured 100% on blogging software. Both suggestions come from the “selling hammers” school of business solutions: If you’re selling hammers, every problem looks like a nail. But intranets are more complex beasts that cannot be supported by either platform alone. At least, not if they’re good intranets. For example…

• Applications—I’ve maintained for years that few employees will visit an intranet just to read the company news. They’ll read the company news when they visit the intranet to do something work-related. On the best intranets, that includes streamlined work processes that have been webified. At a basic level, this includes interactive forms, calculators, data lookups, and the like. As noted earlier, benefits enrollment is a standard element of many intranets, and we’re not talking about just the form, but the ability to match healthcare providers to zip codes and a host of other functions. Expense reimbursement, performance evaluations, procurement, the job interview process, and a host of other work processes that have been moved online require some sophisticated programming.
• Portals—The move to a portal environment is based on the idea of “portlets,” little self-contained windows into which data of just about any type can be piped, whether it’s static HTML content or current sales figures streamed in live from a database. While many portal initiatives have failed, many companies have terrific portals that allow employees to tailor the content they see to their work needs. Given the average of a year and $1 million to implement a portal, I can’t see many companies sacrificing the benefits to move to a blog or wiki environment.
• Static content—Some static web content requires some serious thinking around its navigation. Consider employee benefits information. Wikifying or blogging this content makes no sense, since there should be some hierarchical navigation that includes multiple paths to the same content. For example, you should be able to view medical benefits as a category and navigate quickly to the benefit you’re interested in; you should also be able to view a “Life Events” listing and see links to all relevant benefits, which may include some medical benefits. It should be the same block of copy; nobody should have to alter content twice when a single benefit changes.
• Interactive content—I recently saw an intranet that contained a drop-dead fabulous marketplace section. Here, employees could interact with data using a variety of technologies (including a rare brilliant use of Flash) to learn about competitors, customers, the regulatory environment, and a variety of other aspects of the market in which the cmpany operates.

Undoubtedly, somebody will suggest that all these things can be done on a blog or wiki, but I would maintain that these aren’t the best ways to provide the content or applications in order to make the intranet as easy to navigate and use as possible from the employee’s perspective. Getting a portal onto a wiki, for example, is a sterling example of pounding a round peg into a square hole.

None of which means that blogs and wikis have no place on intranets. Much of what’s on intranets today can migrate to these platforms. But the effort should be strategic, identifying content that is best served by an underlying blog or wiki.