Making a Home for Your Intranet, Part 4

By Paul Chin

Originally published in Intranet Journal (14-Jan-2003)

back back to portfolio

People become homeowners for different reasons. Some like the challenge of designing and constructing their own house. Others like to have the same level of autonomy and customization but decide to contract the actual labour to third parties. If you're just looking to find a nice, cozy place to put up your feet and relax, however, there's no reason to reinvent the wheel.

It may not be in your budget or your area of expertise to build something from scratch, and it's entirely possible that your needs can be met with something that's already on the market. With a little bit of legwork and research, you'll be able to find that place to call your own without having to lace up your steel-toed boots and donning a hardhat. After all, why spend a lot of time, money, and effort to construct a house that may very well already exist down the street?

In this, the fourth part of my series "A Home for You Intranet," I'll be discussing the process of selecting a purchased solution, or what's been dubbed an "intranet-in-a-box." Let's review some of the pros and cons of choosing to buy rather than build:

Advantages of buying a solution

Disadvantages of buying a solution

You need to realize that purchasing a house means you're getting someone else's idea of a home. It's been designed and constructed based on a stranger's requirements, not yours. In this respect, a purchased house may not meet your exact needs in every aspect, but this is why we have renovations. Nowhere does it say you have to keep that tacky wallpaper in the guest room or the faded green carpet that smells as though Rover has been a little too familiar with it.

There's no single solution out there that will meet your every need unless your intranet is to be a very simple one. Product selection is a give-and-take process; Solution A may meet Requirements 1, 2, and 4, but not 3, and Solution B may meet Requirements 1, 3, and 5, but not 2. What you're able to do with your intranet, like your house, is limited to the software solution's functionality. If it can't support one of your requirements, you'll have to either find a package that will, or bend your requirements. It's up to you to determine which requirements are vital and which are WIBNIs (Wouldn't It Be Nice If). You may have dreamed of waking up with the sun on your face but if your bedroom happens to face the west, there's nothing you can really do short of tearing down half the walls.

Now, as you go house hunting, keep these five points in mind:

  1. The cost of the solution
  2. The vendor's install-base and market placement
  3. Software technology
  4. Software functionality
  5. The learning curve

The Cost of the Solution

When buying a house, you have to factor in more than just the basic cost of the house. You also need to factor in any additional costs to get the house in a liveable state: repairs, painting, refurnishing and decorating.

Assuming that you already have the infrastructure—Web server(s), a security backbone, data integrity procedures—in place to support your solution, you will need to calculate the overall solution cost beyond the initial software purchase. Let's break out the calculator:

It's important that the solution you choose matches the scope of your project. Companies seeking to purchase software solutions often focus their attention on avoiding the pitfall of "under-buying", buying a package that does not meet all of their requirements. However, equally important is avoiding the pitfall of "over-buying," buying a package that does far more than what you could possibly need.

It's poor practice to believe that the software with the longest list of features (or worse, the one that's most expensive) will be right for your project. There's no reason to buy a software solution running into the thousands of dollars when you only plan to use a fraction of its functionality. This is especially the case if you intend to build a very small intranet to house simple documents rather than a full-scale, database-oriented site. Software manufacturers tend to pack a lot of unnecessary gadgets into their products to justify higher prices—so remember that bigger is not always better.

The Vendor's Install-Base and Market Placement

Software selection involves more than just reviewing the product itself, you need to know a bit about the software maker as well. A successful, proven software maker with a global presence in top Fortune 500 companies stands a far better chance at survival than a startup who's only been implemented in the "Mom and Pop" shops. This is not to say that the startup's product is no good, but if you you're looking to invest in a long-term solution, you need to increase your chances that the company who developed the software will be around to support it in future years.

Let's say, after a period of analysis and R&D, you decide to invest in ACME Inc.'s intranet-in-a-box. This product is based on the company's proprietary development environment and tightly integrated with its site management tool. A year after you roll your intranet into full production, ACME Inc. goes out of business. By then, you have tens of thousands of documents stored on your intranet, several dozen script-driven utilities created by wizards, and a search engine with a proprietary indexing algorithm; what do you do now? Do you continue to use this orphaned software or do you find some way to extract the whole site out of ACME's development environment?

There's always an inherent danger in maintaining a corporate system on defunct software. Why? Well, you're basically making a bed in a burning house. As the intranet grows bigger and bigger, it will become much more difficult to sever it from its dependencies on the proprietary software.

Admittedly, this is a highly subjective issue and there are no guarantees. Like gambling, selecting a software package requires a leap of faith, especially given the current IT climate. However, you can increase your chances of avoiding the dreaded orphaned software by selecting an established software maker with a wide install-base, thus giving you a much larger network of support.

Software Technology

Three rules:

And if time permits, avoid proprietary software.

Tepees, yurts, earthships, tree houses, wigwams — these are dwellings that are quite different from anything we're used to. Don't get me wrong, there's nothing wrong with any of them, but you should realize that once you move in, you're pretty much stuck with that structure unless you move out. Have you ever tried to change an igloo into a summer cottage?

Intranets are based on an open standard: the Web. Regardless, some manufacturers lock your intranet in their own development environments. They may provide you with click-and-drag restructuring, site mapping and validation, and a library of pre-written Web scripts, but if your intranet can't be moved and maintained outside of all this, you're taking your chances.

Any intranet built with an off-the-shelf solution must be maintainable outside of the development environment. You'll be fine as long as your entire intranet solution is based on the software maker's technology across the board. However, if there ever comes a time when you want to port your intranet to another system, you may be out of luck. Trying to get your intranet out of a locked development environment will be like trying to get a model ship out of a bottle. The bigger your intranet, the more difficult it will be to switch to another system.

Software Functionality

Everyone has a different view of what their home should be and what its look and feel will accomplish. No one really moves into a house without a certain amount of work. After cleaning the floors, repairing loose doorknobs, spackling holes in the walls, repainting all the rooms, and arranging your furniture, it finally begins to look like something you can live in. This is why homes need to be tweaked to fit your own needs and requirements.

Intranet software, right out of the box, only provides you with a template. These templates are based on common intranet models; you still need to fine-tune it to your project specifications, adding things such as interactive scripts, submission forms and database connectivity.

When you go through your software evaluation process make sure that you're basing your selection on what's required in your project specifications and don't be wowed by all the toys and gadgets that are usually thrown in to pad the software. I'd much rather have a package that does a few core things well than a package that does a lot of things poorly.

The Learning Curve

Any new software you buy will require some amount of training. Whether you decide to learn it yourself through manuals, self-experimentation, computer-based training, or face-to-face training depends on personal preference. Some are able to get an overall idea of how something works by playing around with it for a while; others need to learn it through a classroom environment.

Obviously, the more the package has to offer, the longer it will take to learn everything. The good news here, if you're not as technically inclined as an IT professional, is that software makers are now designing their products for the non-techies. Intranets-in-a-box are catering more to content providers rather than Web developers, so it's getting easier for those with limited technical backgrounds.

Time to Go House Hunting

If you're planning to go intranet shopping, remember to do your homework first. Don't buy something because it seemed to work for someone else; it needs to work for you. Check to see what's on the market, look up software reviews on the Internet, and download evaluation copies of the software.

Once you've compiled a short list of candidates, compare each package with one another using the five points I mentioned above. As you go through this process, always remember that you're buying what you need rather than what the software makers think you should want or what they're trying to sell you.

Copyright © 2003 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.