Back to the Intranet Future: Planning For Tomorrow

By Paul Chin

Originally published in Intranet Journal (25-Mar-2004)

back back to portfolio

A recent attempt at home renovation taught me a valuable lesson in foresight. While readying his home for sale, my friend and I spent countless hours sanding, painting, and covering up all the places his wife's little pug had marked its territory. The only thing that was left to be done was to wax the hardwood flooring in his former home office. It was a fairly small room so I convinced him that I would take care of it while he and his family go out and savor the warm weather.

A little more than 30 minutes later, the floor was shining like a new penny. I stood up to bask in my handiwork, the fresh smell of varnish making me more than a little giddy. Then my smile quickly turned to a frown. I looked at the blank wall behind me, to the floor beneath me, and then to the door—at the opposite end of the room.

"Rookie mistake," I thought to myself; I had waxed myself into a corner. After some very colorful expletives that made the neighbors cover their children's ears from my verbal onslaught, I managed to climb out through the window and execute a maneuver that can only be described as downright Spiderman-esque.

I blamed this lapse in judgment on the long hours and the paint fumes but I should have known better, I should have thought ahead instead of just hoping to get the job done quickly.

The Art of Intranet Forecasting

The system you build today may not be the system you end up with tomorrow. This is entirely normal since intranets are directly affected by changes in business requirements, shifting priorities, and organizational restructuring. Having nothing happen is the real symptom of a faltering system. If everything changes around an intranet and the intranet somehow stays the same, as though in a bubble, someone isn't doing their job.

Developers and content owners must follow the changes within their organization and adjust their intranet accordingly. In order to do this, your intranet must be flexible enough to accept these changes without requiring you to rebuild larges chunks of it. And this flexibility must be built into an intranet during system conception.

Intranet specs need to address issues that extend beyond the reach of your immediate requirements. What you think you don't need today may very well be a necessity a few months down the road. Aside from the obvious issues of technology — disk capacity, processor speed, network bandwidth — you also need to take into account organizational and business flux.

All of these things will affect the state of your intranet throughout its lifecycle. The only real issue is how much work will be required to make the necessary adjustments. To ensure that you don't end up developing yourself into a corner, you should always try to follow these rules:

Build an Extensible Infrastructure

I'm sure that many of us who grew up with an older sibling have less than fond memories of trotting off to school wearing clothes that were just a bit too big for us while our parents insisted, "you'll grow into them."

The memories of trying to run in shoes that felt as though they were more suited for some circus clown may have been buried deep within our subconscious, but we can now make use of these unwanted flashbacks to our advantage by applying the same principle to the implementation of our intranet infrastructure: it may seem like a lot for the intranet we have right now, but it will grow into it.

It's a fact of corporate life that we would try to do as much as possible for as little as possible. And as such, we are often tempted to save time, effort, and money by building only what's required to meet immediate needs. But departments and workgroups who were not part of initial planning may decide they would like to have a presence on the intranet, or remote branch offices may need access to the information on the corporate system via virtual private network (VPN). In a blink of an eye, disk capacity and bandwidth is maxed out.

This will lead to a reactionary mad-dash to boost the resources of an intranet that seems to be shrinking while requirements grow all around it. And soon the echoes of the sentiment "that should be enough for now" will ring in the heads of those tasked with implementing the upgrades.

You need to plan for the eventuality that your intranet will grow beyond your current infrastructure. This doesn't mean that you need to double up on everything, it just means that you should factor in ample wiggle room for future expansion.

The more adaptable your intranet is to the erratic changes in business requirements and priorities, the more likely it is to see the other side. Implementing a flexible intranet infrastructure should include addressing issues such as:

Use Industry Standard Technology

The longevity of your intranet depends not only on its content, but also the technology used to build and maintain that content. We have come to accept the fast-paced world of technology as a matter of fact and rarely stop long enough to consider the consequences that these changes have on our intranet.

With the speed in which technology—and the software vendors who support these technologies—changes, you may find yourself trying to support an intranet on defunct technology or using orphaned development tools from companies that are no longer in existence. This is why it's so important to use industry standard technology rather than proprietary technology.

Industry standard technology gives you a far greater advantage in:

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'll 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 to its 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.

Modular intranet structure

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.

Copyright © 2004 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.