Printer Friendly Version

Implement a Modular Intranet Structure

The most important feature an intranet needs to have in order to ensure the greatest level of flexibility and system longevity is a modular application and content structure—the ability for large pieces to be popped into place or extracted with minimal reworking.

Some intranets are so tightly integrated that the addition or removal of a component may cause the entire structure to fold like a house of cards. You're then forced to expend twice the amount of effort required for the updates because you will have to deal not only with the required modifications but also on building struts around your intranet to keep the other pieces in place.

Tacking on Band-Aids so that your intranet can accept changes its to original specs may work as a short-term solution but that's a rather myopic view. In the long-run, your Frankenstein's monster is going to lose that system integration you worked so hard to build, leaving you with a patchwork of fixes rather than improvements.

But no one ever said that you need to sacrifice system integration for a modular structure. You can still get the same level of integration when implementing a modular intranet, with the added advantage of being able to add or remove components without directly affecting the other pieces (see my article "Intranet Content Organization" for more on content structures).

Modular intranets promote system longevity — allowing you to adapt to future or unexpected changes—because individual components are fairly self-contained and, therefore, entire sections can be moved with relative ease (see the diagram below).

For example, there may come a time when your intranet server is no longer able to handle the increase of incoming traffic or the processing power required for large volume database searches. In this case, a modular intranet can be split up into multiple pieces and distributed among a cluster of servers that will share the workload.

Without a modular structure, your intranet will literally need to be dissected and put back together at different locations. This puts an unnecessary strain on resources that can be better spent on more productive matters.

Example of a simple, modular intranet structure.

Encourage Transfer of Knowledge

There are many people — from various departments, workgroups, and in some cases, satellite offices — involved in the development and maintenance of an intranet and its content. They bring their collective knowledge together to create a virtual community in which users can take advantage of a shared pool of information. But people come and go; they're taken off the project for other priorities, are transferred to a different group, or leave the company entirely.

But as is with the world, your intranet must go on with or without them—it's only a matter of how well. Besides, an intranet should never be so fragile as to allow any one person's departure to cause its downfall. What you need to do is to make sure that the gap left by any team member's departure can be filled by someone else—someone with enough knowledge of the system and the responsibilities associated with newly vacated position.

This can only occur when there's a cooperative sharing of information. All primary intranet team members must at the very least have a back-up person — an understudy able to pick up the responsibilities left by the predecessor with minimal training. You never want to be in a position where you have only one person with the know-how to maintain a particular piece of the intranet because, if they were to leave, they take all that knowledge with them.

Unfortunately, some employees may horde information, placing themselves among a clique of the "informationally privileged." And to make matters worse, the fire is fueled by a culture that rewards these individuals as being in-the-know when in fact they're in-the-know simply because they refuse to share their information with anyone else, not because they're any smarter.

Start Thinking About Tomorrow

Intranet developers and content owners should all get into the habit of thinking ahead so they can design what's needed tomorrow rather than what's needed right now. Unlike the implementation of static systems, where only the occasional fix or patch is required, intranets grow everyday and must adapt to constant changes in business environments and organizational structures.

Short-sighted planning to address immediate needs may result in the rollout of an obsolete system by the time it's completed; so a little foresight today will go a long way in preventing a lot of headaches tomorrow.