Network Computingwww.networkcomputing.com

This applies to the technical architecture as well. It is often difficult for management and users to understand the decisions behind the selection of the technologies for which they are being asked to pay. So, now with due recognition to Covey and his many admirers, what about your site? What would you go back and redo given the chance?

From the Top Down Do your sites have a coordinated look and feel? If not, is it the designer's fault? Is there some basic guideline that is published for anyone developing pages on your network? You may want to consider a single site-wide navigation standard and predictable placement of graphical objects, font and style, use of headers, titles, bullets and lists. Here are a few other important matters to consider:

· Page behavior. Are dead-end links identified and cleaned up? If a long-running process is under way, is the user notified in a consistent manner?

· Content management. A site of any size must be managed. Authors cannot simply FTP HTML files to the server at will. There are several check-in/checkout version-control systems out there--use them. Restrict access to the site's directory tree. Realize that HTML files are documents like any others. If you have many documents and diverse authors, you will need to manage them all.

· Core business systems. Obviously, you want to do more than publish a list of interactive sites supporting core activities that may make or break your site. As such, they deserve special handling. My suggestion is, regardless of platform or whether the application is built or bought, you will want to encourage deployment of true distributed applications that are as platform-indep endent as possible and scalable. Also, the single biggest limiting factor for growth is human capital. It will remain so and will only get worse in the foreseeable future. If you didn't create a culture for software reuse when you were developing applications using client/server tools, don't you want to pause and reconsider as you deploy the intranet? If so, you should set a goal for component usage. That is, measure the percent of new applications that are assembled apps created out of predefined objects.

· Network. No site is static. Monitor all (or a reasonable sample of) servers. Daily peaks for page hits and page sizes should be identified and published. Check out the standard reports that come with most servers and use them. You can never have enough bandwidth or en ough reliability. And you will probably not have enough money to buy the infrastructure you need when you need it. Proactively provide networking requirements and negotiate aggressive service level agreements with your network group. To prevent overload, these trends need to be planned for, and planning takes monitoring.

· Servers. It's easy to plan for what's staring you in the face. There will be more Web servers, not fewer, in your network. And proliferation will be of benefit for some; a pain for others. The question is: How many more is too many? In particular, can the advocate establishing the site defend it with a reasonably coherent mission statement? Alternatively, can a tree within one of the larger sites suffice? Unless you maintain an open arms policy toward users wanting to establish their own sites, users will find ways to set up their own. And they'll still expect support.

Success is made up of equal parts of planning and execution, of strategy and tactics. Tomorrow, no one will ha ve time to create solutions to systems thrown together today. Take the time to step back and reassess the intranet you are building today for tomorrow.

Brian Walsh is a senior consultant with Cap Gemini America in Portland, Ore. He can be reached at bwalsh@nwc.com.