Printer Friendly Version

I'm reminded of a week-long backpacking trip I took into the interior of British Columbia several years ago. There were four of us in the group, each carrying their fair share of the load. We split up our supplies so that no one single person carried all of any one particular item. Instead of one big first aid kit, we each carried smaller, individual kits; instead of one large stove fuel canister, we carried two smaller ones; instead of having one person carrying all the breakfasts, another the lunches, another the trail snacks, and another the dinners, we all carried equal portions of each. This way, if we lost a pack or (gulp) a person we would still have enough supplies between us to trek back to civilization — which may be days away.

This proved to be great foresight on our part when one of our members lost his footing during a dicey stream crossing and had to dump his gear for fear of being pulled into the water below by the weight of his pack. He was carrying one of our fuel canisters, and I packed the other one. Had he been carrying our only one, we would have been up that fabled creek without a paddle.

So there's something to be learned from that old clichéd warning about putting all our eggs into one basket: Try it and you'll become bear fodder.

System Availability

Every company has any number of IT applications and systems driving its operation; some play a minor supporting role, others are vital business tools that aid the decision making process. While the unavailability of certain applications may be little more than a minor inconvenience, applications such as e-mail and personal information managers (PIMs) leave a deeper cut in their absence. Then there are those systems we consider mission critical — those used by defense agencies, energy control facilities, medical institutions, and financial organizations — whose very absence, if even for a few hours, would bring about the fury of the Four Horsemen of the Apocalypse.

An intranet, due to the variety of its possible applications in business, can fall anywhere in this scope of system availability because the importance of uptime is directly related to an intranet's function, as well as how tightly integrated it is with corporate business processes. For example, if an intranet acts as a simple document repository — for documents that can also be found outside the system — then a few hours downtime might not negatively impact a company as much as, say, an intranet housing applications that tie directly into core databases required for daily operation. But again, this depends on an intranet's purpose within the company. To some organizations, an intranet's information itself is considered the mission critical system.

As much as we would like to have a 24/7 intranet, regardless of purpose, this is not always feasible. There are numerous situations, both planned and unplanned, that will affect the availability of your system as shown by the examples in the table below:

Planned Downtime	Unplanned Downtime
Scheduled, routine server maintenance Hardware and/or software upgrades Physical server re-location	System crash caused by hardware and/or software failure Database corruption System compromised by virus(es), malicious attacks, or careless misuse

With a little planning, you can maximize system uptime and overall intranet integrity by following these steps:

1. Design an intranet architecture in relation to the importance of system availability
2. Implement a thorough security infrastructure
3. Follow a regular maintenance schedule
4. Maintain consistent backups
5. Design a disaster recovery procedure.

Intranet Architecture

When users log onto a corporate intranet it will appear to them as though they're accessing one giant system. For all they know, everything they see on their intranet could be sitting inside a single monolithic server parked comfortably beside someone's desk in a far-off corner of the company and managed by a Gollum-like IT creature coddling his precious. And, perhaps, that's the way it should be because end-users probably have enough of their own problems to deal with, without having to try figuring out the inner workings of their intranet.

Intranet developers and systems administrators, on the other hand, need to consider an intranet as being composed of various individual components — network infrastructure, Web and application server(s), static content, databases. And all of these components must be available collectively at any given time in order to provide users with a functional whole, and managed behind-the-scenes in such a way as to appear completely transparent to the user community. That's a tall order.

So what type of architecture is right for your intranet? There are dozens of possibilities — from a single server to a whole array of servers. Where and how you house your various intranet components is dependent upon:

• The importance of intranet availability (Do you consider your intranet to be low, medium, or high priority, and what will be the impact of downtime on the user community?)

• Your current network infrastructure (Will your planned architecture fit into the existing corporate network infrastructure, and if not, how much massaging will be required?)

• Your existing, on-hand resources (Can you leverage current in-house resources by "buddying up" with existing servers?)

• How much you're willing to invest on new resources (How much additional equipment needs to be purchased to support your architecture, and are you willing to spend that much?)